TWiki Blog (combined)

Eppur si muove…

TomaszTrojanowski — 2008-01-27T19:11:00Z

Niniejszym mogę z całym spokojem ogłosić oficjalne wydanie pierwszego jądra PLD/FreeBSD, kernel posiada numerek <a href="ftp://ftp.pld-freebsd.org/pub/PLD-FreeBSD/kernel/v6/kernel-6.3.0.0.tar.bz2" target="_top">6.3.0.0</a> i zamyka pewien etap tego projektu. Z wydaniem tego jądra wiąże się bowiem to, że do przebudowania całości nie bedzie już nigdy potrzebny FreeBSD (na kt�rym do tej pory było produkowane jądro dla PLD/FreeBSD). Z ciekawostek, jako że nikt mi nigdy nie powiedział, że do budowania jądra nie da się zaprząc autoconfa i automake'a. I z drugiej strony, z braku pomysłu na szybkie w implementacji narzędzie do budowania tegoż, spr�bowałem użyć do tego celu właśnie autotoolsy… I udało się. Pomijam, że regeneracja plik�w configure i wszystkich Makefile'�w trwa dłuzej niż samo budowanie kernela, kto by sie tym przejmował. Teraz, kolejny duży krok to będzie instalator… ale kiedy?

TomaszTrojanowski replies on ""

TomaszTrojanowski — 2007-07-13T10:37:15Z

Posypał się RAID, a ja niestety nie mam czasu żeby przywr�cić go z backup�w. azazel wr�ci jak tylko ukradnę z czegoś trochę czasu.

spider replies on ""

spider — 2007-07-13T08:32:56Z

azazel did not response

Winowajca odnaleziony

TomaszTrojanowski — 2007-04-24T07:10:00Z

Znalazłem <a class="natExternalLink" target="_blank" href="http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2002-May/051320.html">winnego</a>. Byłem prawie pewien, że to był aniou, ale wydawało mi się że to było rok albo dwa wcześniej. W każdym razie taka jest geneza PLD/FreeBSD.

New look and feel

TomaszTrojanowski — 2007-04-19T12:52:00Z

Tak się złożyło, że dysponując chwilą wolnego czasu zabrałem się do realizacji od dawna odkładanych zadań. Skutkiem czego wiki (a zatem i blog) doczekało się w końcu nowego, lepszego wyglądu. Stare sk�rki są (dla ciekawych) nadal dostępne, np. <a href="http://wiki.pld-freebsd.org/bin/view/Blog/BlogEntry6?skin=pattern" target="_top">http://wiki.pld-freebsd.org/bin/view/Blog/BlogEntry6?skin=pattern</a>

PLD/FreeBSD Preview 1

TomaszTrojanowski — 2007-03-07T08:51:00Z

Ponieważ zgłosiło się do mnie już kilka os�b z pytaniem jak można zainstalować PLD/FreeBSD postanowiłem coś z tym zrobić. Na początek PLD/FreeBSD Preview 1 w postaci spakowanej maszyny wirtualnej do VMWare Workstation. Do pobrania <a href="ftp://ftp.pld-freebsd.org/pub/PLD-FreeBSD/preview/pld-freebsd-preview1.tar.bz2" target="_top">tutaj</a> (41.5 MB). System minimalny jak tylko się dało, więc można sobie popoldkować. Po uruchomieniu maszyny i zalogowaniu się na <code>roota</code> (hasło puste) trzeba skonfigurować sieć: <pre> ifconfig lnc0 192.168.1.2 route add default 192.168.1.1 echo "nameserver 192.168.1.1" > /etc/resolv.conf </pre> albo wyedytować znane z PLD pliki odpowiedzialne za powyższe i zrestartować usługę <code>network</code> <pre> /etc/rc.d/init.d/network restart </pre> I już można działać. Nie polecam instalowania pakietu <code>kernel</code> i <code>loader</code> bo te kt�re są na FTPie mogą kompletnie rozwalić system. Zainteresowanym życzę miłej zabawy. Jak tylko znajdę chwilę czasu postaram się opisać jak zainstalować PLD/FreeBSD na fizycznej maszynie przy pomocy płyty instalacyjnej FreeBSD.

Do builder�w podejscie trzecie

TomaszTrojanowski — 2007-03-05T15:04:00Z

