Marcelo Tosatti válaszol a felhasználók kérdéseire

Linux

Most, hogy a 2.5-ös kernel fejlesztése folyik, az összes fontos teendő a régi kernellel kapcsolatban Marcelo Tosatti-ra maradt. A Slashdot felkérte a tagjait, olvasóit, hogy fogalmazzanak meg kérdéseket a 2.4-es kernelt, Tosatti munkáját illetőleg.

Nézzük mit válaszolt a jelenlegi stabil kernel karbantartója.

Egy dolog igazán hiányzik a kernel kiadások változások logjából (changelog). A változások logja egyre kevesebb információt tartalmaz a nem-kernel hackereknek. Amit szeretnénk látni a logokban, az az hogy érthetően le legyen írva mi változott. Alan Cox a helyes irányba indult el a 2.2.18-as kerneltől kezdődően, viszont a leírásai a változásokról túl technikaiak. A például a fenti dokumentumban set_current_state

* Fixed potential SMP race

többet mond nekem, és a többségnek is azt hiszem. Mit gondolsz erről?

M.T.: Egyetértek abban, hogy a changelog nem a végfelhasználóknak készül. Láttam a különböző kéréseket, megpróbálok részletesebb changelog-okat készíteni. Viszont kérlek értsd meg, hogy fontosabb az, hogy fixáljam a problémákat mint az, hogy részletesebb changelog-ot írjak.

Van olyan naplód, mint Alan Cox-nak? Mert szeretnénk tudni, hogy azon fogsz-e dolgozni, amit most nekünk ígérsz :)

M.T.: Sajnos nincs.

A linux kernel "dagadása" egy komoly probléma. Pl. a 486-os gépemre nem tudom feltenni a Red Hat memória-zabáló disztróját, mert a 16MB RAM-on nem fut, és ez kétségtelenül kernel gond. A kérdés: a kernel "hízása", mind a forráskód, mind az erőforrás igények, gondot okozhatnak a karbantartásban. Úgy látod, hogy ez okozhat jelentős problémát a későbbiekben?

M.T.: A core kernel kód "hízása" valóban súlyos probléma. Én bízom Linusban, hogy nem engedi ezt a 2.5-ben. Ha több driver-t/fs-t teszünk a kernelbe, az valóban rontja a karbantarthatóságot. Egyet tehetünk ez ügyben: az összes elfogadott kódnak tisztának, jól átláthatónak, jól tervezettnek kell lenni a későbbi karbantarthatóság miatt.Gondoltál már arra, hogy a kódjaidat valamilyen ``version control system"-ben tároljad? Ha elkezdenéd használni a CVS-t lehet, hogy a kernelfejlesztők többsége követné a példát.


M.T.: A pre patcheket elég gyakran adom ki. Azonban exportálhatnám ?ket a helyi CVS-embe. Valóban tehetném ezt a jövőben.

Hogyan látod, merre halad a Linux fejlődése összehasonlítva más operációs rendszerekkel (Windows, FreeBSD, stb.)?

M.T.: A beágyazott rendszerek üzlete, az otthoni felhasználók üzelte, a vállalati felhasználás üzelete. Ezeket kezelni, és ezeket az igényeket kielégiteni a lehető legjobban egy szép kihívás. Nem látok semmilyen irányt amely felé a Linux haladna.

Miért te? Mit gondolsz, tudod te rendesen karbantartani a kernelt? Milyen képesítésed van, és miért kellene nekünk (felhasználóknak) biznunk benned?

M.T.: Azt gondolom, hogy azok akik engem választottak ezt azért tették mert tudok különböző emberekkel bánni. Kerülöm a konfliktusokat és inkább a problémákat próbálom megoldani.


A képesítésemről: Négy éve dolgozom a Conectiva-nál mint szoftverfejlesztő. A technikai supportal dolgozom együtt.

Linus a kicsi méretű patcheket szereti, Alan Cox elfogadja a nagyobb patcheket is. Melyek azok a patchek amelyeket szeretsz, és melyek azok amelyeket nem?

M.T.: Azokat a patcheket szeretem amelyek egy bizonyos részét érintik a kernelnek. Azokat pedig utálom amelyek a kernel különböző részeit érintik.

Alan Cox a changelog ügyben nem csak a saját védelmében állt ki, hanem politikai színezete is volt a dolognak. Szerinted Linux kernel a helyes fórum arra, hogy politizáljunk?

M.T.: Én meg fogok tenni mindent azért, hogy ne keveredjen politika a kernelbe.

A hangkártya driverek nagyon szegényesen vannak megírva. A kód nagy része redundáns. Sok driver nem használja az ioctl-eket. Néhány támogatja a /dev/audio-t, némelyik nem. Jelenleg nincs ALSA támogatás a 2.4-ben, és ez azt jelenti, hogy még egy-két évig nem lesz jó audio támogatás a kernelben. Tervezed-e az ALSA-t integrálni a 2.4 kernelfába?

M.T.: Nem tervezem, hogy az ALSA-t integrálom a 2.4-be.

Mint tudjuk a nagy cégek nagy energiákat ölnek bele a Linux fejlesztésébe. Hogyan kezeled azokat a dolgokat, ha nagyobb cégek emberei (IBM, SGI) nagyobb változásokat szeretnének eszközölni a kernelben?

M.T.: Ha a kód amit adnak nem sért érdekeket, természetesen alkalmazom. Miért ne tenném?

Hogyan döntöd el, hogy melyek azok a patchek amelyek belekerülnek a 2.4-be, és melyek azok amelyeknek inkább a 2.5-ben a helyük?

M.T.: Igazán óvakodok az olyan új funkcióktól, amelyek gondot okozhatnak. Azoknak a 2.5-ben a helyük. Azok az új dolgok, amelyek nem okoznak gondot természetesen rendben vannak.

Milyen elvárásaid voltak a Linuxszal kapcsolatban amikor először kezdted el használni, és milyen elvárásaid vannak most?

M.T.: Amikor elkezdtem használni, azt vártam el tőle, hogy legyen egy szerver szoftver.


Most azt várom el tőle hogy egy Unix rendszer legyen, amely képes különböző környezetekben működni.

Ha Linust és Alan Coxot (ne adj isten) elütné a busz, te lennél "Az az Ember"?

M.T.: Nem tudom, dude.

Használsz valamilyen Linux disztribúciót? Milyen operációs rendszereket használsz?

M.T.: Linuxot használok a munkámhoz, és néha Windowst használok a játékokhoz.

Egyforma rendszereket használsz minden gépeden, vagy különböző dolgokat is futtatsz?

M.T.: Linuxszot futtatok az összes gépemen. Szeretek ránézni más OS-ekre is, ha időm engedi...

Milyen fejlesztőeszközöket használsz a munkád során? Tervezed-e a stabil kernelforrást CVS-be vagy más ``version control system"-be tenni (hmm. mintha ez már lett volna...)?

M.T.: Én vi-t használok a forráskód szerkesztéséhez, és gcc-t a forrás fordításáshoz :)

Nem, nem tervezem a kernelforrást semmilyen ``version control system"-be tenni, mert tudni akarom mi kerül bele a kernelbe. (megjegyzés: ezt a választ nem teljesen értem, vagy félreértettem volna? azért ellentmondásos mert közben megjelent egy cikk miszerint Tosatti elkezdte használni a BitKeepert, ami köztudottan egy ``version control system"-féle valami)

A teljes cikket megtalálod itt.