Hacker, White Hat

Ez az interjú része egy cikksorozatnak, amelynek célja, hogy bemutassa azokat a fejlesztőket, akik azért dolgoznak, hogy mi felhasználók jobban kihasználhassuk számítógépünk képességeit, teljesítményét. Azokról a fejlesztőkről szól akik megszállottjai, hívei az ``open source spirit"-nek. Az interjúsorozat mai alanya Kadlecsik József, az iptables egyik fő fejlesztője.

trey: Mondanál néhány szót magadról (iskolák, család), a szabad szoftverekkel kapcsolatos munkásságodról?

K.J.: Kadlecsik József vagyok, az ELTE-n végeztem, mint fizikus. A feleségemmel a budaörsi úti koliban ismerkedtünk meg, ő orosz-töri szakon végzett, de azóta elvégezte a német szakot, és most szótárakkal foglalkozik. Van két fiunk, az egyik hat éves lesz, a másik fél éves. A szabad szoftverekről később még lesz szó... :-)

trey: A KFKI-nál dolgozol. Mivel foglalkozik ez az intézet, és Neked mi a feladatod ott?

K.J.: Olyan, hogy KFKI (Központi Fizikai Kutatóintézet) már jó néhány éve nem létezik. Van egy KFKI telephely, amely otthont ad öt független kutatóintézetnek. Ezek közül az egyik a KFKI Részecske és Magfizikai Kutatóintézet (KFKI RMKI), amelyhez az összes telephely fő számítógépes és hálózati infrastruktúrájáért felelős Számítógép Hálózati Központ (SZHK) is tartozik. Utóbbinak vagyok a főosztályvezető helyettese.

Az RMKI nevéből fakadóan elsősorban részecskefizikával foglalkozik, de vannak anyagtudománnyal, plazmafizikával, biofizikával, űrkutatással, elméleti fizikával és más fizikai ágakkal foglalkozó osztályok, csoportok is. (A KFKI telephelyén lévő kísérleti reaktor kezelése és az azon folyó munkák egy másik intézethez, az ATKI-hoz tartoznak) Az intézetnek igen erős a CERN-nel való kapcsolata, sok csoport és sok kolléga vesz részt CERN-beli kísérletekben. Kis adalék, hogy a hazai Internet egyik első nemzetközi kapcsolata az (akkor még létező) KFKI-t a CERN-nel összekötő 6400 baudos bérelt vonal volt. (A csatlakozópont még mindig megtalálható a 3-as épületben - emléktábla kellene mellé :-)Az SZHK felel a telephelyi belső gerinchálózatért és a külső kapcsolatokért. Mi felelünk néhány - SPARC/Solaris és Intel/Linux alapú - szervergépért, amelyek a központi DNS, mail, interaktív bejelentkezés, stb. szolgáltatásokat nyújtják. A hálózatbiztonság első vonalat is mi alkotjuk, amelyet az RMKI és a telephely hálózatbiztonsági felelőseként én vezetek.

trey: Mikor kezdtél el a Linuxszal foglakozni?

K.J:: 1994 elején én installáltam az első Linuxot az intézetben a saját asztali gépemen. Ahogy az elején említettem, eredetileg fizikus vagyok, és általános relativitáselmélettel foglalkoztam. Reduce számítógépes algebrai nyelv alá írtam Rlispben egy szimbolikus tenzort-algebrai csomagot. Ezen dolgozván '92-93-ban egy évet Bonn mellett a GMD-ben (Gesellschäft für Mathematik und Datenverarbeitung) töltöttem. Ott találkoztam először Unixszal (SPARC/Solaris). Mielőtt hazautaztam volna, elég sokat keresgéltem a hálózaton, főként Usenet csoportokat olvasgatva, hogyan lehetne PC-n UNIX-ot installálni és futtatni. Akkor még csak egyetlen comp.linux csoport volt, elég könnyen rá lehetett találni. Mehettem volna BSD felé is, de a Linux sokkal élőbbnek tűnt, a hírcsoport sokkal pezsgőbb volt. Akkoriban kezdte az SLS mint vezető disztribúció elveszíteni a szerepét és helyette a Slackware kezdett följönni. Harminc-egynehány floppyn :-) hoztam haza '93 karácsonya előtt.

Közben '93 nyarán installáltak egy SPARCCenter 2000 számítógépet Solaris 2.3-mal (szerencsére a 2.2-esből kimaradtunk) az SZHK-ban, és visszajőve egy új nagy szervergép állt "előttem". A kollegák VAX/VMS-en nőttek föl, így számukra a UNIX talán ismeretlenebb volt, mint számomra. Valahogy adódott, hogy én telepítettem és installáltam a fordítókat, interpretereket, szerver és kliens programokat. És lassan fizikusból teljesen átvedlettem rendszergazdává és számítástechnikussá :-).

trey: Fejlesztői és felhasználói szemmel nézve mik a főbb eltérések az akkori (amikor kezdted), és a mostani Linux kernel között?

K.J.: Felhasználói szemmel a felszínen igaziból nincs olyan nagy különbség. Már akkor voltak hatékony shellek, már akkor régen létezett az XFree86. Ugyan úgy használhattam grafikus felületet, mint most. De a web még nem létezett (azt akkor már kitalálta Tim Berners-Lee a CERN-ben, de a gopher jóval ismertebb volt). Fejlesztői szempontból akkor még nem voltak kernel modulok. És mendemonda tárgya volt, hogy vajon mennyire komolyan gondolja Linus, hogy a Linux kernel verziószáma soha nem fogja elérni az 1-et, hanem mindig végtelenül közelíteni fogja alulról :-). Igazából a kérdést nem tudom jól megítélni - akkoriban sima mezei felhasználó voltam, nem dolgoztam a kernellel.

trey: A honlapodat nézegetve láttam, hogy több fejlesztői projected is van. Beszélnél ezekről?

K.J.: Négy "projektem" van, azok közül valójában kettő élő.

