Wywiad z Patrickiem Volkerdingiem

Wszystko o czym chcecie dyskutować a tyczy się choć trochę Slackware Linux i nie tylko!

Moderatorzy: Moderatorzy, Administratorzy

Awatar użytkownika
knives
Użytkownik
Posty: 85
Rejestracja: 2009-09-24, 14:43

Wywiad z Patrickiem Volkerdingiem

Post autor: knives »

Poniżej przedstawiamy przetłumaczony na język polski wywiad z Patrickiem Volkerdingiem, który przeprowadził jeremy z LinuxQuestions.

----------

Patrick Volkerding, założyciel Slackware Linux, zgodził się na wywiad z LinuxQuestions.org. Oto co miał do powiedzenia. Niektóre z pytań zostały napisane przez forumowiczów. Można je rozpoznać po nicku w nawiasie. Dzięki Pat!

--jeremy


LQ) Rozpoczynając, czy mógłbyś powiedzieć coś o sobie? (LQ)

volkerdi) Pewnie. Urodziłem się w Wirginii, gdy mój ojciec stacjonował tam jako dentysta w marynarce wojennej. Gdy byłem bardzo mały, przeprowadziliśmy się do Dakoty Północnej. Jak daleko sięgam pamięcią, zawsze pociągała mnie nauka, wyścig kosmiczny i inne, typowe dla dzieciaka zainteresowania, który chce kiedyś zostać jakiegoś rodzaju naukowcem. Miałem zabawkowy zestaw konstrukcyjny [ang. erector set], mnóstwo klocków Lego oraz całkiem niezły zestaw młodego chemika, pełen trucizn, którymi nie pozwolonoby się dzisiaj dzieciom bawić. Gdy miałem 7 czy 8 lat moja klasa odbyła wycieczkę do uniwersytetu stanowego Dakoty Północnej, aby zobaczyć wydział informatyki. To tam po raz pierwszy miałem styczność z Uniksem i zrozumiałem, że chcę pracować z komputerami. Miałem Atari 2600 i chciałem zdobyć dla niego dość rzadki kartridż z BASIC-iem (nigdy mi się to nie udało), a gdy pojawiły się pierwsze komputery osobiste, zacząłem przebywać w Radio Shackach i innych sklepach z elektroniką, by dostać dawkę informacji o komputerach. Radio Shack w centrum handlowym miał na wystawie TRS-80 Model I oraz kolekcję książek o BASIC-u. Nauczyłem się programować przepisując wydruki programów z jednej z książek o grach komputerowych Davida Ahla, a następnie próbując je zmodyfikować. Sklep nie miał nic przeciwko temu, abym przychodził, pisał kod i zapisywał programy na taśmie, żeby oni mieli dema. Niestety nie dobiliśmy targu i moim pierwszym komputerem był Apple ][+, z którym nauczyłem się programować w Pascalu (UCSD p-System), Hyper-C, Forth i innych językach. Forth doprowadził mnie do uznania odwrotnej notacji polskiej i do dziś używam tylko kalkulatorów HP używających tę notację. Po szkole średniej poszedłem na studia magisterskie z inżynierii komputerowej, ale po 2 latach było dla mnie jasne, że projektowanie sprzętu nie jest moim powołaniem i że stopień naukowy z informatyki będzie dla mnie lepszy. Poza tym, szkoła, którą na początku wybrałem, była bardzo skupiona na VMS [ang. Virtual Memory System]. Przeniosłem się więc do uniwersytetu stanowego Moorhead, który właśnie wtedy dostał kilka maszyn AT&T UNIX podłączonych do Internetu (poprzednia szkoła miała dostęp tylko do BITNET-u, który był stosunkowo bezużyteczny). To pod koniec studiów na MSU pierwszy raz zacząłem pracować z Linuksem.

LQ) Jak doszło do twojego związania się z Linuksem i wolnym oprogramowaniem oraz jak wyglądała droga, która doprowadziła cię do stworzenia Slackware'a? (LQ)

volkerdi) Było to w 1992, gdy pierwszy raz usłyszałem o projekcie, w którym ktoś z Finlandii próbował napisać klon Uniksa. W tamtym czasie używałem OS/2 na 16 megahercowym komputerze 386/sx. To był dobry system operacyjny, ale to, czego naprawdę chciałem, był jakiś rodzaj Uniksa. Oglądałem reklamy Coherenta w magazynie Byte i brałem go pod uwagę, jak również Miniksa. Poszedłem nawet do miejscowego sklepu komputerowego i zapytałem o Xeniksa SCO, który, jeśli dobrze pamiętam, kosztował kilka tysięcy dolarów za pojedynczą licencję! Dziękuję, postoję. Byłem więc bardzo podekscytowany idąc do laboratorium komputerowego, by sprawdzić grupy USENET i strony FTP, gdzie miał miejsce rozwój. W tamtym czasie to było zbyt dobre, by mogło być prawdziwe, ale wkrótce potem miałem dyskietki H. J. Lu w mojej maszynie (to działa!), a następnie sprawdziłem MCC Interim Linux. Yggdrasil już wtedy istniał, ale nie próbowałem go przez długi czas, gdyż moja maszyna nie miała napędu CD-ROM. Szybko wylądowałem (miękko) na jednej z pierwszych wersji dystrybucji SLS Petera MacDonalda.

