Linux

Hurd/Linux vagy Linux/Hurd? Esetleg Linux/HURD/GNU?



Tegnap egy Linux Kernel Mailing List feladóval érkező levél azt állította kernel listán, hogy a GNU/Hurd operációs rendszer egy része a Linux kernel kódjára alapul, így joggal kérhetnék számon a Linux fejlesztők, hogy miért nem Linux/HURD-nek hívják.

Christoph Hellwig megjegyezte, hogy a Hurd hálózati kódja (pfinet) a Linux kernel kódjára alapul. Christian Reichert szerint a GNU/HURD a GNU/MACH mikrokernelt használja amely a Linux 2.0 drivereit tartalmazza.

A felvetésre Gaël Le Mignot Hurd fejlesztő válaszolt. Szerinte a GNU/Hurd - az egész rendszer - jelenleg GNU eszközökből (libc, linker, ...) áll a GNU Hurd (szerverek gyűjteménye) felett, amely a GNU Mach mikrokernelt használja. A GNU Mach 1.x használta a Linux 2.0.36 (ha jól emlékszik vissza) drivereit. A GNU Mach 2.0 (jelenleg 1.9, mint beta verzió), az OSKit keretrendszert használja, és a szükséges driverek egy részét a Linux 2.2.12-ből és a FreeBSD-ből veszi. A jövőben elképzelhető, hogy az L4 mikrokernelt fogják használni. Az L4-hez újra kell írni a user space drivereket, ami időt vesz igénybe, és addig lehetséges, hogy mint hézagpótlót a Linux drivereket fogják használni átmenetileg. A pfinet (a Hurd TCP/IP szervere) a Linux 2.0 IP stackjét használja, de elmondása szerint újra kell írniuk, mert szerintük a Linux 2.0 stack nem a világ legjobb TCP/IP implementációja, és mert a kernel space kód user space-ben futtatva nem a leggyorsabb megoldás.Erre Larry McVoy a Bitkeeper megalkotója (lásd előző cikk) megjegyezte, hogy a Mach nem a GNU projekt "terméke", hanem a BSD kernelre épül. Ráadásul a hálózati kód és a driverek adják az operációs rendszer 50%-át, a driverek nélkül az operációs rendszer nem működik, és összehasonlítva a Linux kódját a hálózati stack és driverek méretéhez képest az előbbi elenyésző. Szerinte, ha a Hurd a Linuxból veszi a drivereket, akkor joggal nevezhetnék Linux/HURD-nek (vagy Linux/HURD/GNU-nak).

Innen kezdődött a flame. Szokás szerint kettészakadt a tábor, valaki McVoy-t szidta (a GNU fanatikusok, akiknek McVoy böki a szemüket a BitKeeper miatt), és voltak akik igazat adtak McVoy-nak. Javasolták Gaël-nek, hogy nézzen inkább körül a Hurd hálózati és IDE kódjában. A thread végén még az öreg motoros Ted Ts'o is megjegyezte (viccesen), hogy a Hurd az ext2fs-t használja így a neve HURD/Linux legyen.

Úgy tűnik a GNU projekt soha nem készül el a Hurd-del. Tavaly márciusban Stallman még azt mondta, hogy 2002-ben megjelenhet a Hurd, ami mikrokerneles lévén jobb a Linuxnál.

"A GNU kernel működik, így most már a GNU rendszerrel tudunk foglalkozni a GNU/Linux helyett, amelyet az emberek eddig használtak" - mondta tavaly Stallman az indiai látogatása alkalmával.

Később novemberben RMS bejelentette, hogy diszk, és I/O gondok miatt késni fog a Hurd. Lassan eltelt egy év, de a levlisták szerint a Hurd még mindig ugyanazokkal a gondokkal küzd, mint egy évvel ezelőtt. Lesz ebből valaha valami?

Kapcsolódó HUP cikkek itt.

Az LKML thread itt kezdődik.

R. M. Stallman pénteki levele ismét nagy flamet robbantott ki az LKML-en. RMS felszólította a Linux fejlsztőket, hogy készítsenek egy szabad klienset amely képes a Bitkeeperrel együttműködni, és váltsanak más verzió követő rendszerre a fejlesztésük során.

A Linux 2.5 kernel fejlesztése a BitKeeper nevű ``version control system"-ben folyik. Linus döntött úgy, hogy a Linux kernel fejlesztői forrását ebben tárolják a CVS-sel szemben. Ezért többen is támadták Linust, többek között RMS. RMS kijelentette, hogy a Linux nem tekinthető 100%-ban free szoftvernek, mert a fejlesztése egy nem free rendszerben folyik.Linus kipróbálta a BitKeepert. A BitKeeper 1998-ban mutatkozott be, Larry McVoy hozta létre abból a célból, hogy segítse a kernel fejlesztés menetét. A BitKeeper tulajdonképpen egy CVS-t kiváltó eszköz, amolyan 'source code management system'. Linus többször hangoztatta, hogy nem tud hatékonyan dolgozni a CVS-sel. Azóta állandó flamek vannak emiatt a kernel listán.

