Trojan

70-431

2008-12-23T21:53:00.001+01:00

I po bólu. Oczywiście do przodu. Pewnie zaraz po świętach dostanę maila z oficjalną informacją o otrzymaniu tytułu "Microsoft Certified System Administrator" i jednocześnie "Microsoft Technology Specialist: SQL Server 2005"... Ale sie porobiło ;)

Na przyszłość

2008-11-14T22:08:00.004+01:00

Nigdy, przenigdy, jeżeli tylko nie musisz, nie stawiaj serwera SQL na kontrolerze domeny. Bo, wcześniej czy później, będziesz miał użytkownika któremu będziesz musiał nadać prawa administratora na tej maszynie.

Sentymentalnie

2008-11-04T22:50:00.003+01:00

Z dzisiejszych wpisów na bashu:

dziś nam facet na elektrotechnice dał cenną radę
"Tylko czasem nie próbujcie sprawdzać jak działa laser w CD-romie, bo laser można w życiu zobaczyć dwa razy... Raz lewym, a raz prawym okiem..."

Usłyszałem to po raz pierwszy od bardzo mądrego Pana, którego nazwiska już teraz nie pomnę, w Instytucie Fizyki PAN jakieś... dwadzieścia lat temu, bez mała. Dobra, może nie o CD-ROMach, ale o laserach ogólnie.

Po co o tym piszę? Bo jest to pewnie jedna z tych kilku rzeczy (wizyta w PANie w sensie) które złożyły się na to, że najpierw miałem być chemikiem, potem o mało co nie zostałem fizykiem, chociaż w zasadzie to można powiedziec że zostałem ;) A i tak pracuję w IT.

70-270

2008-10-31T14:38:00.003+01:00

Kolejny egzamin do przodu. Wczoraj, równo miesiąc po poprzednim, podszedłem i zaliczyłem, z wynikiem 952 punktów, egzamin 70-270. Egzamin był trudniejszy niż się spodziewałem, aczkolwiek najprostszy z dotychczasowych. Tym razem 65 pytań i cztery(!!!) godziny na cały egzamin.

Teraz zostaje mi jeszcze egzamin elekcyjny do MCSA.

Onetowi gratulujemy

2008-10-13T14:48:00.002+02:00

Każdy zwykły użytkownik jest teraz pewnie przerażony... Moja żona była.

Tydzień z Thermomiksem

2008-10-11T16:13:00.005+02:00

Równo tydzień temu, w sobotę, sprezentowałem żonie i sobie nową zabawkę do kuchni -- Thermomiksa TM-31. Chorowałem na niego już od dłuższego czasu, ale żonka dopiero teraz dojrzała do decyzji o zakupie (a może raczej powinienem napisać "o wydatku" ;). No i zaczęło się pichcenie, na początku nieco nieśmiale i raczej zgodnie z załączonymi z urządzeniem przepisami, żeby obyć się trochę, a w miare nabierania doświadczenia w obsłudze coraz śmielsze eksperymenty we wdrażaniu go do naszych zwykłych gustów.

Po tygodniu ja jestem zachwycony, żona jest zachwycona, dzieci są zachwycone. Robienie jedzonka stało się jeszcze przyjemniejsze i szybsze. Dla mnie najważniejszą zaletą jest mniejsza ilość narzędzi kuchennych które trzeba po pichceniu umyć i posprzątać, a których raczej nie właduje do zmywarki. Po drugie odpada też mnóstwo przygotowań, które zabijają sztukę gotowania takich jak siekanie, rozdrabnianie, wyrabianie ciasta, ubijanie, mieszanie, mielenie itp.

Z najciekawszych, Iwona upiekła bułki grachamki, punktem wyjścia oczywiście nie była mąka z otrębami tylko najprawdziwsza pszenica, którą Thermomix zmielił, nastepnie po dodaniu pozostałych składników wyrobił ciasto drożdżowe, które po wyrośnieciu i załadowaniu do piekarnika dało przepyszne bułeczki. Ale naprawdę przepyszne, chyba w życiu takich dobrych nie jadłem. A wszystko to, nie licząc rośnięcia ciasta i pieczenia, w kilka minut. Niesamowite.

