Torvalds szerint a Linux "dagadt és hatalmas"

Címkék

Egy, a LinuxCon 2009 rendezvényen megtartott kerekasztal beszélgetésben Linus Torvalds azt mondta, hogy a Linux "bloated" és "huge", azaz elhízottá és hatalmas méretűvé vált. A kijelentés azután érkezett, hogy felmerült a kérdés, vajon nem érkeznek-e túl gyorsan az új funkciók a Linux kernelbe. A beszélgetés levezetője, a Novell alkalmazásában álló James Bottomley egy Intel felmérést említett, amely arról számol be, hogy a Linux (kernel) teljesítménye kiadásról kiadásra két százalékponttal csökken. Ez az elmúlt 10 kiadást tekintve összesen 12%-nyi teljesítmény-csökkenést tesz ki.

Torvalds válaszában kifejtette, hogy egy kissé szomorú, hogy az általuk fejlesztett kernel nem éppen az az áramvonalas, kis méretű, szuperhatékony kernel, amit megálmodott 15 évvel ezelőtt. Azonban megjegyezte azt is, hogy a kernel legalább bugok szempontjából egész stabilnak tekinthető abban az értelemben, hogy olyan ütemben találják meg a bugokat, ahogy azokat hozzáadják a kernelhez, annak ellenére, hogy közben egyre több kódot lapátolnak a kernelhez.

Az elmondottak dacára azonban nincs nagyobb terv arra, hogy megoldják "dagadt és hatalmas" kernel problémát. A probléma egyik forrásának a Linux népszerűsége tekinthető. A Linux számos platformon fut és mindegyikhez tartalmaz szolgáltatásokat, eszközmeghajtó programokat.

Arra kérdésre, hogy az elhízottság elfogadható-e, Torvalds azt válaszolta, hogy "Nem, én nem azt mondtam. Az 'elfogadható' és az 'elkerülhető' két különböző dolog. Ez elfogadhatatlan és egyben valószínűleg elkerülhetetlen is."

A részletek itt.

Hozzászólások

Nem kell mindent beleforgatni a kernelbe csak ami szükséges nem ? Ekkor máris nem olyan bloated. Vagy valamit nem értek ?

Nekem ennek egy kicsit olyan "storm in teacup" szaga van. De szeretném leszögezni, hogy nem értek hozzá.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Szerintem is. Ez közel sem egyenlő azzal, mintha Gates sírna, hogy lassul a winfos. Pláne, hogy szarik bele. :D

A legtöbb ember ezt úgy értelmezi, hogy: Jajj! Lassul a linux, biztos nem lesz olyan versenyképes!
Inkább arra gondolok, hogy Linus csöppet maximalista és már korán elkezdett foglalkozni egy olyan hatékonysági problémával ami csak évek múlva válna valóságos problémává.
Youtube-on mondta is egy git-es előadásban, hogy nagyon szem előtt tartja a teljesítményt.

Te jó ég! Akkor az már 1,02^10=1,22 Az 22% csökkenés. Mi lesz most? 35 kiadásonként felére lassul a Linuxz. Szerintem mehet Index címlapra! :)

Ettol fuggetlenul kint van az index cimlapon:)

Nem ertem egyebkent a meglepodest. Kozvetve ez volt a cel, amikor atalltak erre a kernelfejlesztesi modszerre par evvel ezelott, nem?

A folyamatos lassulas mar csak azert is erdekes, mert allandoan ilyen meg olyan teljesitmenynovelo fejleszteseket latni a changelog-ban. Akkor azok hova lesznek?

Egyaltalan mitol lassul? Attol nem fog, hogy bekerult egy uj hw tamogatasa.

Valamint mit ertenek a lassulas alatt (a mogottes linkeket nem olvastam ezuttal)?

tompos

Az irónia nem neked szólt, hanem annak, hogy ez így hogy 2% lassulás, ez nem mond semmit. Mi lassul 2%-ot, milyen mérőszámok alapján, stb stb? Szerintem mindenki jól ellenne 2% lassulással, ha ugyanakkor 10%-ot gyorsulnak a processzorok, és funkciókban gazdagabb lesz a kernel. Szóval most ez a "2%" úgy értendő, hogy ugyanannyi ficsör mellett ,vagy a ficsörök száma is emelkedik közben. Bonyolultabb rendszer nem feltétlenül lassabb, de eléggé valószínű hogy az. Szóval én nem csinálnám össze magam attól a 2%-tól. Na valami ilyesmit akart jelenteni a hsz.