Uczęszczałem na zajęcia ze sztucznej inteligencji, gdzie pisaliśmy cały kod w Lispie. Dostarczono nam DOS-owy interpreter Lispa, ale interpreter CLISP, który był w SLS okazał się znacznie lepszy. Powiedziałem mojemu profesorowi o CLISP-ie i o Linuksie, a on zapytał, czy pomógłbym mu z zainstalowaniem Linuksa w laboratorium na jednym z komputerów AT&T 486 z kartą graficzną S3. Udaliśmy się tam i instalacja poszła nam całkiem sprawnie. Wyjąłem mój notes („czas naprawić bugi!”) i zacząłem usuwać wszystkie problemy, które udokumentowałem podczas użytkowania SLS. To doprowadziło profesora do pytania, czy byłoby możliwe naprawienie wszystkich tych problemów, ale na dyskietkach, i zautomatyzowanie instalatora tak, aby przyszli studenci mogli programować w Linuksie, żeby nie trzeba było płacić za licencję przeciętnej wersji LISP-a. Byłem gotowy na to wyzwanie i zacząłem dochodzić do tego, jak to wszystko działa. SLS był rozprowadzany głównie jako binarki prawie bez żadnego kodu źródłowego i z niewielką liczbą wskazówek, jak rzeczy były zbudowane. Nie było żadnych skryptów budujących, ale to było typowe dla dystrybucji Linuksa w 1993 (w tę pułapkę sam na początku wpadłem, do czasu, gdy zmęczyło mnie ponowne uczenie się tego, co dokładnie zrobiłem, za każdym razem, gdy coś musiało zostać przebudowane). Przez następny miesiąc poprawiłem wszystkie bugi w SLS, o których wiedziałem, zaktualizowałem kernel i uprzątnąłem program instalacyjny. Mój przyjaciel, Brett Person, był moim pierwszym beta testerem (który również dużo wniósł do instalatora) i w kwietniu 1993 zachęcał mnie do podzielenia się z Internetem tym, co miałem. Znalazłem kilku innych beta testerów dzięki bezpośredniemu wysyłaniu e-maili do ludzi piszących posty o problemach z SLS na comp.os.linux, pytając czy chcieliby przetestować to, nad czym pracowaliśmy. Otrzymałem sporo komentarzy i więcej zachęt do wrzucenia bety na serwer FTP. W lipcu 1993 umieściłem pierwsze publiczne wydanie Slackware'a na serwerze FTP, działającym na sprzęcie AT&T 3b2 z Uniksem i ogłosiłem to na comp.os.linux. Odpowiedź była dość przytłaczająca… w szczególności dla uniksowej maszyny hostującej. Próbowałem utrzymać wszystko na chodzie przez kilka dni, ale serwer nie wyrabiał, a Linux też nie był jeszcze w stanie sprostać zadaniu (stos TCP/IP ciągle doznawał losowych przestojów), dlatego poprosiłem o pomoc w hostingu. Pośród odpowiedzi była jedna od Roda Grimesa z projektu FreeBSD, który zaoferował miejsce na serwerze Walnut Creek CDROM ftp.cdrom.com, które z wdzięcznością zaakceptowałem. Doprowadziło to do długiego związku z ludźmi z Walnut Creek CDROM.

LQ) Które wydanie Slackware’a było najbardziej wymagające/trudne do złożenia? A które dające największą satysfakcję? (solarfields)

volkerdi) Wracając pamięcią zdecydowanie jest kilka, które wyróżniały się jako szczególnie trudne głównie ze względu na jakąś dużą zmianę. Przejście z a.out do ELF na pewno było jedną z nich, jak również konwersja z ELF libc5 do glibc, gdy ukazało się pierwsze stabilne wydanie glibc. Bardzo ucieszył mnie widok stabilnego wydania glibc, gdyż przyjąłem politykę niezamieszczania wersji beta istotnych komponentów, takich jak biblioteki lub kompilator C. Większość innych dystrybucji zwyczajnie bazowała na wczesnych wydaniach [ang. pre-release] glibc. Sam byłem blisko pogwałcenia mojej polityki w momencie, gdy obiecywana stabilna wersja glibc w końcu się ukazała. Prawdopodobnie najtrudniejszym, a zarazem dającym największą satysfakcję wydaniem był Slackware 13.0, pierwsza wersja wspierająca architekturę x86_64. Eric Hameleers zasługuje na wielkie uznanie za jego pracę włożoną w przeniesienie Slackware’a na systemy AMD64/x86_64 i za zadbanie, aby dodanie wsparcia dla multilib było stosunkowo proste. Byłem skłonny wspierać tylko 64-bitową wersję, używając tych samych katalogów z bibliotekami, jak w 32-bitowym Slackware’rze, gdyż uważałem /lib64 za niepotrzebną komplikację, która będzie wymagała łatania wielu źródeł. Na początku trzeba było dużo poprawiać, teraz gdzieniegdzie też, ale /lib64 był rozwiązaniem, które wszyscy zaadoptowali.

LQ) Slackware jest najstarszą aktywną dystrybucją, jakie Twoim zdaniem są powody tej długowieczności? (ChrisAbela)

volkerdi) W Slackware’rze bardzo staram się spełnić życzenia deweloperów. To nie jest miejsce na dodawanie łatek z nową funkcjonalnością, czy wersji beta (o ile da się tego uniknąć). Lao Tzu powiedział, że trzeba podążać za innymi, żeby ich prowadzić. Oczywiście mam własną koncepcję tego, jak to wszystko powinno działać, ale staram się nie narzucać jej w samolubny sposób. Celem jest rozwój bez zapominania o korzeniach. Nie mam nic przeciwko zmianom, ale próbuję unikać wprowadzania ich tylko po to, żeby się odróżniać. Ludzie, którzy wracają po pewnym czasie do Slackware'a, są mile zaskoczeni, że nie muszą wszystkiego uczyć się od początku. Dzięki temu mamy lojalnych użytkowników - za co jestem wdzięczny. Wygląda na to, że coś robimy dobrze.

LQ) Czy myślałeś, że Slackware może przetrwać tak długo? Czy nadal masz ten sam entuzjazm co na początku? (jmccue)

volkerdi) Nie, nie myślałem, że Slackware może przetrwać tak długo, a na pewno nie, że będę nadal nad nim pracować, ale dosyć wcześnie osiągnięta została pewna masa krytyczna i projekt rozwijałby się dalej czy to za moim przewodnictwem, czy bez niego. Nadal mam wiele zapału jeśli chodzi o Slackware'a, ale jest to inny rodzaj entuzjazmu niż na początku, kiedy wszystko dopiero ruszało. To był ekscytujący okres dla Slackware'a i Linuksa, gdy zaczynały się dopiero przyjmować. Slackware miał pierwsze stoisko poświęcone Linuksowi na COMDEX i ludzie tłoczyli się, żeby zobaczyć nasz serwer web działający na laptopie! Pierwsza konferencja Linux-Kongress, która odbyła się w Holandii [tak naprawdę w Niemczech - źródło – przyp. tłum.] w 1994, była kolejnym kamieniem milowym początków Linuksa. Niewiele jest rzeczy, które mogą przyćmić takie momenty. Gdy Walnut Creek połączył się z BSDi, mieliśmy zamiar zadebiutować na giełdzie, co było bardzo ekscytujące. Niestety później przyszedł krach, oferta publiczna została wycofana, a spółka ostatecznie sprzedana, gdy skończyły się fundusze. Niemniej, cieszę się że nadal robię to, co robię. Uwielbiam pracować nad Slackware'em, być częścią społeczności Linuksa i nadal wierzę, że to co robimy, ma znaczenie.

LQ) Gdzie widzisz Slackware’a za 5 lat? (smoooth103)

