Archiwalia dla 04.2005

Anaconda update

Minęło trochę czasu, od kiedy pierwszy raz siadłem nad Anacondą. Przedstawiam zatem postęp w pracach - wiele się nie zmieniło, ale parę rzeczy pozmieniałem.

Wstępne uwagi - Anaconda do zbudowania wymaga kilkunastu przeniesionych z RedHata lub podbitych przeze mnie pakietów. W tym kudzu, które kategorycznie odmawia zbudowania się za pomocą gcc4. Póki co, pozostaje praca na gcc w wersji 3.x.

Największym bólem jest konieczność każdorazowego przebudowania pakietów Anacondy, przy choćby najdrobniejszej modyfikacji skryptów basha czy Perla wchodzących w jej skład. Z drugiej strony jest to jedną z większych zalet Anacondy na tle innych instalatorów - do zbudowania instalatora używa pakietów RPM, a nie bieżącej zawartości systemu. Między innymi używa własnych pakietów RPM, więc te przebudowuję średnio kilkanaście razy na godzinę - na szczęście prace idą do przodu.

Dużo problemów przysparza mi obecnie kernel. Poprawiłem Anacondę, żeby wypakowywała dodatkowe paczki (pcmcia), bo użycie kernel24-BOOT w grę nie wchodzi - choćby podsystemy SerialATA zmieniły zasadniczo swoje działanie od czasów 2.4 i instalacja ze starego jądra spowoduje zgon systemu przy bootowaniu nowego (to co kiedyś było /dev/hdX, teraz nazywa się /dev/sdX). Martwi mnie spory rozmiar initrd budowanego przez Anacondę z naszego 2.6.11 - ma około 8 MB, czyli sporo więcej niż pozwala bez problemu załadować kernel.

screenshot
Anaconda radzi sobie z wygenerowaniem obrazu isolinuksa

Po zbootowaniu obrazu wygenerowanego przez Anacondę, pojawia się bootsplash isolinuksa. Proszę o wybaczenie, ale nie miałem czasu malować logo PLD, więc jest taki - nazwijmy to - placeholder.

Na tym etapie do zbootowania niezbędne jest dopisanie do kernela parametru ramdisk_size (ze względu na wspomniane kolosalne initrd):

boot: linux ramdisk_size=10000

Po tym zaczyna się zwykła procedure bootowania dystrybucyjnego jądra, umiera ona jednak przy próbie podmontowania roota:

screenshot
Kernel panic przy próbie montowania roota

Niestety, nie mam czasu teraz debugować tego dalej. Do głowy przychodzą mi dwie opcje: albo nasz kernel nie ma wkompilowanej obsługi cramfs (a za ładowanie modułów odpowiedzialny jest initrd, co jest nieco kłopotliwe w sytuacji, gdy on sam spakowany jest cramfs) albo ja coś skopałem na etapie generowania vmlinuz/initrd.

Jeśli to możliwe, to prosiłbym o kontakt kogoś lepiej zaprzyjaźnionego z naszym jądrem, najlepiej kogoś, kto używał już dystrybucyjnych kerneli do generowania bootowalnych płyt. Wolałbym uniknąć sytuacji, kiedy do zbudowania instalatora PLD będzie potrzebne jądro Fedory, a na moim notebooku kompilacja kernela trwa około dwóch godzin, więc nie chcę robić tego na oślep.

Update: wrzuciłem aktualny screen, kernel wykłada się teraz na montowaniu roota.

PLD Workstation

Pewnie kilka osób zauważyło podejrzany ruch, generowany przeze mnie w module SPECS naszego CVS. Spieszę z wyjaśnieniami.

Od kilku dni noszę się z zamiarem przygotowania nowej płytki instalacyjnej dla PLD. Mamy wersję pełną, wersję MiniISO, nasze LiveCD, płytkę ratunkową x86 oraz płytkę ratunkową PPC, czemu więc nie mieć wersji dedykowanej na desktopy?