Po raz trzeci zabrałem się za pisanie builder�w dla PLD/FreeBSD. Efekt jest taki, że podstawowe funkcjonalności są już gotowe, a w czasie kiedy na nowych builderach testowo przebudowywane są wszystkie pakiety spłodziłem kr�tki tekst opisujacy ich działanie. Zainteresowanych zapraszam do <a href="http://wiki.pld-freebsd.org/bin/view/Main/JakDzialajaBuilder" target="_top">lektury</a>.

TomaszTrojanowski replies on ""

TomaszTrojanowski — 2007-02-16T21:11:06Z

Nie jestem do końca przekonany, czy będzie szybsze. Nawet jeżeli tak, to najprawdopodobniej <pre> SELECT DISTINCT id_process AS p1 FROM task WHERE status = 'completed' AND NOT EXISTS (SELECT * FROM task WHERE status <> 'completed' AND id_process = p1); </pre> będzie jeszcze szybsze. Ale to nie o to chodzi.

MarcinGajda replies on ""

MarcinGajda — 2007-02-16T10:07:37Z

Wszystkie... No tak – mają być wszystkie. Wobec tego biję się w piersi, rzeczywiście moje zapytanie nie daje poprawnego wyniku. Mimo wszystko napisałbym to inaczej: <pre> SELECT id_process FROM task WHERE status = 'completed' GROUP BY id_process EXCEPT SELECT id_process FROM task WHERE status <> 'completed' GROUP BY id_process </pre> To zapytanie wciąż będzie szybsze w planie wykonania od Twojego.

TomaszTrojanowski replies on ""

TomaszTrojanowski — 2007-02-16T09:28:14Z

Przecież <code>SELECT id_process FROM task WHERE status = 'completed' GROUP BY id_process;</code> zwr�ci liste proces�w kt�re mają przynajmniej jedno zadanie zakończone, a nie liste proces�w, w kt�rych wszystkie zadania zostały zakończone. Nie widzisz tego? Cały problem leży w tym, żeby uzyskać listę proces�w, w kt�rych wszystkie zadania się zakończyły, użycie <code>WHERE</code> w tym przypadku nic nie da, bo przed wykonaniem funkcji <code>COUNT</code> ograniczy zbi�r poczatkowy do zadań kt�re się nie zakończyły (w przypadku <code>WHERE status <> 'completed'=) albo do zadań kt�re się zakończyły w przypadku =WHERE status = 'completed'=). Czyli używając =WHERE status = 'completed'</code> nie wiemy czy są w tak ograniczonej tabeli rekordy z status <> 'completed' Na przykładzie będzie prościej. Przyjmijmy, że w tabela "task" wygląda tak (pominąłem pierwsze pole bo jest nieistotne w tym wypadki): <table cellspacing="0" cellpadding="0" class="twikiTable" border="1"><tr class="twikiTableEven"><th bgcolor="#6b7f93" align="center" valign="top" class="twikiFirstCol" maxcols="0"> <a rel="nofollow" href="http://wiki.pld-freebsd.org/bin/view/Blog/WebRssCombined?sortcol=0;table=1;up=0#sorted_table" title="Sort by this column">id_process</a> </th><th bgcolor="#6b7f93" align="center" valign="top" maxcols="0"> <a rel="nofollow" href="http://wiki.pld-freebsd.org/bin/view/Blog/WebRssCombined?sortcol=1;table=1;up=0#sorted_table" title="Sort by this column">status</a> </th></tr> <tr class="twikiTableOdd"><td bgcolor="#ffffff" valign="top" class="twikiFirstCol"> 1 </td><td bgcolor="#ffffff" valign="top" > none </td></tr> <tr class="twikiTableEven"><td bgcolor="#edf4f9" valign="top" class="twikiFirstCol"> 1 </td><td bgcolor="#edf4f9" valign="top" > running </td></tr> <tr class="twikiTableOdd"><td bgcolor="#ffffff" valign="top" class="twikiFirstCol"> 2 </td><td bgcolor="#ffffff" valign="top" > completed </td></tr> <tr class="twikiTableEven"><td bgcolor="#edf4f9" valign="top" class="twikiFirstCol"> 2 </td><td bgcolor="#edf4f9" valign="top" > completed </td></tr> <tr class="twikiTableOdd"><td bgcolor="#ffffff" valign="top" class="twikiFirstCol"> 3 </td><td bgcolor="#ffffff" valign="top" > completed </td></tr> <tr class="twikiTableEven"><td bgcolor="#edf4f9" valign="top" class="twikiFirstCol twikiLast"> 3 </td><td bgcolor="#edf4f9" valign="top" class="twikiLast"> running </td></tr> </table> Moje <pre> SELECT id_process, COUNT(status != 'completed' OR NULL) AS count FROM task GROUP BY id_process HAVING count = 0; </pre> zwr�ci: <table cellspacing="0" cellpadding="0" class="twikiTable" border="1"><tr class="twikiTableEven"><th bgcolor="#6b7f93" align="center" valign="top" class="twikiFirstCol" maxcols="0"> <a rel="nofollow" href="http://wiki.pld-freebsd.org/bin/view/Blog/WebRssCombined?sortcol=0;table=2;up=0#sorted_table" title="Sort by this column">id_process</a> </th><th bgcolor="#6b7f93" align="center" valign="top" maxcols="0"> <a rel="nofollow" href="http://wiki.pld-freebsd.org/bin/view/Blog/WebRssCombined?sortcol=1;table=2;up=0#sorted_table" title="Sort by this column">count</a> </th></tr> <tr class="twikiTableOdd"><td bgcolor="#ffffff" valign="top" class="twikiFirstCol twikiLast"> 2 </td><td bgcolor="#ffffff" valign="top" class="twikiLast"> 0 </td></tr> </table> Twoje <pre> SELECT id_process, COUNT(*) AS count FROM task WHERE status = 'completed' GROUP BY id_process; </pre> zwr�ci <table cellspacing="0" cellpadding="0" class="twikiTable" border="1"><tr class="twikiTableEven"><th bgcolor="#6b7f93" align="center" valign="top" class="twikiFirstCol" maxcols="0"> <a rel="nofollow" href="http://wiki.pld-freebsd.org/bin/view/Blog/WebRssCombined?sortcol=0;table=3;up=0#sorted_table" title="Sort by this column">id_process</a> </th><th bgcolor="#6b7f93" align="center" valign="top" maxcols="0"> <a rel="nofollow" href="http://wiki.pld-freebsd.org/bin/view/Blog/WebRssCombined?sortcol=1;table=3;up=0#sorted_table" title="Sort by this column">count</a> </th></tr> <tr class="twikiTableOdd"><td bgcolor="#ffffff" valign="top" class="twikiFirstCol"> 2 </td><td bgcolor="#ffffff" valign="top" > 2 </td></tr> <tr class="twikiTableEven"><td bgcolor="#edf4f9" valign="top" class="twikiFirstCol twikiLast"> 3 </td><td bgcolor="#edf4f9" valign="top" class="twikiLast"> 1 </td></tr> </table> Oczywiscie <code>count</code> jest nieistotne, ale te zapytania zwracaja zupełnie r�żną liste proces�w. Rozumiesz juz o co chodzi czy mam tłumaczyć dalej.