Egy időben nagyon foglalkoztatott az SRP (Secure Remote Password) protokoll, amely sajnos nem tudott elterjedni. Amerikában írott szoftverként a kriptológiai részét hivatalosan nem lehetett letölteni, ezért a skeleton kripto libraryjét összehoztam az SSL kripto libraryjével. Szerintem soha senki nem használta, de jó gyakorlat volt.

Az smstart a maga korában érdekes lehetett. Akkoriban még a sendmail volt az egyeduralkodó MTA, és nagyon utaltam, hogy rootként kell futtatni, ismervén a sendmail biztonsági lyukakban gazdag múltját. Azt akartam, hogy a sendmail futhasson közönséges userként, és ehhez az inn (news szerver) példáját vettem: ott is van egy nagyméretű, monolitikus program, amelyet csak azért kellene rootként indítani, hogy egy 1024 alatti portot megnyithasson. E helyett van egy picike innstart program, amelyik megnyitja a megfelelő portot, átvált a news userré és elindítja az inndt. A megnyitott file-descriptort argumentumban passzolja át. Az smstart és a patchelt sendmail ugyan ezt tudta: annyiban volt érdekesebb a dolog, hogy a sendmail néha újra akarja nyitni a portot és nem csak ezért van szükség a root jogra. Amíg nem létezett postfix, addig karbantartottam és frissítettem. A postfix megjelenésével "hivatalosan" lezártnak és okafogyottnak tekintem az smstartot.

A két élő projekt, amelyeken jelenleg dolgozom a per user uce patch a postfixhez és a netfilter/iptables.

trey: 2001. december elején megírtam a portal.fsn.hu-n, hogy a netfilter core team tagja lettél. Hogyan kezdtél el foglalkozni a netfilterrel? Mi a területed, feladatod a csapatban?

K.J.: Elég régóta keresgéltem egy jó tűzfal csomagot Linuxra. Az ipchains nem volt az, az spf ígéretes volt, de soha nem vált elterjedtté, sikeressé. Amikor a netfilter megjelent, elérhetővé vált és bele tudtam nézni, nagyon felkeltette az érdeklődésemet. Elkezdtem patcheket, javításokat írni, megpróbálni elérni, hogy azok bekerüljenek a rendszerbe, és lassan egyre jobban belefolytam a munkába.

A csapatban nincsen felosztás, hogy ki mivel foglalkozik - az érdeklődési kör határozza ezt meg. Egészséges anarchia van :-). Aki épp a legaktívabb egy területén, az foglalkozik azzal és viszi előre. Engem mindig is a connection tracking és a netfilter stateful része érdekelt, jelenleg is azon dolgozom.

trey: Hogyan kerül be egy magyar fejlesztő egy ilyen csapatba?

K.J.: Megpróbáltam előrébb vinni egy projektet és meglehetősen sokat dolgoztam rajta. Az Enshcedeben a Linux Kongress előtt tartott netfilter workshopon személyesen is megismerhettük egymást a core team tagjaival és a legaktívabb patch-írókkal - utána hívtak meg a core team-be.

trey: Rendszeresen készítesz Postfix patcheket is. Ennek mi az oka? Felhasználói elégedetlenség, vagy csak bugfixek készítése?

K.J.: Fogós kérdés! IMHO jelenleg a postfix a patch nélkül is a legjobb MTA. Nekem a KFKI telephely sajátosságai miatt extra funckionalitásra volt szükségem, és mivel Wietsenek épp elég dolga van az egész rendszerrel, ezért megírtam magam a szükséges részeket. Ebből lett a per user uce patch. Mások is elkezdtek használni, kértek új funkciókat, így egyre nőtt. Mára nagyjából elérte a felső határát: tovább bővíteni már nem érdemes. Én azt várom, hogy postfix smtpd szétválik egy smtpd/policyd párosra, és a most az smtpd-be zsúfolt funkcionalitás bekerül majd a policyd-be. Mi a patchet egy maximálisan konfigurálható spam szűrőként használjuk: bármely felhasználónk választhat, hogy mely feltételek alapján akarja a spameket kiszűrni (az SMTP HELO/EHLO nevének szintaxisa, DNS-beli regisztráltsága, az SMTP kliens DNS-beli regisztráltsága, saját telephelyi tiltólisták, RBL-szerű tiltólisták, stb., stb., stb.). Ezen felül, ha valaki akarja, a tiltófeltételei ellenére beengedhet (kivételeket tehet) E-mail címekre vagy akar egész domainekre. A felhasználók egy web-felületen állíthatják a feltételeiket/kivételeiket és napi összesítőt kapnak a kiszűrt levelekről, hogy könnyedén reagálhassanak, ha egy fontos partnerüket véletlenül kitiltottak.

trey: Beszéljünk kicsit az iptablesről. Azt mondják, hogy az iptables kódja kicsit monolitikusra sikerült. Jelen pillanatban az egész egy nagy memóriablokkban helyezkedik el, pl. az összes egyezések, targetek a láncok rulesetjei egy táblában vannak. Mi a véleményed erről? Kell ezen változtani? Vannak erre törekvések?

K.J.: A fogalmazást hogy monolitikus, szerencsétlennek tartom. Szerintem mind a netfilter, mind az iptables nagyon jól modularizált. Húsz fölött van a mainstream kernelben lévő matching/target/helper modulok száma, a patch-o-maticben pedig 70 (!) fölött van az új funkcionalitást, modult tartalmazó patchek száma. Tulajdonképpen meglepő, hogy ezek közül milyen kevés ütközik, ami a jó modularitást igazolja.

Amire Te gondolsz és a harmadik mondatodban írod is az az, hogy a kernelben az összes szabály és tábla egyetlen memóriablokkban van és a netfilter egyszerű pointer műveletekkel "közlekedik" a láncok és szabályok között. Ez egy kompakt memóriablokkot eredményez, de hátrány, hogy nem lehet láncot/szabályt egyszerűen hozzáadni: az iptables lekéri a kerneltől az élő szabályokat, elkészíti az *egész* új táblát mint memóriablokkot, átadja a kernelnek és az a régit helyettesíti az újjal. Mindez néhány száz szabály fölött egyre lassabbá teszi az új szabályok hozzáadását (törlését/módosítását). Erre egy workaround az iptables-save, iptables-restore, amelyekkel el lehet menteni és egy lépésben visszatölteni egy működő, teljes konfigurációt. Nyilván workaround, ezért a 2.5-ben várhatóan áttérünk láncolt listák használatára.

