mmazur.7thguard.net

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.

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?

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.

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.)

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ą. :(

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.

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.

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ć.

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.

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.

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ę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.

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?

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...

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 ;)

Aw, shucks, we're blushing.

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.

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?

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.

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 :)

Ponieważ robię piętnaście rzeczy na raz z których większość muszę zrobić sam, to niestety nie mam za dużo czasu. Acz nie obraziłbym się, jakby mi ktoś pomógł z pewną rzeczą (na potrzeby PLD).

Otóż bardzo by mi się przydały informacje o zajętości poszczególnych builderów (głównie Th, ale jak ktoś dorzuci Ac, to się nie obrażę). I niestety nie jest to zrobienia jakimś prostym dodawaniem/odejmowaniem i paroma grepami -- jedyny sensowny sposób, to wziąć informacje o buildach z dłuższego okresu i wyplocić jakieś ładne obrazki, żeby można było pooglądać "trendy" + do tego wygenerować jakieś średnie powiedzmy tygodniowe, etc.

Nie trzeba być specem od niewiadomoczego (nie trzeba być też deweloperem PLD), wystarczy mieć zacięcie i umieć się w miarę dobrze posługiwać shellem (sedy, grepy i takie tam) i/lub jakimś językiem skryptowym (pythonem, czy tam perlem) oraz rozgryźć jak się używa jakiegoś gnuplota, czy czegoś podobnego.

Jak ktoś będzie zainteresowany, to ja odpowiem na pytania bardziej szczegółowe i powiem co dokładniej jest potrzebne, ale ogólnie sprawa się ma tak, że ja daję paczkę maili z builderów Th, mówię jak wyciągać z tych maili interesujące informacje i jak konkretnie mają wyglądać dane wyjściowe, żeby były przydatne, po czym ktoś zabiera się za grepowanie, obrabianie i plotowanie, a na koniec dostajemy serię ładnych obrazków oraz dodatkowo trochę liczb.

Jeśli wszystko działa jak trzeba, dane okazały się przydatne, a delikwentowi się nie znudziło, to później mogę jeszcze dostarczyć paczkę maili z builderów th od początku ich istnienia (a nie tylko za dwa ostatnie miesiące), żeby dane były bardziej kompletne i dzięki temu użyteczniejsze.

(Zgłoszenia w komentarzach albo na żabę.)

Spisałem sobie, co mam zamiar napisać odnośnie m.in. tego, jak widzę przyszłość pld. Erm. I w sumie mi się odechciało pisać, bo trochę tego za dużo. Będzie się trzeba kiedyś wziąć, ale na pewno nie teraz, muszę inne rzeczy zrobić.

A przy okazji -- zna ktoś może stronę, która by w krótkich żołnierskich słowach opisywała przynajmniej te najbardziej popularne dystrybucje? I nie chodzi mi o 'przyjazna dla początkujących; bardzo bezpieczna', bo takie ogólniki są mi nieprzydatne -- potrzebuję konkretów, czyli krótki opis zasad paczkowania, używanego package managera, 'rozkładu' dystrybucji (drzewa testowe na ftpie, zasady 'promocji' paczek do na przykład 'stable') i może coś też o sposobie deweloperowania (sposób robienia releasów, trochę o technice pracy nad dystrybucją). Wątpię, żeby coś takiego istniało, no ale raz się żyje. Zna ktoś?

Kolega mi powiedział, żebym sobie zainstalował linuksa, ale nie wiem którego wybrać. Może pomożecie?

A na serio. Pytanie głównie do osób używających tych najpopularniejszych dystrybucji (gentoo, debian, ubuntu, etc.), ale także do tych, co używają mniej popularnych (w tym pld), pod warunkiem, że używali także czegoś innego (tzn. mają jakieś porównanie) -- co konkretnie, zwłaszcza przez porównanie z jakąś inną dystrybucją, spowodowało, że obecnie używacie tej, a nie tamtej. I to prosiłbym w miarę dokładnie, może być na jabbera, jak ktoś chce ze mną pogadać na żywo.

(Potrzebne mi to do pld, tzn. mam teraz fazę nad myśleniem sobie jak to pld mogłoby się rozwijać i potrzebuję mieć jakieś konkretne dane odnośnie tego, co powoduje, że różne dystrybucje są postrzegane jako fajne przez ich użytkowników.)

Prawie cztery lata po forku. Odzyskanie domeny to już chyba ostatni rozdział tej historii.

Heh. Prawa Murphy'ego. Ten mail to ja wtedy miałem wysłać na listę, ale akurat padł mi net.

Tyle lat. Jaki ja wtedy byłem młody.

Coś się rusza z organizacją prawną PLD. Powoli, bo powoli, ale do przodu. A to głównie za sprawą Arcadiusa Meeshkyevicha, który coś ma ostatnio dużo zapału bojowego. A to został Release Managerem PLD 3.0, później się coś mocno za różne części automatyki wziął, zajmuje się wspominanymi wczoraj donacjami na sprzęt, a teraz jeszcze to. Całkiem możliwe, że tym razem w końcu się uda (ja też jestem obecnie w innej sytuacji, niż byłem, więc mogę pojechać, podpisać, sypnąć groszem, etc.).