volkerdi) Wydaje mi się że możemy tylko zgadywać. Pięć lat to bardzo długi okres, jeśli chodzi o komputery. Kiedy myślę o tym, co się wydarzyło, naprawdę nie byłbym w stanie przewidzieć rozwoju wypadków uzależnionych głównie od deweloperów i ciągle zmieniających się potrzeb użytkowników. Dlatego staram się skupiać raczej na celach krótkoterminowych. Kiedy zostaną osiągnięte, jasne staje się, co trzeba zrobić w dalszej kolejności. To raczej ewolucja niż ukierunkowany rozwój zgodny z jakimś założonym projektem. Wyzwanie na następne pięć lat, to pozostać wiernym korzeniom Slackware'a i filozofii Uniksa, podczas gdy inne projekty i deweloperzy mogą mieć odmienne podejście do rozwoju Linuksa jako całości. Wygląda na to, że świat odchodzi od komputerów osobistych na rzecz urządzeń komunikacyjnych, a aplikacje (zwłaszcza w biznesie) przenoszone są do chmury. Jaki wpływ będzie to miało na Slackware’a dopiero się okaże.

LQ) Czy masz jakieś plany dotyczące sukcesji, np. Slackware Foundation, podobnie do Mozilli, LibreOffice’a itp.? (kingbeowulf)

volkerdi) Nie wydaje mi się, żeby te przykłady mogły być nazwane „planem sukcesji” -- Mozilla Foundation jest organizacją non-profit, a LibreOffice jest forkiem powstałym w wyniku niezadowolenia z kierunku, jaki Oracle obrał dla OpenOffice'a (a przynajmniej z poczucia, że rozwój projektu zmierza w złą stronę). Jeśli chodzi o to pierwsze, rozważałem coś w tym kształcie. FreeBSD ma organizację non-profit, która zbiera dotacje w postaci sprzętu i funduszy, i wydaje się, że u nich to działa. Rozważałem to, ale nie wiedziałbym od czego zacząć. Założenie organizacji non-profit jest poważnym przedsięwzięciem i ciężko porywać się na coś takiego bez pomocy z zewnątrz.

Żeby odpowiedzieć na pytanie, które, jak mi się wydaje, naprawdę zadajesz -- czy będzie Slackware bez Patricka? Myślę, że tak. Kiedy zachorowałem w 2004, przeprowadziliśmy wiele dyskusji na ten temat i opracowaliśmy plan na wypadek wielkiego „co jeśli”. Ludzie z ekipy nie mieli zamiaru porzucić projektu.

W każdym razie, nie mamy planu sukcesji jako takiego, ale poradzimy sobie z tym, jeśli do tego dojdzie. W międzyczasie staramy się nie jeździć wszyscy tym samym autobusem.

LQ) Co myślisz o panice, która wybucha, kiedy strona domowa Slackware’a przestaje działać? (kristizz)

volkerdi) Panika generuje jeszcze więcej paniki i kiedy wszyscy zaczynają świrować, to ja też. Zwłaszcza że kod strony był sklecony wiele lat temu przez ludzi, którzy dawno odeszli gdzie indziej. Niestety zawsze kiedy projekt trafia na jakieś wyboje, znajdą się ludzie, którzy postrzegają to jako jego ostatnie drgnienia. Tak było od zawsze i nie tylko w odniesieniu do naszego projektu. Netcraft chyba potwierdzał już śmierć każdego projektu open source jaki istnieje. Niemniej to bolesne, kiedy ton komentarzy sugeruje, że brak natychmiastowego rozwiązania problemu wynika z mojego lekceważenia. Uwierzcie, zależy mi na tym, ale kiedy trolle zaczynają ciskać we mnie ciętymi komentarzami, czuję się zniechęcony i myślę sobie „kiedyś byłem guru Linuksa, ale dostałem strzałą w kolano”. Jednak staram się wyjść z tego z nowymi pokładami determinacji. Strona znowu działa, Mark Post przepisał ją w nowym PHP. Mamy w planach dodanie paru rzeczy, jak np. system zarządzania treścią, który pozwoli częściej publikować nowe treści. Minęło trochę czasu od kiedy slackware.com kipiał aktywnością -- nasza obecność w sieci jest głównie na LinuxQuestions i osobiście wolę to, niż prowadzić własne forum. Próbowaliśmy tego w okolicach 2000 roku i okazało się, że poświęcaliśmy więcej czasu na forum niż na rozwój projektu. Dlatego ostatnie problemy rozwiązaliśmy po prostu przenosząc starą stronę, niż pisząc nową od zera. Dużo zostało zrobione w kierunku zbudowania zupełnie nowej strony, ale ten wysiłek powinien zostać włożony w przygotowanie -currenta do kolejnego wydania. W kolejce czeka dużo rzeczy do zrobienia.

LQ) Czy Twoja ciężka praca się zwróciła, i czy rozwój Slackware’a zaspokaja Cię finansowo i osobiście? (BlackRider)

volkerdi) Cóż, jeśli chodzi o finanse to ostatnich kilka lat było dosyć ciężkich. Gdybym parę lat temu nie podjął strategicznej decyzji o powrocie do Minnesoty, nie byłbym w stanie się utrzymać pozostając w rejonie Zatoki San Francisco. Kalifornia nie jest tanim miejscem i zawsze tam musiałem zaciskać pasa. Zresztą tutaj też ostatnio zaciskałem go dosyć mocno. Nawet nie mam już ubezpieczenia… odpukać. Osobiście – jak najbardziej. Zaprzyjaźniłem się z ludźmi z całego świata. Codziennie piszą do mnie ludzie, którzy uwielbiają Slackware'a, polegają na nim w krytycznych zadaniach, i nie chcą używać niczego innego. Praca nad projektem daje dużo radości, a goście z ekipy są moimi najlepszymi kumplami. Tego nie da się wycenić w dolarach.

LQ) Możesz opisać swój typowy dzień pracy? (slacker77)

volkerdi) Nie mam jakiegoś przyjętego rozkładu, ale dzień zazwyczaj rozpoczynam od wypicia kawy (bardzo ważne!), czytania e-maili i LinuxQuestions oraz dyskusji z resztą ekipy na IRC-u. Śledzę sporo list dyskusyjnych, jak np. BugTraq, oss-security i innych dotyczących oprogramowania, aby mieć pojęcie o zmianach, które będą nas dotyczyć. Reszta ekipy zajmuje się swoją działką, proponują pakiety, a ja doglądam czy jest już pora żeby zintegrować je z -currentem. Jest dużo kompilowania i testowania potencjalnych aktualizacji, a w ostatnich latach coraz więcej nakładania łatek, tak więc sporo czasu spędzam na szukaniu potrzebnych poprawek albo na pisaniu swoich. Naprawdę musimy to wszystko robić. Wydaje się, że aktualizacje toolchaina (gcc i glibc w szczególności) coraz częściej psują istniejący kod, dlatego to, co powinno być prostym podbiciem wersji, staje się nagle przenoszeniem wszystkiego na nowy kompilator (ciekaw jestem jak szeroko przyjęły się llvm/clang, bo podejrzewam, że to trochę mniej ruchomy cel). Oczywiście aktualizacja skryptów, kompilowanie, paczkowanie i testowanie to chleb powszedni projektu, ale przed tym trzeba się dużo naczytać… Wolę tworzyć dobre, niż częste wydania, bo nie jest wcale łatwo wycofać się z błędnego pakietu w -current, co dopiero w wersji stabilnej.

