Linux

Új 'pre' kernel érhető el a szokásos kernel.org -on, és a mirrorokon.

Az FSF (Free Software Foundation) és a GNU atyja, Richard M. Stallman (RMS) a Takeda alapítvány 2001 -es díját nyerte el. A díjazottak között volt még Linus Torvalds, és Ken Sakamura a TRON nyílt architektúra fejlesztője. Mindegyik győztes 100 millio yen -el lesz díjazva, amely körülbelül 830,000$. A díjakat december 4. -én adják át.

Hogy ki is RMS? És miért kapta a díjat?

"Richard Stallman vagyok, az eredeti sokat utánzott EMACS bevezetője, régebben az MIT AI laboratóriumában dolgoztam. Nagyrészt fordítókat, editorokat, debuggereket, parancsértelmezőket, az Inkompatibilis Időosztásos Rendszer-t és a Lisp Machine operációs rendszert fejlesztettem. Élen jártam a terminálfüggetlen képernyő támogatásban is. Azóta egy ,,crash''-biztos fájlrendszert és két window rendszert írtam Lisp gépekre, és terveztem egy harmadik window-rendszert, amin most dolgozom; ez a rendszer sok rendszerre át lesz írva, beleértve a GNU-t is."
[...]

Megjelent a legújabb 'pre' kernel. Ez a verzió hálózati kártya frissítéseket, UFS filerendszer kódtisztítást, és az Andrea Arcangeli féle Linux VM tuningolását tartalmazza.

Változások logja:


- Jeff Garzik: network driver updates


- Christoph Hellwig: UFS filesystem byteorder cleanups


- me: modified Andrea VM page allocator tuning

Most, hogy Linus befejezte a 2.4.15-pre4 -ben az egyesítést Alan Cox kernelfájával (ac tree), és átadta a 2.4 -es kernel karbantartását Tosatti -nak és team -jének, eljött az ideje, hogy megnyissák a 2.5 -ös fejlesztői kernelfát. Ennek alkalmából nézzünk egy kis kernel összefoglalót.

A mostani a leghosszabb időszak, amely eltelt fejlesztői kernel nélkül.

Az első stabil kernel az 1.0 -ás 1994. március. 3 -án jelent meg. Az 1.1 -es development kernel 1994. április. 6 -án. A kettő között eltelt napok száma 34 nap.

Az 1.2 -es stabil kernel 1995. március. 7 -én jelent meg. Az 1.3 -as development kernel 1995. június. 12 -én. A kettő között eltelt napok száma 97 nap.

A 2.0 -es stabil kernel 1996. június. 9 -én jelent meg. A 2.1 -es development kernel 1996. szeptember. 30 -án. A kettő között eltelt napok száma 113 nap.

A 2.2 -es stabil kernel 1999. január. 26 -án jelent meg. A 2.3 -as development kernel 1999. május. 11 -én. A kettő között eltelt napok száma 105 nap.

A 2.4 -es stabil kernel 2001. január. 4 -én jelent meg. A 2.5 -ös development kernel napjainkban bármikor megjelenhet. A kettő között eltelt napok száma több mint 300 nap.
Hogy mi az oka annak, amiért ilyen hosszúra nyúlik a 'devel tree' megnyitása? Valószínű az, hogy a 2.4 kernel sorozat stabilizációs munkálatai napjainkig húzódtak. A új Linux VM mostanra került olyan állapotba, hogy belekerülhetett a stabil kernelbe, és Linus és Alan mostanra tudták a saját kódjukat összeegyeztetni. Ahogy Linus mondta egy csomó dolog fejlesztése a 2.5 -ös kernelbe tolódik, a fejlesztés megnyitása már csak napok kérdése.

Új 'pre' kernel jelent meg, számszerint a 2.4.15-pre6. Főként a '/proc/cpuinfo' került bele újdonságként ill. update -ként az Arm, PPC, és az S390/S390x/sh mainframe -khez.Változások:

Vége a nem nyílt kódú kernelmoduloknak? Többé ne használjuk az nVIDIA és más gyártók, programfejlesztők programjait?

Meglepetés érhet minket, ha az elkövetkező kernelekbe olyan modult akarunk betölteni, ami szeretné használni a GPLONLY_ szimbólumokat, viszont nem GPL stílusú licece -el rendelkezik . Ha megpóbálunk betölteni egy olyan modult amelynek nem GPL stílusú licece van, ennek ellenére mégis GPLONLY_ szimbólumokat akar használni, egy kedves kis hibát kapunk:

"unresolved symbols"

panaszkodik, és az alábbi üzenetetet írja ki:

"Note: modules without a GPL compatible license cannot use GPLONLY_ symbols."

("Megjegyzés: azok a modulok amelyeknek nem GPL kompatibilis licece van, nem használhatják a GPLONLY_ szimbolumokat.")

Ez az üzenet néhány felhasználóban megdöbbenést kelthet (nem tudják mire vélni a dolgot), ezért egy kis magyarázat gyanánt a következő verziójú modutils a alábbiakat közli velünk:

"Hint: You are trying to load a module without a GPL compatible license and it has unresolved symbols. The module may be trying to access GPLONLY symbols but the problem is more likely to be a coding or user error. Contact the module supplier for assistance."

(Útbaigazítás: Ön megpróbált olyan modult betölteni a kernelbe, amely nem rendelkezik GPL kompatibilis license -el, ezért "unresolved symbols" hiba lépett fel. A modul megpróbálhat hozzáférni GPLONLY_ szimbólumokhoz, a probléma több mint kódolási vagy felhasználói hiba. Lépjen kapcsolatba a modul szállítójával a további segítségért.")
Ez úgy tűnik, hogy egy lépés a jó irányba, bár felvet néhány nyílvánvaló kérdést:

Eric S. Raymond CML2 -je, vagy más néven 'Configuration Menu Language' -- amely része lesz az következő generációjú kernel build rendszerének -- most hivatalosan is kész a 2.5 szériához. CML2 tarlamaz egy fordítót a domain-specifikus konfigurációs nyelv számára, amelyet arra használunk majd, hogy segítségével a kernelt konfiguráljuk és feloldjuk vele az előforduló függőségeket (ha jól értem a dolgot akkor a 'make menuconfig' felújított verziója lesz lamerek számára).

A CML2 és a Linux 2.5 több különböző konfigurációs felülettel 'érkezik' hozzánk, pl. lesz olyan amely egy kalandjáték formájú lesz (ROTFL, kezd érdekes fordulatot venni a Linux fejlesztése). Tehát arról van szó, hogy ha kedvünk tartja, úgy fogjuk a kernelt konfigurálni, mintha egy kalandjátékot játszanánk. Aki már játszott MUD -al az tudja miről van szó. Ez állítólag azért jó, mert a 'nem-technikai' felhasználók is tudnak majd jól kernelt fordítani.

Hát nem tudom miért van erre szükség, lehet én értettem félre az egészet. De ha nem, akkor nem értem miért kell ilyen suxx dolgokkal leégetni a Linux -ot, miért kell debil, komoly operációs rendszerhez nem illő dolgokat a kernelhez illeszteni?

Úgylátszik mindenkit az új kernel karbantaró érdekel. Ahogy ma bejelenetették hivatalosan, hogy Marcelo Tosatti [ marcelo@conectiva.com.br ] lesz az új maintainer a 2.4 -es kernelfában, megélénkültek az események körülötte. Marcelo szívesen beleegyezett, hogy válaszol mindenki kérdésére, tehát itt az alkalom, hogy megkérdezzünk tőle mit fog csinálni ha Linus és Cox helyére lép. A kérdéseket egy fórumban lehet feltenni. Mindenkit kérnek, hogy egyszerre csak egy kérdést tegyen fel, mert nagyon sok kérdezőre számítanak. Amint Marcelo -nak lesz ideje, válaszolni fog a kérdésekre. Néhány válaszát már el is olvashatod a fennti linken.

A ma megjelent press release-ben ez olvasható:

Marcelo Tosatti-t - aki 18 éves és a Conectiva-nál dolgozik fejlesztőként - választotta Linus Torvalds és Alan Cox a 2.4-es Linux kernel új karbantartójának. November végén elfoglalja ezt a pozíciót, és ezzel átveszi Alan Cox helyét.

Tosatti felelőssége lesz az elkövetkezőekben, hogy megszabja a 2.4-es verziójú kernel útját, és hogy eldöntse mely javítások kerülhetnek bele az elkövetkező kernelekbe. Ezenfelül munkája lesz még, hogy olyan frissítéseken dolgozzon, amelyek biztosítják majd a Linux kernel kompatibilitását a boltokba kerülő új hardverekkel. A felelősség nagy. Az Ő felelősége lesz, hogy milyen módon befolyásolja a kernel fejlesztését, amelyet majd emberek és vállalatok ezrei fognak használni. Cox bízakodó a döntésével kapcsolatban, mint azt naplójában írta, "Marcelo elfogadta a lehetőséget, hogy a 2.4 -es kernel karbantartója legyen. Ez jó hír mert Marcelo okos, lelkes és olyan gyártónál dolgozik, ahol megtanulhatta a QA (minőségbiztosítás) kérdéseit. Ennek kell jól működnie."

Mint tudjuk a Linux (és más Unix-like operációs rendszerek is) csak 496 napig tudják számolni az uptime -ot, azaz a szerver bekapcsolásától eltelt időt. Az uptime számláló 496.1 nap után túlcsordul, és 0 -ról kezdi a számlálást újra.

Tim Schmielau készített egy kernelpatch -et (a 2.4.15-pre2 -hez), amely javítja ez a problémát.
Ahogy írja: "a mellékelt patch lehetővé teszi a 32 bit -es linux boxokon, hogy az 'uptime' kijelzése nagyobb lehessen 497.1 napnál. Semmilyen user space -beli program módosítása nem szükséges." A kernelpatch -et elküldte Linus -nak, és kéri, hogy füzzék bele a stabil kernelbe.