MarcinGajda replies on ""

MarcinGajda — 2007-02-16T08:25:07Z

Ależ... SELECT id_process FROM task WHERE status = 'completed' GROUP BY id_process; Coś mi się wydaje, że owracasz jednak kota ogonem, zupełnie niepotrzebnie. Przeczytaj o WHERE, zanim zaczniej kombinować po g�rkę. Dobrze byłoby, gdybyś też obejrzał plan dla Twojego i mojego zapytania. Może wtedy być zrozumiał, dlaczego Twoje podejście jest co najmniej niewłaściwe.

TomaszTrojanowski replies on ""

TomaszTrojanowski — 2007-02-15T14:46:54Z

Fakt, błedem było nie napisanie bezpośrednio do czego mi to posłuży. Więc naprawiam ten błąd, bo widzę czytanie ze zrozumieniem to rzadka sztuka. Używając tej swojej klauzuli <code>WHERE</code> wylistuj wszystkie takie procesy, dla kt�rych wszystkie zadania (z tabeli "task") mają status 'completed'. Bo ja to zrobię tak: <pre> SELECT id_process, COUNT(status != 'completed' OR NULL) AS count FROM task GROUP BY id_process HAVING count = 0; </pre> Tylko żeby Cię żołądek nie rozbolał, jak będziesz się gimnastykował.

Marcin Gajda replies on ""

Marcin Gajda — 2007-02-15T13:07:55Z