Zobacz: fortune -m "three lines" fortunes2

LQ) Czy możesz opisać swoją konfigurację pulpitu (menedżer okien / środowisko graficzne)?

volkerdi) Na swoim komputerze używam KDE takiego, jakie jest dostarczane ze Slackware’em i używałem go prawie wyłącznie od czasu kiedy zostało dodane. Wcześniej przez lata używałem FVWM. Próbowałem większości popularnych menedżerów okien i środowisk wystarczająco długo, żeby poznać je od podszewki. Jestem też fanem Xfce, gdyż jest przyjemny i działa płynnie na moich starszych maszynach, a dostarcza kompletne środowisko.

LQ) Czy zdradzisz nam jakiego sprzętu używasz do testowania/rozwoju/codziennej pracy? (tuxrukes)

volkerdi) Prawie całą pracę wykonuję na AMD Phenom II X6 1100T pracującym z częstotliwością 3,3GHz z 16GB pamięci. Ma pięć dysków SATA. Cztery z nich działają jako LVM na RAID5, a jeden służy do tymczasowych, testowych instalacji. Chomikuję sprzęt i wiele moich starych komputerów nadal jest używanych, np. do podpisywania pakietów, generowania sum kontrolnych czy list plików, oraz do synchronizacji aktualizacji z serwerem, na którym trzymamy jeszcze nieupublicznione drzewa plików. Mam w ten sposób dostęp do różnych kart graficznych - nVidii, Intela i AMD, zatem mogę się upewnić, że są obsługiwane poprawnie. To było szczególnie ważne, kiedy szykowaliśmy wydanie 13.37, bo wszystkie sterowniki zaczęły używać modesetting kernela… musieliśmy rozwiązać kilka niebanalnych problemów.

LQ) Slack zawsze miał dość zamknięty model rozwoju. Jak najłatwiej można wnieść do niego swój wkład? Poprzez udział w rozwoju popularnych projektów? Czy najlepiej rozpocząć projekt powiązany ze Slackiem i zobaczyć czy się przyjmie? (bobzilla)

volkerdi) Jeśli uważasz, że brakuje czegoś, na co jest szerokie zapotrzebowanie, zawsze możesz zgłosić swój SlackBuild na slackbuilds.org (o ile jeszcze go tam nie ma… kolekcja jest dosyć spora). To nam także pomaga, kiedy zdecydujemy się włączyć dany pakiet do oficjalnego wydania. Rozpoczęcie nowego projektu też jest dobrą drogą. Kiedy zrezygnowaliśmy z GNOME-a, ucieszyło nas, że znaleźli się ludzie, którzy zaczęli go dostarczać. Testowanie -current i zgłaszanie błędów jest bardzo pomocne, zwłaszcza jeśli znalazłeś rozwiązanie problemu. To samo dotyczy kandydatów do aktualizacji w wydaniu rozwojowym. Otrzymujemy pomocną dłoń od ludzi, którzy testują najnowsze wersje oprogramowania i odkrywają, że obecny SlackBuild na nich nie działa, sprawdzają dlaczego, i dają nam o tym znać. Sporo z tych dyskusji toczy się na LinuxQuestions, więc proszę, dzielcie się swoją wiedzą.

LQ) Jak dobierasz sobie ludzi do ekipy? Jak zostali wybrani AlienBOB, Alan_Hicks, rworkman itp.? (suppy)

volkerdi) Najpierw trochę historii -- dzisiejszy rdzeń Slackware'a to tak naprawdę druga w kolejności ekipa. W pierwszej byli David Cantrell, Chris Lumens i Logan Johnson. David i Logan podeszli do mnie na targach w Chicago. W tamtych czasach Slackware nie miał swojej strony internetowej, a oni zaoferowali pomoc przy jej stworzeniu. Kiedy przeprowadziłem się do Kalifornii, żeby pracować w Walnut Creek, oni też dostali tam stanowiska i pracowaliśmy razem dopóki nie pękła bańka dotcomów. David i Chris pracują teraz dla Red Hata, głównie nad instalatorem, a Logan pracuje w MOVL. Chris był parę lat temu sławny za wymyślenie motywu „hot-dog” Fedory.

Obecny zespół wziął się z systemu nieoficjalnych mirrorów Slackware’a. Erik Jan Tromp (znany również jako alphageek) prowadził stronę z listą tych serwerów lustrzanych. Poza jego własnym było tam kilka innych stron i administratorów; mieli kanał IRC, na którym omawiali sprawy dotyczące tych mirrorów. Wreszcie napisali do mnie o tym i zwabili na IRC. Początkowo mieliśmy omawiać sprawy dystrybucji oprogramowania, ale skończyło się na dyskusjach o rozwoju. Na tym kanale IRC przede mną byli ludzie tacy jak: mrgoblin, amrit, karlmag, alphageek i kilku innych, którzy tam zaglądają, ale nie są już tacy aktywni. Po tamtym okresie ludzie, którzy zostali włączeni do ekipy, zazwyczaj wnieśli jakiś znaczny, nieoficjalny wkład w Slackware'a. Robby i Alan otrzymali zaproszenia z uwagi na ich pracę nad SlackBuilds.org, a alienBOB za stworzenie czystego portu do architektury x86_64 i za pracę nad swoimi dodatkowymi publicznymi pakietami. Fred Emmott ze Slamd64 (teraz pracujący w Facebooku) też został zaproszony i nadal go tam widujemy. Mark Post dołączył po przeniesieniu Slackware'a na mainframe IBM S/390 (i zgłoszeniu poprawek do odkrytych w tym procesie błędów). Heinz Wiesinger otrzymał zaproszenie za dokonanie kilku cudów, z których najnowszy to rozgryzienie problemów z MySQL-em i PHP, włączając sposób skompilowania PHP w jednym przejściu, z pozostawieniem wszystkich rozszerzeń kompatybilnych z różnym odmianami PHP i różnymi modułami Apache Multi-Processing. Przyjęliśmy również sporo jego SlackBuildów ze slackbuilds.org, więc wydaje się, że dobrze pasuje.

Zadziw nas odpowiednio, a może też zostaniesz zaproszony. Ale uważaj, bo mamy przerażające rytuały inicjacyjne.

LQ) Czy rozważałeś lepsze sposoby na komunikację z użytkownikami Slackware'a (np. przez blog lub Google+)? A co z bardziej otwartym modelem rozwoju, takim jak git? (wiele osób)