Od bardzo bardzo dłuższego czasu chciałem napisać kilka zdań na temat kwestii związanych z płaceniem deweloperom za konkretne funkcje przez taką przykładową fundację, ale przez ostatnie kilka dni wyprodukowałem tyle tekstu, że już mi się nie chce. Może za parę dni.

In other news -- mam na uczelni straszną ilość projektów w tym semestrze. Najprawdopodobniej uda mi się (przynajmniej częściowo) w ramach dwóch z nich dokończyć automatykę builderową (tak, że już właściwie nie będzie tam brakowało żadnej funkcjonalności; co najwyżej będzie trochę miejsca na polerowanie). Po pierwsze poprzez zrezygnowanie z używania poczty do przesyłania wiadomości między builderami (jest to wybitnie upierdliwe, a dodatkowo wymaga od serwera hostującego posiadania działającego demona pocztowego + instalki gpg). Najprawdopodobniej zostanie to zamienione na xmlrpc, czy coś w tym stylu.

Na bazie powyższego natomiast zostanie dorobiony jakiś centralny system zarządzania zleceniami na builderach. Jeszcze nie wiem do końca co to będzie robiło i jak zostanie zaprojektowane (ale wiem w czym -- mysql, php + interfejs webowy, bo o tym jest projekt na uczelnię :), ale na pewno będzie potrafiło wyświetlać obecne kolejki na builderach, modyfikować im priorytety oraz mordować aktualnie wykonujące się zlecenia.

Kto wie, może za parę lat wreszcie ziści się moje marzenie, że infrastruktura pldowa będzie na tyle rozbudowana, że Release Managerem będzie mogła zostać tresowana małpa. I wtedy po raz trzeci obejmę tę funkcję, ale tym razem uda mi się coś wydać!

Dla fanów strony pld-linux.org/Sponsors na pewno nie będzie to zaskoczeniem, ale osoby nie zaglądające tam co najmniej dwa razy dziennie może zainteresować jeden z nowszych wpisów.

Otóż pewnymi kanałami udało nam się otrzymać od amd cztery opterony na potrzeby rozwoju pld. Rationale? Ano powiedzieliśmy, że produkujemy trochę różnych patchy na tę architekturę i w ich interesie leży, żebyśmy je w miarę wygodnie mogli produkować dalej. Widać ktoś, gdzieś się z nami zgodził :)

(Kanałów niestety nie mogę wyjawić. Niech się głupi ochroniarze dalej zastanawiają jak udało nam się uprowadzić córkę prezesa.)

A, jak ktoś ma nadwyżki pieniężne, bądź jakieś walające się po domu dyski, czy inne kontrolery scsi, to niech zaglądnie na na stronę z listą potrzebnego sprzętu.

Już nie raz się spotkałem z tym, że ludzie mówią na PLD 'poldek'. Strasznie to dziwne. Jakoś nigdy nie widziałem, żeby na gentoo ktoś mówił 'emerge', albo na debiana 'apt-get'.

Istnieje pewna bardzo dobra zasada mówiąca, że jeśli masz być częścią projektu kogoś, z jakąś ideą, to zapisuj się tylko i wyłącznie wtedy, jeśli ów człek zapewni ci pełną swobodę działania, a swoją ideę będzie realizował dopiero na bazie twojej pracy. Tzn. żeby ingerencja w twój "naturalny" tok postępowania w celu realizowania Idei, była jak najmniejsza.

Jest to generalnie charakterystyka dobrego menedżera, że najpierw stara się zrozumieć jak działa to, czym ma zarządzać, później określa co by chciał zrealizować, a na końcu wymyśla taki plan, żeby osiągnąć maksymalnie dużo z tego, co osiągnąć chce, jednocześnie w jak najmniejszy sposób ingerując w zasady już wypracowane w ramach organizacji przez pracowników (oczywiście te zasady, które się sprawdzają).

Sytuację tego typu mam obecnie w pracy. I dopiero teraz jestem w stanie docenić wiedzę i doświadczenie, jakie dało mi obserwowanie różnych projektów open source oraz uczestniczenie (na różnych poziomach zaangażowania) w pld. Jestem też w stanie docenić jak dużo mogą dać ludziom rzeczy typu radio studenckie, czy jakiekolwiek inne projekty robione w grupie.

I jako ciekawostka. Oto projekt człowieka, który jednak nie do końca rozumie jak osiągnąć to, co chciałby osiągnąć.

Quite recently I've stumbled across another one of the many smaller rpm based distros out there. It's not the first time I got interested in such a project and probably won't be the last, because to me they all are potential candidates for using PLD as their base. And I really think having a bunch of such projects (not PLD per se, but using our packages and at least parts of our infrastructure) would be really beneficial to both PLD and the external projects involved. Let me tell you why.

I could say that there are two main reasons for PLD being a very good base distro, one technical and the other organizational, but in reality they are really interconnected, so I'll try to cover both of them in one pass.