trey: Az iptablest használóknak sokszor meggyűlik a bajuk az IRC, RealAudio és egyéb galád dolgok használatával =). Úgy hallom dolgoztok egy newnat API dolgon amely segít enyhíteni ezt a problémát. Beszélnél erről?

K.J.: A netfilter/iptables több szempontból is óriási előrelépés az ipchainshez képest: ezek közül az egyik, hogy képes stateful csomagszűrésre. Azaz elegendő egy kapcsolatot *kezdeményező* csomagot engedélyeznem, a kapcsolathoz tartozó összes többi, bármely irányból jövő csomagot egyetlen további szabállyal engedélyezni tudom:

... -m state --state ESTABLISHED -j ACCEPT

Bonyolultabb protokollok azonban segéd-kapcsolatokat is használnak, amelyeknél a "szerverport" egy random port valahol 1024 fölött. Ilyen például az FTP-nél az adat-csatorna (dir/ls/get/put), vagy IRC-nél a DCC kapcsolatok, stb. A netfilternél ezekhez a protokollokhoz léteznek helper modulok, amelyek értelmezik a protokollt és a szükséges segéd-kapcsolatok fogadására felkészítik a rendszert. Ezek után többé nincs szükség az összes 1024 fölötti port nyitvahagyására, az összes ilyen kapcsolatot egyetlen szabállyal engedélyezni lehet:

... -m state --state RELATED -j ACCEPT

Azonban az eredeti netfilternél bármely protokoll esetén csak egyetlen segédkapcsolatra lehetett felkészülni, pedig léteznek olyanok protokollok is, amelyeknél több kapcsolatra kell egyidejűleg várni. Például több IRC DCC parancsot lehet kiadni anélkül, hogy várnánk az első felépülésére. Vagy a netmeeting (H.323) szinten több parallel audio és video csatornát használ. Ezeket az eredeti netfilterrel nem lehet kezelni. Félreértés ne essék: például egymás *után* természetesen több DCC parancsot le tudott kezelni, ha az adatcsatornák felépülését megvártuk:

DCC SEND ...

DCC SEND ...

Amit nem volt képes kiszolgálni, az a következő:

DCC SEND ...

DCC SEND ...

A newnat API lényege, hogy lehetővé tesszük, hogy egy protokollnál több segédcsatornára tudjon fölkészülni a rendszer.

A newnat API-t is figyelembe véve jelenleg a következő protokollokat tudjuk kezelni: FTP, IRC, talk (talk/ntalk/ntalk2), tftp, PPTP, H.323 (point-point kapcsolat esetén).

trey: Jelenleg az iptables a kernelspace-ben működik, nyilván hogy gyors legyen. Hallottam olyan törekvésekről, hogy userspace iptables. Ez mi is tulajdonképpen?

K.J.: A netfilterben elejétől fogva benne volt az a lehetőség, hogy bármely csomagot átadjon egy UP-ben futó processznek és onnan (később) visszakapva azt továbbítsa (vagy eldobja). Ez lehetőséget ad arra, hogy a kernelbeli részt tetszőleges UP-beli processzel egészítsük ki. (A forrásban több helyütt lehet olvasni, hogy az a rész lehetne a user space-ben is :-) Jelenleg az ULOG targeten kivül ez a lehetőség nincs még kihasználva.

trey: Készülőben van az iptables2. Miben lesz ez különböző, mint az elődje? Megtudhatunk erről valamit?

K.J.: Az iptables/netfilter egy remekül bővíthető rendszer. Minden új netfilter kiterjesztéshez a szerzőnek meg kell írnia a hozzá tartozó másik felet, egy iptables kiterjesztést. A jelenlegi interface-ben ezek az UP-beli kiterjesztések igen szorosan kötődnek a parancssor értelmezéséhez. Ez nehézségeket és problémákat okoz, amint valaki nem az iptables frontend segítségével akar szabályokat generálni. Ezért egy új interface készül, amelyik elrejti majd a kiterjesztéseket az alkalmazás elől és a kernel-kommunikációt több interface fogja majd támogatni (libiptc,

libnfnetlink).

trey: Az iptables a Linux csomagszűrője. Mennyire követed figyelemmel más rendszerek törekvéseit ezen a területen? Gondolok itt a multiplatformos IPF-re és az OpenBSD-s PF-re. Vesztek át egymástól ötleteket? Van valamiféle kontaktus más rendszerek fejlesztőivel?

K.J.: A TCP window trackinget az IPF-ből vettük át :-). De komolyabban véve a kérdést: valamilyen szinten követjük egymás munkáját, de egyáltalán nincs feature-war. Az erre való akar burkolt biztatást nem nagyon szeretjük ("ez és ez benne van az x szoftverben, az iptables miért nem tudja?")

trey: Ha jól tudom Rusty Russel a iptables fejlesztésének az irányítója. Ha nem létezne az iptables, és Te most kezdenél neki megalkotni, mit csinálnál máshogy?

K.J.: Én eleve láncolt listákban tárolnám a szabályokat.

trey: Ahogy a Linux kernel fejlődik, úgy változik a csomagszűrő is. Sokakban felmerül a kérdés, hogy miért hoz minden nagyobb Linux kernel release újabb kódot? Arra gondolok, hogy 2.0-as kernelben a FreeBSD-s IPFW portja volt, majd a 2.2-esben az ipchains, a 2.4-esben pedig az iptables. Mi a véleményed erről a dologról?