Zastanawiałem się nad korzystaniem z portali społecznościowych. Mam konta na Google+ i Twitterze, gdzie ogłaszałem lub dyskutowałem o sprawach związanych ze Slackware’em. Mam również konto na Facebooku, ale nie używam go zbyt często. Nigdy nie ciągnęło mnie do prowadzenia własnego bloga (jednakże cieszę się, że alienBOB ma swój). Staram się umieszczać więcej informacji w ChangeLogu, niż tylko listę zmienionych pakietów.

Co do bardziej otwartego modelu rozwoju, jak git czy inny system kontroli wersji, to prawdopodobnie stanie się koniecznością. W szczególności rworkman próbuje przeforsować ten pomysł. W tej chwili mamy kilka osób prowadzących własne drzewa, a ja coraz więcej czasu poświęcam na synchronizację zmian między aktualizacjami, które były rozwijane równolegle. Zawsze zdawałem sobie sprawę z tego, że się nie skaluję*, ale ostatnio staje się coraz bardziej oczywiste, iż koordynowanie samemu wszystkiego, co ma się znaleźć w wersji -current, na dłuższą metę nie będzie możliwe, gdyż liczba pakietów ciągle rośnie. Zwłaszcza jeśli oczekujemy, że porty na ARM oraz inne architektury będą korzystały z tego samego drzewa źródłowego. Przy okazji, może już czas zastanowić się nad centralizacją niektórych części systemu SlackBuild. Choć dobrze jest mieć samowystarczalny skrypt, to nie jest to zbyt wygodne, gdy przychodzi wspierać nową architekturę. Nie ma to jak dodanie kilku nowych opcji do bloku ARCH i konieczność edycji każdego SlackBuilda, aby osiągnąć to, co powinno być łatwą zmianą. To rzeczy, którym musimy się przyjrzeć, gdy wypuścimy te wydanie i rozpoczniemy nowy cykl rozwojowy.

* Wyrażenie nawiązuje do sytuacji z 1998 roku, kiedy to stało się jasne, że Linus Torvalds sam nie podoła nawałowi pracy nad źródłem Linuksa. Zaczęto wtedy mówić o problemie, że Linus się nie skaluje [przyp. tłum.]

LQ) Co myślisz o obecnym trendzie w środowiskach graficznych (Unity, GNOME 3)? Dawno temu wybrałeś KDE dla Slackware'a. Czy jesteś zadowolony z kierunku (pulpit semantyczny), jaki obrali deweloperzy tego środowiska? (fgcl2k)

volkerdi) Nie miałem do czynienia z Unity czy GNOME-em 3 wystarczająco długo, by wyrobić sobie o nich opinię, ale obserwacja Unity wywarła na mnie wrażenie środowiska, które prawdopodobnie jest intuicyjne dla ludzi przyzwyczajonych do interfejsów znanych ze smartfonów i tabletów. Wydaje mi się, że deweloperzy ww. środowisk chcą trafić w ten właśnie rynek. Jestem pewien, że czułbym się bardziej komfortowo w GNOME Shellu. Między GNOME-em a KDE cieszę się, że to KDE jest w głównym drzewie Slackware'a. Niezmiernie mi się podoba i uważam, że jest bardziej spójne. Może to dlatego, że jest rozwijane głównie w C++. Zwykle wolę C niż C++, ale jestem przekonany, że C++ jest lepszym językiem do rozwoju interfejsów graficznych, gdyż łatwiej jest wykorzystać dostępne komponenty, zatem pokusa, by ponownie wynaleźć koło lub robić rzeczy poza dostarczonym frameworkiem, nie jest aż tak silna. Przejście z Qt3/KDE3 do Qt4/KDE4 było nieco wyboiste (choć przeczekaliśmy kilka pierwszych wydań) i myślę, że większość ludzi przyzna, iż KDE4 wyewoluowało w środowisko graficzne światowej klasy. Czekam też z niecierpliwością na nowe Xfce, ale będzie ono wymagało zaabsorbowania kilku zależności GNOME-a, których byłem zadowolony, że się pozbyliśmy. Ale to nic takiego, ponieważ Robby odwala większość ciężkiej roboty. Nowe wersje Xfce wyglądają naprawdę dobrze, więc dodanie z powrotem kilku pakietów będzie warte zachodu.

LQ) Wkrótce kilka potencjalnie inwazyjnych zmian zagości w niektórych popularnych dystrybucjach. Jak wpłynie to na Linuksa i, w szczególności, Slackware'a? Czy są takie, które rozważyłbyś zespolić ze Slackware'em? (55020 & tuxrules)

volkerdi) Tak, widzę kilka zbliżających się rzeczy, które mogą wprowadzić zamieszanie do sposobu, w jaki prowadzimy prace, a może nawet sprawić, że Slackware stanie się mniej uniksowy. Chyba dwie największe na horyzoncie to Wayland i systemd. To czy ich użyjemy, czy nie, pozostaje sprawą otwartą. Możliwe, że nie będziemy mieć w tej sprawie wyboru. Będzie to zależało od rozwoju oprogramowania, na które nie mamy wpływu. Trudno powiedzieć czy przejście na te technologie byłoby dobre dla Slackware'a. Przechodząc do systemd, podoba mi się pomysł szybszego bootowania (oczywiście), ale lubię też kontrolować start systemu za pomocą skryptów powłoki, które da się przeczytać. Wydaje mi się, że większość użytkowników Slackware'a również to preferuje. Nie spędzam całego dnia na rebootowaniu mojego komputera a przejrzawszy pliki konfiguracyjne systemd, wydał mi się to obcy sposób kontrolowania systemu. Próba kontroli procesów, gniazd, urządzeń, punktów montowania itd., wszystko w jednym daemonie jest sprzeczne z uniksową koncepcją „rób jedną rzecz, a dobrze”. Dla zwykłego użytkownika, jeśli spowoduje to szybsze uruchomienie się komputera, to misja wykonana. Z udevem ustępującym miejsca systemd w tych zadaniach, będziemy musieli zdecydować czy będziemy sami kontynuować rozwój udeva, sprawić, by systemd zastąpił jedynie funkcje udeva, a może czy chcemy cały ten kram. Wayland, w porównaniu, wygląda nieszkodliwie, ale pod warunkiem, że uda im się zaimplementować protokół sieciowy bezpośrednio lub przez jakiś dodatek. To kolejna rzecz, która jest większości niepotrzebna, ale bez której część użytkowników nie może się obejść. Lubię X11 i prawdopodobnie zostanę przy nim, jeśli przeprowadzka na Waylanda oznaczałaby utratę tej funkcji, nawet jeśli metoda renderingu Waylanda niosła ze sobą zalety takie jak mniejsza liczba artefaktów lub większa wydajność. Będziemy musieli zaczekać z określeniem bilansu zysków i strat do momentu, gdy takie porównania będą możliwe.