hm.
én régebbit használok rajta (2001-eset). no persze a frissítések föl vannak rá rakva, leginkább praktikus okokból (pl. így már nem kerül végtelen (egészen pontosan: újra-tovább-mégse-de-tökmindegy-melyiket-választod) ciklusba, ha olvasás közben kiveszem az olvasóból a cédét, valamint így már föl lehet kapcsolódni hálózatokra úgy, hogy maradjon néhány vírusmentes percem letölteni egy vírusirtót (amiből 1 percet elvesz az, amíg az avg free letöltési oldala elszámol 60-tól 0-ig, de ez még mindig jobb, mintha a blaster tenné ugyanezt)).

és kiadásonként egy átlagos gép mennyivel gyorsabb?

OFF
Ez a Linus gyerek eljöhetne ide miniszterelnöknek: ő kicsit álmodott, és nagy lett belőle (gyakorlatilag az egyetlen rossz tulajdonsága, amellett a millió jó mellett, ami miatt ekkorára hízott). itt meg a b@lfasz lúzerek egyre nagyobbakat álmodnak, az ország meg közben beledöglik.
ON
_____________
烏邦土 - 乾屎橛

Ahhoz kepest, hogy legutobb mikor azt talaltam mondani, hogy a Linux kiadasrol kiadasra egyre lassabb, majdnem meglincseltek, ez jelentos fejlodes. :)

(Egyebkent Wirth torvenye rulez, Moore lemondhat. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

a többi os meg csak gyorsul gondolom :)
ergo a többi os-nél van igazából szar a palacsintában mert előbb utóbb kezelhetetlenül gyorsak lesznek :)

Nos igaza van brutális nagyra dagadt, a kernel kódbázisa (csak tudja ő csinálta az egészet :D nézzetek meg egy új kernelt, kb a fele volt, a 2.6.1-es). mivel mindenhova Linuxot akarnak tenni ami kütyü (mobiltelefon, mp4-lejátszó......) irtózatos mennyiségű kódot jelent ez, a beépített rendszereknél. Egy csomó beépített rendszerre szabott distro keletkezett. Az asztali pc-k piacára is erősen kezd betörni ez megint egy adag illesztő program, kényelmi cucc....., a szerver piacon meg mindig ott is volt. Ezzel nincs is baj, sőt nagyon jó. Fejlesztői szempontból (habár nem tartom magamat annak, de csak írok sok programot Linux alá is, winnel összehasonlítva kész öröm), baromi jó dolog a nyílt forráskód, az nekem mindegy hogy ezt hívhatnák Free-dos-nak, vagy Haiku-nak, most a Linux ezen a téren a legjobb. Véleményem szerint, a felső vezetést -ha lehet ilyet mondani Linux esetén- kell egy kicsit átszervezni, több ember kell, és nekik jól össze kell dolgozniuk. Szerintem eléggé túl lehetnek terhelve. Elég jól önszervező ez a "világ fejleszt" dolog, majd itt is kialakul egy protokoll, ami jó. De szerintem jól van ez így, hogy van egy univerzális kernel, amiből mindenki azt hajtogat ki amit akar, csak több ember kell a karbantartáshoz, jól átgondolt protokollal.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Lehet, hogy most 5 éves linux használatomnak mondok ellent, de a kernel télleg nagyra dagadt. Nem hiszek az ilyen univerzális dolgokban. Táli-nyári gumikban sem hiszek, Télre téli gumi, nyárra nyári. Linux is libekből áll össze, kernelt is ilyenre kellene alakítani. Szerintem ... Ha így alakul, 5 év múlva tölthetjük le az 1 Gb-s kernelt és forgathatjuk. :)