W niecałe pietnaście minut ugotowałem w tym pieczarkową zupę-krem, w trzy minuty zrobiłem capuchino, również w trzy minuty - frappe, bukiet surówek z trzech rodzajów surówek także w trzy minuty (no dobra, nie licząc obierania warzyw). Masę na placki ziemiaczane ucieram w pięć minut, a nie jak do tej pory przeszło pół godziny. Iwona w dwie minuty jest w stanie zrobić kruche ciasto na moją ulubioną szarlotkę, a w kolejne dwie - utrzeć jabłka.

Wspomnę jeszcze o soczkach domowej produkcji "Kubusiach", sokach bananowych, soku z zielonej pietruszki i dżemach wpróbowanych na chłopcach oraz niezliczonej ilości drinków wypróbowanych na rodzicach, chlebie pszennym, chałce i innych.

O osiem mniej...

2008-10-09T09:36:00.003+02:00

Nie odnotowałem tego, bo jakoś mi wyleciało, nie chciało mi się, zarobiony byłem. Ostatniego dnia września zaliczyłem kolejny egzamin na ścieżce kariery zawodowej - 70-290. Wynik o osiem punktów gorszy od poprzedniego egzaminu, więc też jest zajebiście. A teraz na tapecie kolejny.

W dobre ręce

2008-07-22T11:50:00.002+02:00

Oddam domenę pld-freebsd.org i ewentualnie repozytorium w dobre ręce. Domena wygasa pod koniec sierpnia wiec jest jeszcze czas na cesję albo transfer. Ja niestety nie mam już czasu ani chęci żeby ciągnąć dalej ten eksperyment.

968... czyli jak zostałem MCP

2008-07-15T20:06:00.003+02:00

Powoli, z linuksiarza staję się rasowym windowsiarzem, nie to żebym jakoś specjalnie tego chciał, bardziej z racji wykonywanego zawodu. W związku z tym dzisiaj o godzinie 10:30, rozpocząłem egzamin oznaczony symbolem 70-291, czyli szumnie "Implementing, Managing, and Maintaining a Windows Server 2003 Network Infrastructure".

Zaczęło się całkiem sympatycznie - rejestracja, później kawa w oczekiwaniu aż się egzamin "ściągnie" (cokolwiek by to miało znaczyć ;). Po wejściu do sali egzaminacyjnej, krótki instruktarz i zaczęło się. Wylosowałem 47 pytań, na których rozwiązanie miałem ponad cztery godziny(!). Po pierwszych pięciu stwierdziłem, że to będzie banalnie proste... po dwudziestu już nie byłem tego taki pewien, bo pojawiły się trudniejsze pytania. Po półtorej godzinie udzieliłem odpowiedzi na wszystkie pytania i wykonałem jedną symulacje jaka mi się trafiła.

Zostało duuuuużo czasu. Stwierdziłem, że zastanawiać się nad udzielonymi odpowiedziami, po pierwsze, nie chce mi się, a po drugie, mógłbym jeszcze coś spieprzyć zbyt dużo myśląc, więc zakończyłem egzamin. Chwila niepewności.... i jest wynik - tytułowe 968. Zajebiście. Tego się nie spodziewałem, miałem nadzieję na 900, ale realnie zakładałem 850.

Po wyniku możnaby przypuszczać że zawaliłem jedno, góra dwa, pytania. Być może były to te dwa pytania z WSUSa, na które kompletnie strzelałem.

Następny w kolejce jest 70-290, a na razie czekam na maila z Microsoftu z potwierdzeniem zdania egzaminu.

Czwarta cywilizacja czwarta

2008-07-14T15:15:00.007+02:00

Dochodzę do wniosku, że jestem chyba graczem-gawędziarzem. Więcej mówię o graniu w swoje ulubione pozycje niż to rzeczywiście robię.

Civilization IV, polska premiera - 25 listopada 2005, pudełko stało na półce 30 listopada, łącznie zagrałem w nią trzy razy (w sensie zagrałem i ukończyłem). Civilization IV: Warlords, polska premiera - 25 sierpnia 2006, pudełko stało na półce dwa dni później, zagrałem raptem jeden raz. Civilization IV: Beyond the Swords, premiera - 30 lipca 2007, pudełko przyszło 10 sierpnia. W tę ostatnią udało mi się zagrać kilka razy(!) w przeciągu bez mała roku.

Teraz czytam informacje o nowym dodatku i już się oczywiście napalam na kupno, sprawdzam czy przypadkiem mój sprzet nie będzie wymagał upgrade'u, notuję w PIMie żeby nie przegapić premiery. Ostatecznie, stanie się kolejną ozdobą na półce, w którą zagram może dwa razy. A może nie ;)