W tej chwili przejmuję się inną wielką zmianą, która wpłynie na przyszłość nie tylko Slackware'a, ale również Linuksa. Jest nią nadciągająca implementacja systemu Secure Boot we wszystkich komputerach z certyfikatem zgodności z systemem Windows 8 oraz całkowitym zablokowaniem sprzętu ARM bez możliwości wyłączenia tej „funkcji”. Początkowo zakładałem, że będziemy kontynuować z koniecznością wyłączenia Secure Boota, by zainstalować Slackware'a, ale zaskoczyło mnie, że nie wszystkie dystrybucje obrały tę drogę. Jeśli to sprawi, że dual boot nie będzie możliwy bez zmiany opcji w BIOS-ie, albo pozbawi nas sterowników, gdyż będą one zaprojektowane do pracy tylko z pewnymi podpisanymi kernelami, to będziemy musieli zmienić podejście. Nie mogę jednak sobie wyobrazić naszych użytkowników, zadowolonych z faktu, że od teraz mają zakaz kompilacji własnych kerneli i modułów. Celem będzie maksymalne zwiększenie wolności użytkowników do modyfikacji własnych systemów, a jeśli oznacza to, że będą musieli w BIOS-ie przełączyć jedną opcję, to chyba nie jest aż tak wysoko postawiona poprzeczka.Mam nadzieję, że nie przekształci się to w potrzebę flaszowania BIOS-u, gdy ta opcja zniknie w kolejnej generacji sprzętu; jeśli w ogóle będzie to możliwe. Wystarczyłby jedynie taki wymóg w następnej certyfikacji sprzętu zgodnego z systemem Windows. Namawiam wszystkich do podpisania petycji Free Software Foundation „Secure Boot vs Restricted Boot”, aby powiadomić producentów sprzętu o swoim stanowisku. Szczególnie rozczarowało mnie to, że systemy oparte na ARM-ie, a zaprojektowane do pracy z Windowsami, będą zablokowane, ale może Google lub inna firma ujmie się za nami. Możliwe, że Alan Hicks wyprzedził swój czas, gdy kupił sobie laptopa Apple'a do pracy z Linuksem. Zaprawdę, przyszło nam żyć w interesujących czasach.

LQ) Co myślisz o Fedorze i Solarisie „upraszczających” system plików przez np. połączenie /usr/bin z /bin? Rozważyłbyś kiedyś takie rozwiązanie? (ruario)

volkerdi) Oczywiście, ale najpierw zobaczymy jak to przejdzie w innych dystrybucjach oraz w jakim stopniu aplikacje zaczną tego oczekiwać. W Slackware’rze (i innych dystrybucjach) wiele programów, które normalnie instalują się w /urs/bin, muszą być przeniesione do /bin, ponieważ są potrzebne zanim /usr jest dostępny, jeśli jest on na osobnej partycji. Tak samo biblioteki musiały być przeniesione. Doprowadziło to do wielu symlinków z /usr/bin wskazujących na /bin, oraz z /usr/sbin na /sbin i w innych miejscach w systemie. Nie jestem pewien, czy jest to złe na tyle, żeby wprowadzenie zmian było warte cierpienia, ale jest to coś, co biorę pod uwagę. Najbardziej bolesnym wymogiem, jeśli chodzi o /usr, była reguła, iż musi być możliwym zamontowanie go jako dysk sieciowy. Może było to dobrym pomysłem w czasach, kiedy dyski twarde były małe i kosztowne, ale dzisiaj raczej nikt tak nie robi. Jeśli wprowadzimy taką zmianę, byłaby ona znacząca (i na pewno usprawiedliwiłaby podniesienie numeru wersji o jeden), ale nie jestem pewien jak (lub czy) przeszłaby aktualizacja z poprzedniej wersji. Być może przy pomocy narzędzia w instalatorze, który przekształciłby system do nowego układu. Taki taniec na działającej maszynie byłby trudnym zadaniem, gdyż menedżery pakietów, które są oparte na skryptach powłoki, używają programów, które w tym samym czasie musiałby być przenoszone.

Swoją drogą, zastanawiamy się jak najlepiej poradzić sobie z katalogiem /run. Ma sens, jeśli nie połączenie /var/run z nim, to przynajmniej sprawienie, by był dostępny we wczesnych stadiach uruchamiania systemu.

Jeśli chodzi o tego typu zmiany, musimy być pewni, iż faktycznie rozwiązują one istotne problemy i że lepiej na tym wyjdziemy nie doświadczając przy okazji nowych kłopotów, których wcześniej nie mieliśmy. Obecnie, nim /usr stanie się dostępny, możemy mieć ograniczoną liczbę narzędzi, ale dotychczas udawało nam sobie poradzić we wczesnych stadiach bootowania. Przykładowo, jeśli te zmiany wymuszą użycie initramfsu w każdym systemie, to niekoniecznie uważałbym to za uproszczenie.

LQ) Biorąc pod uwagę sukcesy młodszych dystrybucji, czy żałujesz jakichś decyzji z obranego kierunku dla Slackware’a, oraz czy masz aspiracje do przystosowania swojego dzieła dla mas? (vdemuth)

volkerdi) Heh… to trudne pytanie. Oczywiście, patrząc z perspektywy czasu dostrzegam wiele rzeczy, które mogą być uznane za „momenty Gary’ego Kildalla”, gdzie inne decyzje doprowadziłyby do sławy i pieniędzy. Czy byłoby to dobre dla mnie lub Slackware’a? Trudno powiedzieć. Wystarczy spojrzeć na to, co dzieje się z niektórymi zwycięzcami loterii. Powodem, dla którego nie podążyłem za ofertami, które mogłyby poprowadzić mnie na tę ścieżkę, było to, że ludzie z forsą tak naprawdę nie chcieli Slackware’a. Pragnęli jego użytkowników. Nie byłem nawet pewien czy mnie chcieli – mógłbym zostać szybko zepchnięty na margines. Nie wiedziałem nic o rozpoczynaniu biznesu i pozyskiwaniu inwestorów. Na początku niechętnie akceptowałem zapłatę za moją pracę, gdyż czułem, że wykorzystywałem programistów tworzących komponenty, które ja składałem w całość. Oczywiście od tamtej pory wokół Linuksa wyrosła cała branża i nie miałbym nic przeciwko posiadaniu większego kawałka, ale gdyby moim celem było zarobienie jak największej ilości pieniędzy, to nie jestem pewien czy tak by się stało. Możliwe, że Slackware byłby gwiazdą jednego sezonu lub stałby się czymś zupełnie innym, niż jest teraz. Pod wieloma względami Slackware wyewoluował w narzędzie do nauki. Na początku jest trudno, ale w końcu przychodzi nagroda w postaci zrozumienia. Slackware nie będzie z tobą walczył, jeśli chcesz wymienić lub przekompilować jego część. Jakoś myślę, że to nigdy nie będzie to, czego chcą masy, ale nie przeszkadza mi to.