Persze. Attól még módosítható, a dolog, nem is azt mondtam, hogy egy hatalmas kernel van és kész, a kódbázis az jó ha közös, és abból a többi "lib" külön megoldható. Például amikor elindult a 64-bit az a kernelen belül még külön könyvtárban volt, aztán jött valami emberke, hogy mi lenne ha nem külön filekben/könyvtárakban tárolnák, a 64-bites részkódokat, hanem egy filen belül, hisz alig különbözik a kettő, kevesebbet kell gépelni. Ami igaz is, viszont ha majd bontásra kerülnek kódok akkor most majd szívás visszafelé. Jó dolog ez a monolit kernel, amíg nem egy akkora monolit, mint egy hegy. :D

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Személy szerint úgy gondolom, hogy ez tipikus tendencia a szoftverek világában. Ha pl. 10 évet visszamegyünk az időben, azt látjuk, hogy minden szoftver messze gyorsabb volt, pláne úgy, hogy gyengébb hardvereken futottak. Persze, hogy a linux-ra is igaz, meg a windows-ra is, stb...
Funkcionálisan egyre többet kell nyújtani, másik oldalon meg ott a kényszerű kompatibilitás a régebbi rendszerekkel. Ez olyan kettősség, aminek ez a törvényszerű eredménye.
Azért azt se felejtsük el, hogy a hardver meg fényévekkel előrébb jár, mint bármilyen szoftverfejlesztés, és akár csak a plusz nyers erő is simán kompenzálja a szoftverekben rejlő akárhány százalékos lassulást.

Persze persze.
De ha pl. egy ősi dos-os programot futtatunk egy mai vason, az gyorsabban fut, mint anno egy 486-oson (brute force), Wirth's law ide vagy oda. Wirth is úgy gondolta, hogy a gyorsabb vasakon komplexebb alkalmazások futnak ugyanannyi idő alatt, mint régen a lassú vason az egyszerűbb alkalmazások.
Erre jó példa az Intel P3 kontra P4 proci esete is, avagy nagyobb üzemi frekvencia, kontra pipeline hossz.

Persze, hogy az egyre bonyolultabb vasak, és egyre komplexebb kódok korában azt látjuk, hogy most is ugyanannyi - vagy több - idő elvégezni egy adott feladatot, mint régen.

Egyébiránt meg, szerintem sokkal nagyobb probléma az, hogy a CPU-k egyfolytában várják az adatokat, mert nincs, ami időben kiszolgálná őket.
Ez itt a fő probléma. Az lenne a tuti, ha a base ram is full-speed lenne, mint pl. az L1 cache. Az forradalmi lenne az egész IT szektorra vonatkozóan.

Azonban megjegyezte azt is, hogy a kernel legalább bugok szempontjából egész stabilnak tekinthető abban az értelemben, hogy olyan ütemben találják meg a bugokat, ahogy azokat hozzáadják a kernelhez, annak ellenére, hogy közben egyre több kódot lapátolnak a kernelhez

Ekkora marhaságot hogy mondhatott Linus, te jó'sten... /o\

Szerintem félreértetted. Gondolom arra próbált utalni, hogy nagyjából olyan ütemben halad a régi bugok kigyomlálása a kernelből, mint amilyen tempóban újabbak derülnek ki az új fejlesztések kapcsán. Magyarul nő a kernel, de nem nő vele lineárisan az abban lévő bugok száma. Én legalábbis így értelmeztem...

Gondolom arra próbált utalni, hogy nagyjából olyan ütemben halad a régi bugok kigyomlálása a kernelből, mint amilyen tempóban újabbak derülnek ki az új fejlesztések kapcsán. Magyarul nő a kernel, de nem nő vele lineárisan az abban lévő bugok száma.

Kár hogy az első mondatból nem következik logikailag a második...

Még jó, hogy nem következik, akkor nem lenne információ értéke!!! :-D

Egyébként szerintem egy kis igazítással számodra is érthetővé válik:
"Magyarul nő a kernel, de nem nő vele lineárisan az abban lévő bugok száma."
helyett
"Magyarul nő a kernel, de nem nő vele lineárisan az abban lévő javítatlan bugok száma."

Ha még mindig nem, akkor gondolj bele ebbe:
új sorok száma/új bugok száma=lineáris (asszem 1000 C sorra egy bug, vagy mi a mondás)
javított bugok/idő=konstans (kisebb ingadozást eltekintve, közel ugyanannyian pofozgatják)
új sorok száma/idő=exponenciális (a kernel mérete egyre nő)