Idea więc jest taka: wziąć Anacondę i zbudować jednolite, spójne środowisko oparte na Gnome 2.10, będące jednocześnie zwykłą instalacją PLD (nie, nie chcę używać Fedory). Kilka osób zacznie mnie pewnie zaraz wyzywać, że sobie zachciałem klikalnego Linuksa zrobić i że lame, a prawdziwy admin to tylko konsola. Pamiętajmy jednak o zwykłych ludziach. Nie, PLD nie jest dla typowego użytkownika, ale są też krewni i znajomi deweloperów, którzy choćby z wygody (jest kogo zapytać o radę) wolą używać PLD. Zresztą, czemu deweloperzy nie mogą mieć wygodnego instalatora? Jeśli zaś chcesz skrytykować Gnome i poradzić mi inne środowisko, nie masz po co pisać. Po pierwsze - po zakończeniu prac udostępnię całość i będziesz mógł sobie zbudować wersję z dowolnym zestawem pakietów. Po drugie - używam Gnome’a i nie będę zgadywał, co jest potrzebne, żeby KDE zadziałało.

Póki co, udało mi się przenieść do PLD większość pakietów wymaganych do kompilacji anacondy. Resztę braków (na potrzeby kompilacji) biorę tymczasowo z Fedory, choć jutro nie powinno to już być potrzebne. Innymi słowy, jutro anaconda będzie się natywnie budowała w czystym PLD.

Kolejnym etapem jest przygotowanie struktury katalogów i niezbędnych plików dla anacondy, coby była w stanie wygenerować obraz płyty. Znalazłem pod tym kątem bardzo dużo miłych HOWTO. Problem jest tylko jeden - wszystkie zaczynają się słowami “weź li dwie szczypty Fedory, a najlepiej przegraj na dysk zawartość wszystkich jej płyt”. Chcę zacząć zupełnie od zera i może to być dość bolesne zadanie.

Dalsza robota to głównie tuning listy pakietów, dodawanie skryptów prekonfigurujących, testowanie na VMware i, koniec końców, artwork.

Życzcie mi powodzenia, a ja wracam do dłubania w CVS.

Strip #011: Untitled Comics part 2

Jako, że pracuję właśnie nad mega wielkim i poważnym CMS-em dla klienta w PHP, mój mózg krąży po wszystkich możliwych pomysłach poza tymi przydatnymi w programowaniu. Przy okazji zaplątał się też ponownie w okolice UC.

Tutaj w graficznych przeglądarkach wyświetla się komiks

Strip #010: Untitled Comics

Przeglądałem dzisiaj Untitled Comics i nie mogłem się powstrzymać ;).

Tutaj w graficznych przeglądarkach wyświetla się komiks

Strip #009: Technologia idzie naprzód

Zainspirowany niewielką burzą mózgów, która rozgorzała w firmie ostatnio, postanowiłem pójść o krok dalej.

Tutaj w graficznych przeglądarkach wyświetla się komiks

Strip #008: Dziś o 13:37…

Pomysłowość bezmyślnych ludzi mnie przeraża. Ciekawe, co by się stało, gdyby łańcuszek papieżowych trendów głosił dziś o 21:37 wystawiamy na 2 godziny telewizory plazmowe przed budynek. Podejrzewam, że byłbym bogatszy o kilka telewizorów.

Łańcuszkom mówimy nie i w zamian propagujemy własny - dziś o 13:37 gasimy światła i gramy w Ponga!

Tutaj w graficznych przeglądarkach wyświetla się komiks

Fakty i mity

Jeśli jesteś jedną z osób, które zwykły mówić ja nigdy nie zostanę deweloperem, bo się do tego nie nadaję, to właśnie za chwilę stracisz część swoich argumentów. Ale może od początku.

Jeśli usłyszałeś od kogoś, że w PLD są tylko spece, to twój rozmówca miał rację, tylko źle go zrozumiałeś. W PLD spece są, ale w repozytorium.