LQ) Jakich narzędzi używasz do śledzenia tych wszystkich paczek w Slackware’rze oraz jak podejmujesz decyzje co i kiedy ma być uaktualnione? (trxdraxon)

volkerdi) Właściwie nie potrzeba wielu narzędzi aby śledzić taką liczbę pakietów, jakie mamy. Mam zakładki w lftp, dzięki którym mogę łatwo znaleźć źrodłowe serwery FTP wpisując „lftp <paczka>”, i zostawiam wskazówki w drzewie (paczka.url). Poza tym, zapisuję w kilku notesach listę rzeczy do zrobienia. Wiem, że niektórzy z was będą się śmiać ze śledzenia rzeczy na papierze, ale jest to dość efektywny sposób wymyślenia co dalej robić. Trudniejsze od szukania nierozwijanych już programów jest rozważanie skutków aktualizacji każdej paczki i jaki wpływ będą one miały na system. Część z tego to zgadywanie, a część oparta jest o wcześniejsze doświadczenia. Kiedy robisz to już od pewnego czasu, zaczynasz zauważać które paczki można bezpiecznie zaktualizować, a wobec których powinieneś być ostrożny (pomimo obietnic kompatybilności ABI/API). Dodatkowo, wszyscy mamy ulubione projekty, których rozwój i ogłoszenia śledzimy. Prośby użytkowników również są niesamowicie ważne w określaniu co ma zostać zaktualizowane. Szczególnie gdy aktualizacja jest wymagana jako zależność do czegoś, czego nie dostarczamy. Mamy kilka narzędzi napisanych przez Stuarta Wintera, które używamy do odnajdowania paczek linkujących do danej biblioteki lub binarek, które muszą być przekompilowane, gdyż biblioteki, na które wskazywały, gdzieś się zagubiły. Te narzędzia przydają się, gdy współdzielone biblioteki podbijają swoje numery wersji. Raczej nie miałbym nic przeciwko posiadaniu skryptu, który wyszukiwałby nowsze wersje wszystkich pakietów Slackware'a i generował raport o tym, co jest dostępne, jednak i tak radzimy sobie ze znalezieniem wszystkiego co potrzeba. Aktualizacje, które nie dotyczą bibliotek lub zależności, mogą być dokonane w dowolnym momencie. Paczki, które są zależnościami innych programów, muszą być traktowane z ostrożnością i jeśli będzie trzeba przebudować wiele rzeczy, wtedy może poczekam aż będą dostępne aktualizacje dla większych paczek (np. KDE). Jeśli podbicie wersji pewnej zależności wywoła potrzebę przebudowania innych pakietów, to zrobię je wszystkie za jednym razem. Nawet w wersji -current nie lubię mieć niedziałających przez dłuższy czas rzeczy i zostawianie niespełnionych zależności jest nie do przyjęcia. Utrzymanie starszych wersji Slackware’a jest robione głównie z powodów bezpieczeństwa. Tam wolę aktualizację paczek niż ich łatanie jeżeli kompatybilność jest zapewniona (czasami to naprawi też inne problemy), ale jeśli aktualizacja może oznaczać złamanie kompatybilności, wtedy raczej załatamy problem aniżeli dopuścimy do potencjalnych problemów w systemach produkcyjnych.

LQ) Jak wpływa na ciebie reputacja Slackware'a? Czy fakt, że twoja dystrybucja jest uważana za trudną w instalacji/użytkowaniu i jest przeznaczona dla ekspertów napawa cię dumą, czy raczej odbierasz to jako coś negatywnego, co odpycha nowych użytkowników od Slacka? (trademark91)

volkerdi) Mam nadzieję, że to nie cała reputacja Slackware'a! A jeżeli już o tym mowa, to nie do końca się zgadzam. Pierwotnym założeniem projektu była prostota i łatwość w obsłudze, ale, parafrazując Einsteina, wszystko powinno być tak proste, jak to tylko możliwe, ale nie prostsze. Piętrząc na sobie kolejne warstwy dochodzimy do punktu malejących zysków, gdzie każda kolejna warstwa zmniejsza efektywność. Dotyczy to głownie konfiguracji systemu. Widziałem jak zautomatyzowana konfiguracja robi rzeczy takie jak usuwanie wszelkich komentarzy z pliku konfiguracyjnego lub, jeszcze gorzej, rekonstruuje go ponieważ użytkownik ośmielił się zmienić coś ręcznie bez użycia zalecanych narzędzi. Uważam, że Slackware został niesprawiedliwie potraktowany w niektórych recenzjach w dużej mierze z powodu tego, że istnieje tendencja, aby skupiać się na procesie instalacyjnym, a nie na systemie jako całości. Oczywiście trzeba poświęcić trochę czasu na naukę, ale przecież odnosi się to również do innych dystrybucji. Nigdy nie staraliśmy się utrudniać życia użytkownikom. Z drugiej strony, być może też nie próbowaliśmy uchronić ich przed strzeleniem sobie w stopę. Przypisywanie aliasów ‘rm’ do ‘rm -i’ z pewnością nie uczy użytkownika ostrożności.

LQ) Zagorzałość fanów Slackware'a jest wręcz legendarna. Czy chciałbyś im coś przekazać?

volkerdi) Slackware może nie mieć wielu użytkowników, jednak są oni bardzo oddani i lojalni. Istnieje naprawdę wiele wspaniałych gości w społeczności Slackware'a. Dzięki za trzymanie mnie w ryzach!

LQ) Domyślnie Slackware instaluje całą gamę edytorów tekstu. Którego z nich właściwie używasz? (dugan)

volkerdi) Przez większość czasu używam edytora elvis (trochę z przyzwyczajenia, ale także ponieważ działa bardzo dobrze), jednak jestem również zwolennikiem vima. Jego funkcja podświetlania składni zaoszczędziła mi już wiele czasu podczas debugowania skryptów powłoki.

Muszę jednak przyznać, że zeszłego roku na Southeast Linux Fest cholernie mi zaimponowała prezentacja Andre Psaltisa na temat Emacsa. Po tym rozpowiadałem tam niektórym, że spróbuję przerzucić się na Emacsa. Naprawdę próbowałem przez jakiś czas, ale nie wystarczająco długo, by swobodnie poruszać się w tym środowisku (pozostałem jednak pod wrażeniem). Szybko powróciłem do strefy komfortu vi.

LQ) Jak ogólnie stoją sprawy? Czy jest coś, co fani Slackware'a mogliby zrobić by pomóc? (H_TeXMeX_H)