Kapcsolódó HUP cikkek itt.

Az LKML thread itt kezdődik.

A Linux kernel fejlesztésének legfrissebb eredményei.Karbantartó: Marcelo Tosatti

Verzió: 2.4.22-pre7

Letölthető: patch-2.4.22-pre7.bz2

Változások logja: itt

LKML thread: itt

Karbantartó: Alan Cox

Verzió: 2.4.22-pre6-ac1

Letölthető: patch-2.4.22-pre6-ac1.bz2

LKML thread, Változások logja: itt

Karbantartó: Andrea Arcangeli

Verzió: 2.4.22pre6aa1

Letölthető: 2.4.22pre6aa1.gz

LKML thread, változások logja: itt

Karbantartó: Alan Cox

Verzió: 2.6.0-test1-ac2

Letölthető: patch-2.6.0-test1-ac2.bz2

LKML thread, változások logja: itt

Aki hosszabb-rövidebb ideje olvassa a Linuxos híreket, annak már feltűnhetett Joe Barr hírhedt neve a cikkekben.

A BBC NEWS jelentése szerint a Linux operációs rendszer nagy szerepet játszik Afganisztán "normális életének" beindításában.

Manapság egyre kisebbek a RAM chipek (köszönhetően a nagy RAM igényű alkalmazásoknak, egyre több chipet integrálnak a gyártók a RAM modulokra, következésképpen a chipek mérete egy kisebb lesz, vagy belső felépítésük lesz egyre bonyolultabb), ami miatt a RAM chipek sokkal sérülékenyebbek. Sajnos elegendő ahhoz, hogy dobhassuk ki az egész modult, hogy egy RAM modulon egyetlen bit hibás. Az olcsó asztali gépeknél - amelyekben általában noname gyártók által forgalmazott RAM-okat szerelnek - ez nem is jelent akkora problémát, hiszen ezeknek a moduloknak az ára elenyészik a gép árához képest. A gond inkább a komolyabb szervereknél van, ahol követelmény a minőségi ECC (error check & correction - hibajavító képesség), registered RAM modulok használata. Ezeknek a moduloknak az ára nem kevés, és nagyon tud fájni anyagilag, ha a garancia letelte után ezek a moduok meghibásodnak (itt nyilván kivételt képeznek a Lifetime garanciával árusított komolyabb modulok, mint például a K****tone). Vagy a másik nagyon kellemetlen dolog, ha egy notebook alaplapjára forrasztott RAM chip hibásodik meg. Ennek a javítása rendszerint a notebook alaplapjának cseréjével jár.

De nem kell annyira elkeseredni, mert van szaknyelven szólva "workaround" a dologra.Létezik egy projekt, amelynek az a célja, hogy a meghibásodott RAM modul hibás részeit "elfelejtesse" a Linux kernellel. Azaz a projekt által készített kernelfolt felkészíti a Linux rendszermagot arra, hogy a paraméterben megadott RAM területeket egyszerűen hagyja figyelmen kívül.

A projekt neve BadRAM. A működése egyszerű. A hibás RAM-mal rendelkező gépen lefuttatjuk az ismert RAM tesztelő programot a Memtest-et. A teszter által rossznak jelzett területeket rögzítjük, átalakítjuk a BadRAM által értelmezhető alakra, amellyel aztán úgy bootoljuk be a Linux kernelt, hogy a loadernek paraméterként megadjuk a hibás memóriaterület címeit. Valahogy így:

LILO: linux badram=0x008042f4,0xff805fff

Ezzel tudattuk a Linux kernellel, hogy mely az a terület, amelyet nem szabad allokálnia. Az ellenőrzéshez futtassuk a dmesg programot:

dmesg | grep ^Memory:

Memory: 158524k/163840k available

(940k kernel code,

412k reserved,

1856k data,

60k init,

0k highmem,

2048k BadRAM)

Amint látjuk, a memóriában 2MB-nyi hibás területet detektált a kernel.

Ha valakinek kényelmetlen a loadert paraméterezni, és kicsit jártasabb a kernelhackelésben, akkor a rossz terület adatait fixen is bele tudja drótozni a kernel forrásába.

A készítő szerint az alábbiak miatt van létjogosultsága a projektnek:

- a chipkészítés erőforrásigényes: veszíts kevesebbet, aludj jobban

- ez is egy módja annak, hogy bizonyítsák, mennyire flexibilis operációs rendszer a Linux

- a fent említett laptop kérdés miatt