...i jeszcze raz

2008-07-14T13:52:00.001+02:00

Trzecia zmiana silnika bloga. Najpierw był NewsBruiser, później blog na bazie TWiki -- teraz przyszedł czas na Bloggera.

Eppur si muove...

2008-01-28T04:11:00.000+01:00

Niniejszym mogę z całym spokojem ogłosić oficjalne wydanie pierwszego jądra PLD/FreeBSD, kernel posiada numerek 6.3.0.0 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?

Winowajca odnaleziony

2007-04-24T16:10:00.000+02:00

Znalazłem winnego. 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

2007-04-19T21:52:00.000+02:00

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. http://wiki.pld-freebsd.org/bin/view/Blog/BlogEntry6?skin=pattern

PLD/FreeBSD Preview 1

2007-03-07T17:51:00.000+01:00

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 tutaj (41.5 MB). System minimalny jak tylko się dało, więc można sobie popoldkować.

Po uruchomieniu maszyny i zalogowaniu się na roota (hasło puste) trzeba skonfigurować sieć:

ifconfig lnc0 192.168.1.2
route add default 192.168.1.1
echo "nameserver 192.168.1.1" > /etc/resolv.conf

albo wyedytować znane z PLD pliki odpowiedzialne za powyższe i zrestartować usługę network

/etc/rc.d/init.d/network restart

I już można działać. Nie polecam instalowania pakietu kernel i loader 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

2007-03-06T00:04:00.000+01:00

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

Ciekawa własność NULLa

2007-02-15T07:08:00.000+01:00

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:

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

Zapytanie które zwróci nam identyfikator procesu wraz z ilością zadań przyporzadkowanych do tego procesu jest oczywiście trywialne i wyglada tak:

SELECT id_process, COUNT(*) FROM task GROUP BY id_process;

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:

SELECT id_process, COUNT(status != 'completed') FROM task GROUP BY id_process;

nie wystarcza ponieważ COUNT zlicza zgrupowane wartości bez wzgledu na ich wartość. W tym przypadku zarówno TRUE jak i FALSE 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 SUM i IF w następujący sposób:

SELECT id_process, SUM(IF(status != 'completed), 1, 0) FROM task GROUP BY id_process;

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 NULL są niepoliczalne dla funkcji COUNT. Jeżeli zgrupujemy rekordy które w zadanym polu maja cztery wartości z czego dwie są równe NULL to funkcja COUNT na tym polu zwróci nam 2, a nie 4.

Wystarczy zatem doprowadzić ostatnie zapytanie wykorzystujące funkcję COUNT 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

status != 'completed' OR NULL

spełnia te założenia ponieważ przyjmuje jedną z dwóch wartości: TRUE dla pola "status" różnego od 'completed', albo NULL 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:

SELECT id_process, COUNT(status != 'completed' OR NULL) FROM task GROUP BY id_process;

Śliczne, prawda?

Dlaczego CVS ssie...

2007-02-06T23:11:00.000+01:00

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 http://svn.pld-freebsd.org/svn/packages, dostepnym równiez przez ViewCVS: http://svn.pld-freebsd.org/cgi-bin/viewsvn/.

Struktura repozytorium różni sie znacząco od płaskiego modelu repozytorium stosowanego w PLD. W dużym uproszczeniu wygląda ona tak:

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

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 nazwa_pakietu-nazwa_łatki.patch jak ma to miejsce w PLD.

Ściagnięcie całego drzewa trunk może wygląda nastepująco:

svn checkout http://svn.pld-freebsd.org/svn/packages/trunk packages

Natomiast ściagniecie i kompilacja pakietu db z takiego repozytorium wygląda tak:

$ cd ~/packages
$ svn checkout http://svn.pld-freebsd.org/svn/packages/trunk/db
$ cd db/SPECS
$ rpmbuild -ba --define "_topdir ~/packages/db" db.spec

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 find. I tak odpowiednikiem grep jakisstring * w katalogu SPECS jest

find . -name "*.spec" -exec grep -H jakisstring {} \;

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

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.

$ cd ~/packages
$ svn commit -m "- updated to 4.5\n- updated patch1 patch" db

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 %changelog, tak jak ma to miejsce w chwili obecnej w PLD. Według mnie używanie $Log$ 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 %changelog 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.

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

2007-01-31T23:19:00.000+01:00

Poprzedni blog umarł śmercią naturalną. Nie żałuję. Z początku NewsBruiser nawet mi się podobał, zapewne dlatego że pierwsze wrażenie wynikało z punktu widzenia 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.

Dlaczego PLDowy %changelog w rpmie ssie

2006-03-10T23:18:00.000+01:00

A ssie, i to bardzo, szczególnie w naszym wykonaniu. Mianowicie, już po raz kolejny natknąłem się na ten sam problem: załóżmy że utworzyłem sobie nowego brancha (dla ustalenia uwagi niech nazywa sie on DEVEL) i na nim wprowadzam pewne zmiany. Trwa to jakiś czas więc w tym czasie ktoś inny zdążył zrobić jakąś kosmetyczną poprawkę tego speca na HEAD. W takiej sytuacji próba zmerge'owania brancha DEVEL na HEAD zawsze kończy się koniecznością ręcznego rozwiązywania konfliktów. Nawet w przypadku gdy zmiana na HEAD jest naprawdę kosmetyczna, i jako taka, bez problemu zintegrowałaby się ze zmianami na HEAD -- zawsze pozostaje kwestia nieszczęsnego changeloga generowanego z $Log$.

Satysfakconujące mnie rozwiazanie jest takie, że w repozytorium sekcje %changelog speców pozostaja puste, a ich generowanie dokonuje się na builderach tuż przed zbudowaniem pakietu źródłowego. W tym celu trzeba do skryptu builder dodać opcję (np. -c lub inną jeżeli taka już istnieje), która po ściągnięciu speca z repozytorium wklei sekcję %changelog wygenerowaną na podstawie cvs log nazwa.spec.

Plusy takiego rozwiazania. Po pierwsze, możliwość generowania changeloga takim jakim powinien być czyli z osobnymi wpisami dla każdej zmiany, a nie w dotychczasowej formie gdzie używamy wrappera który tworzy jeden wpis zawierający listę wszystkich zmian. Po drugie, możliwość kontrolowania ile wpisów trafia do pakietu, dzieki czemu odpada konieczność czyszczenia co jakiś czas changeloga w repozytorium. I po trzecie, i chyba najważniejsze, zmniejsza to redundancję w repozytorium.

Opisana wyżej metoda staje się jeszcze bardziej atrakcyjna, gdy repozytorium jest w SVN, a nie CVS. W tym pierwszym istnieje możliwość poprawienia commitloga określonej rewizji.

Xorg 7.0 Release Candidate Zero

2005-08-04T19:52:00.000+02:00

Co prawda z przeszło dwutygodniowym opóźnieniem, ale już jest. Pozostaje teraz to wszystko spakietować i cieszyć się jeśli zadziała.

Asimov I., Silverberg R., Brzydki mały chłopiec

2005-07-15T05:01:00.000+02:00

Spodziewałem się jakiejś pointy. Niestety, albo mi umknęła, albo nijakiej nie było. Sam Asimov nigdy mnie jeszcze nie rozczarował, natomiast wespół z Silverbergiem już po raz drugi (pierwszym było Nastanie nocy). Zresztą całą książkę czyta się ciężko, sprawia wrażenie napisanej na siłę i pewnie tak jest biorąc pod uwagę że jest to przerobione na powieść opowiadanie Asimova.

Cole A., Bunch C., Sten

2005-07-12T06:44:00.000+02:00

W końcu kawałek porządnej hard SF. Ale rzeczywiście kawałek, bo stanowczo za krótka. Pocieszajacym jest natomiast, że jest to pierwszy tom ośmiotomowej sagi. Trzeba tylko zdobyć nastepne tomy, bo powieść czyta się rewelacyjnie, jest lekka, pełna humoru i naprawdę wciąga.

GNOME

2005-07-11T21:01:00.000+02:00

A miało być tak pięknie. Niestety GNOME w PLD/FreeBSD delikatnie mówiąc niedomaga. Evolution segfaultuje przy starcie, epiphany krzyczy że nie może zainicjować mozilli, mozilla startuje ale przy wyjściu segfaultuje. Duuużo pracy.

Pocieszające jest to, że podobny problem z segfaultującym przy starcie gnome-panel, rozwiązałem przez przebudowanie tegoż.

Benford G., Przez morze słońc

2005-07-10T08:52:00.000+02:00

Drugi tom sagi jest znacząco lepszy od pierwszego. Akcja zaczyna się rozwijać i ciekawić, mimo że książka jest dość trudna w czytaniu. Jak dla mnie autor stanowczo przesadza z "luźnim strumieniem myśli".

Sam pomysł fabuły nie jest chyba dość oryginalny, cywilizacja maszyn wszechogarniajaca galaktykę, gdzie walczące o przetrwanie życie organiczne spychane jest na margines.

Skrypty startowe

2005-07-10T02:13:00.000+02:00

Zakończyłem wstępną implementacje skryptów startowych: http://svn.pld-freebsd.org/svn/rc-scripts/trunk. Schematem działania nie różnią się wiele od standardowych skryptów FreeBSD, ale wiele funkcjonalności jest jeszcze nie zaimplementowanych. Kiedyś, jeżeli wena dopisze stworzę jakiś dłuższy artykuł na ich temat.

Benford G., W oceanie nocy

2005-07-07T19:53:00.000+02:00

Nie zrobiła na mnie specjalnego wrażenia. Co prawda kołek od zawieszania niewiary nie trzeszczy zbytnio, co wydaje się naturalne u autora będącego fizykiem z wykształcenia, ale opowieść nie porywa. Recenzje ma pozytywne, chociaż według mnie trochę przesadzone.

Mimo to kolejny tom przeczytam, chociażby z tego powodu, że już leży na biurku. Nie spodziewam się jednak żebym wytrwał do końca cyklu, chyba że autor czymś mnie zaskoczy.

PLD/FreeBSD

2005-07-06T23:59:00.000+02:00

W zasadzie to nie pamiętam od czego się zaczęło. Gdzieś w okolicach roku 2002, albo 2003, wylądował na pld-devel-pl@pld-linux.org mail z pomysłem zrobienia PLD na jądrze FreeBSD. Kto, i kiedy wysłał tego maila nie udało mi się odszukać, ale sam pomysł zapamietałem bo wydawał mi się oryginalny. Jakiś czas później, kiedy już miałem okazję przyjrzeć się pracującemu FreeBSD, zauważyłem że to bardzo przyjemny i wydajny system. Brakowało jednak narzędzia pozwalającego na sprawne i wygodne zarządzanie pakietami bez zbędnych nakładów pracy (czyli rpma i poldka)

Niewiele myśląc zainstalowałem na domowej maszynie FreeBSD (wtedy jeszcze 5.1), stworzyłem chroota na którym zamierzałem eksperymentować i... sportowałem rpma. Od tego czasu powoli, acz sukcesywnie rośnie liczba pakietów. Projekt dorobił się własnych builderów, repozytorium w subversion, distfiles, list dyskusyjnych i ftpa z pakietami.

Do produktu końcowego, czy nawet do czegoś co możnaby nazwać wersją beta, jeszcze długa droga, ale mimo że upłyneły już prawie dwa lata mój zapał nie stygnie, a projekt ciągle posuwa się do przodu. I oby tak dalej.

In the Beginning

2005-07-06T21:39:00.000+02:00

Dopadło i mnie. Ten powszechny w Internecie zwyczaj wyzewnętrzniania swojej radosnej twórczości, był jak do tej pory skutecznie przeze mnie ignorowany. Czytanie wszelkiej maści blogów, nie mówiac już o pisaniu, wydawało się niepotrzebnym zwiększaniem entropii i nasuwało skojarzenia z jakimś dziwnym rodzajem ekshibicjonizmu. Okazuje się że nie jest to regułą, coraz częściej spotyka się w sieci wartościowe i godne uwagi weblogi, w założeniu mój taki własnie ma być. Jak będzie w praktyce? Czas pokaże.

Garść technikaliów. Wypadałoby wspomnieć o silniku na którym to działa. Po niezbyt długich poszukiwaniach wybór padł na NewsBruisera, napisanego co prawda w Pythonie, ale jak sie wydaje, spełniającego większość moich oczekiwań. Instalacja i wstępna konfiguracja przebiegła bardzo sprawnie (nie ma się za bardzo nad czym rozpisywać) -- po sciągnięciu i rozpakowaniu tarballa działa praktycznie od ręki. Przypuszczam że dużo więcej czasu zajmie dopracowanie wyglądu całego webloga.