Ebből nem triv, hogy új bugok/javított bugok=lineáris, szóval van hírértéke.

Ja értem, egy ilyen hasracsapott adattal kell számolni, hogy 1000 C sorra egy bug jut, így már világos.

Esetleg néhány más népi bölcsességet is hozzá kellene venni ezekhez a komoly statisztikákhoz, hogy mégnagyobb szakmai értéke legyen a Linux-szal kapcsolatos kijelentéseknek...

Ha jól értelmezem (fixme) linus szavait, akkor a linux kernel fejlesztése rossz úton halad, mivel ráállt egy olyan útra, ahol az eszköz támogatottság egyenes arányban áll a bugok számával, a lassulás mértékével, és a stabilitás romlásával.
A szakiktól kérdezem. Elkerülhető ez, és ha igen hogyan?
Esetleg mikrokerneles megoldásra kéne átállni????
(bár szvsz linust ha keresztre feszítik sem fogja ezt támogatni. Egy közel 20 éves vitát nem hajlandó elveszíteni :)))) (tannenbaum)
--
A linux felhasználóbarát. mindössze megválogatja a barátait...

abban nem. de sebességben már igen. eredetileg pont a "sebesség" szólt a monolitikus felépítés mellett. a funkciók számának, és támogatott eszközszám rohamos emelkedésével viszont kezdi elveszteni ezt az előnyét a monolitikus linux.
ez nem jelenti az, hogy elméletileg nem lehetne egy olyan monolitikus kernelt írni amely a jelenlegi funkcionalitás mellett megőrizné sebességét és hatékonyságát is. a valóságban viszont a linux kernel fejlesztői erre már képtelenek.

ha rosszmájú szeretnék lenni, akkor most azt emelném ki, hogy a "valamennyit" szón van a hangsúly:D
realtime képességek kapcsán már kitárgyaltuk egyszer a témát Denessel. ő, aki egyébként valóban tanulta is, megértette az előnyeit a mikrokerneleknek, rt feladatok terén.
általános, különösen szerver feladatoknál, tradicionálisan a monolitikus kernelek voltak előnyben. mach+linuxal sokat kísérleteztek egy időben, és az általános tapasztalat az volt, hogy az mklinux ~10%al lassabb, mint monolitikus linux társa. a cikk szerint az elmúlt 10 linuxkiadás során 12%ot lassult, azaz ennyi teljesítménycsökkenés volt tapasztalható a linux kernel alapú rendszernél. amennyiben az Intel valós adatokat közöl, akkor felvethető a kérdés,
még mindig előnyösebb a monolitikus linux?
L4 µkernel mellett ráadásul kisebb teljesítménycsökkenéssel kell számolni, mint Mach mellett.

a hír szerint folyamatosan csökken a linux teljesítménye, ráadásul Linus elismeri, nem tud mit kezdeni vele. erre nem én, hanem Strogg felveti a kérdést, Esetleg mikrokerneles megoldásra kéne átállni? Hunger helyesen megjegyzi, hogy ettől nem csökkenne a bugok száma. ehhez tettem hozzá, hogy sebességben viszont lehetséges hogy segítene, ha mára már valóban ilyen szintet ütött meg a lassulás. de természetesen mindig akad pár ügyeletes inkvizítor aki a torkomnak ugrik, ha ilyen eretnek gondolatokat hall:D talán nem vallási kérdésként kellene kezelni az informatikai problémákat;)

Meg mindig nem tudjuk, hogy hogy mertek teljesitmeny csokentest, es hogy hol jelentkezik.
De arra fogadni merek, ha micro kerneles lenne meg lasabb lenne.

Egybkent micro kernel es micro kernel kozott is orasi kulonbseg lehet ugyan ugy mint monolitikus es monlitikus kernelnel, az rt szempontbol ez inkabb egy apro reszlet, mintsem fontos dolog.

Maga az rt kerdeskor sem olyan egyszeru, hogy ragsztunk ra egy real-time cimket es akkor mar mindenre jo ahol rt cimkes feladat van.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