First thing to keep in mind is that PLD is really a lot more about technology then about providing a product. Sure, we do have something that could more or less be called a linux distribution, but on a day to day basis, most developers just view it as a place for keeping the software they use in one place and not something one treats as a whole. I assume at least some people would object, but let's face it -- our track record with regards to doing actual releases is probably worth a thousand words. PLD, being nine years, has one official release which has been abandoned ages ago, one in permanent freeze mode (we could probably advertise it as a remedy for global warming) and one in active development. Yes, we've always looked up to Debian.

Let's face it -- we're just not that good at getting our acts together and agreeing on something that could be put in a box.

This has its upsides however -- it means that the project has developed internal policies that are mostly meant to stay out of developers' ways. Otherwise, with actual releases clearly lagging, the project would collapse under it's own weight a long time ago (we did get close to that while releasing PLD 1.0, but that's a long story).

So what are those policies? Well, for the most part, there simply aren't any. There are a lot of technical things to keep in mind, best practices, kosher ways to do things 'n stuff (PLD is one of those projects that really push what rpm's capable of). But other then that, people are generally free to do whatever they want and need. Sure, there are some rules with regards to how our cvs repository is organized, but that too is rather straightforward and thought up in such a way, that the most popular types of changes aren't a pain in the ass for the developers performing them.

So how would a new project fit in? First, it'd be best for someone to talk to one of our more experienced developers (I'd be more then happy, so feel free to ping me) in order to discuss expectations and possibilities. After that it's just a matter of that developer writing a short email with a request for new developer accounts, having two other developers sign off on it (that's never a problem) and voila -- the new guys are free to start playing.

But what exactly would they be free to do?

Well, alter packages obviously. Let's say you want to build a desktop oriented distribution for home users. First thing -- they don't need stuff like openldap, mysql or postgres linked everywhere. No problem, just define appropriate global bconds (build conditionals; think USE flag from gentoo's emerge) on your build machine and build the required packages. You'll probably have to add bconds (or fix support for them) in a package or two, but generally that should be a quickie.

Ok, now for something more ambitious. PLD by default produces a shitload of subpackages for every app. Just to show you what I mean.

poldek:/ac> ls kde
Display all 716 possibilities? (y or n)

You probably don't want that in a desktop distro, since it'll just confuse users. So is there a way to somehow change this while still keeping your changes mergable with PLD? Yup. One solution -- you can create metapackages that just have a lot of Reqs on the subpackages you want. Or a more elegant approach -- using a bcond, depending on which rpmbuild will produce either a big package for, let's say, kdelibs or a multitude of subpackages (and I did test that's it's in fact possible, although I haven't seen anyone actually using this yet; see comment on pushing rpm :).

And now for something even bigger. Below is a typical way of how PLD splits libraries by default.

poldek:/th> ls libogg-*
libogg-1.1.3-2
libogg-debuginfo-1.1.3-2
libogg-devel-1.1.3-2
libogg-static-1.1.3-2

Libogg is the main stuff, debuginfo is something for gdb to munch on, devel are mostly C headers and static are static versions of a given lib (think .so vs. .a files). Confusing for our desktop users? You betcha. The same bcond rule applies here, however going through

[mmazur@klapek SPECS]$ ls|grep spec$|wc -l
11325

spec files and adding a bcond into each and every one of them probably isn't the way to go. The preferred solution here would most likely be altering rpm and it's default macros in a way that would allow for a global bcond that would work on all (well, most, some would probably need fixes of various sorts) our spec files out of the box.

And that's just a taste of the technological freedom offered in PLD. Rule of thumb is -- as long as your changes don't actually break anything for other developers, aren't ugly as hell and are in compliance with our technical policies -- you have a green light.

(And if you want to do something really weird, there's always the possibility to branch it, however I would advice against doing that too often -- we're using CVS which is not all that great with branches, even considering we have a healthy amount of scripts helping us with various tasks. YMMV however.)

There is more of course. I won't go into details, but we do have things like a builder infrastructure (python scripts for automatic package building and uploading) and an ftp infrastructure (ditto for tossing those packages around an ftp site) plus you're quite likely to be able to get someone to host your builder or two. And if you're worried about those systems not satisfying your needs -- PLD 2.0 has 8 basic distinct targets for which packages get built (that's five distinct architectures), meaning a lot of builders and a lot of files to keep track off on our ftp server. And it's all being run by a single guy. With a sex life. Involving another person. Not over the internet. And not the phone, either.

Sure, there's still a lot to be done there, but I do believe those scripts should constitute a really reasonable basis for most people.

Oh, and if you're worried about us being too Polish oriented, there's no need to. All cvs commits are in English, our website is in English, and though the Polish devel maillists are seeing more traffic then the English ones, that's just because people are lazy. Threads started on the English lists get the same amount of attention.

And if you don't believe me, we have two non-Polish developers, one from .us and the other from .ee (no, I won't tell you what obscure country that is, go look it up), that will be more then happy to confirm my story. And their willingness has absolutely nothing to do with us having their relatives held hostage.

Really.

For the record -- a couple of days ago Arcadius Meeshkyevich announced that he has taken over the position of Release Manager for PLD 3.0. Most developers agree that this should speed up the release of said PLD Th by at least a decade or two.