K-J.: Az IPFW port Alan Coxtól már az 1.1-ben benne volt. Azt javította föl Jos Vos a 2.0-ban (ipfwadm), majd - még mindig erre alapozva - írta át Rusty a 2.2-ben (ipchains). A 2.4 teljes szakítás az eredeti kóddal, abból semmilyen rész nem maradt benn a kernelben.

Ez lényegében egy természetes fejlődés volt, minőségi ugrásokkal. Nem hiszem, hogy a lépcsők kihagyhatok lettek volna.

trey: Használsz más rendszert is a Linuxon kívül?

K.J.: Igen, SPARC/Solarist. Időnként a kollégáim gépein látok Windowst is.

:-)

trey: Fejlesztéseid során milyen eszközökkel dolgozol? Gondolok itt a hardverre és szoftverekre.

K.J.: Az asztali gépem egy Athlon, az általában a külső tesztelő gép szerepet játssza, ha UML valamilyen okból nem használható. Van egy Pentium III-as laptopom, azon fejlesztek. Különösebb szoftvereket nem használok: editorok (joe, vi, mikor hogy), make, gcc, gdb, UML, célprogramok tetszőleges csomagok generálására. Csupa fapados eszköz :-).

trey: Amikor nem dolgozol, nem kódolsz, mivel töltöd az idődet?

K.J.: A gyerekeimmel, a családommal. A nagyobbik imád kirándulni: lassan a polcai már alig bírják az értékes kavicsok és kövek súlyát. A kagylóhéj-gyűjteménye is kiemelkedő, nem beszélve a törött cserepekről. :-) Az egyik "ritkaság" egy a kertben kiásott rozsdás, régi, nagyméretű kulcs - a hozzá tartozó kincsesládát még nem találtuk meg, de minden tavasszal lelkes kutatómunka folyik :-)).

trey: Több fejlesztővel is beszélve meglepődve láttam, hogy egyik sem az "otthon sötétben kódoló, soha ki nem mozduló típus". A honlapodon láttam, hogy Te is természetszerető ember vagy, szívesen jársz erdőkben, vagy ha teheted kajakozol. Mi volt a legnagyobb kalandod eddig?

K.J.: Egy Rabá-túrán kajakkal majdnem lecsorogtunk a feleségemmel egy kövekből épített duzzasztón. Ha jobban elbambulunk, akkor tényleg veszélyes lehetett volna.

Még mielőtt a Szigetközt feldúlták, részt vettünk egy Szigetköz-kerülésen: Győrből föl a Mosoni-Dunán, aztán az Öreg-Dunán vissza, de ahol csak lehet, bemenni az ágakba. Az egyiknél felfedeztünk egy víz alatti forrást, amitől a víz hőmérséklete az ágban a vele kapcsolatban lévő Dunáéhoz képest legalább 5-8 fokkal hidegebb volt. Azóta sem találkoztunk ilyennel.

trey: Úgy tudom, hogy jelenleg Svájcban vagy a CERN-nél. Mit csinálsz ott, most is dolgozol?

K.J.: A HEP (High Energy Physics) közösségbe tartozó intézeteknek mint a CERN, DESY, Fermilab, SLAC, Rutherford Lab, stb., több közös szervezete és bizottsága van. Az egyik ezek közül a HEPCCC (HEP Computing Coordinating Committee), amelynek van egy HTASC (HEPCCC Technical Advisory SubCommittee) nevű technikai tanácsadó albizottsága. Ennek a munkájában veszek reszt Magyar CERN Bizottság képviseletében. Évente két-három alkalommal találkozunk, általában a CERN-ben. A munka a legfőbb számítástechnikai kérdések számbavételéből és felméréséből áll. A mostani ülés legfontosabb pontjai a biztonsági kérdések (tűzfalak, biztonsági policyk és az autentikációk, roaming userek, VPN-ek egymással való kapcsolata) és az AFS jelene/jövője volt (a HEP közösség szinte kizárólagosan AFS-re támaszkodik, alapvető fontosságú szolgáltatás).

trey: Mi az amit egy kezdő hackernek javasolni tudnál? Hol kezdjen hozzá a dolognak?

K.J.: Válasszon ki egy létező, számára érdekes, izgalmas területet és ássa bele magát. Kövesse nyomon a fejlődését, majd próbálja jobbítani a már létező eszközöket. Aztán ha az nem az ő ízlésének megfelelő irányba megy, akkor kezdjen neki egy újnak, jobbnak :-).

trey: Esetleg szeretnél még valamit elmondani ami nem szerepelt a kérdések között?

K.J.: Ha egy tipográfus véletlenül olvasna ezt a cikket, és tenni szeretne valamit a free szoftverek és a Linux hazai jobb elterjedéséért, akkor előtte nagy lehetőségek állnak: készítsen minőségi ISO Latin 2 fontkészleteket és tegye közkinccsé azokat a lehető legtöbb formátumban úgy, hogy ugyanazokat a fontokat lehessen használni konzolon, PostScriptben, (La)TeXben, X-ben, StarOffice és leszármazottaiban egyaránt. Hú de jó is lenne...



Üdv,

Józsi

--

E-mail : kadlec@sunserv.kfki.hu, kadlec@blackhole.kfki.hu

PGP key: finger kadlec@sunserv.kfki.hu | WWW: http://www.kfki.hu/~kadlec



Address: KFKI Research Institute for Particle and Nuclear Physics

H-1525 Budapest 114, POB. 49, Hungary

Egy hosszabb interjút készített az ITWales Alan Cox-szal. Az interjúban Cox beszél a Red Hat-ról, a Linux kernelről (természetesen), a Microsoft-ról, Linux Standard Base-ről, stb.

Az interjút megtalálod itt.

Alan Cox-ról egy képet találsz itt.

A Kerneltrap egy interjút készített a Linux guru Alan Cox-szal. Alan Cox talán a második legismertebb Linux kernel hacker Linus Torvalds után. Az interjúban beszél magáról, kapcsolatáról a számítógépekkel, a Red Hat-ról mint munkaadóról, Marcelo Tosatti-ról, a 2.4-es kernelről, a DMCA-ról, a Linux jövőjéről és még sok más dologról.