az igazat megvalva az operacios rendszerek targy feleve soran egy azaz egy darab slide volt a mikrokerneleknek szanva, ennyit tanultam rola az iskolaban. :)
mindenesetre a legutobbi esetben ugy velem igazad volt, most viszont turul16-tal ertek egyet, mert bar a microkernel latency-je kritikus helyzetben jobb lehet (ezt targyaltuk legutobb), de a throughputja viszont valoszinu rosszabb, mert alapesetben bonyolultabb a modulok kozti kommunikacio es tobbet kell kontextust valtani (pl. kernelbol userspacebe es vissza).
mint turul16 is irja, nem tudjuk mi okozta a linux lassulasat (es hogy pontosan mi lassult), de konnyen lehet, hogy olyan dolgok amik egy microkernelt is ugyanugy erintenenek.

- Use the Source Luke ! -

Szerintem a hardverek nagyobb mértékben gyorsulnak, mint ahogy a Linux kernel lassul. Akkor végeredményben mégiscsak a gyorsulást tapasztalja a felhasználó.

De szerintem elfogadható a lassulás, ha cserébe új, hasznos szolgáltatások jönnek. Különben hogyan lehetne elérni, hogy többet is tudjon, és gyorsabb is legyen?!

Szerintem a hardverek nagyobb mértékben gyorsulnak, mint ahogy a Linux kernel lassul.

Nem. (És a linkelt oldalt nem számítva, már csak azért sem, mert a Linux kernelt az esetek többségében nem a legújabb 4 magos x86 desktopon futtatják, hanem N+1 fajta beágyazott procimagon, ahol többnyire még L2 cache sincs, in-order, és hasonlók...)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Azért a "nagyra nőtt" -et meg a "lassult" -at válasszuk szét. Az első főleg a fejlesztés-karbantartás miatt érdekes (mert annak ellenére hogy egy "a" gépen egy Slackwaret vagy bármit futtatva a teljes tárház 1-2%-a aktiválódik pl. kernel modulok formájában, a fejlesztőknek az egésszel foglalkozniuk kell), a második nem (közvetlen) következménye annak.

A Linux kernel kódbázisának fokozott növekedése főleg az eszközmeghajtók, fájlrendszerek és egyebek baromi gyors érkezésének köszönhető. Pl. csak a legutóbbi kiadásban (.31) vagy 2-3 tucat hangchip támogatása érkezett. Most katasztrófaként éljük meg a kódbázis növekedését, miközben Torvalds valószínűleg a fejlesztés menedzselésének problémáira utalt.

Az Intel féle 12%-os teljesítménycsökkenésről szóló cikket szerintem jó lenne kirakni vezércikknek, ha az nyilvánosságra kerül (úgy láttam a kommentekből, hogy az nem publikus). Lehet, hogy korreláció van az Intel-féle GCC-gyorsító erőfeszítésekkel. (mivel a gcc az elsődleges (egyetlen?) fordítóprogram a kernelre és a disztribúciókra nézve.)

********************
"...ha nem tévedek!" (Sam Hawkens)
http://holo-media.hu

Inkabb az llvm-tol varnek majd gyorsulast. A kernel rengeteg pici O(1) fuggvenybol all amik sok kis fileban vannak. Kod tisztitas, meg karbantarthatosag meg hasonlo bla-bla miatt szepen darabolodnak a dolgok, kod ismetles elkerulese vegett kulon filebe kihelyezodnek azok fuggvenyek amiket tobb hasonlo dolog hasznal.

Ezzel az a baj, hogy a gcc/binutils szinte semmilyen optimalizaciora nem kepes objektek kozott, foleg nem kepes inline-olni.

(pl. scimark kodjaval jatszottam, hogy random.c kodjat bele teszem oda ahol hasznaljak es eleg jelentos javaulast eszleltem.)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ha ez minden szoftverre igaz lenne, azert az iparag kifizetne par millio dollart es mar kifejlesztettek volna...Jol jonne mondjuk egy parezer dollaros matematikai megoldo eseten, vagy olyan matematikai optimalizaloknal, ahol egy teljes koru tanszeki licenc 20 gepre 150millio euro. H a par tized szazalekot lehet gyorsitani ilyen szoftvereknel parhuzamositas nelkul, akkor az rendkivuli javulasnak szamit.

Igaz, hogy ez sem tökéletes megoldás, de szerintem ideje lenne gondolkodni a disztribútoroknak egy olyan telepítési opción, hogy a harverfelismerő szkript meghívna egy másik szkriptet, ami eldönti milyen kernelmodulok töltődhetnek be.

