mmazur.7thguard.net

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.

Temat interesujący, ale ponieważ nigdy nie miałem specjalnie dużo wspólnego z bezpieczeństwem komputerowym, nie mogę poniższych tez przedstawić z pierwszej osoby. Zamiast tego widzicie mocno przeredagowaną przeze mnie dyskusję ircową sprzed kilku dni. Występują: M -- ja, N -- znajomy programista niehakier oraz S -- znajomy były hakier... a zresztą sam się przedstawi.

(To są zabawy z formą. A jak ktoś nie zauważył, to wydźwięk poniższego ma być taki romantyczno-nostalgiczny.)

S: No więc faktycznie, mam w czytniku RSS-owym securityfocus.com i milw0rma, ale nie bawię się tym już od dawna, tzn. tak od dwóch lat. Z małym incydentem pomiędzy, ale to była rozrywka tylko :)
A nie robię już tego z trzech powodów: raz -- nie mam czasu, dwa -- jest dużo dużo trudniej i mi się nie chce :) oraz trzy -- przestałem być na bieżąco i jest ciężko w to wskoczyć.
Ale faktycznie, czasy się trochę zmieniły i jest już zupełnie inaczej, niż kiedyś. Przez to, że nowe języki (np. python), stały się popularniejsze, sporo "zabezpieczeń" jest już na tym poziomie. Odpadają wszystkie buffer overflowy, off-by-one, format stringi i cała masa innych błędów. Plus właśnie jakieś NX bity i tego typu rzeczy, które dość skutecznie przeszkadzają.
No i cała masa ludzi, którzy się tym zajmowali i byli diablo dobrzy albo zajęła się czymś innym, albo pracuje w którejś security company, albo rozpłynęła się w powietrzu. Trochę kontaktów dalej utrzymuję, ale właściwie ogranicza się to do jednego kanału na IRC-u na efnecie.

N: A kto był dobry i może o nim słyszałem? Ale nie jakieś lcamtufy, tylko inne :)

Udało nam się ustalić następujące nicki: insect, appelast, nergal, venglin, z33d, bulba, kil3r. Ja dorzuciłem jeszcze carsteina :)

S: Kto tam jeszcze... halfdead, ludzie z synnergy.net, v0id, twd. Ale to raczej blackhaty, mało o nich słychać.

N: A są na przykład goście, którzy są "sławni", ale nikt ich nie zna? Tzn. zrobili coś spektakularnego i podpisali się jakoś pseudonimem artystycznym, ale w sumie nikt nie wie kto to, bo na IRC-u ich nie ma, nikt ich nie zna, itd.

S: W sumie gobbles, ~el8.

M: Jak rozumiem wyjaśniło się kto siedział w gobbles?

S: Ja wiem tylko o anakacie, ale to chyba nie wszyscy, którzy się tam udzielali :)
No i oczywiście całe team-teso, segfault.net, thc.org, hert.org, pheneolit. To chyba największa elyta, chociaż trochę się złajthacili w pewnym momencie :)

S: A z polaków jeszcze mi przyszedł do głowy cliph i funkysh, czyli isec.pl. I masa bugów w kernelu :) No i Paul Starzetz "ihaquer" też tam z nimi robił.
No i to są takie whitehaty, które po nocach psują :) Tzn. byli. Teraz już nie wiem.

M: Jak byli młodzi i szaleni, to pewnie produkowali sploity. Jak są starzy, to mają co robić, przestało im się chcieć i raz na ruski rok cośtam wypuszczą z nudów.

N: Czyli jednak, hakerstwo to robota dla młodych gniewnych.

S: Na to wygląda. Tzn. insect z tego co wiem jest tak pod 40-tkę już chyba.
Tak sobie przeglądam phrack issues i zauważyłem, że kojarzę autorów z ksyw i nazwisk max do numeru 54. Starszych już nie znam :)
W sumie kusi mnie, żeby pojechać znowu na jakiś ph-neutral albo CCC, żeby napić się piwka. Jak byłem na ph-neutral w 2005, to faktycznie, jak sobie pomyślę teraz, średnia wieku była gdzieś koło 22-23 pewnie. Ludzi po 30-tce można by policzyć na palcach jednej ręki.

M: Studenci. Za nastolatka się bawisz, koło dwudziestki masz już pokaźną wiedzę i możesz rzeczywiście coś większego zrobić. W ciągu max paru lat się wtedy wystrzelasz, później zasysają cię korporacje i kaplica.

S: No, tak to chyba działa.