Alan Cox, mint ahogy más is megszületett, iskola, bárányhimlő, kanyaró, mumpsz következett. A számítógépekkel akkor kötött közelebbi ismeretséget, amikor volt egy-két olyan tanára, aki képes volt ebédidejét feláldozni néhány érdeklődő diák kedvéért. Ekkortájt az iskolának volt 3 számítógépe, amelyen 15-20 perces órákat lehetett venni. Körülbelül ekkor lehetett, hogy Cox egy ZX81-es gazdájává vált (akkoriban ez volt az első tömegcikknek számító computer a UK-ben), és lassan már ő tanította a tanárokat.



Az iskola végén a 3 órás vizsgát 30 perc alatt oldotta meg, és szembesült saját "tudásának fényességével" (ezt nem én találtam ki, saját maga állította magáról).Mielőtt az egyetemre ment volna, egy rövid ideig dolgozott a számítógépes játékfejlesztés iparágában is. Egy ideig játékokat portolt, majd nekilátott egy saját játék fejlesztésének is. Ahogy mondja, a játékfejlesztői ipar megtanította arra, hogy a milyen a való világ. A számítógépes játék üzletet akkoriban egy olyan ember irányította, aki csődöt mondott a zeneiparban, és bármelyik pillanatban az öreganyját is eladta volna. Ebben a világban voltak olyan emberek, akik sokkal jobban voltak Cox-nál, és voltak olyanok, akik meg voltak győződve saját ragyogó képességükről, de mentálisan instabilak voltak.



Természetesen, mint a zeneiparban, itt senki sem keresett jól, de érdekes módon a játékfejlesztő cégek tulajdonosai egyre nagyobb autókkal jártak, és egyre drágább házakban laktak. Ki érti ezt?



Az egyetemen változó volt az előmenetele, de visszatekintve az egyetemi éveire, akkor boldog volt. Az akkor tanult vezetési szakértelem, szoftver mérnök-tudomány, matematika, adatbázis tudás mind-mind segítségére vannak most is, amikor a Linux-szal foglalkozik.



Az iskola után több dologgal is foglalkozott: dolgozott egy nagyobb C++ hálózati projecten, írt ISDN kódot a Sonixnak később dolgozott a 3COM-nak is. Ezután az NTL-nél volt rendszeradminisztrátor, dolgozott egy kisebb internetszolgáltatónál (Cymru.Net), amelyet az NTL vásárolt meg. Amikor innen megszabadult, akkor került a Red Hat-hoz, és kezdett el főállásban a Linux-szal foglalkozni.



Sokan kérdezhetnék tőle, hogy: "miért nem ment mindjárt a Red Hat-hoz dolgozni, biztos szívesen foglalkoztatták volna?"



Erre Cox azt mondja, nehéz döntés volt az, hogy a Red Hat-hoz ment dolgozni. Biztos akkor is tudták volna foglalkoztatni, de ha egy embernek a hobbyja főállássá változik, akkor nagy áldozattal kell számolni. Ugyanis az egészből elveszhet a "fun factor", és lehet, hogy elmegy a kedve az egésztől.



Tehát 2000. január. 1-én csatlakozott a Red Hat-hoz, ekkor jelent meg a Red Hat mint cég Európában. Coxnak megfelelt a Red Hat világképe, mert a Red Hat managementje egyszerre hisz az open source-ben, és abban hogy emellett lehet egy céget sikeresen profitot termelve vezetni. Cox szerint a Red Hat nem csinál mindent a legjobban, de törekszenek erre.



Cox annak idején fejlesztett egy játékot Blizzard Pass néven. A játék ZX81-re készült, a Tynesoft adta ki anno egy Spectrum 128K launch pack keretében. A játék jogai valahol a Adventuresoft UK-nál és/vagy a Tynesoft-nál vannak.



Cox elmondja, hogy szívesen játszik a mai napig is különböző játékokkal. Főként a MUD stílusú játékokkal múlatja az idejét, viszont megjegyzi, hogy ezek a játékok sajnos semmit nem változtak az elmúlt 10 évben.



Sokan meglepődtek amikor bejelentette, hogy nem folytatja a 2.4-es kernel karbantartását. Mi miatt hozta ezt a döntést?




A 2.4-es kernelről Cox a következőket mondja: Abban a döntésében, hogy a továbbiakban nem ő tartja karban a 2.4-es kernelfát, több dolog is szerepet játszott. Most, hogy nem kell a 2.4-es kernelsorozattal foglalkoznia, egy csomó szabad ideje maradt más dologra. Például több időt fordít régi SCSI driverek kódjának javítására, és több ideje maradt arra, hogy kielégítse a Red Hat felhasználók által támasztott igényeket is.

Másrészről Cox vallja, hogy jót tesz a kernel fejlesztésének az, hogyha nem egy szűk elit tartja kézben a munkát. Jó ötlet fiatal fejlesztőket bevenni a komoly munkába, mert a friss gondolkodás segít előre mozdítani a fejlesztést. Cox azt mondja, hogy biztos akar lenni abban, hogy jó munkát végez, és nem csak azért mennek utána az emberek mert ismert. Nem akar abba a hibába esni, hogy a háta mögött összesúgjanak az emberek, hogy milyen hülyeséget csinál.

Sok embernek furcsa nézetei vannak Brazíliáról. Nem úgy kéne tekinteni Brazíliára, mint egy harmadik világra. Brazília egyike a tíz legnagyobb gazdaságú országnak, és egészében véve a bűnözés is sokkal kisebb mint a UK-ben, vagy a USA-ben. Rengeteg jó project indul Brazíliából, olyanok mint a Window Maker vagy az APT for RPM. (itt gondolom azért beszél Brazíliáról mert Marcelo Tosatti brazil származású - trey)

Ha már a Window Makerről esett szó... Milyen felhasználói környezetet használ?

Teljesen változó. Általában xfce-t futtat, de gyakran használ Gnome+Nautilus párost is. Emellett bele-bele tekint a KDE fejlesztésébe is, például elég sok időt töltött a KDE beta tesztelésével.