De ezt már rég meg kellett volna oldani.
Emiatt mindig anyázok ha kernelforgatásra fanyalodok.

Rosszul vagyok Linus utóbbi kijelentéseitől. Én bírom ezt az embert, de könyörgöm ölje már meg valaki! Az ilyen kijelentéseivel mindent lerombol, amit életében felépített.

*******************************
Mindörökké Debián forevör ! ! !

" Torvalds szerint a Linux "dagadt és hatalmas" "
- De legalább nem pici és nem puha - szerintem :)

A probléma egyik forrásának a Linux népszerűsége tekinthető. A Linux számos platformon fut és mindegyikhez tartalmaz szolgáltatásokat, eszközmeghajtó programokat.

nade ettől mitől lesz lassabb (kisebb teljesítmény)?

attól, hogy van egy eszközmeghajtó (valószínű a modul be sincs töltve), vagy vannak szolgáltatások, amikre sosem kerül a vezérlés... azoknak nem kellene semmi hatással bírnia arra a kódrészletre, amit valóban végrehajt a processzor. Nem?

Vagy mindenfelé belekerülnek if meg switch hegyek, és ezért?

G

Egy felesleges driver csak elpazarolt memoriat jelent (neheny kilobyte), altalanas absztrakcios retegek meg mindig ott vannak, amiket azert hoznak letre, hogyha plusz egy hasonlo valamit akarnak hozza adni akkor az egyszerubb legyen, ill. ha az osszes hasonlo valami kozos funkcionalitasan akarnak valtoztatni akkor azt egy helyen kelljen megtenni. Minel tobb valamit kell lefednie annal bonyolultabb lehet.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szerintem meg semmi baj ezzel, emlékszem még arra, amikor a wifi, és a mobilnet windózos meg mekes kiváltság volt..
a disztribútorok úgyis úgy faragják a kernelt ahogy nekik tetszik, meg még te is tovább faraghatod.

Azért egy Minimál Linuxot még ma is ki lehet hozni 500 mega alatt
Lásd-> Puppy, Arch, Slitaz, stb

A Linuxban pont az a jó, hogy annak ellenére, hogy egyre kompatibilisabb, mégsem KÖTELEZŐ neked mindent benne tartani a kernelbe, ami nem kell.

szerintem...
De, lehet, hogy én vagyok a hülye...
Én kifelyezetten örülnék, ha a végén két nagy irány maradna

Linux, BSD (és persze a többi Unix alapú cucc: Mac OS, meg atöbbiek)
Azt sem bánnám, ha akkora lenne a kernel, mint egy óriási vajasra kidűlledt baromba puffadt hangár!
Csak a gépemen fusson gyorsan....

Mellesleg még mindig sokkal gyorsabb, mint akár egy Win XP SP3
persze ez csak saját tapasztalat a saját gépemen

Ami már 2 éves technika

C2D 2 GHz
2GIB RAM
Intel HD 4500

szóval én így szeretem a pingvint, ahogy van...

Dell Studio 15 + az épp aktuális disztró amit használok... :-D

Nekem csak olyan gepem van, amin a korabeli (2-3-4 eves) Linuxok mentek pocc-roff, az ujakat meg hegeszteni kell, es egyaltalan nem biztos, hogy a hegesztes vegen mukodni is fog. Ghz feletti, GB RAM_os gepekrol beszelunk, nem az Amigaimrol... (Azokon utoljara a 2.2 ment rendesen...)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Attól még lehet a hazája Finnország, nem?

Vagy ha az ember nem lehet próféta saját hazájában, és a hazája már az USA, akkor Finnországban mindenhol Linuxnak kellene lennie (az USA-ban meg nem). Ha meg Finnország a hazája, akkor az USA-ban kellene mindenhol Linuxnak lennie. :)

suckIT szopás minden nap! Grand Central Dispatch API a FreeBSD-hez

Ha vkit meg erdekelne esetleg az eredeti tema, a Linux Magazine foglalkozik vele, de a cikk nem annyira jo, igy nem linkelem lol

Allitolag sok beagyazott rendszer meg a Linux 2.2 es 2.4 valtozatait hasznalja reszben emiatt.