Torvalds szerint a Linux "dagadt és hatalmas"

 ( trey | 2009. szeptember 22., kedd - 13:26 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Kernelfejlesztés és karbantartás szempontjából (kódbázis) kell feltételezem érteni ezt és nem a kernelfordítás eredményeként kapott vmlinuz-ra.

--
trey @ gépház

Akkor viszont a teljesítmény csökkenésnek nincs így értelme. Szerencsére nálam a 30-as 5-10%-al mozgékonyabb a 25-29-eseknél. Ennek megfelelően Én nem látok nagy veszélyt abban a kimutatott csökkenő tendenciában sem.

A 30.4-es kernelnél sajnos van némi "memória szivárgás", nem kicsit, nagyon...
______________________________________________________________________________
- Igazi alternatíva az Ubuntu-ra: www.blackpanther.hu vagy ha ez nem jött be akkor a microsoft.com -

Szerencsére a Linux disztribútorok értenek a kernelhez, és kijavítják ezeket a hibákat, mielőtt a felhasználóikhoz érnének.


suckIT szopás minden nap! MySQL 6.0: az Oracle első áldozata?

nekem ez az ábra jutott eszembe a cikkről:

http://img29.imageshack.us/img29/8203/clipboard01pt.png

hallottam olyan véleményt, hogy a linux kernel a görbe jobb szélén jár, bár linus szerint stabil.

a kernelforgatáshoz nem sok köze van szvsz


szerintem.

nekem is ez az ábra ugrott be

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! :)

Most a baromság mellett a lényeget is meg lehetne látni. Mégis csak annak a szájából hangozott el (nem, nem a számok), aki ezt az egészet kitalálta, a fejlesztését felügyeli.

--
trey @ gépház

ezek szerint megis csak sz*r van a palacsintaban linuxeknal

--
When in doubt, use brute force.

Én az elmondottakból nem ezt a következtetést vontam le. Bár ha definiálnád a "sz.r van a palacsintaban"-t, akkor lehet kiderülne, hogy mégiscsak egy dologról van szó.

--
trey @ gépház

Na jó, de te elolvastad a cikket. :)

Igen, az szokott számítani ;)

--
trey @ gépház

A tobbseg elvan nelkule ... :)

Azert ha mar ezt is definialni kell, akkor definialjuk a definiald szot is.

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

Szerintem ketté kéne választani az vitaindító Intel felmérést és azt, amint Linus mondott. Valószínűleg okosabbak lennénk, ha látnánk, hogy az Intel mit mért, miből jöttek ki ezek a számok.

--
trey @ gépház

Valoban nem lenne hatrany, ha elerhetove tennek azt a belso tanulmanyt. Foleg, ha mar igy nyilvanosan is hivatkoztak ra (masok). Gondolom hallunk meg rola. Egyebkent igazad van, a ket dolgot kulon kell valasztani.

Nem olvastam a cikket, de az Intelnek van ilyenje publikusan:
http://kernel-perf.sourceforge.net/results.machine_id=35&options=.html


suckIT szopás minden nap! ZsebBSD

koszi, majd vetek ra egy pillantast. vagy tobbet ;)

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.

"a ugyanakkor 10%-ot gyorsulnak a processzorok"

többen is fölhozzák ezt a "gyorsulnak a hardverek"-dolgot. én ezt nem értem, nekem már jó ideje megvan a laptopom, de még sose gyorsultak benne a hardverek. ezért tehát nem örülök, ha lassulnak a szoftverek.

A kenyérpirítódban szoktál firmware-t frissíteni? Na, néhány ember szerint a gépet azzal az OS-sel kell használni, ami akkor volt életben, amikor megvetted a vasat. :)


suckIT szopás minden nap! MySQL 6.0: az Oracle első áldozata?

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)).

Mindegy.

Na, néhány ember szerint a gépet azzal az OS-sel kell használni, ami akkor volt életben, amikor megvetted a vasat. :)

én pedig ha tehetem, haladok a korral... főleg, ha nem lesz tőle lassabb

--
by Mikul@s

Haladjon Ön is a korral, süssön Váncza sütőporral:)

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