Miért ajánlotta Marcelo Tosatti-t a 2.4-es kernel karbantarójának? Hogy érez vele kapcsolatban?

Cox nyomon követi Tosatti munkáját. A 2.4.17-es kernelben Tosatti egy rakás dolgot Cox patch kollekciójából emelt át. A különbségek Tosatti és Cox kernele között elenyésző, és érthető. Cox kimondhatatlanul elégedett Marcelo munkájával, azzal ahogy a kerneleket kiadja, és ahogy az emberekkel bánik. Voltak emberek, akik el akarták nyomni Tosattit akkor ,amikor a kernelfa karbantartónak kinevezték, de Tosatti le tudta kezelni ezeket az embereket, és túlélte az újságirók áradatát is.

Mi a véleménye a 2.4-es kernelsorozatról? Mennyire stabil összehasonlítva a 2.2-es sorozattal?

A kernel releasek során kiadott 2.4-es kernelek egyre stabilabbak. Viszont sok ember a mai napig is 2.2-es kernelt futtat a kritikus szervereken, mert az azt csinálja amit szeretnének, és bizonyított már az évek során. Mivel a hardvereik nem kívánják meg a frissítést, ez érthető is. Ez egy jó döntés a legtöbb project számára.

A 2.4.9-ac és a 2.4.9-RH (a Red Hat által kiadott kernel) Cox szerint nagyon jó. Meg van velük elégedve. A 2.4.17-es kernel a jelenlegi stabil kernel, amely a legújabb fixekkel és egy kis tuningal (finomhangolással) nagyon jó lehet. Cox elmondja, hogy akkor elégedett egy kernellel igazán, ha az stabilan fut a gépein, és csak nagyobb frissítés miatt kell csak a gépeit reboot-olni.

Milyen finomhangolásokra gondol?

Ez a kérdés mindig problémát szokott okozni. Mindig akkor gondolja az ember, hogy valamit hangolni kell, amikor a munkát már befejezte. Az alacsonyabb diszk áteresztőképességet (bottleneck effektus - amikor egy rendszer többre lenne képes, de a legszűkebb keresztmetszet határozza meg, és korlátozza le egy gép vagy OS teljesítményét, mindig a legszűkebb keresztmetszetet veszik figyelembe egy adott rendszer méretezésénél - trey) úgy látszik a VM réteg okozza. Cox elmondja, hogy nem elégedett a jelenlegi Linux kernel VM-el. Amikor Linus a stabil kernelbe Andrea Arcangeli VM- kódát tette, az alábbi kijelentés hangzott el:

"Úgy gondolom, hogy Alan is meglátja a fényt hamarosan."




Cox úgy látja, hogy a jelenlegi VM körülbelül 20%-al lassaban, gyengébben teljesít általánosan. Cox azt mondja, hogy nem hinné, hogy Andrea VM-je valami technikai csoda lenne. Szerinte egyszer Linus rosszul döntött, és nem akar visszavonulót fújni. Többen tesztelik Rik van Riel -rmap VM implementációját, és egyetértenek abban, hogy a 2.5-ben ezzel kellene folytatni a fejlesztést (közben a 2.5-ben megjelent az -rmap VM implementáció, és Linus részéről is elhangzott olyan kijelentés, hogy a 2.6-os kernelben akár már az -rmap kerülhet - trey).

Cox tartja karban még mindig a 2.2-es kernelfát. Mikor hagyja abba a 2.2-es kernel karbantartásást?

Cox azt mondja, hogy addig folytatja a 2.2-es kernelfa munkálatait, amíg úgy érzi, hogy az emberek használják. Abban a pillanatban, amikor úgy látja, hogy senki nem használja, be fogja fejezni a vele való munkát. Akkor már csak kisebb erőfeszítéseket tesz, hogy mindig stabil maradjon ez a kernelfa.

Kicsit előretekintve, lesz-e 2.4.6-ac sorozat?

Cox erre a kérdésre azt mondja, hogy nem gondolkodik ennyire előre.

A 2.5-ös kernel fejlesztését mennyire tartja szem előtt?

Jelenleg semennyire. Mást nem nagyon tesz, mint összegyűjt egy adag drivert és más stuffokat, amelyeket eljuttat Linusnak, aki a bio-n dolgozik (block IO réteg - trey), úgy gondolja, hogy Dave Jones jelenelg nagyon jó munkát végez a 2.5-ös sorozattal.

A kernelhackerek nagyon tisztelik Cox erőfeszítéseit és munkásságát a Linux kernel körül. Nagy tapasztalata van abban, hogy összegyűjtse a foltokat és stabil kerneleket kreáljon. Például a 2.4-es kernel "unstable" állapotának idején az -ac kernelek rettentően stabilan működtek. Mire a legbüszkébb a munkájába?

A 2.4-ac sorozat tényleg jól sikerült. Nem ezt tartja nagy dolognak, hanem azt, hogy sok gyártó/forgalmazó az ő kerneleire épít, ez a nagy dolog. Nem csak a kód minősége a fontos, hanem az is, hogy megmutatja a Linux közösség hogy milyen hatékonyan lehet együtt dolgozni. A 2.4-ac kernel úgy épült fel, hogy számos helyről érkező patcheket fogott egybe, és kovácsolt működő egésszé. A legnagyobb dolog szerinte a Linuxban az, hogy "van egy másolatom, készítek róla annyit amennyit akarok, megváltoztatom, a helyi viszonyokra adaptálom, stb.". A fejlesztés során rengeteg jó dolog születik, például a LTSP (Linux Terminal Server Project), amelynek segítségével a Linux eljuthat az iskolákba, ahol olcsó megoldásként használható.

Erre mondja Cox: "_Em_powered by Linux".

Nemrégiben megjelent a 2.4.18pre3-ac1 (és még kettő release közben - trey). Ez az első kiadás a novemberi 2.4.13-ac8 óta. Mit tartalmaz ez a release? Lesz folytatása a dolognak?