Tak... Śliczne? Prymitywne, hack taki, że aż żołądek boli. Wygląda na to, że nie doszedłeś jeszcze w nauce SQL do klauzuli WHERE… SELECT id_process, COUNT(*) FROM task WHERE status <> 'completed' GROUP BY id_process; M�głbyś też pomyśleć o przesiadce na bazę danych (np. PostgreSQL), a nie korzystać z żałosnej imitacji.

Ciekawa własność NULLa

TomaszTrojanowski — 2007-02-14T22:08:00Z

W b�lach implementacji swoich builder�w natknąłem się na ciekawą własność NULLa w MySQL. Nie wiem czy pojawia sie ona r�wnież innych SQLach. Najprościej bedzie na przykladzie. Zał�zmy, że mamy dwie tabele "process" i "task". Tabela "process" zawiera listę proces�w wykonywanych przez pewien abstrakcyjny procesor, na każdy proces składa się pewna ilość zadań, przy czym każde zadanie może należeć tylko do jednego procesu; czyli prosta relacja jeden do wielu. Dodatkowo każde zadanie posiada właściwość "status" określająca stan tego zadania. Dla ustalenia uwagi niech pole "status" może przyjmować trzy wartości: "none", "running" lub "completed". Definicja tych tabel może wyglądac tak: <pre> CREATE TABLE process ( id INT UNSIGNED PRIMARY KEY NOT NULL auto_increment, name VARCHAR); CREATE TABLE task ( id INT UNSIGNED PRIMARY KEY NOT NULL auto_increment, id_process INT UNSIGNED NOT NULL, status ENUM('none', 'running', 'completed') NOT NULL); </pre> Zapytanie kt�re zwr�ci nam identyfikator procesu wraz z ilością zadań przyporzadkowanych do tego procesu jest oczywiście trywialne i wyglada tak: <pre> SELECT id_process, COUNT(*) FROM task GROUP BY id_process; </pre> Problemem natomiast jest zapytanie zwracajace identyfikator procesu wraz z ilością zadań przyporzadkowanych do tego procesu, ale takich kt�re nie zostały jeszcze zakończone, czyli mają status r�żny od 'completed'. Proste: <pre> SELECT id_process, COUNT(status != 'completed') FROM task GROUP BY id_process; </pre> nie wystarcza ponieważ <code>COUNT</code> zlicza zgrupowane wartości bez wzgledu na ich wartość. W tym przypadku zar�wno <code>TRUE</code> jak i <code>FALSE</code> jest traktowane jako element to zliczenia. Zatem powyższe zapytanie zwraca to samo co poprzednie, czyli identyfikator procesu wraz z ilością zadań przyporzadkowanych do tego procesu. Możnaby oczywiście uzyć funkcji <code>SUM</code> i <code>IF</code> w następujący spos�b: <pre> SELECT id_process, SUM(IF(status != 'completed), 1, 0) FROM task GROUP BY id_process; </pre> Ale to nie dość, że niezgodne z zasadami sztuki, to jeszcze mało czytelne i pewnie mało wydajne. Aby w prosty spos�b uzyskać oczekiwany wynik wystarczy wykorzystać to że wartości <code>NULL</code> są niepoliczalne dla funkcji <code>COUNT</code>. Jeżeli zgrupujemy rekordy kt�re w zadanym polu maja cztery wartości z czego dwie są r�wne <code>NULL</code> to funkcja <code>COUNT</code> na tym polu zwr�ci nam <code>2</code>, a nie <code>4</code>. Wystarczy zatem doprowadzić ostatnie zapytanie wykorzystujące funkcję <code>COUNT</code> do takiej postaci, w kt�rej wartość argumentu jest policzalna gdy pole "status" jest inne niż 'completed', a niepoliczalna (czyli r�wna =NULL=) w przeciwnym wypadku. Wyrażenie <pre> status != 'completed' OR NULL </pre> spełnia te założenia ponieważ przyjmuje jedną z dw�ch wartości: <code>TRUE</code> dla pola "status" r�żnego od 'completed', albo <code>NULL</code> w przeciwnym wypadku. Ostatecznie zapytanie zwracajace identyfikator procesu wraz z ilością zadań przyporzadkowanych do tego procesu, takich kt�re nie zostały jeszcze zakończone wygląda tak: <pre> SELECT id_process, COUNT(status != 'completed' OR NULL) FROM task GROUP BY id_process; </pre> Śliczne, prawda?

Dlaczego CVS ssie…

TomaszTrojanowski — 2007-02-06T14:11:00Z

W gruncie rzeczy tekst ma być o tym dlaczego SVN jest lepszym wyborem w przypadku repozytorium pakiet�w. Swoje przemyślenia opieram na bez mała trzy i p�ł rocznym doświadczeniu z repozytorium <a class="natExternalLink" target="_blank" href="http://svn.pld-freebsd.org/svn/packages">http://svn.pld-freebsd.org/svn/packages</a>, dostepnym r�wniez przez ViewCVS: <a class="natExternalLink" target="_blank" href="http://svn.pld-freebsd.org/cgi-bin/viewsvn/">http://svn.pld-freebsd.org/cgi-bin/viewsvn/</a>. Struktura repozytorium r�żni sie znacząco od płaskiego modelu repozytorium stosowanego w PLD. W dużym uproszczeniu wygląda ona tak: <pre> packages +- trunk | +- db | | +- SOURCES | | | +- patch1.patch | | | +- patch2.patch | | +- SPECS | | +- db.spec | +- rpm | +- SOURCES | | +- patch1.patch | | +- patch2.patch | +- SPECS | +- rpm.spec +- branches | +- rpm-4.1.1 | | +- db | | | +- SOURCES | | | | +- patch1.patch | | | | +- patch2.patch | | | +- SPECS | | | +- db.spec | | +- rpm | | +- SOURCES | | | +- patch1.patch | | | +- patch2.patch | | +- SPECS | | +- rpm.spec | +- rpm-4.4.1 | +- db | | +- SOURCES | | | +- patch1.patch | | | +- patch2.patch | | +- SPECS | | +- rpm.spec | +- rpm | +- SOURCES | | +- patch1.patch | | +- patch2.patch | +- SPECS | +- rpm.spec +- tags +- Ac-rpm-4.4.1-2 +- db | +- SOURCES | | +- patch1.patch | | +- patch2.patch | +- SPECS | +- rpm.spec +- rpm +- SOURCES | +- patch1.patch | +- patch2.patch +- SPECS +- rpm.spec </pre> Jak widać na powyższym schemacie dla każdego pakietu została wydzielona osobna gałąź w drzewie repozytorium. Taki zabieg, poza uporzadkowaniem i separacją składnik�w poszczeg�lnych pakiet�w, pozwala na rozdzielenie przestrzeni nazw plik�w w pakietach. A co za tym idzie, powoduje że np. nazwa patcha może być dowolna dla zadanego pakietu i nie istnieje konieczność pilnowania żeby nazwy łatek dla r�żnych pakiet�w nie kolidowały ze sobą. W szczeg�lności, nie ma potrzeby narzucania nazewnictwa tych łatek do postaci <code>nazwa_pakietu-nazwa_łatki.patch</code> jak ma to miejsce w PLD. Ściagnięcie całego drzewa <code>trunk</code> może wygląda nastepująco: <pre> svn checkout http://svn.pld-freebsd.org/svn/packages/trunk packages </pre> Natomiast ściagniecie i kompilacja pakietu db z takiego repozytorium wygląda tak: <pre> $ cd ~/packages $ svn checkout http://svn.pld-freebsd.org/svn/packages/trunk/db $ cd db/SPECS $ rpmbuild -ba --define "_topdir ~/packages/db" db.spec </pre> Powyższy przykład nie uwzględnia oczywiście ściagnięcia ewentualnych tarballi z distfiles. Drzewiastej strukturze repozytorium można zarzucać niemozliwość "przegrepowania" wszystkich specy, albo wprowadzania masowych zmian w specach. Wadę tą można wyeliminować używając polecenia <code>find</code>. I tak odpowiednikiem <code>grep jakisstring *</code> w katalogu SPECS jest <pre> find . -name "*.spec" -exec grep -H jakisstring {} \; </pre> w katalogu packages/trunk. Praca z takim repozytorium nie jest dużo bardziej skomplikowana, niż z płaskim repozytorium CVSowym. A prawie zupełnie nie r�żni się gdy użyjemy odpowiednio zmodyfikowanego skryptu <a class="natExternalLink" target="_blank" href="http://svn.pld-freebsd.org/svn/admin/devel-scripts/trunk/builder">builder</a>. Kolejną przewagą nad CVSem są "atomowe" commity. Polega to na tym, że po wprowadzeniu zmian z pakiecie, zmiany są przekazywane do repozytorium jednym poleceniem, np. <pre> $ cd ~/packages $ svn commit -m "- updated to 4.5\n- updated patch1 patch" db </pre> Co najważniejsze, takie dokonanie zmiany jest traktowane w repozytorium jako integralna całość identyfikowana numerem rewizji w repozytorium, a nie jest złożeniem zmian w poszczeg�lnych plikach. Co za tym idzie możemy łatwo odszukać, że np. update db do wersji 4.5 pociągneło za sobą usuniecie pliku SOURCES/patch1.patch. W CVSie, niestety, każda tego typu zmiana jest w repozytorium traktowana osobno, dlatego dużo wiecej pracy kosztuje odnalezienie jak zmieniły się pozostałe pliki pakietu, podczas określonej zmiany pliku spec. Takie zachowanie CVSa jest dla mnie szczeg�lnie uciążliwe, ponieważ w swojej pracy intensywnie śledzę zmiany w repozytorium PLD w celu nanoszenia niekt�rych z nich w PLD/FreeBSD. Atomowość commit�w w repozytorium pociaga za sobą r�wnież zwiekszenie przejrzystości commitlog�w, dzięki temu są one generowane jako pojedynczy mail, a nie dwa osobne maile zawierajace zmiany odpowiednio, w module SPECS i w module SOURCES. Kolejna przewagą Subversion jest możliwość przenoszenia plik�w (z zachowaniem historii zmian) z poziomu użytkownika. W CVSie taka operacja wymaga zaangażowania administratora repozytorium, kt�ry musi dokonać takiej zmiany po stronie serwera. Dla niekt�rych kolejną wadą SVNa może być niemożliwość generowania sekcji <code>%changelog</code>, tak jak ma to miejsce w chwili obecnej w PLD. Według mnie używanie <code>$Log$</code> do generowania loga to średnio dobry pomysł, tym bardziej, że taki log nie jest tworzony w formacie przyjmowanym przez RPMa. Słuszniej byłoby gdyby <code>%changelog</code> był generowany z loga SVNa na source-builderach w formacie natywnym dla RPMa. Na koniec wypada jeszcze wspomnieć o łatwości instalacji serwera Subversion. Po raz pierwszy zajeło mi to kilkanaście minut, podczas gdy na instalację serwera CVSu straciłem kilka(naście) godzin.

JohnDoe replies on ""

JohnDoe — 2007-01-31T21:24:25Z

Tylko test

In the Beginning… umarł blog, niech żyje blog

TomaszTrojanowski — 2007-01-31T14:19:00Z

Poprzedni blog umarł śmercią naturalną. Nie żałuję. Z początku NewsBruiser nawet mi się podobał, zapewne dlatego że pierwsze wrażenie pochodziło ze sfery użytkownika. P�źniej zaczęły się problemy, a to jakaś ikona się nie wyświetla, a to nie mam kontroli nad layoutem. Dlaczego? Nie wiem, i nawet nie chce mi się tego analizować. Po prostu organicznie nie cierpię Pythona. Tak się złożyło że powziąłem noworoczne postanowienie, że w końcu zacznę pracować nad serwisem WWW dla PLD/FreeBSD. Niech świat się dowie że istnieje coś takiego jak PLD/FreeBSD, a nuż ktoś sie zlituje i pomoże, albo jeszcze lepiej przekona, że to nie ma sensu. Jak to z postanowieniami bywa, zacząłem je realizować z "niewielkim" op�źnieniem. Ponieważ wszelkiego rodzaju Wiki są obecnie na topie (czyt. trendi, albo dzezi, albo jeśli ktoś woli kaczi), tam też postanowiłem szukać silnika do serwisu. Drugim ważnym kryterium jakie powinien spełniać silnik było to że musiał być napisany w Jedynym Słusznym Języku Skryptowym(TM) czyli perlu. Wśr�d tak ograniczajacych kryteri�w jedynym godnym uwagi silnikiem okazał sie TWiki. I tak zostało. Przy okazji przewalania dokumentacji TWiki okazało się, że posiada od rozbudowany system wtyczek, wśr�d kt�rych jest jedna zmieniająca dział TWiki w dość zaawansowany system blogowy. Po drobnych problemach z instalacją, system stanął i zapadła decyzja o wskrzeszeniu bloga. I oto jest. Do mojego prywatnego TODO powędrowały dodatkowo: spolszczenie systemu do używalnej postaci i stworzenie jakiegoś ślicznego layoutu. Do tego drugiego zatrudniłbym kt�regoś ze znajomych web-grafik�w. Zobaczymy.