- mert egyszerűen cool ;-)

Megjegyzés: azért a "produktív" környezetben a biztos megoldás a rossz modulok cseréje!

A BadRAM patchek elérhetőek a projekt honlapján. Folt a 2.6.0-test kernelhez a fejlesztő levelében.



További kapcsolódó HUP cikkek itt.

Ahogy Linus egy mostani interjúban bejelentette, Andrew Morton lesz a 2.6-os kernel széria karbantartója. De vajon ki is Ő?

Andrew Morton 43 éves, angliai születésű ausztrál. Elektromérnöki diplomát szerzett a Dél-Walesi Egyetemen. Nős, 3 gyermek atyja. Jelenleg Palo Alto-ban (Kalifornia) él. 1986-ban néhány barátjával gyártott egy "csináld magad" 68000-alapú számítógépet. Ők készítették a gépet, és a hozzá kapcsolódó Unix-szerű operációs rendszert is. A gépből mintegy 400 darabot adtak el. A Minixet a Macmillan-tól licencelték, amelyet Morton egyik barátja Colin McCormack portolta a gépükre. Talán ez volt az egyetlen nem PC-s portja a Minixnek. Az Applix 1616 projektet csak mókának szánták, de sokat tanultak belőle.Később Morton 9 évet töltött el a Nortel Networks R&D-nél, ahol a menedzsment része volt. Amint egy interjúban mondta, értékes tapasztalatokat szerzett azzal, hogy komplex 5-9-es rendszereket szállítottak partnereiknek. Morton 1994 óta Linux felhasználó. Az első igazi közreműködése a Linux kernelben 2000 márciusban volt, amikor a 2.3.47 idején Alan Cox elavultnak minősítette Morton 90 centes hálózati kártyáját. Morton ekkor folytatta a kártya kerneloldali támogatását, és első alkalommal egy 2500 soros patchet küldött Torvaldsnak. Mivel elégedettséggel töltötte el az, hogy olyan hasznos dolgot csinál, amely másoknak is jó, folytatta a kernellel kapcsolatos munkákat.

Sokáig egyetlen kernelrészért sem felelt közvetlenül, inkább csak "beleütötte az orrát" (saját bevallása szerint) mások projektjeibe, és azokban próbált meg segíteni. Számos érdekes elképzelés fűződik a nevéhez. Ilyen például a low-latency patch, amely hasonló bizonyos szempontból Rober Love preemptive kernelfoltjához. A másik fontos terület ahol Morton közreműködött a fejlesztésben, az az ext3 filerendszer. Átrágva magát az ext3 kódján - ami a bevallása szerint a legkomplexebb, legbonyolultabb része a kernel forrásának - számos bugot javított. Munkája során egy notebookot használ, és egy kétutas szervert. A szerveren NFS szerver, és egy Half-Life szerver is található, amelyet a gyerekekkel szokott használni.

Az interjút megtalálod itt.



További kapcsolódó HUP cikkek itt.

Hogy a mai nap se teljen el Linus interjú nélkül, álljon itt az InfoWorld mai riportja. Ez ma készült, és olyan kérdések is megtalálhatóak benne, amelyeket eddig nem válaszolt meg a Linux atyja.

Az interjút megtalálod itt.

A Linux Journal-on jelent meg egy interjú Moshe Barral, az OpenMosix vezető fejlesztőjével. Az OpenMosix egy klaszter megoldás, amelyet számos projekt implementált. Ilyenek a ClusterKNOPPIX, PlumpOS vagy a Gentoo amely szintén foglalkozik az OpenMosixszal. Az OpenMosix a Mosix forkja, amely akkor keletkezett, amikor a fejlesztők nem tudtak megegyezni, hogy a kód GPL-es legyen-e vagy sem. Az OpenMosix GPL licenc alatt érhető el. A Mosix egy klaszter (fürt) menedzsment rendszer. Segítségével tetszőleges számú x86 munkaállomásból és szerverből építhetünk egy egységet, amely többnyire úgy működik mint egy SMP rendszer. Ezt egy olyan algoritmussal oldja meg a klaszter, amely a node-októl (a klaszter tagjai) származó folyamatos visszajelzések alapján hozza meg a döntéseket.

Moshe Bart többen is vádolják azzal, hogy "lenyúlta" Prof. Amnon Barak-tól (a Mosix eredeti fejlesztőjétől) a Mosix kódját, és most magának szeretné a dicsőséget (mint ahogy az interjú egyetlen hozzászólásában is olvashatjuk).

Az interjút megtalálod itt.

További kapcsolódó HUP cikkek itt.

Igen, még egy interjú Linus Torvaldsszal. A kérdések a szokásosak, de érdemes azért elolvasni, mert mindegyikben lehet új dolgokat felfedezni.

Az interjú itt.