Az emberek folyamatosan küldték a bugreportokat. Ebbe az -ac kiadásba azok az anyagok kerültek, amelyet Cox jelenleg futtat, és amelyeket továbbít majd Tosattinak.

A 2.2-es kernel nagyon stabil, az -ac patchek nem fognak nagyobb véltozásokat tartalmazni. Mit fog csinálni a megmaradt idejével?

Aludni fog.

Driverek kódjának tisztításával, egy kicsit új dolgokkal, és többnyire a Red Hat felhasználók problémáival fog foglalkozni.

Csak a Linux OS-t futtatja kizárólag, vagy más operációs rendszereket is használ?

Linuxot futtat minden eszközön, kivéve a mikrohullámú sütőt és a mosógépet =).

Vannak jóslatai a Linuxal kapcsolatban a jövőre nézve?

Az elkövetkező öt évben (de tényleg csak találgat):

- Linux fokozottan megjelenik a TV boxokon


- Jobban konszolidálódik


- Több munka fog a klaszterezésre és a hibatűrésre koncentrálni


- Limitált desktop elterjedés


- Az emberek kitalálják, hogy melyik szoftvermodell a leghasználhatóbb


- Csökkenő szoftverfejlesztés az EU-ban, az USA-ban és Kelet-Európában, folyamatosan tevődik át a fejlesztés Brazíliába és hasonló országokba, a Linux cégek is hasonlóan átteszik székhelyeiket ezen országok valamelyikébe


- IBM mint lehetséges Linux disztribútor, mert egy nagy részt vásárolt a SuSE-ban


- Lehetséges, hogy Linus közvetlenül a Linux munkájáért fog fizetést kapni -> a Transmeta meg fog halni

Hogy értékeli a Linushoz fűződő kapcsolatát? Linus a barátja?

Üzleti szembontból esetleg. Ők nagyon különböző emberek. Linus nagyon elfoglalt ember. Cox kevésbé. Cox mottója: "Élj gyorsan, halj meg öregen, és közben legyél biztos abban, hogy mindenki tudja, itt jártál".

Mit csinál, amikor nem a Linuxszal foglalkozik?

Új dolgokat. Főz, és kertészkedik. Legjobban a kínai ételeket szereti. Azért felesége Telsa jobban főz. Telsával az egyetemi évek alatt ismerkedett meg, egy házban laktak Aberystwyth-ben (The University of Wales, Aberystwyth - trey).

Mit tud mondani azoknak a lelkes újoncoknak, akik a kernelfejlesztés felé kacsintgatnak?

Ne foglalkozzanak azokkal, akik azt mondják, hogy a kernelfejlesztés nehéz dolog. Valóban egy nagy program, de a bugok fixálása, a driverek írása jó kiinduló pont lehet. Ez az egész nem varázslat, nem íródott titkos nyelven.

Játszani kell a kóddal, kipróbálni dolgokat, és élvezni az egészet. Cox a hálózati kóddal kezdte annak idején. Nem működött jól, Cox nekiállt javítani rajta. Mindent amit tudott a TCP/IP-ről azt az internetről töltötte le. Az első próbálkozásai nem voltak valami jók, csak a mulatság miatt csinálta.

Az eredeti interjút elolvashatod itt.

Dave Jones London -ban él, jelenleg a SuSE foglalkoztatja mint főállású kernelhacker -t. Az elmúlt 6 hónapban - amióta befejezte a Glamorgan egyetemet - fokozottan részt vett a Linux kernel fejlesztésében. Több futó project -je is van, mint például a Powertweak, x86info, OProfiler, és a Kernel Janitors Project. Továbbá Ő a karbantartója a -dj patcheknek a 2.5 -ös kernelsorozatban, szinkronban tartja a stabil 2.4 -es kernelfával, ennek eredményeképpen jelentősen javítja annak stabilitását.



Dave 27 éves, Dél Wales -ből származik. Fiatal korától kezdve érdeklődött a számítógépek iránt, fiatalsága nagy részét olyan dolgokkal töltötte, mint az ismerkedés a 68K assembly nyelvvel. Miután befejezte az iskolát, 10 évet különböző munkakörökben töltött el, az egyszerű adatrögzítőtől a játék fejlesztőig. Közben tavaly nyáron megkapta a diplomáját a Glamorgan egyetemen, ahol számítástechnikai (vagy informatikai?) szakon tanult. A diplomaosztó után elköltözött London -ba, ahol jelenleg is él. Részben a Londonban lakó barátok, részben a munka miatt költözött a fővárosba.Mielőtt az egyetemre került volna, egy rövid ideig az Amiga játékfejlesztői részlegénél dolgozott. Ekkor fedezte fel a GNU eszközöket, és ez idő tájt olvasott a Linux -ról is, de az egyetem előtt nem találkozott a Linux -szal. A Linux -ot az egyetem első évében fedezte fel. Teljesen elkápráztatta, és innentól kezdve ideje nagy részét a Linux -szal töltötte. A második évtől kezdve - nem tudja, hogy hogyan, de - egyszercsak azt vette észre, hogy különböző disztribútoroktól/hardware gyártóktól kapott munkát. Az utolsó évét az egyetemen már úgy töltötte, hogy félig a tanulmányokkal foglalkozott, félig pedig a SuSE -nak dolgozott. A SuSE -nál végzett munkái mellett több projectben is tevékenyen részt vesz.

A következő cikk holnap fog megjelenni a hackerek topicban. A cikk főszereplője Dave Jones lesz.

Dave Jones London -ban él, a SuSE foglalkoztatja jelenleg mint főállású kernelhacker -t. Az elmúlt 6 hónapban amióta befejezte a Glamorgan egyetemet - fokozottan részt vesz a Linux kernel fejlesztésében. Több futó project -je is van, mint például a Powertweak, x86info, OProfiler, és a Kernel Janitors Project. Továbbá Ő a karbantartója a -dj patcheknek a 2.5 -ös kernelsorozatban, szinkronban tartja a stabil 2.4 -es kernelfával, ennek eredményeképpen jelentősen javítja annak stabilitását.

