mmazur.7thguard.net

Moje największe informatyczne wpadki

Tue, 10 Feb 2009 02:43:58 +0100

Zainspirowane tym wpisem.

1. Pisząc wiele lat temu automatykę ftp-ową do pld, wstawiłem tam demona lockującego (o, to). Fakt, oryginalnie miał robić też kilka innych rzeczy, ale w praktyce nigdy tego nie zakodowałem, więc zamiast paru prostych flocków jest osobny proces i gadanie z nim po unix sockecie.

2. Używanie lokalnych mysql-i jako miejsca do logowania danych, by je później zasysać na centralnego mysql-a i tam obrabiać. I to wszystko na kilkudziesięciu maszynach. W praktyce był to bardzo czasochłonny w maintainowaniu i podatny na błędy koszmarek, który na szczęście nie jest już w użyciu. (Przy padach maszyn bazy się psuły, trza je było ręcznie naprawiać, a update schematu bazy na parudziesięciu maszynach był... upierdliwy.) Serio, już lepiej pisać do pliku, jeśli się nie korzysta z jakiś dedykowanych rozwiązań dla systemów rozproszonych (hadoopy, czy coś).

3. linux-libc-headers. Eh. Przez sporo releasy kerneli 2.6.x upgrejdowałem parędziesiąt mega nagłówków (katalog "include" ze źródeł linuksa) ręcznie przy pomocy diffa i patcha. Tak, jestem skończonym idiotą. Obecnie z umiejętnością używania rzeczy typu mercurial (czy też po przeszkoleniu się w gicie) maintainowanie czegoś takiego byłoby pewnie o rząd wielkości łatwiejsze. Chooooociaż. To były czasy 2.6.0, rok 2003, git nie powstał jeszcze przez półtora roku. Ha! Nie jestem idiotą, tylko prawdziwym twardzielem! (Właśnie sobie uświadomiłem, że grzebałem w zdecydowanie fajniejszych rzeczach, jak byłem nastolatkiem :(

4. Backupy. Udało mi się w jednej firmie już kilka razy odtwarzać/odzyskiwać dane, bo ktoś/ja nie dopilnował, ale ewidentnie uczę się bardzo powoli, gdyż w chwili obecnej jestem odpowiedzialny za co najmniej kilka systemów, którym od dawna mam dorobić sensowny backup, a które, jeśli umrą, to spowodują, że będę miał bardzo przekichane. I nie tylko ja. Ale już niedługo wszystko będzie backupowane. Serio serio. (Dzisiaj miałem badblocka na laptopie i tak się przeraziłem, że szybko zapuściłem mój autobackup. Okazało się, że poprzedni był we wrześniu...)

5. Programistyczny mainstream. W javie zdarzało mi się dłubać, bo musiałem coś zmodyfikować, ale nigdy nie potrafiłbym sam napisać całego programu. C++ poznałem za gówniarza w stopniu podstawowym i nigdy tej wiedzy nie pogłębiłem (nigdy się na przykład nie nauczyłem tej debilnej składni ichnich templejtów). Ostatnie IDE, jakiego używałem z własnej woli (studia pomijam), to były jakieś MS Visual C++ za czasów Windowsowych, czyli przed 2002. Miałem wtedy 14-16 lat. C znam dobrze (sporo grzebałem; eskpertem nie jestem), pythona wystarczająco (cały czas używam, ale gigantycznych systemów nie pisałem). Czyli jak patrzę na ogłoszenia o pracę, to właściwie nie mam w nich czego szukać.

6. Windows. Chcielibyście zatrudnić administratora, który musi się chwilę w głowę podrapać, żeby znaleźć panel administracyjny, bo fizycznie Windowsy ogląda raz na pół roku przez pięć minut? No właśnie. Powinienem był się bardziej zdywersyfikować. Że dywersantem zostać.

Więcej grzechów nie pamiętam. Jeśli sobie jeszcze kilka przypomnę, to wrzucę drugą część tego wpisu.

Oczywiście liczę na rozpoczęcie łańcuszka. Jeśli namówisz dwóch innych blogerów na opublikowanie listy takiej, jak powyższa, to spotka cię wielka miłość/fiskus zabierze ci trochę mniej wypłaty (niepotrzebne skreślić). Serio serio.

Multidistro mega howto

Sun, 16 Nov 2008 01:58:58 +0100

Vide poprzedni wpis -- zna ktoś jakąś stroną z krótkimi opisami wykonywania różnych operacji pod różnymi distrami, czy mam sam zakładać? Znam rpm -qa, umiem obsługiwać poldka i chciałbym prostą stronę, z której dowiem się jak podobne rzeczy osiągnąć emergem, albo getując apta. Plus bardzo przydatne byłyby szybkie kursy budowania paczek, wytłumaczenie struktury deweloperskiej, rozkładu katalogów na ftp-ie, etc, etc. Taki data mine dla zaawansowanych adminów. Anyone?

Na ringu zostały: mercurial i git

Sun, 24 Aug 2008 19:34:11 +0200

Distributed VCS-y są fajne, od paru lat w pracy używałem darcs-a. Problem z darcsem jest taki, że (a) ma w cholerę bugów i (b) praktycznie rzecz biorąc jest martwy. Czas na alternatywy.

Ostatnio bawię się bazaarem m.in. dlatego, że PLD przeszło na launchpad.net z którym bazaar jest domyślnie zintegrowany, więc gdyby kiedyś mi się nudziło i przerzuciłbym PLD-owego CVS-a do bazaara, to od razu mielibyśmy integrację z bugtrackerem. Poza tym bazaar jest dosyć intuicyjny, Shuttleworth przekonująco pisze, a całość jest w Pythonie.

Problem: nie odpowiada on mojemu trybowi pracy.

Darcs ma dwie wielkie zalety:

1. Polecenie do robienia commitów jest domyślnie interaktywne, tzn. pyta się czy zapisać każdą jedną zmianę w każdym pliku. Brzmi wkurzająco, ale, po pierwsze, wystarczy nacisnąć 'a' (all) i z głowy, a po drugie oznacza to, że mogę, mając kompletnie rozgrzebany plik z kodem, zauważyć, że właśnie stworzyłem self-contained zmianę i sobie ją commitnąć niezależnie od całej reszty śmiecia w pliku. Jest to bardzo naturalny sposób pracy, bo, zwłaszcza przy większych zmianach, dopiero w trakcie ich tworzenia zauważam wyodrębniające się niezależne, eee, ciągi funkcjonalne (?). Afaik inne VCS-y zaadoptowały to w postaci trybu "interactive" (bazaar przez plugin, hg chyba domyślnie w kodzie, nie wiem jak git).

2. Darcs nie ma rewizji, dla niego rezpozytorium to tak naprawdę zbiór patchy. Oznacza to, że (a) komenda rebase (w bazaarze jak zwykle w postaci pluginu, w hg nie mam pojęcia, czy w ogóle jest, a git ma domyślnie) jest kompletnie bez sensu, bo mogę sobie pullnąć patche z czegokolwiek na cokolwiek, ważne, żeby się nakładały i (b) mogę utrzymywać kilka wersji dokładnie tego samego drzewa, różniących się tylko i wyłącznie jednym patchem.

Punkt pierwszy to nie problem, punkt drugi i owszem. Wynikają z niego dwa różne workflowy:

1. Surwiwal fitnessu (survival of the fittest). System ma robić X. Nie mam pojęcia jaki jest najlepszy sposób na zrobienie X, więc robię kilka możliwych implementacji, po czym odpalam je na różnych maszynach. I dalej wprowadzam równoległe zmiany sprawdzając, jak różne wersje na nie zareagują. W darcsie jest to proste, wystarczy, żebym w pewnym momencie do jednego drzewka wprowadził patch XX, a do drugiego XY i pullując nowe zmiany z drzewka A do B lub vice versa, pamiętał o niepullowaniu tych konkretnych patchy. I mogę sobie tak rozwijać równoległe wersje tego samego programu praktycznie w nieskończoność, zachowując owe różniące je patche. O ile wiem w bazaarze w ogóle tak się nie da, nie wiem jak w hg i gicie.

2. Odgałęzianie się od ruchomego pnia (dla twardzieli: odbranchowywanie się od movowalnego trunka). Sprowadza się do tego, że mam gotowy kawałek softu, który jest rozwijany niezależnie ode mnie przez upstream i ja mam na ów soft nałożyć własne poprawki, sporadycznie mergując się z upstreamem. W darcsie nie problem, mogę pullować dowolne patche skądkolwiek dokądkolwiek, w pozostałych natomiast potrzebny jest rebase. Jak pisałem: bzr i git to mają, nie wiem jak hg.

Pierwszy tryb rozwoju softu jest dosyć specyficzny dla mojej pracy, drugi natomiast, co uświadomiłem sobie dosyć niedawno, wcale nie (acz też obecny). radioemiter.pl i pld-users.org to dokuwiki, www.pld-linux.org to MoinMoin, forum.pld-linux.org to bodajże phpbb (acz nie stawiane przeze mnie). I gdybym wtedy wiedział to, co wiem teraz, to wszystkie one od razu lądowałyby w jakimś VCS-ie. Bardzo ładnie ten problem wyszedł z pld-users, gdzie jeden z adminów zupgrejdował do nowszej wersji dokuwiki i wszystkie moje site-specific zmiany poszły do /dev/null. I żeby je teraz odzyskać będę się musiał z jakimiś patchami i diffami bawić (zakładając, że gdzieś się zachowała stara wersja). A tak, to jeden rebase i po paru minutach miałbym z głowy.

I właśnie dlatego nowy 7thguard, stawiany na drupalu, będzie od początku czymś wersjonowany.

Przy czym nie samym rebasem człowiek żyje. Można powiedzieć, że na co mi rebase -- ściągam najnowszą wersję upstreama, diffuję względem wersji od której się odbranchowałem, po czym próbuję nałożyć takiego patcha na swój kod z commitlogiem "upgrade to upstream X.Y.Z". Prawda, rzecz w tym, że w wypadku tego typu workflowu bardzo liczy się przejrzystość commitlogów, gdyż po paru latach pogubię się w tym, co tam właściwie jest zrobione względem oryginału, a już tym bardziej będzie z tym miał problem ktoś inny chcący też coś pomóc.

I tutaj wychodzi drugi problem z bazaarem -- nie wspiera on przepisywania historii. Rebase rebasem, ale po jakimś czasie commitlogi wyglądałyby tak: 3. implemented X; 4. fixed bug in X; 7 upgraded to upstream 5.0; 11 X obsolete, same functionality implemented elsewhere", etc, etc. Tego typu historia jest ważna w przypadku publicznego projektu, do którego jest np. bugtracker i w którym spójność całości jest święta (to dlatego Linus nie rebase'uje swojego drzewa, ani nie grzebie w jego historii post-factum). Jest ona natomiast ewidentną przeszkadzajką (bo zamazuje obraz zmian) w przypadku projektów bardziej prywatnych, typu opisanych powyżej/tych, co mam w pracy. Po prostu utrudnia życie.

Jestem praktycznie pewien, że z gitem tutaj nie byłoby problemów, nie wiem natomiast jak hg.

W ogóle dosyć oczywiste jest, że bazaar odpada i że najprawdopodobniej wyląduje na gicie. Łudzę się jeszcze, że hg spełni moje wymagania, acz nie mam jakiś specjalnych nadziei. Ot, po prostu, autorzy gita najprawdopodobniej przewidzieli powyższe przypadki użycia oraz setki innych, o których jeszcze nie pomyślałem i które pewnie nigdy nie będą mi potrzebne. Do tego git ma pewnie zaimplementowane optymalne sposoby integracji z wszystkimi innymi rozwiązaniami na rynku (perforce anyone?), więc gdybym kiedykolwiek trafił do jakiejś firmy, gdzie standardem jest coś niespecjalnie wygodnego, najprawdopodobniej byłbym w stanie uprzyjemnić sobie życie przy pomocy odpowiednio użytego gita.

Główny problem z gitem jest taki, że jest on trudny i nieintuicyjny dla ludzi wychowanych na czymkolwiek innym. Tego problemu nie ma z bazaarem, nie wiem jak z hg, ale git to jest oczywisty kosmos. Jest to trochę sytuacja jak z vimem -- używam, bo jest dla mnie wydajniejszy, niż alternatywy. Ale gdybym musiał kogoś innego zmuszać do jego używania, to już byłby problem. Ale nie muszę, bo edytować tekst można w czymkolwiek. Z VCS-ami już nie ma tak łatwo. Jeśli wrzucę 7thguarda do gita, to znacznie podniosę poprzeczkę dla kogokolwiek, kto chciałby w tym później coś pogrzebać (ditto dla pld-users i reszty). Tak nie jest w przypadku np. bazaara, bo czyś z CVS-a, SVN-a, czy czegoś takiego, będziesz się czuł jak w domu.

(To jest powód dla którego przy jakichkolwiek zmianach PLD prawie na pewno nie wyląduje na gicie. Zaawansowane funkcje gita i tak nie zostałyby wykorzystane, a ludzie by się pewnie w końcu zbuntowali, że nowy soft działa kompletnie na odwrót, niż stary dobry CVS. Tego problemu praktycznie nie byłoby właśnie z bazaarem.)

W ogóle nowy 7thguard to będzie ciekawy przypadek. W teorii w ogóle nie powinienem musieć grzebać bezpośrednio w kodzie drupala, wszystko powinno być do załatwienia themami, konfigami i pluginami. W teorii. Jak to wyjdzie w praniu, to się jeszcze zobaczy.

Hmmm, tak się zastanawiam. Może te systemy to jest nowy sposób na rozwój różnych webowych CMS-ów i takich tam? Może to właśnie powinno być specjalnie robione tak, żeby klienci mogli upgrejdować swoje rozwiązania przy pomocy jakiegoś bzr-a z rebasem? Nowe tarballe powinny od razu zawierać katalog .bzr, a nowe wersje powinny być także dostępne do łatwego pullowania/mergowania takimi narzędziami? Graficzne konfigo-klikadła powinny automatycznie commitować wprowadzone zmiany? Interesting... Ciekawym, czy dałoby się taki sposób tworzenia stron dla klientów wprowadzić w mojej opolskiej firmie. Acz to już temat na osobny wpis.

PLD @ Amazon EC2

Tue, 19 Aug 2008 20:53:19 +0200

19:47 <Aria> Amazon EC2 AMI ID: ami-5ced0935 <- pld linux th base setup as a public image, you can setup an ssh key through amazon's api and run your very own.
19:47 <Aria> (Caleb Maclennan's work)

Ok, that's like way cool 'n shit. Those crazy foreigners and their crazy ideas!

(My next entry will be about Google switching to PLD. Seriously. Stay tuned.)

Linux na /dev/drzewo, idę na Vistę

Thu, 14 Aug 2008 01:04:00 +0200

Ten wpis i tak jest przeraźliwie długi, nie chce mi się linkować do definicji używanych pojęć (od czego wujek google), a już tym bardziej do źródeł z których wiem w jaki sposób np. power management, albo WiFi ssie w Linuksie. Ale to zazwyczaj wystarczy poszukać prezentacji maintainerów tychże podsystemów. Oni wiedzą najlepiej co jest źle. Przykład. I dla niekumatych: ja w tym tekście w żaden sposób nie krytykuję niedesktopowych zastosowań Linuksa. A, i jeszcze polecam przeczytać to.

Im jestem starszy, tym bardziej szanuję swój czas i tym większą mam ochotę używać optymalnie dopasowanych narzędzi. Czyli np. przestać używać Linuksa na desktopie, bo prawda jest taka, że, w porównaniu do konkurencji, technicznie wypada dosyć blado.

Zaawansowane zarządzanie energią (aka hibernacja i pochodne)? Raz działa, raz nie działa, sterowniki często nie mają obsługi niczego poza on/off (a Vista afaik jest bardziej bateriooszczędna od Linuksa). Dźwięk? Podstawowy zazwyczaj działa, ale alsa jest wybitnie głupio zrobiona (próbował ktoś kiedyś wykombinować co robią różne ustawienia w mixerze?) i dalej wszyscy jeżdżą na różnych demonach dźwięku. O jakimś standardzie dla kodeków nie wspomnę. WiFi? Jak działa, to dobrze, jak nie, to masz pecha, bo pewnie nie ma dla ciebie sterowników. Obsługa 3D? Hahaha. Xorg jest sto lat za murzynami (i to prawie we wszystkim), binarne sterowniki supportują co chcą (a w ATI pewnie dalej nie działają), kernel dopiero zaczyna mieć jakieś ficzery pozwalające mu nad tym wszystkim zapanować (i nie wiadomo, czy nvidia i amd będą z tego korzystać), a konkurencja od X lat traktuje to wszystko jako oczywiste ficzery. Obsługa różnych dodatkowych urządzeń? Jak trafisz na coś supportowanego, to git, jak nie, no to pech. Rosyjska ruletka z kupowaniem jakiegokolwiek osprzętu, a przy kupowaniu laptopa to tylko z listą supportowanego sprzętu w garści.

Część z tych rzeczy to po prostu opóźnienia w rozwoju (głównie Xorg), na część natomiast jest albo za późno (ktoś ma ochotę poprawiać alsę? albo dalej twierdzić, że gstreamer wszystko rozwiąże? ile to już lat?), albo są nieuniknionymi konsekwencjami metodologi open source. Prawda jest taka, że dla producentów sprzętu/użytkowników binarne sterowniki i nieczęsto updejtowane Windowsy są zdecydowanie tańsze w supportowaniu/wygodniejsze, więc nie ma i nie będzie masowego ich otwierania. Z czego wynika, że dla rozwiązań desktopowych Linux będzie zawsze gorzej supportowany, bo zawsze będzie spora część rynku preferująca binarki. Producent może stworzyć sprzęt, napisać sterowniki, przetestować na dosłownie kilku dostępnych na rynku Windowsach, dopisać proste GUI i wsio. Na Linuksie (a) musisz mieć otwarty kod, czyli tajemnica handlowa /dev/null (tajemnica handlowa jest znacznie starsza od Linuksa i, niezależnie od życzeń Linuksiarzy, producenci raczej nie zaczną z niej rezygnować), (b) produkowanie własnego oprogramowania do obsługi sprzętu jest kompletnie niepraktyczne, więc obsługa twojego sprzętu będzie tylko do tego stopnia przyjazna, do jakiego pozwala obecny stos softu danego typu. Czyli zazwyczaj średnio na jeża albo wcale (alsa i jej intuicyjny mixer? karty 3d i zaawansowane ustawienia 3d? nie wiem, kamera i jakieś niestandardowe ficzery? wszystko padaka).

Oczywiście spora część z tych problemów zostanie rozwiązana, gdy Linux na desktopie się odpowiednio rozpędzi i producenci będą zmuszeni go supportować. Tyle, że to się nie stanie. Linux na desktopie technicznie jest sto lat za murzynami, a fajne programy open source albo już od dawna są (Firefox), albo niedługo będą (KDE-pochodne) miały porty pod Windowsa i OS X. Więc niby z jakiego powodu rynek masowy miałby wybierać desktopy linuksowe? Bo KDE4 ma fajny zestaw programików do groupware? Niedługo będzie dostępny pod Windowsy.[1] Coś jeszcze? Czy naprawdę istnieją jakieś konkretne podstawy, żeby przypuszczać, iż desktopowy Linux osiągnie masę krytyczną?

([1] I jest to afaik także prawda w przypadku typowo linuksowatych narzędzi deweloperskich. Obecnie da się spokojnie postawić linuksowe środowisko deweloperskie z desktopem na nielinuksie. ssh/vnc/sieciowe x11/samba to twoi przyjaciele.)

Natomiast w drugą stronę przewaga jest miażdżąca. Konkurencja zawsze ma soft state-of-the-art, a Linux albo całkiem sensowną alternatywę (dostępną także na systemy konkurencji...), albo popłuczyny (photoshop anyone?), albo zupełne nic (rynek gier hahaha).

Nadganianie tego typu zaległości jest możliwe jeśli się ma bardzo dużo wykwalifikowanej i skupionej na konkretnym celu kadry oraz wytworzy odpowiedni ekosystem tworzenia wysokiej klasy oprogramowania dla danego systemu. Microsoft ma tony kasy i tysiące inżynierów, więc może sobie pozwolić na przepisanie systemu grafiki w Viście od zera. Dodatkowo wytworzył gigantyczny ekosystem zewnętrznych firm, które sporo zarabiają na produkowaniu softu pod Windowsy (takie Adobe małą firmą nie jest). Linux ma: brak nawyku płacenia za cokolwiek (ekosystem możemy pożegnać), gigantyczną ilość dystrybucji praktycznie uniemożliwiającą wydawanie binarnych wersji softu oraz stosunkowo niewielką ilość rzeczywiście wykwalifikowanych inżynierów, którzy jeszcze zazwyczaj robią to samo po kilka razy (KDE vs. GNOME, PulseAudio vs. gstreamer vs. czysta alsa, chyba z dwa podejścia do nowej generacji sterów 3d w xorgu, gigantyczna ilość różnych dystrybucji, etc.). W takich warunkach można zapomnieć o dogonieniu kogokolwiek.

Heh, ja sam używam dystrybucji o której słyszał jakiś ułamek promila użytkowników Linuksa. I lubię jej używać ze względu na pewne specyficzne rozwiązania techniczne, czyli głównie poldka i duże rozdrobnienie paczek, ale tak naprawdę to się bardzo dobrze sprawdza tylko na serwerach i w niewielkich specjalizowanych środowiskach (w pracy parokrotnie używałem PLD-owych chrootów), a na desktopie jest wybitnie upierdliwe. Desktopy są znacznie bardziej skomplikowane od serwerów i jeśli mam KDE rozparcelowane na 700+ pakietów (a mam :), to można zgłupieć. A do tego dochodzi jeszcze zatrzęsienie różnych dodatkowych bibliotek i demonów do obsługi różnych rzeczy. Hal, policykit, cośtamkit, acpid, serwer dźwięku (który?), bluetooth, coś do wifi, xorg (też 700 paczek :), czcionki i co tam jeszcze. Oszaleć można. Nawiasem mówiąc ciekawym czym się teraz obsługuje WiFi z GUI? Pewnie jakąś nakładką KDE-ową na NetworkManagera (bo przecież nie można napisać po prostu NetworkManagera, tylko trzeba oddzielić backend od frontendu i napisać co najmniej dwa frontendy, jeden dla GNOME, drugi dla KDE; żeby nie było za prosto).

(Może powinno zostać jakimś oficjalnym policy PLD, że desktop ma niższy priorytet, niż serwer? Kto wie, może mogłoby to ułatwić pewne rzeczy.)

Więc o ile PLD może mi dodawać pewną wartość na serwerach (poldek, sposób pakietowania, domyślne konfigi, unifikacja względem FHS i takie tam), o tyle na desktopie praktycznie nie ma na to szans, a wręcz przeciwnie -- takie Ubuntu jest znacznie lepiej zintegrowane, przetestowane i zjada mniej czasu (dlatego staram się upgrejdować swojego laptoka tylko wtedy, gdy naprawdę muszę, bo zawsze coś się pieprzy przy okazji). Dodatkowo w takim Ubuntu Mark Shuttleworth może powiedzieć, że chce obrać kierunek rozwoju X, sypnąć groszem na ludzi to implementujących no i jakiś tam cel zostaje osiągnięty. W projekcie typu PLD jest to możliwe na znacznie mniejszą skalę (np. FHS), na pewno nie desktopową. Nie może przyjść "lider" i powiedzieć, że robimy X, bo go wszyscy oleją. A w Debianie to już w ogóle są cyrki (widzieliście jakie oni flejmy generują o wszystko? porn-geta na przykład, czy ten aplet do monitorowania zużycia CPU z rozbierającą się kobitą). O sensownym quality control można w PLD zapomnieć. Windows się wydaje raz na ruski rok, to się przy okazji mocno przetestuje, Ubuntu raz na pół roku plus Ubuntu ma ludzi od testów, a PLD ma deweloperów, którym się takich rzeczy robić nie chce (mi też się nie chce).

Pytanie: co zamiast? Na pewno nie zrezygnuję z Linuksa na serwerach -- raz, że nic mnie nie kosztuje, dwa, że lubię swoje PLD i trzy -- zawodowo jednak zajmuję się Linuksami, więc muszę mieć bieżący z nimi kontakt. Ale na desktopie? Albo Vista albo OS X. (Oczywiście nie teraz, tylko jak mi laptop padnie i będę musiał kupić nowego. Obecny by Visty nawet nie uciągnął.)

Główna zaleta Appla -- jest uniksowaty, więc mi bardziej po drodze (większość moich obecnych narzędzi po prostu się buduje i działa, bez jakiś akrobacji). Główna wada Appla -- nie mam go jak najpierw przetestować, a kupować muszę od razu ze sprzętem Appla, który jest afaik drogi (i jest go mniejszy wybór, niż standardowych intelowatych). W przypadku Windowsa Vista mam laptop dziewczyny z tymże, więc mogę sobie testować do woli (o czym będą inne wpisy; materiał do wpisu o Firefoksie mam już gotowy, więc się za jakiś czas pojawi, ale do tego od Visty nie).

Inne problemy:

1. Wirusy. W OS X afaik nie problem, ale w Viście jednak wypadałoby mieć jakiegoś antywira. Nie lubię mieć antywirów, jestem przyzwyczajony do braku konieczności ich posiadania. Z punktu widzenia odporności na wirusy kompletny chaos ABI w zatrzęsieniu dystrybucji Linuksa to zaleta.

2. Upgrejdy systemu. Upgrade poldkiem jest upierdliwy, ale prawda jest taka, że swoje desktopy upgrejduję po parę lat bez żadnych reinstalek i po kilku poprawkach zawsze prawie wszystko działa (teraz np. mam wkurzające problemy przez niedorobiony evdev w xorgu). Nie sądzę, żebym przeżył niereinstalkowy upgrade XP do Visty. Nie wiem jak z OS X. Z drugiej strony na raz wydaną Vistę przez następne wieeeele lat wychodzi soft, który można sobie po prostu upgrejdować. Na PLD jak robisz za długie przerwy, to później nowy python wymaga 70% nowego systemu (bo openldap pociągnął coś, co wymaga ixów, ixy są już nowe, więc całe kde i wszystko graficzne trzeba zassać, etc...; i chciałeś nowego pythona, a przy okazji dostałeś rozwalonego evdeva). Mnie od dawien dawna nie podnieca gonienie za numerkami (czego w znacznej mierze nauczyła mnie upierdliwość upgrejdów w PLD), więc Vista by mi tu pewnie bardzo pasowała. Ba, dalej używam KDE3.5, bo mnie przeraża KDE4.

3. Gnicie systemu. Na PLD problemu nie ma, bo poldkiem i rpm-em mam kontrolę nad wszystkim i jak mi się zrobi za dużo śmiecia, to po prostu wyinstalowywuję co chcę, jadę prostym skryptem po zagubionych plikach i mam czysto (jak mówiłem, mogę po parę lat robić upgrejdy całego systemu praktycznie bez nieprzyjemnych skutków ubocznych; wymagają tylko trochę czasu). Nie wiem jak z Applami, ale afaik Vista nadal sobie z tym problemem nie poradziła. Znajomy m.in. przez to ostatnio wrócił do XP, a laptop mojej dziewczyny zamyka się teraz po kilka minut. Dla mnie to jest naprawdę problem, ja jestem bardzo przywiązany do faktu, że PLD daje mi pełną kontrolę nad wszystkimi plikami w systemie (które do tego są uporządkowane; viva la FHS, viva la patche w PLD) i będę miał poważne problemy ze zrezygnowaniem z tego ficzeru. Ten brak kontroli na najbardziej podstawowym poziomie to jest główny powód dla którego nie lubię dotykać Windowsów. Z drugiej strony -- przy tych setkach pakietów desktopowych to ja i tak zazwyczaj nie wiem co się w systemie dzieje.

4. W Windowsie (i OS X?) za sporo rzeczy jednak trzeba płacić. I to nawet za takie, które w Linuksie dostaję jako standardowe wyposażenie. Taka Vista jest bardzo słabo konfigurowalna w porównaniu do dowolnego Linuksa. Zazwyczaj są płatne narzędzia, żeby dodać brakującą funkcjonalność, ale są brzydkie, bo są płatne. Drażni mnie wydawanie kasy na coś, co uważam za podstawową funkcjonalność. Szczęściem jednak jest sporo softu open source tego typu pod Windowsy, ale nie wiem, czy wszystkie moje potrzeby byłyby zaspokojone. Tak czy siak o tym będzie osobny wpis (z serii "Jak zostać power userem" :).

Dobra, tyle. Tak jak pisałem, na pewno w tym momencie na żadną Vistę się nie przenoszę, co najwyżej przy zmianie laptopa. Ale nawet wtedy nie jest to przesądzone, gdyż (a) tak naprawdę cieszę się z faktu, że np. w nic nie gram i rzadko korzystałbym z ficzerów, których w Linuksie nie mam, (b) jakby co, to zawsze jest laptop dziewczyny; oby mnie nie zostawiła i (c) jednak jest zestaw ficzerów typowo Linuksowych do których jestem bardzo przyzwyczajony. Acz hgw jak te rzeczy wyglądają w OS X. Przy czym gdybym dziadkowi kupował nowy laptop, to pewnie wrzuciłbym Vistę, dał mu dostęp tylko do konta nieadminowego i nie miałbym z tym większych problemów, niż mam obecnie z jego PLD i GNOMEm (mam nadzieję; nie wiem jak z wirusami).

Jak komuś się chciało to czytać w całości, to gratuluję samozaparcia. Ja to muszę przeczytać jeszcze z dwa razy, żeby zrobić korektę przed publikacją. :(

PLD moves to launchpad

Wed, 16 Jul 2008 14:26:14 +0200

It's "official". Here's the announcement.

Wonder how that's gonna go. I kind of buy into Mark Shuttleworth's vision of upstream-downstream integration and based on what I've seen, I really like Launchpad. Hope other developers use it.

PLD RPG

Sun, 20 Apr 2008 22:06:58 +0200

Większość zainteresowanych pewnie już widziała, ale może kogoś ominęło -- PLD RPG/Linux. Autorowi zdecydowanie trzeba pogratulować kreatywności i mieć nadzieję, że to nie ostatni jej przejaw. Właśnie się z paroma deweloperami PLD zastanawiamy, czy by w tym względzie jakoś nie pomóc.

"Na dnie Bałtyku w betonowych butach", 500 słów. Albo "pobity do nieprzytomności przez bandę geeków", wierszem. Ewentualnie "zakopany żywcem w lesie", obrazek, A3, kredkami świecowymi.

Zapewniamy odpowiednie... materiały, gdyby autorowi brakowało natchnienia. Cała przyjemność po naszej stronie.

Co dolega PLD

Sat, 29 Sep 2007 15:38:57 +0200

Mój mail sprzed paru minut.

Ja wiem, że to dziwnie brzmi, ale ja się na PLD wychowałem. Cała moja podstawowa wiedza, doświadczenia, wzięły się z tego projektu. PLD nie ma przed sobą wielkiej przyszłości. Przy pomocy PLD nie da się niczego osiągnąć. Openmoko ma przyszłość. Kernel ma przyszłość. KDE ma przyszłość. Jest wiele opensource'owych projektów z przyszłością. Takich, w których udział miałby dla mnie (znaczy -- mojego CV) wymierne korzyści.

Ale jakoś nie potrafię z tym PLD zerwać.

Lefthand e-Faktura a administratorzy

Fri, 14 Sep 2007 14:38:17 +0200

Nie wiem, śmiać się, płakać? (Dla niewiedzących -- poniższa komenda listuje pliki znajdujące się w paczce rpmowej.)

[root@uslugi ~]# rpm -qlp lefthand-server-1.5.3-2.i386.rpm
/tmp/lefthand-server
/tmp/lefthand-server/buildroot.tar.gz
/tmp/lefthand-server/install.sh
/tmp/lefthand-server/manifest.txt
/tmp/lefthand-server/scripts
/tmp/lefthand-server/scripts/postinstall.sh
/tmp/lefthand-server/scripts/postuninstall.sh
/tmp/lefthand-server/scripts/preinstall.sh
/tmp/lefthand-server/scripts/preuninstall.sh
/tmp/lefthand-server/scripts/rpmfiles.txt
/tmp/lefthand-server/scripts/rpmheader.txt
/tmp/lefthand-server/scripts/tarMainInstall.sh
/tmp/lefthand-server/scripts/tarMainUninstall.sh
/tmp/lefthand-server/scripts/tarinstall.sh
/tmp/lefthand-server/scripts/taruninstall.sh

Ja rozumiem, że firmy idą na łatwiznę, bo pełna obsługa systemów linuksowych jest dosyć upierdliwa. Ale powyższe to tak, jakby ktoś mi pokazał środkowy palec. Mam nadzieję, że to będzie działało z PLD-owym Firebirdem, bo średnio mam ochotę takie gówno sobie wrzucać na serwer.

Update: A te pliki to tak naprawdę domyślny instalator Firebirda ze zmianą w postaci ustawienie hasła administracyjnego na masterkey, zamiast zapytania się o nie. Ciekawym, czy sama binarka bazy to też domyślnie wzięta od upstreamu, czy ich własny build.

Przypowieść o optymalizowaniu benefitów w kontekście

Sun, 26 Aug 2007 19:24:23 +0200

Dłuższy czas temu napisałem na listy PLD maila prezentującego różne wnioski z lipcowego zlotu, po czym wrzuciłem krótkie podsumowanie tutaj oraz linka na 7thguarda. Oryginalnie natomiast planowałem zrobić to na odwrót, czyli wnioski ze zlotu opisać tutaj, a na listy wrzucić tylko linka. I to byłby błąd.

Pisząc tutaj raz, że bardziej uważam na styl tekstu, a dwa, że staram się pisać tak, by ludzie nie pracujący ze mną nad projektem X też wiedzieli o co chodzi. W praktyce oznacza to, że pisanie zajmuje mi znacznie więcej czasu, a co za tym idzie mam większe problemy w ogóle z zabraniem się za wirtualne pióro, czyli owo podsumowanie zlotu najprawdopodobniej by w ogóle nie powstało.

I to jest problem, bo często zamiast napisanego na kolanie tekstu, który byłby przynajmniej zrozumiały i przydatny dla jakiejś wąskiej grupy ludzi, nie produkuję w efekcie kompletnie niczego.

A sensownym gadaniem/pisaniem też można co nieco zdziałać, zwłaszcza, jeśli się, tak jak ja, stara mieć wpływ na kierunek rozwoju danego projektu w szerszej perspektywie. Tylko to się trzeba skupiać na projekcie, a nie na blogu...

Tytuł wpisu pochodzi z oryginalnego szkicu tego tekstu, który był trzy razy za długi i miał pełno takich fuj-słów w sobie. Wrr. Zostawiam go (tytuł znaczy się) ku przestrodze samemu sobie.

O zlotach wedle Mortona

Sun, 26 Aug 2007 18:14:49 +0200

Cytat z maila Andrew Mortona:

My overall take on kernel summit: we spend far too much time talking about technical stuff.

There is little benefit in doing this: we conduct technical discussions over email and we do it well, and there are many very good reasons for doing it that way. In fact when the KS discussion gets too techy I just start ignoring it (...)

Plus the minisummits are better suited for the technical material.

Polecam przeczytanie całego maila. Generalnie chodzi o to, że najwyraźniej nie tylko ja jestem zdania, że przeznaczanie fizycznych spotkań większą grupą na omawianie technicznych zagadnień, które z definicji interesują tylko pewien podzbiór ludzi, jest stratą czasu. Jeśli chcesz sobie o technikaliach porozmawiać sensownie, to skrzyknij tylko te osoby, które mają w tym jakiś interes, usiądźcie sobie przy jakimś stole i gadajcie, bądź też użyjcie maila/irca, jak zwykle. Natomiast jeśli chcesz robić ogólną publiczną prezentację, to najpierw się upewnij, że rzeczywiście jest ona interesująca dla większości twoich słuchaczy. Jeśli nie jest, to najlepiej jeśli oszczędzisz tak czas swój, jak i innych.

Tyle jeśli idzie o spotkania dla osób technicznych. Zastanawia mnie jak by to wyglądało w przypadku początkujących (LUG-i i takie tam). Pewnie jakoś podobnie, ale ani mi się nie chce zastanawiać, ani w sumie nie mam podstaw, żeby oceniać.

Piętrzy się i pieprzy

Sat, 25 Aug 2007 00:30:37 +0200

Piętrząca się robota ma taką fajną właściwość, że im więcej jej jest, tym więcej innych rzeczy (i ludzi) czeka, aż zostanie zrobiona. Podprojekt pracowy -- potencjalnemu podzleceniodawcy szczegóły wysyłam juz chyba z dwa tygodnie. Główny projekt pracowy leży od chyba już dwóch miesięcy i nadal nie chce się dać zmusić do działania. Ciekawym kiedy klienci zaczną nas gonić z widłami. Projekt rozwojowy pracowy, który w dłuższym okresie czasu powinien nam zaoszczędzić sporo bólów głowy (bo wreszcie będziemy mieli jak trzeba napisaną integrację wszystkich podsystemów), leży już od paru miesięcy (nie licząc chyba z pół roku, jak ktoś inny miał go robić, ale w końcu nie zrobił). I regularnie gadam z współodpowiedzialnym za niego współpracownikiem, że już w następnym tygodniu, już zaraz. Tyle główna praca.

Do tego dochodzi moja nowa firma. Co tu było... a, tak. Porządne przygotowanie infrastruktury firmowej (i przygotowanie pracowników do jej używania). Jeśli sobie teraz odpuszczę, to za parę miesięcy będą płakał, że wszystko mi się wali, nikt nie wie co zrobić, klienci wrzeszczą, a ja mogłem temu zapobiec, ale się w końcu nie zabrałem. Do tego dwóch współzałożycieli na tydzień sobie wyjeżdża w góry, więc będę odpowiedzialny za serwisowanie systemów, których na oczy nie widziałem, które nie wiem co robią i które na dodatek chodzą na windowsach, o których nie wiem praktycznie nic. Boże, jeśli przez ten czas żaden klient nie zadzwoni z awarią, to obiecuję, że egzemplarz "Boga urojonego" spalę na popiół i zacznę regularnie chodzić do kościoła.

O moich pomysłach rozwojowych na firmę i pomniejszych duperelach (jak poprawianie literówek i przecinków po moim wspólniku) nie wspomnę.

No i na zakąskę hobby, czyli rzeczy, za które mi nie płacą. Ten człowiek od serwera jabberowego pld... ile to tygodni temu mu pisałem, że już zaraz mu prześlę szczegóły jak tym administrować. pld-users.org jak leżało pół rozgrzebane, tak leży (gausus, revy, ty przebrzydły koboldzie!). Hackaton pldowy na początku września można pewnie między bajki włożyć (gausus, jak ja cię dopadnę, to ci brodę zgolę!). Dodatkowe buildery pldowe dla mniej popularnych architektur oraz szkolenie chętnych ludzi z ich obsługi i stawiania, oczywiście też mam w planach... gdzieś tak już od dwóch miesięcy. Fundacja PLD, hahaha. A mityczną nową wersją 7thguarda, to pewnie będziemy z honejem dzieci, tfu, wnuki straszyć. (Honej, jak to czytasz, to chyba mam pomysł, który nawet ma szansę zadziałać, ale to ci opowiem na początku września, jak już będę wiedział coś więcej). O byciu szefem studenckiej rozgłośni radiowej oraz pomysłach na to, jak ją ruszyć do przodu nawet nie wspominam. Szczęście naczelnym jest kto inny, więc najgorsze co się stanie, to to, że nie zrealizuję swoich pomysłów, ale poza tym nic się nie zawali.

A jak mi się w październiku studia zaczną, to się już w ogóle zesram ze szczęścia.

A najgorsze w tym wszystkim jest to, że im więcej tych rzeczy się nawarstwia, tym trudniej w ogóle zacząć. I człowiek tylko spędza dnie na unikaniu jakiejkolwiek pracy, bo jest tego tyle, że odechciewa się zabierać za cokolwiek. Zapewne dlatego, że końca i tak nie widać.

Rozwiązanie jest bardzo proste -- rzucić podstawową (i najbardziej czasochłonną) robotę i tylko skupić się (zawodowo) na zakładaniu firmy oraz hobbystycznie na paru odpowiednio wybranych projekcikach. Problem taki, że firemka przez czas dłuższy (jeśli w ogóle) nie będzie jakoś sensownie dochodowa, a ja się przez ostatnie dwa lata za bardzo przyzwyczaiłem do pieniędzy.

Treningi tańca kosztują. Treningi sztuk walki kosztują. A ja lubię tańczyć, lubię walczyć i lubię być w formie. Lubię jeździć na pingwinaria, jesień, czy zlot pldowy nie patrząc na cenę. Samochodem też lubię jeździć nie licząc pieniędzy na stacji benzynowej. Wczoraj (w ramach unikania pracy) byłem w sushi barze, pokosztowałem win, pokosztowałem potraw, pogadałem sobie z barmanką, kupiłem butelkę wina, zapłaciłem za całość jak za zboże i dałem sowity napiwek. I nie miało to żadnego zauważalnego wpływu na mój miesięczny budżet.

Pointa, pointa, ty cipo (żeby tak sparafrazować klasyka). Nie ma podsumowania. Podsumowanie napisze Życie (w formie noweli). Najlepiej by było, jakby mnie wyjebali z podstawowej pracy, bo wtedy wszystko by się samo rozwiązało. Ograniczyłbym wydatki i przestał żyć jak yuppie, a bardziej wrócił do nerdowych korzeni. Ale mnie nie wywalą, bo już za kilka dni, wkurwiony na maksa, że nie wiem co robię, znowu jakimś cudem wykombinuję jak naprawić podstawowy system pracowy. I znowu dostanę wypłatę. I nadal będę miał TODO do sufitu.

A chuj. Pieprzona potrzeba snu, pieprzony real life (trzeba było zostać nerdem), pieprzona zaledwie 24godzinna doba i pieprzone studia (które muszę skończyć przez pieprzone wojsko, bo mi obiecali, że jak skończę, to zostanę z automatu rezerwistą). I chuj ci w dupę ansari, hipisie jeden. Tak, wiem, nic nie muszę, ty też nic nie musisz, antymon nic nie musi, w ogóle załóżmy komunę i palmy zioło oraz zapładniajmy kobiety całymi dniami. Kiedyś czytałem, że sukces w życiu mierzy się umiejętnością unikania brania na siebie coraz to nowych zobowiązań, wraz z upływem czasu. No cóż, na razie idzie mi wybitnie chujowo.

Tak, żyłka mi pękła, ale nic mi nie będzie. Już w podstawówce nauczyłem się nie przejmować zobowiązaniami i mam taki zawór bezpieczeństwa, że jeśli w danym momencie nie mam ochoty czegoś robić, to po prostu tego nie robię. Dlatego całe wczoraj i przedwczoraj spędziłem na obijaniu się (a jutro z samego rańca jadę na cały dzień w góry stołowe ze znajomymi), mimo, że powinienem pracować po paręnaście godzin dziennie, żeby z wszystkim zdążyć. Nie muszę wspominać, że moi nauczyciele nie byli nigdy zachwyceni tą moją umiejętnością :) Prawda jest taka, że za parę tygodni sprawy pracowe będą w większości uregulowane, takoż sprawy firmowe, natomiast część hobbystycznych będzie zrobiona, a część nadal będzie leżała odłogiem. Ot, życie.

A, gausus, wcale nie jesteś brzydki i nie wyglądasz jak kobold. No, dobra, wyglądasz, ale twojej brody to bym się nie odważył tknąć, bo u nas w pldówku ma ona praktycznie status artefaktu. Ansari, co do tej propozycji seksualnej, to nie obraź się, ale tak naprawdę nie jesteś w moim typie. Hmm, a antymona to tak dawno nie widziałem, że w sumie nie wiem już jak wygląda.

Dobranoc.

Znowu o zarządzaniu open source'ami i nie tylko

Mon, 13 Aug 2007 03:36:25 +0200

Linux kernel management style. Ten tekst jest tak treściwy i na temat, że mógłbym na jego temat popełnić co najmniej kilka wpisów, w każdym cytując po kilka akapitów. Jak mi się będzie kiedyś nudzić, to go przetłumaczę i będę każdemu podsyłał do przeczytania co najmniej po kilka razy.

Wiecie na przykład dlaczego większość PLDowych cudzych pomysłów z miejsca kwalifikuję jako nieaplikowalne i niepraktyczne? Bo jestem egoistycznym chujem? No tak, to też, ale chodzi mi o to, że pomysłodawca (a) zazwyczaj tak naprawdę nie rozumie implikacji swoich pomysłów, zwłaszcza w stosunku do użytkowników/deweloperów (czyli ogólnie ludzi) oraz (b) jeśli rzeczywiście byłby przekonany do swojego pomysłu, to na krytykę zwracałby uwagę tylko pod kątem wyciągania z niej jakiś przydatnych spostrzeżeń, a energię poświęcał jego realizacji. Innymi słowy za każdym razem, gdy czyjś pomysł rozbija się o to, że jestem brzydki i mam wszy na pępku, to tylko utwierdza mnie to w przekonaniu, że i tak szanse realizacji miałby marne (mówiłem, że jestem chujem :).

Moja rada? Dużo czytajcie na tematy związane z tym, co chcecie robić. Im lepiej będziecie rozumieli ludzi, których to, co chcecie robić, dotyczy, tym bardziej będziecie czuli jeśli któryś wasz pomysł rzeczywiście będzie miał potencjał. Co za tym idzie większy będzie wasz zapał i mniejsza szansa, że jakiś brzydal was od pomysłu odwiedzie. Tak jak mówiłem na zlocie pldziarzy -- jeśli ja coś chcę zrobić, to po prostu robię. I nie dlatego, że mam jakieś magiczne moce, ale dlatego, że jeśli się już za coś biorę, to zazwyczaj jestem mocno przekonany, że ma to sens.

Nawiasem mówiąc parę miesięcy temu zostałem szefem swojouczelnianego radia internetowego (że Koło Naukowe Radio Emiter). I mam nawet pomysł co zrobić, żeby to radio było relewantne i produkowało pewne ilości kontentu, który znalazłby swoją niszę. Ale i tak nie znajdę na to czasu. W najlepszym wypadku uda mi się to w jakiś sposób spójnie opisać i przedstawić reszcie radiowców w nadziei, że podchwycą. Nadziei płonnej, bo prawda jest taka, że z zapałem realizuje się własne pomysły, a nie cudze.

Eh. Świat jest pełen ciekawych rzeczy, o których można poczytać, które można zrobić. Niestety większość z tego, co czytam, zaraz zapominam (nie mogę tego przeboleć prawdę mówiąc), a na rzeczy, które chciałbym robić, nie mam czasu (w tym na czytanie). Jedyne rozwiązanie, jakie mi przychodzi do głowy, to jak najszybciej się dorobić i później żyć w pewien określony sposób. O czym chętnie bym napisał coś więcej... tylko kiedy?

Od zera do menedżera, lekcja 375

Tue, 31 Jul 2007 23:47:52 +0200

Jestem zwolennikiem zarzucania ludzi możliwościami robienia tego, na co mają ochotę (w przypadku projektów open source czytaj: dawania im odpowiednich uprawnień). Robienie jest ciekawsze, gdy co chwilę można robić coś nowego. A gdy robienie jest ciekawsze, robiący robi więcej i bardziej się przykłada.

Ostatnio się jednak na tym przejechałem. Dosyć oczywisty (po czasie) wniosek z owego przejechania się -- zawsze należy najpierw stwierdzić, czy istnieje więcej jak jedno podejście do poprawnego wykonania zadania. W 99% przypadków na dziesięć istnieje. Wtedy żaden problem przydzielić zadanie komukolwiek, niech się bawi. Jak zrobi źle, to albo da się komuś innemu, albo niech autor sam poprawia. Natomiast w pozostałych 1% przypadków nie warto ryzykować i należy postawić na sprawdzonych ludzi. Żeby potem nie żałować.

I małe post scriptum. Takie uwagi są zdecydowanie ciekawsze, gdy się je omawia na konkretnych przypadkach. Niestety publiczne opisywanie konkretnych sytuacji i konkretnych ludzi stoi w konflikcie z chęcią robienia czegoś z rzeczonymi ludźmi. Przeanalizowanie czyjejś pracy w gronie zainteresowanych członków projektu to jedno. Robienie tego samego publicznie, nawet jeśli jest to tylko tłem do analizy własnych poczynań, to już zupełnie coś innego. Albo rybka albo rower... Albo to z jakimiś grabkami i łopatką było.

Drażni mnie to. Muszę się sam cenzurować, inaczej zacznę kopać pod sobą dołki. Coraz bardziej romantyzuję czasy, gdy flejmowałem do woli kogo chciałem, bez brania pod uwagę jakichkolwiek konsekwencji. Stare dobre czasy...

Zajętym

Fri, 20 Jul 2007 18:56:30 +0200

W pracy lekkie urwanie głowy, więc jak miałem coś zrobić, a nie robię, to właśnie dlatego.

Przy czym nie wszystko muszę robić ja, więc jeśli znajdzie się jakiś pld deweloper do postawienia dwóch vserwerów w xenie od gaususa, to można by wreszcie uruchomić pld-users oraz dodatkowe architektury do Th (aida th).

(Piszę tu, a nie na listy, bo jak ktoś mnie czyta, to znaczy, że ma nadwyżki wolnego czasu. A o taką osobę chodzi ;)

Gosh

Fri, 13 Jul 2007 16:06:16 +0200

Aw, shucks, we're blushing.

Pozlotowo PLDowo

Tue, 10 Jul 2007 17:14:18 +0200

Cholera, tematy do pisania mam, ale nie mam czasu, bo praca goni. Nie będę się powtarzał, więc tylko wrzucę link do mojego maila na listy pldowe. Link.

O co chodzi w tym komponentyzowaniu PLD mówiłem na zlocie, ale nie mam czasu teraz opisywać. Niedługo postaram się skrobnąć. I w ogóle skrobnąć o tym, co na tym zlocie mówiłem. Eh, za dużo tego. Jeszcze muszę coś machnąć o 7thguardzie i w ogóle wrażenia z wyjazdu (a był pełen wrażeń :), ale to też nie wiem kiedy. Mam nadzieję, że w miarę szybko.

Portage-like repo layout

Thu, 17 May 2007 00:55:01 +0200

PLD will have an additional CVS repository layout that looks more or less like portage. The 'less' part is about not using gentoo's package categories (sys-devel, sys-db, etc.), however it's most likely perfectly doable, at least for the majority of our packages, to automatically fetch that metadata from gentoo, and place it somewhere. Either in a file (like 'packages/glibc/gentoo-category') or make an additional module that looks 100% like gentoo's portage tree (perfectly doable server side; we'd have 'packages' with a flat structure, that is 'packages/packagename' and, say 'portage' with portage-like structure, meaning 'portage/packagecategory/packagename'). The question is -- why? What does it give us? (Except for the coolness factor :)

One crazy idea -- create that portage tree in our cvs repo, hack the original gentoo's portage to be able to use rpmbuild instead of those ebuilds (quick dirty hack would do) and try to actually set up a pld system using gentoo's installers. Sounds cool, not that it's in any way usefull however :) Other then getting us a mention on slashdot for pulling this off probably.

Oh, and for the record -- no, it's not, and will not be possible to have, like in gentoo, more then one package of the same name, but under different categories. Both rpm internally and the way our repo is organized prevent this.

Hmm. It would however be possible to have aliases based on gentoo's group/name pairs. What would you say if poldek -i git-core was equal to poldek -i dev-util/git (-i stands for install). And same for the builder script? Considering poldek already provides a virtual filesystem, we could just expand it, so it would look something like this:

[root@klapek ~]# poldek
(...)
poldek:/all-avail> cd dev-util
poldek:/all-avail/dev-util> ls
(...)
git-1.5.0.3-2 (git-core-1.5.0.3-2)
git-1.5.1.2-1 (git-core-1.5.1.2-1)
(...)
517 packages
poldek:/all-avail>

Now that sounds both cool and potentially usefull. What'd ya think? Any other ideas?

PLD według użytkowników

Sun, 13 May 2007 17:00:07 +0200

Wieki temu, chyba na pierwszej jesieni linuksowej, spotkaliśmy z Jajcusiem bodajże Debianowego (albo Gentoowego, ale Gentoo chyba wtedy nie było jeszcze takie popularne) zealota. W sensie takiego człowieka, który mógł godzinami się rozwodzić nad tym, jaki to Debian jest świetny i że nadaje się absolutnie do wszystkiego.

Jajcuś stwierdził, że fajnie by było, gdyby PLD miało takich ludzi. Wtedy w sumie przyznałem mu rację.

Później natomiast zacząłem się skłaniać w kierunku opinii, że tak deweloperzy, jak i użytkownicy powinni wiedzieć w jakich kategoriach należy mówić o PLD i w żadnym razie nie powinno być to twierdzenie, że PLD jest fajne, bo jest najfajniejsze i tyle. Zawsze jestem nerwowy, gdy, zwłaszcza jakiś deweloper, chce zachwalać PLD, bo łatwo tutaj powiedzieć coś, co przyniesie więcej szkody, niż pożytku. Na przykład czy PLD nadaje się na desktop? Nadaje z zaznaczeniem, że musisz rozumieć choćby podstawy obecnych desktopowych technologii (udev, hal, etc.) i nie oczekiwać, że wszystko można osiągnąć w dwóch klikach, jak w Ubuntu. I że jeśli użytkownik czegoś takiego oczekuje, to niech się trzyma od PLD z daleka, bo później będzie uciekał z krzykiem. Takich przykładów można mnożyć.

Tym samym bardzo mnie cieszy ten wątek na PLDowym forum. Tak trzymać.

Oczywiście nie wszystko jest idealne, tzn. obecnie dostępnym publicznym materiałom daleko do doskonałości, zwłaszcza biorąc pod uwagę, że z konieczności starają się one sprawę uprościć. Zawsze stronom takim jak Jakilinux przyglądałem się przez palce, ponieważ z natury rzeczy (jako że są tworzone przez użytkowników, niekoniecznie specjalnie zaawansowanych) są one skłonne do popularyzacji różnych mitów na temat poszczególnych dystrybucji. Acz chyba trzeba będzie w końcu coś z tym zrobić -- przyjrzeć się jak PLD jest widziane publicznie, skonfrontować to z rzeczywistością i postarać się stopniowo prostować nieścisłości.

Zapowiada się ciekawie, bo to już bardziej podpada pod PR i marketing. Oczywiście wiąże się to także z koniecznością określenia jakiegoś konkretnego kierunku rozwoju PLD i podobnymi sprawami. Mam zamiar trochę o tym wszystkim popisać, ale niestety nie w najbliższych tygodniach, no bo studia i praca. Ale nie ucieknie.

Th builder data

Fri, 11 May 2007 20:35:30 +0200

Per Patrys' suggestion, I've generated SQL data from builder activity and he promised to generate some graphs from them. I've uploaded it -- full version since end of 2005 and a short version with data for the last two months only. I was mainly interested in the amount of time the builders are actually active and it would appear that they still have lots of processing time left and we're not bogging them down that much.

If someone's curious and willing to spend a little time on it, it's perfectly possible to retrieve some interesting stats from the data (and generate pretty graphs; maybe using Swivel). Like who's the most active sender (arekm, the release manager; sends allmost as much requests as the rest of the developers combined) by month, how many requests were sent by month, etc, etc. I haven't added any info on whether the builds were successfull and whether they resulted in a (failed) upgrade, though that's doable and I'll most likely do it some time in the future (to get some broader idea about which architectures are the most problematic, which desync most often, etc, etc.). Also would be interesting to figure out builder downtimes (shouldn't be to hard to figure out an algo; let's say no builds for more then a day or two) and also plot that.

For people wanting to actually play with the data -- builder 'th-ftp' is just a script which mails ppl when it finds there's something wrong with a package and if you want to count unique requests actually sent by people, look at 'th-src' (however by comparison with the number of requests actually processed by the binary builders, it can be clearly seen that something like 28% of sent requests fail a the source builder). And one more thing -- the i486 lacks data for the past few months. That's because it stopped sending mails for some reason and nobody bothered to fix it.

Oh and here's the "script" I've generated it with. And yes, that's shell generating python, which in turns generates sql :)