volkerdi) Wyślijcie prawników, broń i pieniądze! Bywało lepiej, ale też gorzej. Cieszę się, że wróciliśmy do Minnesoty przed załamaniem gospodarczym… na zachodnim wybrzeżu finansowo byłoby dla nas ciężej. Jestem niezmiernie wdzięczny za dotacje, które pozwalają nam funkcjonować. Gdybym miał pojęcie jak inaczej fani Slackware'a mogliby pomóc, z pewnością dałbym wam znać. Prawdę mówiąc, w erze wszechobecnego dostępu do szybkiego Internetu, model biznesu oparty na sprzedaży fizycznych nośników ma niewiele sensu – wystarczy wysłuchać skarg wytwórni nagraniowych. Wyłania się pytanie, jak generować stałe źródło finansowania projektu. Może okresowe zbiórki dotacji, coś na wzór radia publicznego?

LQ) W 1994 w jednym z wywiadów przyznałeś, że warzysz swoje piwo. Czy nadal starcza ci na to czasu? A skoro mowa o piwie, jakie jest twoje ulubione i czy jest to twój ulubiony alkohol? (ruario)

volkerdi) Tak, rzeczywiście zajmowałem się warzeniem piwa, ale było to wieki temu. Odkąd przeprowadziliśmy się do Kalifornii, nigdy już nie powróciłem do tego zajęcia. Nadal jednak posiadam cały zestaw i ostatnio kusi mnie by znów spróbować. Kupiłem nawet trochę niemieckiego jasnego słodu i chmiel Spalt, tak więc niebawem pewnie uwarzę trochę Altbier. Zimne miesiące już za nami, ale kotłownia nawet w lecie pozostaje chłodna, gdy włączona jest klimatyzacja (znakomite miejsce na serwery).

Jeśli już piję alkohol, to tak, zwykle jest to piwo (poza tym, to kawa i napoje gazowane, ale próbuje ograniczać ich spożycie). Guiness jest moim ulubionym piwem, a jeśli chodzi o tanie piwa, to Pabst Blue Ribbon.

LQ) Słuchałem wywiadu z tobą w Hacker Public Radio. Poza The Grateful Dead i kadzidełkami, jakie inne gatunki muzyczne lubisz? Jakie masz inne zainteresowania poza Slackware’em? (kingbeowulf)

volkerdi) Lubię również jazz, klasykę mistrzów takich jak Miles Davis czy John Coltrane. Poza tym, J. S. Bach, szczególnie jego partity na klawesyn. Zainteresowałem się nimi dzięki książce "Gödel, Escher, Bach: an Eternal Golden Braid" Hofstadera oraz Ofierze Muzycznej Bacha. Są one fascynujące zarówno pod względem muzycznym jak i matematycznym. Earl Scruggs i John Hartford należą do moich ulubionych gitarzystów banjo. W latach 90-tych widziałem koncert Jormy Kaukonena (który kiedyś był gitarzystą w Jefferson Airplane) niedaleko miejsca, gdzie teraz mieszkam w Minnesocie. John Hartford był również w programie, ale wtedy nie byłem jeszcze tak obeznany z jego muzyką, w której dominowało stare banjo z dużą liczbą utworów o parowcach i rzece Mississippi. Przez lata zebrałem wiele jego płyt i przypuszczalnie dzięki temu jednemu koncertowi sprawiłem sobie 5-strunowe banjo. Jeśli chodzi o inne gatunki muzyczne, to blues, dixieland, big band, trance/glitch (np. Oval), mashupy "dźwięków z odzysku" jak Negativland oraz starą muzykę country. Istnieje bardzo dobra stacja radiowa z muzyką country w Fallow w Nevadzie, której zawsze słuchałem, kiedy podróżowałem w pobliżu, a jedyną rzeczą, jaką miałem w samochodzie, było zwykłe radio. Teraz posiadam satelitarne radio w samochodzie… ostatnio nastawione jest na stację z muzyką z lat czterdziestych.

Lubię stare samochody i posiadam Firebirda z 1967 roku, którym jeżdżę już ponad połowę mojego życia. Zeszłego lata moja żona kupiła Chevroleta z 1950 roku z 6-cylindrowym silnikiem Stovebolt 230 i przebiegiem tylko 53 tysięcy mil. Ten jednak będzie wymagał trochę pracy… Muszę włączyć ssanie by zastartował i gaśnie, jak tylko się rozgrzeje. Mam zestaw naprawczy dla gaźnika typu B firmy Rochester, który powinien pomóc (paliwo wycieka przez uszczelkę). Może przyjrzę się jeszcze spadkom podciśnienia, a może klapa cieplna, która się zacięła, przypieka ten gaźnik. Ależ to świetna rozrywka dla technofila!

Uwielbiam także fotografię. Kiedyś robiłem czarno-białe zdjęcia (Kodakiem Tri-X) i sam je wywoływałem. Teraz wszystkie moje aparaty są cyfrowe i choć nie posiadam lustrzanki, lubię osiągać dobre rezultaty używając relatywnie taniego sprzętu. Używam automatu Canon S90, który, dzieki zainstalowanemu rozszerzonemu oprogramowaniu CHDK, udostępnia wiele zaawansowanych funkcji, które normalnie istnieją wyłącznie w lustrzankach. S90 pozwala na zapis obrazu w formacie RAW, lecz nawet tańsze modele mogą to robić przy zainstalowanym CHDK. Zrobiłem mnóstwo zdjęć przy użyciu techniki bracketingu, która polega na robieniu serii zdjęć przy różnej ekspozycji, które poźniej mogą być nałożone na siebie by uzyskać zdjęcie HDR, czyli obraz o rozszerzonym zakresie jasności. Zajmowałem się także fotografią latawcową wykorzystując funkcję czasową CHDK, gdzie aparat umieszczony na latawcu wykonywał zdjęcia co 15 sekund. Jak dotąd mój aparat nadal jest w jednym kawałku i w ten sposób uzyskałem wiele naprawdę wspaniałych zdjęć.

LQ) Przez te wszystkie lata musiałeś udzielić wielu wywiadów. Czy jest jakieś pytanie, na które zawsze chciałeś odpowiedzieć, a które nigdy dotąd nie padło? (jeremy)

volkerdi) Czy chcesz wpaść do mnie na bzyku bzyku?

Nie no, żartuję oczywiście, ale nie mogłem się powstrzymać przed zamieszczeniem tutaj jakiegoś nawiązania do Monty Pythona :-) [link -- przyp. tłum.] A odpowiadając na twoje pytanie, nic mi nie przychodzi do głowy.

Dziękuje wam. Bawiłem się świetnie. Powtórzmy to kiedyś na Reddicie.

Trzymajcie się,

Pat

###

Źródło: http://www.linuxquestions.org/questions ... re-949029/
Tłumaczenie: elesmod (a.k.a. knives), ydoom, sycamorex
Korekta: mina86 (który wniósł olbrzymią ilość poprawek i podniósł jakość tekstu), OkObaka, alekow, dienet
ODPOWIEDZ