Oczywiście, to tylko jeden z moich kiepskich żartów, ale jego celem jest podkreślenie, że nie wszyscy pracujący przy dystrybucji muszą być (i nie są) bogami Linuksa. Jeśli wydaje ci się, że przy tak dużym tworze pracuje dwieście klonów Kevina Mitnicka, to właśnie padłeś ofiarą mitu. PLD swoją wielkość (a jesteśmy bodaj największą dystrybucją na świecie, jeśli chodzi o ilość dostępnych i możliwych do zbudowania pakietów) zawdzięcza właśnie rozdrobnieniu pomiędzy sporą liczbę osób o bardzo różnych zainteresowaniach i potrzebach. Panuje tu jedna zasada - rób to, na czym się znasz i czego sam używasz. Dzięki temu mamy ogromny przekrój pakietów, od tych stricte desktopowych do tych o bardzo specyficznych zastosowaniach serwerowych. A kto nad tym panuje? Teoretycznie nikt, w praktyce całością kieruje Release Manager, czyli opiekun danej linii dystrybucji. Jego praca nie polega oczywiście na staniu i poganianiu innych za pomocą bicza. Praca jest całkowicie dobrowolna i wykonywana w wolnym czasie (za wyjątkiem jednego człowieka, którego wszyscy chyba znają, ale jest on w rzeczywistości klastrem ludzi zamieszkujących na stałe w czeluściach naszego CVS). Nad jakością, niejako przy okazji, czuwa ogół deweloperów. Za zepsucie czegokolwiek czeka cię lincz publiczny i siedem lat ciężkich robót w pobliskiej restauracji szybkiej obsługi na literę M. W praktyce skończy się najwyżej na krótkim flame’ie, ciężko bowiem kogoś zwolnić z wolontariatu. Nie zdarzyło się chyba jeszcze, żeby ktoś wskutek pomyłki utracił prawo dokonywania zmian w dystrybucji. Jak więć można pomóc?

Pomóc może prawie każdy. Tutaj pewnie odezwą się głosy mówiące ja nie umiem programować, ale smutna prawda jest taka, że nie jest to umiejętność niezbędna ani nawet wymagana, a w codziennej pracy często nieprzydatna. Wymagane jest za to pewne doświadczenie w pracy z systemami linuksowymi. Pozostałe umiejętności zależeć będą od kierunku, w jakim zechcesz się udać. Oczywiście, mamy programistów i własne projekty OpenSource, ale na tym dystrybucja się nie kończy. Gro pracujących nad nią ludzi stanowią opiekunowie bazy pakietów i to o nich w mowie potocznej mówi się deweloperzy.

Podstawowym zadaniem takiego dewelopera jest dbanie o to, by dystrybucja (przynajmniej w ramach danej linii) była spójna, ale jednocześnie dostarczała niezbędnej funkcjonalności każdemu użytkownikowi, nie stając się jednocześnie dinozaurem ze względu na przestarzałe oprogramowanie. Codzienna (termin zwyczajowy, nie oznacza konieczności pracy od poniedziałku do niedzieli) praca polega na edycji plików spec - instrukcji dla farmy maszyn budujących pakiety. Jeśli pakiet jest potrawą, a komputer budujący kucharzem, to plik spec jest przepisem na przyrządzenie tej potrawy. Wygląda trochę jak strona z książki kucharskiej dla opornych, potrzebujesz następujących składników, następnie weź takie naczynie i wsyp do niego to i tamto, mieszając powoli aż do uzyskania jednolitej konsystencji. Brzmi groźnie, ale składnia recepty jest dość prosta i opanowanie jej nie zajmuje więcej niż dwa dni. Zwłaszcza, że krótki opis, przykładowy plik i linki do szczegółowej dokumentacji znajdują się w naszym poradniku dewelopera.

A jak zostać deweloperem? To proste - trzeba chcieć. Na początek dobrze zapisać się na listy dyskusyjne do tego celu przeznaczone. Rozsądnie jest też znaleźć sobie opiekuna na start - osobę, która wyjaśni wątpliwości, pomoże, doradzi i, co najważniejsze, będzie miała uprawnienia wprowadzić nasze zmiany do dystrybucji. A należy tu zaznaczyć, że całość utrzymywana jest w repozytorium CVS, do którego prawo zapisu mają tylko deweloperzy. Stąd początkowe ulepszenia musimy komuś podsyłać, jeśli nie mamy opiekuna, to możemy wysłać je na listę pld-devel-pl. Tutaj kilka uwag pro-forma - opiekuna nie szukamy na siłę, jeśli nikogo nie znamy, to nie wysyłamy do wszystkich maila z pytaniem, kto się podejmie; poprawki przysyłamy w postaci czystego tekstu, nie pakujemy plików spec zipem, tarem ani rarem; poprawki do istniejących plików wysyłamy w postaci zunifikowanej łatki (wypluwa ją z siebie diff -u); nie zniechęcamy się, jeśli nikt nam nie podziękuje i nie padnie do stóp, a bardziej prawdopodobne jest, że ktoś zwróci nam uwagę na kilka błędów w naszych pierwszych dziełach.