N: O ile wcześniej nie zrobisz czegoś głupiego za co dostaniesz wyrok :)

S: Albo zostajesz idealistą i zakładasz TPB [ThePirateBay; wspomniany wyżej anakata to jeden ze współzałożycieli -- przyp. mm]
Albo spamerem. Masa spamerów to ex-haxorzy. Sam znam dwóch. Haxorom łatwiej, bo znają się na rzeczy, ale ciężko znaleźć drugiego takiego, jak anakata :)

M: Ale spamowanie jest... :(
No właśnie. Security się kurwa skomercjalizowało.

S: Ja to wiem...

Od czasu kupna dziadkom laptopa i podłączenia Internetu, mam dosyć unikalną okazję rozmawiania z kimś, dla kogo komputery nie istnieją "od zawsze" i to wszystko jest nowe. Dwie rzeczy stają się jasne: po pierwsze nowoczesne środowiska graficzne, zwłaszcza do kupy z Internetem, są skomplikowane i po drugie -- terminologia z nimi związana też jest bardzo skomplikowana, wcale nie taka intuicyjna i ma dużo niejasno zdefiniowanych przypadków specjalnych.

Przykład pierwszy: pendrive'y vs. płyty.

Wkładasz pendrive'a, pokazuje się okienko, kopiujesz pliki, wyciągasz pendrive'a, działa (chyba, że nie działa, bo najpierw trzeba "odmontować wolumin"; dziwny gnome, jutro będę z tym walczył). Wkładasz płytę, odpalasz jakiś program (nawet bardzo prosty, jak gnomowy asystent nagrywania), "kopiujesz" do niego pliki (ale one wcale się nie skopiowały), wciskasz "nagrywaj", czekasz i dopiero teraz się skopiowały. Dlaczego tak jest? No bo pendrive'y są na flashu, który działa jak zwykły dysk komputerowy i jest bardzo szybki, można łatwo kasować i nadpisywać i w ogóle, natomiast płyty optyczne tradycyjnie są nagrywalne tylko raz (i to powoli), więc najpierw trzeba się zdecydować co chce się nagrać, a dopiero później się nagrywa. Proste! Acz prostsze będzie "bo tak".

Przykład drugi: tacka systemowa.

Gadu-gadu (a konkretnie gaim; coś gnomowe w każdym razie) odpala się razem z komputerem i jak się chce, żeby się okienko z listą kontaktów pojawiało, to trza kliknąć w ikonkę na górze. Analogicznie ze skypem. Co się dzieje, jeśli przez przypadek usuniesz tackę systemową z tego paska na górze (sam nie wiem jak to się cholera nazywa)? Nie ma ikonki gg. Więc trzeba ją przywrócić! No bierze się z menu "Aplikacje", przeciąga na pasek i jest mała ikonka, dokładnie w tym samym miejscu. I jak na nią klikniesz, to pojawia się okienko z listą kontaktów, tylko takie kompletnie niedziałające. I jak się na nią kliknie jeszcze raz, to się drugie niedziałające pojawia. Etc, etc.

Co jest nie tak? No więc jak klikasz na ikonkę na tacce systemowej (?), to ona tylko przywraca (?) zminimalizowany (?) nie do paska zadań (?) program (?), natomiast dokładnie taka sama ikonka osadzona bezpośrednio na tym górnym pasku (?) uruchamia program (?), a nie przywraca już uruchomiony. Znakami zapytania zaznaczone różne dziwne terminy, które trzeba znać, żeby zrozumieć tę wypowiedź.

Przykład trzeci: co to w ogóle jest ten program?

Ano właśnie. Program to takie instrukcje, które można uruchomić, że z dysku do pamięci... eee. Jest dysk i jest pamięć i jest procesor. I przy uruchamianiu program jest wgrywany z dysku do pamięci i on wtedy w tej pamięci siedzi i działa... Eeee. Ale jak on już jest odpalony, znaczy uruchomiony ten mityczny program, to on później może wczytywać różne dokumenty, czyli jak jest oowriter, znaczy ten program do pisania dokumentów, to to białe z tekstem to jest dokument, a wszystko dookoła to jest program.

I dlatego jeśli kopiujesz plik oowriterowy na pendrive'a i później go otwierasz, to on wcale nie siedzi na tym pendrivie razem z tymi ikonkami dookoła (toolbar oowritera), bo te ikonki to jest część programu, a nie dokumentu. I wyeksportowanie dokumentu do pdf-a i wgranie na pendrive'a to wcale nie jest "przegranie samego dokumentu bez programu", bo on zawsze jest "bez programu", tylko po prostu gpdf (czy jak to się tam w gnomie nazywa) ma mniejszy toolbar od oowritera no i jest read-only.

Wszystko jasne? Nie? No trudno, żeby było, jak dalej nie udało mi się wytłumaczyć co to jest ten program i jak wygląda jego cykl życia w komputerze.

Przykład czwarty: terminologia ciąg dalszy.

Dlaczego okno się nazywa oknem? Prawdę powiedziawszy sam nie wiem. A jakby się dobrze zastanowić, to co okienko w komputerze ma wspólnego z takim prawdziwym oknem? Że jest prostokątne? Drzwi też. Microsoft Doors Vista. X-Door.

Dziadek na okna mówi tabele i niezbyt często pamięta, żeby mówić "okna". Ma sens. Prostokątne, ma wiersze i czasami się kolumna trafi. Ja się dalej w sumie nie przyzwyczaiłem i za każdym razem, jak mówi "tabela", to się staram wyciągnąć dalsze informacje, czy to rzeczywiście chodzi o to, co ja myślę, że chodzi.

Okno, przycisk zamykania/maksymalizacji/minimalizacji, belka tytułowa, pasek menu (czy jakoś tak), pasek narzędzi (? że to z ikonkami znaczy się), menu kontekstowe, menu. Właśnie, menu. Menu "Aplikacje" w gnomie to menu. Menu kontekstowe pod prawym przyciskiem myszy to menu. Menu w gaimie na którym widać listę kontaktów, to nie jest menu, tylko lista kontaktów. Dlaczego? Eeee. No bo... Eeee. W sumie nie wiem. Jestem pewien, że ma to odzwierciedlenia w nazwach elementów API Gtk, ale to nie jest wytłumaczenie. Jakbym miał się zastanowić, to "menu" zazwyczaj mają czasowniki, natomiast "listy" rzeczowniki. No i inaczej wyglądają. Czy jakoś tak. Nie wiem :(

No i mógłbym tak w nieskończoność.

Podsumowując -- przy obecnym poziomie skomplikowania tak architektury działania współczesnych systemów operacyjnych, jak i używanych przez nich środowisk graficznych, ja większości typowych problemów nie jestem w stanie wytłumaczyć z sensem bez jakiegoś wcześniejszego kursu z podstaw systemów operacyjnych i obsługi środowisk graficznych. Po prostu się nie da.

Archetypiczna sekretarka ucząca się "piąte menu od prawej" w Excelu jest całkiem zabawna, póki człowiek sobie nie zda sprawy z tego, że żeby to rzeczywiście zrozumieć trzeba przyswoić naprawdę sporą ilość wiedzy. Ludzie wychowani z komputerami mają o tyle dobrze, że ich mózg się nauczył rozróżniać to wszystko i oni intuicyjnie wiedzą jak z tego korzystać, nawet jeśli świadomie nie wiedzą dlaczego coś działa tak, a nie inaczej. Osoby później mające styczność z komputerami mają po prostu dużego pecha.

<@mmazur> Jak się nazywa ta belka na której wszystko jest na dole ekranu?
<@mmazur> Tam gdzie jest menu start, pasek zadań, tacka systemowa, etc?
<@fixxxer> taskbar?
<@mmazur> A po polsku?
<@fixxxer> aka pasek zadań?
<@mmazur> Hmmmm.
<@mmazur> Pasek zadań to jest u mnie tylko aplet tego czegoś na którym jest lista zadań.
<@mmazur> KDE to po prostu 'panel' nazywa.
<@mmazur> Chyba.
<@fixxxer> a, ty pytasz o linuksa :)
<@fixxxer> no to nie wiem jak w kde, ale w gnome to jest właśnie panel
<@fixxxer> (przy czym w gnome są dwa)
<@mmazur> Górny i dolny?
<@fixxxer> (domyślnie)
<@fixxxer> mhm

Się człowiek całe życie uczy :(

Właśnie się dowiedziałem, że bash ma vi mode. Ile czasu bym zaoszczędził, gdybym się o tym fakcie dowiedział sześć lat temu :(

Postanowienie noworoczne: zidentyfikować wszystkie używane przeze mnie codziennie narzędzia i przeczytać ich dokumentację od deski do deski!

Iiijasne. Przy okazji będę milszy dla ludzi, będę częściej sprzątał mieszkanie, zrzucę z 10 kg, będę częściej dzwonił do rodzinki, mniej przeklinał...

1. Nagranie jest mocno przeedytowane pod kątem przydatności do słuchania. Jeśli ktoś pamięta, że coś się wydarzyło inaczej, niż jest nagrane, to wysoce prawdopodobne, że dobrze pamięta.
2. Wyciąłem co najmniej kilka minut swoich mlasknięć (co mikrofon bardzo ładnie ponagrywał), chrząknięć, eeeeeyyyyeeeeeania, za długich pauz, przerw technicznych oraz najzwyklejszych wpadek. Więc nie, wcale tak płynnie nie mówię.
3. W środę miałem depresję, że poszło tragicznie. Po przesłuchaniu stwierdzam, że aż tak strasznie tragicznie wcale nie poszło. Nic czego nie może naprawić kreatywna sesja z edytorem dźwięku.
4. Acz kilka rzeczy jest oczywistych -- po pierwsze, wcale nie mówię tak płynnie i poprawnie technicznie, jak mi się wydawało, że mówię :(
5. Po drugie -- miałem nadzieję zrobić super zajebistą prezentację. Poświęciłem na nią z dwa-trzy razy więcej czasu, niż zwykle poświęcam na takie rzeczy. Wyszło niewiele lepiej, jeśli w ogóle. Jedno staje się dla mnie jasne -- jedyny sposób na idealnie płynną prezentację, to po prostu usiąść, napisać całość słowo w słowo i później albo czytać, albo wyryć całość na blaszkę. Nie ma siły, żebym z kartką opisującą tylko schemat wystąpienia był w stanie przeprowadzić je płynnie -- bez zacięć, bez pauz, bez niepotrzebnego powtarzania się. Po prostu się nie da. Może są jacyś geniusze, którzy potrafią, ale generalnie wątpię, żeby to było w zasięgu normalnego człowieka. Mowa ludzka tak nie działa. Zapomina się słów, robi pauzy, gubi wątki, różne rzeczy rozpraszają.
6. Po trzecie -- jeśli chcę zrobić płynną integrację tego co mówię, z tym co jest na rzutniku, to powinienem mieć w zasięgu wzroku swój laptop, żebym nie musiał się odwracać w celu upewnienia się co właściwie w danym momencie jest na rzutniku (mam ten bezprzewodowy dynks do obsługi prezentacji, więc mogę zmieniać slajdy patrząc się na publiczność). Takie odwracanie psuje płynność, a i mnie dekoncentruje.
7. Po czwarte -- różne techniczne drobiazgi o zwracaniu uwagi na które człowiek się uczy z wykładu na wykład.

Link do ogga. Jutro jeszcze powinien być nius na stronie oplugowej wraz z jakimiś fotkami.

A, disclaimer: mówiąc zrobiłem sporo uproszczeń, a i wykład był dosyć konkretnie stargetowany (na studentów, którzy nie wiedzą jak takie rzeczy ugryźć). Dodatkowo co najmniej kilka razy powtarzałem, że coś jest moim poglądem na sprawę i na pewno są miejsca, gdzie to działa (z powodzeniem) kompletnie inaczej. Także wiem, że nie opisałem wszystkiego, co było do opisania. Był to świadomy wybór.

Doświadczenie uczy, że jeśli wyjeżdżam do rodzinki na parę dni, to nie zrobię tam absolutnie nic z tego, co sobie zakładałem, że zrobię. Wniosek -- całą robotę "na już" robić przed wyjazdem, by móc w pełni korzystać z urlopu. Starzeję się.

Jedną z rzeczy, które miałem zrobić było przygotowanie tego wykładu. No cóż, mam jeszcze dwa dni czasu. A tak w ogóle, to zapraszam.

Acz jeśli ktoś ma pecha żyć w Polsce B (czytaj: poza Opolszczyzną), to rzecz będzie nagrywana (sam dźwięk; niestety nie mam kamery, żeby nagrać obraz i uzupełnić kolekcję) i jak będzie dostępny ogg, to tutaj dam info (no i na stronę oplugową). Także stay tuned.

Jak to w życiu -- wszystko ma swoje zady i walety.

Było tak: pracowałem nad systemem korzystającym z dziesiątek procesorów, gigabajtów RAM-u i gigabitów łącza. Naszym klientem były korporacje od których, jako programiści, byliśmy dodatkowo oddzieleni mało przepuszczalną warstwą szefostwa.

Jest tak: nowa firemka oficjalnie działa od półtora miesiąca. Jestem szefem działu IT. W praktyce oznacza to, że zajmuję się naszą "wirtualną" infrastrukturą oraz odpowiadam za większość rzeczy mających coś wspólnego z programowaniem.

Różnice? Sporo. Pierwsza -- poprzednio "klient" był dla nas bytem czysto wirtualnym. Terminy przychodziły i odchodziły. Nie odczuwaliśmy praktycznie żadnych konsekwencji naszej pracy (tak pozytywnych, jak negatywnych). Szefowie wiedzieli co i jak, a myśmy byli za firewallem. Teraz natomiast jeśli zawalę termin, to będę mógł się pójść osobiście potłumaczyć facetowi, który za zlecenie zapłacił. Oraz jego pracownikom, którzy z systemu mieli korzystać. Poziom odczuwalnej odpowiedzialności jest zdecydowanie inny.

Druga różnica -- pieniądze. Zaczynam podejrzewać, że w takim lowendowym plumkaniu, jakim się obecnie zajmuję, po prostu nie ma sensownych pieniędzy, a co za tym idzie, jest ono praktycznie skazane na marną jakość. Jeśli masz doświadczenie, interesujesz się tym, co robisz, jesteś na bieżąco z nowymi technologiami, to będziesz się zajmował nadzorowaniem jakiegoś mikroprojekciku w PHP za grosze? Czy może jednak pójdziesz pracować w sensownej firmie za sensowne pieniądze, albo założysz zaawansowanego technologicznie startupa z zamiarem zbicia na nim kokosów? No właśnie.

Case in point -- mam ponad półtora roku doświadczenia z całkiem sporych rozmiarów systemem rozproszonym. A zajmuję się administracją niewielkiego serwerka linuksianego oraz nadzorowaniem jednego PHP-owego kodera, gdzie wspomniane doświadczenie jest mi tak niesamowicie przydatne...

Oczywiście są i zalety. Po raz pierwszy od lat moja lista TODO nie jest nieskończona. Ba, kurczy się! Mam na niej zaledwie kilka pozycji i wiem, że jeśli przysiądę, to pod koniec tygodnia mogą zostać może dwie. Zacząłem znowu czytać książki! Na razie powoli, ale się rozkręcam.

Dodatkowo fajnie się patrzy na tego mojego PHP-kodera, jak się uczy. Czystszy kod, lepsza struktura, lepsze narzędzia, separacja kodu i HTML-a, smarty, porządnie zaprojektowana baza danych. Jeszcze z dwa takie projekty i będzie na tyle samobieżny, że w ogóle nie będę musiał patrzyć na to co on robi. A jak zechce później znaleźć sensowniejszą pracę, to nie powinien mieć problemów.

I, ponad wszystko, nie ma to jak możliwość ustalania własnych priorytetów. Znacznie przyjemniej się pracuje.

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

Padaka. Jedyny SCM, który ma windowsowe GUI z prawdziwego zdarzenia (tzn. integrację z Windows Explorerem), to subversion via tortoisesvn. Więc chcąc nie chcąc, będę w firmie używał scentralizowanego SCM-a, bo alternatywy są jeszcze bardzo niedopracowane: bzr-tortoise, tortoisehg i tortoisedarcs są albo stare, albo niedopracowane, albo masakrycznie trudne w instalacji. A zazwyczaj po trochu z każdego. (Patrzcie i płaczcie.)

Za to tortoisesvn jest po prostu miły. I widać, że się autorom chce.

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

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 wielu wielu lat uparcie twierdzę, że nie lubię programować. Ostatnio usłyszałem ciekawe stwierdzenie -- pisanie programów jest dlatego wciągające, że programista ma cały czas wrażenie, że już zaraz za chwilę wszystko mu zacznie działać. I chyba coś w tym jest. Jeśli już się zmuszę do zabrania się, to czas upływa dosyć szybko i się nie nudzę. Rzecz w tym, że ja już bardzo dawno temu sobie w jakimś stopniu uzmysłowiłem, że "już zaraz za chwilę" to tylko złudzenie. Mam już pewne doświadczenia w tej kwestii, ale i tak nadal konsekwentnie udaje mi się niedoszacowywać czasochłonność kolejnych projektów. I tego właśnie nie lubię. Ten jednozdaniowy punkt na liście TODO może mi zająć równie dobrze 4 godziny, jak i najbliższe dwa tygodnie. Tym bardziej do szewskiej pasji doprowadza mnie fakt, że poniekąd pracuję w dziale R&D.

A, tak, radości płynące z pracowania nad rzeczami, których nikt wcześniej nie robił i których działania tak do końca nie jestem w stanie zrozumieć. Jest problem? No to trzymam kciuki, żeby wyrobiona na poprzednich błędach intuicja naprowadziła mnie na prawidłowe rozwiązanie. A jeśli nie naprowadziła? To za kilka tygodni, gdy będę miał już tego po dziurki w nosie i będzie mi się chciało płakać, kompletnie przez przypadek znajdę jakąś drobną rzecz, która wszystko naprawi. Przeżyłem to już kilkukrotnie, w tym kilka dni temu.

Przy czym różnica pomiędzy teraz i kiedyś polega na tym, że kiedyś na zakończenie takiego maratonu wysmarowałbym obszerny mail do przełożonego z "wytłumaczeniem" dlaczego nie działało i dlaczego moje zmiany wszystko naprawiły.

Teraz nie mam już takich złudzeń. Nie wiem co konkretnie powodowało, że system nie działał, nie wiem które z moich działań tak naprawdę poprawiły jego działanie, a tym bardziej nie wiem dlaczego.

I tylko jak sobie przypominam kazania Dijkstry o tym, jak to programy powinny być formalnie weryfikowalne, a nie pisane "na czuja", to mnie pusty śmiech ogarnia. Szkoda, że nie jestem satanistą, bo bym mu zbezcześcił grób, albo coś.

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

Aw, shucks, we're blushing.

Zadanie pierwsze: napisać w ramach R&D mocno skomplikowany system, który pozwoli stwierdzić, czy to, co chcielibyśmy sprzedawać klientom jest w ogóle wykonalne.

Zadanie drugie: stworzyć drugą generację centralnego systemu przechowywania, analizy i wizualizacji (bardzo bardzo dużych ilości) danych. Pierwsza generacja to prosty php i mysql mojego autorstwa. (Ta prostota to chyba główny powód, dla którego jest to nadal względnie łatwe do maintainowania i po niezliczonej ilości rozszerzeń i poprawek nadal się nie zawaliło.)

Konkretne problemy techniczne do rozwiązania opiszę w następnym poście (lub dwóch). Za dużo by tego było na teraz.

Wnioski: poziom skomplikowania tego wszystkiego jest straszny. Poświęcenie sporych ilości czasu na zapoznanie się z konkretną technologią zanim się jej użyje na pewno zwiększy trafność podjętej decyzji, ale i tak poziom niepewności w tym wszystkim jest wysoki. Właśnie zaczyna do mnie docierać dlaczego na pewnych stanowiskach warto zatrudniać ludzi z co najmniej kilkunastoletnim doświadczeniem. Młodzi zdolni mają swoje zalety, ale trudno nie docenić człowieka, który przychodzi, mówi "robiłem już coś takiego pięć razy", po czym zabiera się do roboty.

Nawiasem mówiąc zastanawiam się jak wygląda poziom skomplikowania programowanie vs. administracja. Pierwsza reakcja -- programowanie bardziej skomplikowane. Z drugiej strony -- ilość wiedzy odnośnie samego Oracla jest gigantyczna. A przy obecnym nacisku na heterogeniczność sieci można wylądować co najmniej z kilkoma ekosystemami (windows vs. linux, oracle vs. cośinnego, iis vs. apache, java vs. .net) i też trzeba tym jakoś zarządzać.

Eh. Jutro się zapisuję na fryzjerstwo.

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

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

Przeczytałem "Pragmatycznego Programistę". Większość rzeczy tam zawartych była mi w większym lub mniejszym stopniu znana, więc część podrozdziałów albo tylko przeskanowałem, albo w ogóle zignorowałem [1]. Tak czy siak książka zdecydowanie dobra i polecałbym wszystkim początkującym (i nie tylko) programistom. Zwłaszcza żałuję, że nie przeczytałem jej jakieś dwa-trzy lata temu (co najmniej; preferowalnie znacznie wcześniej), zanim zabrałem się za pisanie pldzianej automatyki ftpowej. Wtedy zacząłem po raz pierwszy bawić się na serio obiektami w pythonie i tak sobie klepiąc przyszło mi do głowy, że ok, samo tworzenie obiektów jest proste, tyle, że nie mam zielonego pojęcia w jaki sposób dzielić różne rzeczy na obiekty. Szkoda, że wtedy nie postanowiłem coś bardziej doczytać na ten temat.

[1] Jak byłem mały, to potrafiłem przeczytać od deski do deski praktycznie dowolną knigę. Teraz niestety już nie potrafię -- znacznie spadła mi tolerancja na książki techniczne -- za dużo tam słów, za mało przydatnej treści. Nawiasem mówiąc będę musiał pomyśleć w jaki sposób dałoby się napisać książkę tak, żeby zaawansowani nie mieli wrażenia, że tracą czas, a jednocześnie ci nie do końca zaawansowani byli w stanie z niej coś wynieść. Bo zdecydowanie powinno się dać.

Jedna rzecz jest w tym wszystkim mocno przerażająca -- ogrom materiału. Wszyscy znają przypowieść o archetypicznym 'informatyku', który kiedyś nauczył się jakiegoś visual basica i do tej pory wszystko robi przy jego pomocy. No i prawdę mówiąc ja się nie dziwię. Takie rozwiązanie jest bardzo kuszące.

Naczelną zasadą tej książki jest, że programista powinien wiedzieć wszystko o swoim fachu, bo tylko dzięki temu może dobierać właściwe narzędzia do zastanych problemów i używać ich w prawidłowy sposób.

Tylko ile tego wszystkiego jest! Ekosystem uniksiany (shelle, skrypty, szybkie przetwarzanie tekstu), ekosystem javowy (eclipse, javadoc, jUnit, jBoss, jAdziękuję), ekosystem .netowy, języki dynamiczne (trza by przynajmniej z dwa teraz znać, tj. pythona i ruby'ego), a to tylko same narzędzia. Do tego dochodzi jeszcze masakryczna ilość wiedzy, żeby z tego sensownie korzystać. Już te lata wymagane na zdobycie doświadczenia w tym wszystkim pominę -- poznęcam się trochę nad samą suchą wiedzą odnośnie programowania (obiektowego). Na niskim poziomie trza znać jakiś język (maluteńki język zwany javą na przykład). Do tego dochodzą te wszystkie narzędzia i frameworki. Do tego na najwyższym poziomie jakieś typowe architektury, MVC, klient-serwer, etc. A żeby nie było zbyt różowo, to taki UML (z którego olewamy 99%, bierzemy tylko podstawy) i jeszcze jakieś wymysły typu design patterns.

Brrr. W przypadku tych ostatnich zdecydowanie zgadzam się z krytykami -- jeśli przy rozwiązywaniu określonych typów problemów koduje się w sposób, który "zasługuje" na stworzenie wzorca, to znaczy, że nie powinno się robić wzorców, tylko (a) rozszerzyć język o nowe abstrakcje i (b) zrobić jakiś framework/zestaw modułów do niego. To co już jest, jest i tak cholernie skomplikowane, więc zupełnie nie podnieca mnie przedzieranie się przez formalne opisy wzorców projektowych, żeby znaleźć ten, przypominający akurat to, co mam zamiar robić. W takich przypadkach zdecydowanie powinienem mieć gotowy framework, który prowadzi mnie za rączkę krok po kroku, minimalizując przy okazji szansę, że sobie odstrzelę nogę.

Ja jestem leniem. Ja się nie lubię uczyć nowych rzeczy zbyt często. Ilość wiedzy jaka w tym wszystkim jest zawarta mnie przeraża.

(A jak ktoś już jest kompletnie pokręcony, to może spróbować się nauczyć htmla, cssa i jsa w stopniu zaawansowanym, tzn. takim, który wystarczy do stworzenia jakiejś bardziej zaawansowanej strony działającej we wszystkich popularniejszych przeglądarkach. Good luck.)

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

Ja do tego całego CC zawsze miałem stosunek, erm, no w sumie nigdy nie wiedziałem na co to komu właściwie ma być. Tak, jasne, wszyscy teraz blogi piszą na potęgę, tyle contentu, więc jakby się go dało sklejać do woli, to by było fajnie i w ogóle. Ale kto by chciał sklejać i po co?

Aż mnie właśnie trafiło, jak przejrzałem artykuł o zasadach działania algorytmów kwantowych, nie używający nic, poza podstawową algebrą. Osoby mnie stale czytające już pewnie dawno zauważyły, że mam zboczenie na punkcie sposobów wtłaczania wiedzy w (zwłaszcza młodych) ludzi. Jestem zdania, że jak najwięcej profesjonalistów z wszystkich dziedzin powinno się zajmować tą kwestią i próbować coś robić w tym kierunku, bo dzięki temu raz na jakiś czas trafiają się ludzie, którzy rzeczywiście wykombinowali jak takie rzeczy powinno się pisać i dzięki nim powstają różne perełki. A to właśnie z czytania takich rzeczy powstają pasjonaci. Początkujący programista wie tylko tyle, że po przeczytaniu paru stron tekstu i wklepaniu kilku magicznych znaków w edytor, nagle pokazuje się na ekranie 'hello world'. On jeszcze wie i rozumie bardzo mało (kompilator? linker? kod maszynowy? polimorfizm? czarna magia?), ale to jest już ten najważniejszy początek, dzięki któremu ma motywację do dalszego zgłębiania tematu.

Ale wracając do tego kwantowego artykułu -- takich rzeczy jest na pewno więcej. Z niezliczonej ilości tekstów na te tematy (i na wszystkie inne), zapewne dałoby się zebrać do kupy te kilka napisanych przystępnym językiem i poruszające to, co najciekawsze.

I gdyby ludzie piszący takie rzeczy mieli w zwyczaju publikowanie ich na CC, to zwykły hobbysta, interesujący się akurat powiedzmy komputerami kwantowymi i mający zacięcie do pracy z tekstem pisanym (cholera wie, może nawet związany z tym zawodowo) mógłby po prostu zebrać odpowiednią ilość materiałów (tzn. od razu zabrać się do roboty, bez wysyłania najpierw zapytań i negocjowania czegokolwiek z autorami), poddać obróbce wedle woli (bo na przykład znacznie lepiej od oryginalnego autora wie, jak czynić tekst przystępnym dla odbiorcy) i 'wydać' takie coś poświęcając też czas na 'marketing'.

(Ilość ciekawych materiałów dostępnych w necie jest bardzo duża. To, nad czym boleję, to że wszystkie one są w formie bardzo poszatkowanej, tzn. jeśli jest się młodym człowiekiem, który sam nie wie czego chce, to trzeba mieć naprawdę duże zacięcie do klikania i czytania ton tekstu, zanim się będzie w ogóle miało jakiś pomysł na to, czym się chce zainteresować. Bardzo brakuje mi rzeczy typu "Complete guide jak zostać hakerem mroku, adresowany do młodzieży licealnej". Napisanie czegoś takiego od podstaw jest bardzo trudne i czasochłonne. Gdyby można było wziąć już istniejące teksty, i po prostu je złączyć do kupy i przerobić pod określony "target", to znacznie wzrosłaby szansa, że powstało by cokolwiek i że to cokolwiek miałoby jakąś większą wartość (choćby dlatego, że byłoby oparte o teksty, o których już wiadomo, że są wartościowe)).

Jeśli domyślną 'licencją' ogólnie pojętej wiedzy byłoby 'bierz i rób co chcesz' [1], to drastycznie wzrosłaby ilość ludzi mogących zrobić coś pożytecznego, nawet w tematach, z którymi nie są bezpośrednio związani (vide wikipedia). Powyższe "Quantum computing for dummies" jest tylko najprostszym tego przykładem.

[1] Nawiasem mówiąc tradycyjne periodyki naukowe typu Science, czy Lancet próbują bronić swojej obecnej pozycji jako jedynego źródła, z którego można otrzymywać publikacje naukowe. Okopały się na swoich pozycjach, zatrudniły nawet cholernie drogiego speca od PR-u. Ale nie pociągną długo. To jest zmiana tak oczywista dla większości ludzi, że albo się dostosują, albo zginą. Daję im może 5 lat.

Nawiasem mówiąc w końcu po ciężkich bojach udało mi się dziadków namówić na kupno komputera (z internetem). Spodoba im się (zwłaszcza dziadkowi) i na pewno będzie to ciekawsze i bardziej kreatywne od dziergania tysięcznej krzyżówki. Ale oni już nie będą całkowicie samodzielni w wyszukiwaniu nowych rzeczy. To nie to pokolenie.

Ale pomyślcie o ludziach powiedzmy do lat trzydziestu, którzy z internetu korzystali od wieku szkolnego, a więc dla nich jest to kompletnie naturalne. Spora część z tych ludzi już partycypuje w rozwój [2] różnych projektów, projekcików, społeczności małych i dużych. W wolnym czasie. A za jakieś trzydzieści-czterdzieści lat oni przejdą na emerytury. Będą mieli znacznie więcej wolnego czasu, a nie sądzę, żeby chęć robienia różnych fajnych rzeczy im przeszła.

To będą zdecydowanie ciekawe czasy.

[2] Sorry, musiałem chociaż raz tej frazy gdzieś użyć.