Mivel a netbookok, telefonok es embedded kutyuk korat eljuk, a kernel szempontjabol a kerdes ertelmezhetetlen. Ugy esetleg, hogy "mennyivel lassabb"...

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

a hardverek is egyre bonyolultabbak ergo azok is lassulnak :)

Tehát érdemes az összes 5500-as sorozatú Xeon-t kidobni, és Pentium Pro-kat venni helyettük ezek szerint. :)

Igazából egyenesen a 8 bites rendszereket kellene megcélozni, mert ennek a rengeteg (64) bitnek a kezelése annyira lelassítja a mai gépeket, főleg a régiekhez képest, hogy jaj.

:D
___________________________________________________________________________
MOS Technology 6510 @ 0.985 Mhz + 64 KByte (32kB RAM + 32 kB ROM)

:D
___________________________________________________________________________
MOS Technology 6510 @ 0.985 Mhz + 64 KByte (32kB RAM + 32 kB ROM)

"Ezért van az, hogy az igazi hackerek 8 bites gépekkel dolgoznak, amely a lehető legkevesebb felesleges számítást jelenti, tehát ezek a gépek gyorsak, mint a szél." - zokogok...

Ma, amikor a Linux-exploitokat HD-s youtube videón mutatják be?


suckIT szopás minden nap! MySQL 6.0: az Oracle első áldozata?

Nekem is pont ez jutott eszembe róla. :)
---
Internet Memetikai Tanszék

Most már hasonlít a TUX-ra!

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
_____________
烏邦土 - 乾屎橛

Ha ide jönne tuti az államadósságot álmodná:))

hát, ha ő maga alapból nem is, de valami anyagot biztos kapna, hogy azt álmodja, amit sugallnak neki. :)

_____________
烏邦土 - 乾屎橛

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?" -=-

"Ahhoz kepest, hogy legutobb mikor azt talaltam mondani, hogy a Linux kiadasrol kiadasra egyre lassabb, majdnem meglincseltek,"

Linket!!!111 Ahahahah :)

--
trey @ gépház

Linket? Real life esemeny volt. En nem csak a weben vagyok bator es pofatlan, mint egyesek. :P

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

Károly, látom a pascalos beidegződéseket azóta sem tudtad levetkőzni (->Wirth) ;)

--
Aries
http://pikop.hu

Irigykedj csak. :P

-=- 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 :)

Linux egy kernel, FYI!

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Ezek után én nem lennék ebben olyan biztos. A Southwestnél is két seggre kell jegyet venned 120 kilósan...


suckIT szopás minden nap! MySQL 6.0: az Oracle első áldozata?

jah, pl win7 mennyivel gyorsabb, mint vista!
bar ott volt honnan gyorsulni :>

--
When in doubt, use brute force.

Haha! Az nem volt nehéz. :)

Voltak ilyenek bőven, amikor megjelentek az egyre durvább pentiumok. :)


suckIT szopás minden nap! MySQL 6.0: az Oracle első áldozata?

További részletek a The Register cikkében.

--
trey @ gépház

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. :)

Az Android mar ilyen.

401M linux-2.6.31

Nem kell ahhoz öt év.


suckIT szopás minden nap! MySQL 6.0: az Oracle első áldozata?

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.

Idézet:
és akár csak a plusz nyers erő is simán kompenzálja a szoftverekben rejlő akárhány százalékos lassulást.

Nem. Egyébként meg lásd amit itt meg itt írtam. :)

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

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.

Sőt, mekkora lenne, ha merevlemez sem kellene a gépbe, hanem rögtön az is a prociban lenne.
2 TB-os Intel quad core CPU. Na az tényleg forradalmi lenne.


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

Megint elterjednének a sok socketes rendszerek, hogy raid-ben is lehessen használni.

CPU-RAID, az tényleg nagyszerű lenne! Lassan elérné a PC-s technológia is a 20 évvel ezelőtti szintet. :)


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

-

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\

miért is? csak mer' nem vágom :( buta vagyok na :((

akkor minek magyarázzam

hogy ne maradjak buta :D

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...

A mikrokernel nem segít a bugok számát illetően.

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.

Szerintem most meg leszel lincselve, h ilyet mersz mondani... :)

---
pontscho / fresh!mindworkz