A cikk egy cikksorozat része, amelynek célja, hogy bemutassa napjaink kernelhackereit. A cikksorozat eddig megjelent darabjait megtalálod itt.

A hackerek topic következő alanya Dave Jones lett volna, de úgy döntöttem, hogy előbbre veszem Rik van Riel -t. Annál is inkább mert ma jelent meg vele egy interjú a NET -en. A cikk egy sorozat része, melynek eddig megjelent tagjai: Matthew Dillon (FreeBSD kernelhacker), Robert Love (Linux kernelhacker).

Rik van Riel kétségkívül az egyik legaktívabb kernelfejlesztő. Nevéhez fűződik a Linux kernel VM -jének fejlesztése. Az ő VM -jét váltotta fel a jelenlegi stabil Linux kernel VM -je (virtual memory managemet).

Rik van Riel hollandiában született 1978 -ban. 1994 -ben kezdett foglalkozni a GNU/Linux -al. Miután Linux konzulensként dolgozott egy holland cégnél, a Conectiva S.A munkatársa lett, amely a legnagyobb Linux cég dél-amerikában (Tosatti, a jelenlegi 2.4 kernelfa karbantartója is a Conectiva munkatársa, és hasonlóan Riel -hez ő is meglepően fiatal). Az érdeklődése a Linux témakörben elsődlegesen a VM felé fordult. Ő és Arcangeli felelősek a napjaink Linux kernelének a virtuális memória kezeléséért.

Azt tudjuk, hogy Linus a 2.4.10 -es kerneltől kezdve az Arcangeli féle VM -et részesítette előnyben Riel VM -jével szemben. Erről a döntésről Riel -nek az a véleménye, hogy Linus kissé mellőzte őt. Riel Alan Cox -al együttműködve számos patch -et köldött Linus -nak, de Linus ezeket ignorálta, és később azt hányta a szemükre, hogy nem küldtek neki patch -eket. Természetesen ezek után Torvalds kicserélte a Riel féle VM -et az Arcangeli VM kódra. Riel az új Linux VM -ről azt állítja, hogy jobb teljesítményt nyújt egy tipikus desktop gépen. Viszont nem biztos, hogy nagy terhelés alatt is megállja a helyét. Például a Red Hat nem szállítja a disztribúcióiban az új VM kóddal ellátott kerneleket. Riel elmondja, hogy sok felhasználó az ő által írt VM implementációt használja, és neki nem kell többet Linus -al dolgoznia, és ez jó dolog.

Szerinte ha Linus nem áll az útba, ő képes lenne jó VM -et alkotni. Többet nem akar foglalkozni azzal, hogy Linus -nak tetszik-e amit csinál, vagy sem. Csak a kóddal akar foglalkozni, szerinte a kód tartalma a fontos. Linus viszont úgy osztályozza a kódot, hogy ha az csúnya, pontatlan - mert mondjuk nincs ideje a hackernek napokat a tisztításával foglalkozni - de ellenben jól működik, akkor Linus egyszerűen eltávolítja.

Ma Robert Love a soros a hackerek topicban. Love jelenleg a preeptív kernelpatch karbantartója. Ő hét éve használ Linux -ot, és több munkájával járult hozzá a jelenlegi kernel fejlesztéséhez.

Robert Love jelenleg számítástechnikai tanulmányokat folytat, és matematikát tanul a kaliforniai Gainesville egyetemén. A floridai Fort Lauderdale -ből származik. Pembroke Pines -ban született és ott is nevelkedett. Egyelőre nem nős, de van egy gyönyörű barátnője (állítja Ő =)). Az érdeklődési köre a programozás terén az operációs rendszerek, és a tudományos/matematikai számítások.

Várhatóan a 2004 -es évben fejezi be a jelenlegi egyetemi tanulmányait, de utána még szeretne az egyetemen maradni, és gazdasági tanulmányokat szeretne folytatni.

A Linux -al 1994 -ben ismerkedett meg közelebbről. Az 1.0 -ás Linux kernellel kezdte a Linux -al való ismerkedést. Azelőtt nem találkozott semmilyen Unix jellegű operációs rendszerrel. Akkor kapott az édesanyjától egy 386sx típusú számítógépet, amelyre egy beta Windows 95 -öt telepített. Komolyabban a Linux -ot a 2.0 -ás kernelnél kezdte el használni, majd a 2.2 -es kernel idején teljesen felhagyott a többi operációs rendszerrel, és csak a Linux -ot használja azóta is.Hogy mik az okok amiért a Linux felé fordult?

A következő cikk holnap fog megjelenni a hackerek topicban. A cikk főszereplője Robert Love lesz. Robert Love a preemptív kernelpatch szerzője, és számos más a kernelben szereplő driver, optimalizáció, patch közreműködője.

Új topic-ot indítottam a vasárnap a Matthew Dillon cikkel. Az topic célja, hogy bemutassa napjaink népszerű (kernel) hackereit. Azokat az embereket, akik a mindennapi életük során valami meghatározó dolgot tettek le az asztalra, és nagyban hozzájárultak ahhoz, hogy a mostani operációs rendszereink ilyen szintre eljutottak.

Hogy miért sötét oldal?

Mert a nagy szoftveróriás szemében Ők a sötét oldal képviselői, napjaink Neo-i, akik nappal alszanak, éjjel az iRC-n, és levelezési listákon élnek, sötétben kódolnak. Szobájukból nem mennek ki, teljesen megszakadt a kapcsolatuk a külvilággal, és normális emberi kommunikációra már képtelenek (majd látni fogjuk, hogy ez mennyire nem így van, de ne szaladjuk előre). Ők azok, akik a számítástechnika ellenségei, mert a munkájukkal "drága", "használhatatlan", felhasználók által nem használt operációs rendszereket írnak, és a szabadidejüket azzal töltik, hogy a "rendes", "becsületes" szoftverfejlesztő cégeknek elvegyék a kenyerét.