Pliki spec brzmią strasznie? Mamy też dział dokumentacji, a ta przy dynamicznie rozwijającym się oprogramowaniu szybko się dezaktualizuje. Panowie zajmujący się tą działką z chęcią przywitają skorych do pomocy. Potrzebujemy także zainteresowanych prowadzeniem tłumaczeń dokumentacji na inne języki. Wymagana jest przede wszystkim znajomość opisywanego tematu, podstawowa chociażby wiedza z dziedzin gramatyki i ortografii oraz umiejętność pisania w sposób zrozumiały. Jeśli uważasz, że dokumentacja to dla ciebie zbyt wiele, pozwól, że zaproszę cię do rozwoju naszej oficjalnej strony. Ta ostatnia oparta jest o publicznie dostępne Wiki i nie wymaga żadnych specjalnych uprawnień do wprowadzania na niej zmian. Zanim jednak ruszysz sprawdzić, czy da się za jej pomocą pozdrowić ciocię, uprzedzę że zmiany w każdym aspekcie dystrybucji są natychmiast widoczne dla wszystkich zapisanych na stosowne listy monitorujące, więc swym przebojowym włamaniem możesz co najwyżej zyskać paru wrogów i etykietkę niespecjalnie rozwiniętego intelektualnie.

Jeśli i to nie spełnia twoich oczekiwań, możesz zawsze uwolnić swoją duszę artysty. Z otwartymi ramionami przyjmiemy wszystko, co nadaje się do publikacji - tapety, wygaszacze, style, skórki do programów, zestawy dźwiękowe czy własne kursory. Jedynym warunkiem jest licencja pozwalająca na swobodną dystrybucję danego elementu i odpowiednio wysoki poziom wykonania (choć o gustach się nie dyskutuje, przypominam o istnieniu pojęcia smaku).

Co zaś mitów się tyczy, jeśli planujesz zasilić nasze szeregi dla sławy czy poklasku, to trafiłeś kiepsko. Nikt jeszcze na tym nie zarobił, a i płeć przeciwna nie darzy większą sympatią ludzi związanych z Linuksem. Pracujemy dla siebie samych i dla własnych korzyści, czy to z powodu dostępu do szerokiego oprogramowania, czy możliwości lepszego poznania używanej przez siebie platformy.

Pozdrawiam i żegnam się powoli, jako że godzina już niemłoda. Mam nadzieję, że kogokolwiek zainteresowałem.

Skinowanie bloga

Jako, że znalazłem chwilę czasu na kreatywną zabawę z kodem, pozwoliłem sobie dorobić kilka theme’sów dla tego bloga. Ku uciesze molestujących mnie ludzi, powrócił, znany dobrze tym z was, którzy czytają mnie dłużej, zestaw evil. Dla używających przeglądarek napędzanych mozillowym silnikiem Gecko gratka - theme mozilla, czyli zestaw pełen okrągłości i nawiązań kolorystycznych do stron Organizacji.

Stosowna funkcjonalność dostępna jest na głównej stronie, w prawym panelu. Mam nadzieję, że się spodoba.

Polska prasa tematyczna

Poniższe zdarzenia miejsce miały w ostatni piątek, pierwszego kwietnia. Dzień piękny i ciepły, godziny popołudniowe, ja po pracy zbierałem się właśnie do wycieczki na dworzec celem wyjazdu do Poznania. Świadom konieczności spędzenia przynajmniej dwóch godzin w pociągu, postanowiłem urozmaicić sobie jakoś podróż. W tym celu udałem się do pobliskiego kiosku z zamiarem kupienia jakiegoś czasopisma na drogę.

- Dzień dobry, czy dostanę Linux+? - zagadnąłem pogodnie kioskarkę
- Nie, nie ma
- A może dostanę Linux Magazine?
- Nie, też nie ma
- A może Chip Special?
- Nie, ale mam Polskie Amatorki
- Wie pani, to są magazyny komputerowe…
- A, to nie, mam Click i Komputer Świat

Stanąłem tam jako głaz, wryty i zmieszany. Nie wyglądało to na dowcip prima-aprilisowy, a zakupu Linux+ dokonywałem tam już wielokrotnie. Całe zajście, dość zabawne, przywróciło moją wiarę w fantazję i kreatywność polskich pracowników. :)