miert kellene bantani? azert mert ertelmetlen amit irt? hogy kell azt ertelmezni, hogy a linux kernel fejlesztoi keptelenek olyan kernelt irni, amely a _jelenlegi_ funkcionalitas mellett megorzi (jelenlegi) sebesseget es hatekonysagat is? ;)

> azert mert ertelmetlen amit irt?

prygme: "Mikrokernel segít a sebességben." Hahaha. De tényleg nem érdemes bántani szegényt, mert úgyse tanul belőle.

nyilván te tanultál operációs rendszerekről, kernelekről, ezért vagy ilyen biztos a dolgodban:)

> nyilván te tanultál operációs rendszerekről, kernelekről

Nyilván nem csak tanultam, hanem még hozzá is olvastam, el is gondolkodtam, és meg is értettem valamennyit.

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.

> Maga az rt kerdeskor sem olyan egyszeru,

Szerintem azt hiszi, hogy az rt azonos azzal hogy gyors :-)))

> akad pár ügyeletes inkvizítor aki a torkomnak ugrik

Én csak Pontscho hozzádszólását látom. Most leügyeletesinkvizítoroztad.

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 ! -

stallman bácsihoz járt hittan órára :)

Ha Stallmanhoz járt volna hittan órára, akkor nyilván a mikrokernelt erőltetné. Hint: GNU Hurd

--
trey @ gépház

lol, pont ide akartam biggyeszteni, de megeloztel :p

Szerintem meg leszarja a 20 éves vitát. Linus ennél azért pragmatikusabb.

Szerintem rosszul értelmezed.

--
trey @ gépház

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?!

Idézet:
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?" -=-

De itt az összes szoftverről beszél általánosan. Akkor nem kell aggódni, mindegy mit használunk, mind lassul :) Na majd ha lesz kvantumszámítógép!

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.

Igen. Szerintem egy normális kódoptimalizálással (fordítóval) 1,5-2 szeresére is lehetne gyorsítani a programok futását.

hatékonyabb algoritmusokkal meg főleg

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.

Hát abból amit én néztem tesztekből és fent is linkelték pl. (http://kernel-perf.sourceforge.net) egy tendencia olvasható ki, mégpedig az, hogy nincs tendencia. :D

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 ! ! !

De ezt már rég meg kellett volna oldani.
SURPRISE! Már rég így van. Miféle ősi distrót használsz te? Szerintem az a kivétel manapság, amelyik nem így működik.
---
Internet Memetikai Tanszék

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

Idézet:
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

"A Linuxban pont az a jó, hogy annak ellenére, hogy egyre kompatibilisabb..."

:-)))

Gondolom a hw-re gondolt, ami 100%-ig igaz. Pl. Próbálj meg telepíteni egy Ubuntu 9.04-et új Macbook5,2-re, majd ha nem sikerült könnyedén, akkor tedd meg ugyanezt az Ubuntu 9.10 alpha 6-tal. Rögtön megérted, hogy miről beszélt.

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?" -=-

Fájó szívvel mondom ezt - tudod, hogy nekem is itt figyel az A1200-es az asztalomon -, de nem az Amigák a mérvadóak manapság, hanem az, hogy az új vasakat mennyire támogatja a kernel. Ez van...

Pár hete jártam a Helsinki-i egyetemen (Campus Kumpula), ahol a gépeken Windows-t láttam futni, nem Linux-ot. Ezek szerint Linus sem próféta a saját hazájában.

Linus pár éve már Amerikában él, nem?

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

Logikai hibat velek felfedezni: az, hogy az ember nem lehet profeta a sajat hazajaban, attol meg nem biztos, hogy profeta lesz egyaltalan akarhol :)
Bill Gates viszont nagy valoszinuseggel foldonkivuli, a Windows reszesedeset latva...:)

De mióta hazament az Alpha Centaurira, azóta a Windowsnak is csökken a részesedése. Remélem nem kell menet közben újraindítani az űrhajót, mert a mentőkapszula a végén még ismét a Föld nevű bolygón landol. Az meg kinek hiányzik? :)

Steve Ballmernek. Varja vissza a tesot.

Inkább menne ő is utána! :)

És te is az ágy alatt tartod? :)

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.