Linux

ACPI karbantartó csere

Címkék

Andy Grover bejelentette, hogy a továbbiakban nem Ő a Linux kernel ACPI kódjáért felelős személy. A feladatkörét Len Brown veszi majd át.Az ACPI nem a legnépszerűbb területe a Linux kernel fejlesztésének sem a fejlesztők, sem a felhasználók között. Viszont egy korszerű gép működtetéséhez elengedhetetlen az operációs rendszer nyújtotta jó ACPI támogatás.

Andrew bejelentése itt.

Ismerjük meg a Slackware 9.1-et

Címkék

Tegnap megjelent a Slackware 9.1 RC1, amelyből sejteni lehet, hogy nincs messze a végleges verzió. Ebből az alkalomból az OSNews.com egy előzetest készített az operációs rendszerről. A Slackware az egyik "ősi" Linux disztribúció, nem kimondottan felhasználóbarát (vagyis nem foolproof), de meglepően a naprakész, jól összeszedett Linux terjesztés.

A áttekintést elolvashatod itt. A képernyőképek is elég meggyőzőek. Nem lett rossz ez a GNOME 2.4.

Andrew Morton: 2.6.0-test5-mm4

Címkék

Andrew Morton ma kiadta a negyeik patchét a 2.6.0-test5 kernelhez. Az újdonságok között szerepel a 32-bit dev_t támogatás, amely Al Viro munkája. Ezen kívül számos más javítás érhető el a patchben.

LKML: slabtop

Címkék

Chris Rivera egy új segédprogramot jelentett be az LKML-en. A program elsősorban a kernelfejlesztőknek lesz majd hasznos. A neve slabtop.

Az ütemező fejlődésének mértéke

Címkék

Mark Wong egy csokor Linux ütemező benchmark eredményt postázott az LKML-re. A tesztek Rusty Russell Hackbench mérőprogramjával készültek.A tesztprogram 100 processzt indít, amelyek egy adott socket-en figyelnek. Ezekre a "hallgatózó" socketekre másik 100 processz ír, és közben a tesztprogram méri a felhasznált időt. Ezt a folyamatot többször megismétli a teszt úgy, hogy közben növeli a processz csoportok számát. Ezzel is értékelve az ütemező skálázhatóságát.

Az eredmények a 2.5.28 fejlesztői kerneltől indulnak, és egészen a mostani 2.6.0-test5 kernelnél fejeződnek be.

Andrew Morton (a jelenlegi 2.6-os kernel karbantartó) válaszolt Mark levelére, amelyben azt kérte, hogy valaki magyarázza el a teszteredmény számsorait, mert nem teljesen érti. Feltette a kérdést, hogy "Most akkor királyak vagyunk, vagy megszívtuk?". Erre Mark azt írta vissza, hogy "az általános trend azt mutatja, hogy minden javul, szóval úgy gondolom, hogy királyak vagyunk".

Teszteredmények:

Hackbench STP Results History for 2.5/2.6 (Linus BK fa)

Hackbench STP Results History for 2.5 mm/2.6 mm (-mm fa)

A thread itt és itt kezdődik.

Bootoljunk gyorsabban!

Címkék

Egy érdekes cikk jelent meg az IBM DeveloperWorks oldalain arról, hogy hogyan tudjuk csökkenteni a Linux rendszerünk bootolási idejét.

A Windows XP felhasználók gyakran emlegetik, hogy az operációs rendszerük 15-30 másodperc alatt elindul, viszont egy átlagos Linux munkaállomásnak (függően a boot időben elinduló szervizek számától) ennél jóval több időre van szüksége. Azok közül akik erre hivatkoznak kevesen tudják, hogy azért indul a Windows XP ennyire gyorsan, mert a Microsoft megváltoztatta az XP boot koncepcióját.

A régi rendszereknél (Win95, 98, Me, NT, 2k) boot időben a rendszer felderítette, hogy milyen eszközök vannak ráakasztva a gépre, azokat megszólította (hey, itt vagy? -> várta az ACK-ot, ezt jól meg lehet figyelni egy CD-ROM esetében, amire "ránéz" a win95-win9x mikor bootol), aztán ha az eszköz "visszaszólt", hogy "Yes" vagyok, akkor ment tovább a bootfolyamat. Ez elég hosszú ideig tartott.Az XP-nél telepítéskor volt egy hardver detektálás. Az ott felismert eszközökről a rendszer a későbbiekben feltetelezi, hogy a gépben vannak, NEM szólítja meg őket boot időben. Cserébe, amikor elindul az OS fél percig nem lehet hozzányúlni, mert semmi mást nem csinál, mint darálja a drivereket (erőteljes HDD tevékenység), és próbálja megkeresni az új stuffokat. Ezen kívül az XP szervizek is akkor indulnak el, amikor a felhasználó már látja az asztalt.

Hogy miért van ez így? Azért, mert a Microsoftnál rájöttek, hogy ennek pszichológiai jelentősege van. Az user ebből annyit érzékel, hogy "jééé, 32 másodperc volt a boot idő", de azt már kevésbé veszi észre, hogy utána még egy jó ideig nem lehet a rendszert használni.

Az hogy ez hogyan alakul a Linux rendszerek esetében, arról Árpi készített egy mérést májusban.

A developerworks-ön megjelent cikk azt taglalja, hogy hogyan lehet a boot időt csökkenteni. A cikk lényege, hogy a boot-idejű szervizeket párhuzamosan indítja el, ha van arra mód. Ezzel a módszerrel akár felére lehet csökkenteni a boot időt. Természetesen ez erősen függ a rendszertől is.

A cikk itt.