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.
- A hozzászóláshoz be kell jelentkezni
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 ?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 -
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
nekem is ez az ábra ugrott be
- A hozzászóláshoz be kell jelentkezni
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 --
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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! :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
ezek szerint megis csak sz*r van a palacsintaban linuxeknal
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
Na jó, de te elolvastad a cikket. :)
- A hozzászóláshoz be kell jelentkezni
Igen, az szokott számítani ;)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A tobbseg elvan nelkule ... :)
- A hozzászóláshoz be kell jelentkezni
Azert ha mar ezt is definialni kell, akkor definialjuk a definiald szot is.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem olvastam a cikket, de az Intelnek van ilyenje publikusan:
http://kernel-perf.sourceforge.net/results.machine_id=35&options=.html
- A hozzászóláshoz be kell jelentkezni
koszi, majd vetek ra egy pillantast. vagy tobbet ;)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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 hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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)).
- A hozzászóláshoz be kell jelentkezni
Mindegy.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Haladjon Ön is a korral, süssön Váncza sütőporral:)
- A hozzászóláshoz be kell jelentkezni
és kiadásonként egy átlagos gép mennyivel gyorsabb?
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
a hardverek is egyre bonyolultabbak ergo azok is lassulnak :)
- A hozzászóláshoz be kell jelentkezni
Tehát érdemes az összes 5500-as sorozatú Xeon-t kidobni, és Pentium Pro-kat venni helyettük ezek szerint. :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
:D
___________________________________________________________________________
MOS Technology 6510 @ 0.985 Mhz + 64 KByte (32kB RAM + 32 kB ROM)
- A hozzászóláshoz be kell jelentkezni
:D
___________________________________________________________________________
MOS Technology 6510 @ 0.985 Mhz + 64 KByte (32kB RAM + 32 kB ROM)
- A hozzászóláshoz be kell jelentkezni
"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...
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Nekem is pont ez jutott eszembe róla. :)
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Most már hasonlít a TUX-ra!
- A hozzászóláshoz be kell jelentkezni
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
_____________
烏邦土 - 乾屎橛
- A hozzászóláshoz be kell jelentkezni
Ha ide jönne tuti az államadósságot álmodná:))
- A hozzászóláshoz be kell jelentkezni
hát, ha ő maga alapból nem is, de valami anyagot biztos kapna, hogy azt álmodja, amit sugallnak neki. :)
_____________
烏邦土 - 乾屎橛
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"Ahhoz kepest, hogy legutobb mikor azt talaltam mondani, hogy a Linux kiadasrol kiadasra egyre lassabb, majdnem meglincseltek,"
Linket!!!111 Ahahahah :)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
Károly, látom a pascalos beidegződéseket azóta sem tudtad levetkőzni (->Wirth) ;)
--
Aries
http://pikop.hu
- A hozzászóláshoz be kell jelentkezni
Irigykedj csak. :P
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
Linux egy kernel, FYI!
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
jah, pl win7 mennyivel gyorsabb, mint vista!
bar ott volt honnan gyorsulni :>
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
Haha! Az nem volt nehéz. :)
- A hozzászóláshoz be kell jelentkezni
Voltak ilyenek bőven, amikor megjelentek az egyre durvább pentiumok. :)
suckIT szopás minden nap! MySQL 6.0: az Oracle első áldozata?
- A hozzászóláshoz be kell jelentkezni
További részletek a The Register cikkében.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
Az Android mar ilyen.
- A hozzászóláshoz be kell jelentkezni
401M linux-2.6.31
Nem kell ahhoz öt év.
suckIT szopás minden nap! MySQL 6.0: az Oracle első áldozata?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
é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?" -=-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Megint elterjednének a sok socketes rendszerek, hogy raid-ben is lehessen használni.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
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\
- A hozzászóláshoz be kell jelentkezni
miért is? csak mer' nem vágom :( buta vagyok na :((
- A hozzászóláshoz be kell jelentkezni
akkor minek magyarázzam
- A hozzászóláshoz be kell jelentkezni
hogy ne maradjak buta :D
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A mikrokernel nem segít a bugok számát illetően.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Szerintem most meg leszel lincselve, h ilyet mersz mondani... :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
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? ;)
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
nyilván te tanultál operációs rendszerekről, kernelekről, ezért vagy ilyen biztos a dolgodban:)
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
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;)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> Maga az rt kerdeskor sem olyan egyszeru,
Szerintem azt hiszi, hogy az rt azonos azzal hogy gyors :-)))
- A hozzászóláshoz be kell jelentkezni
> akad pár ügyeletes inkvizítor aki a torkomnak ugrik
Én csak Pontscho hozzádszólását látom. Most leügyeletesinkvizítoroztad.
- A hozzászóláshoz be kell jelentkezni
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 ! -
- A hozzászóláshoz be kell jelentkezni
stallman bácsihoz járt hittan órára :)
- A hozzászóláshoz be kell jelentkezni
Ha Stallmanhoz járt volna hittan órára, akkor nyilván a mikrokernelt erőltetné. Hint: GNU Hurd
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
lol, pont ide akartam biggyeszteni, de megeloztel :p
- A hozzászóláshoz be kell jelentkezni
Szerintem meg leszarja a 20 éves vitát. Linus ennél azért pragmatikusabb.
- A hozzászóláshoz be kell jelentkezni
Szerintem rosszul értelmezed.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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?!
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
hatékonyabb algoritmusokkal meg főleg
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 ! ! !
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
" Torvalds szerint a Linux "dagadt és hatalmas" "
- De legalább nem pici és nem puha - szerintem :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"A Linuxban pont az a jó, hogy annak ellenére, hogy egyre kompatibilisabb..."
:-)))
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Linus pár éve már Amerikában él, nem?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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...:)
- A hozzászóláshoz be kell jelentkezni
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? :)
- A hozzászóláshoz be kell jelentkezni
Steve Ballmernek. Varja vissza a tesot.
- A hozzászóláshoz be kell jelentkezni
Inkább menne ő is utána! :)
- A hozzászóláshoz be kell jelentkezni
És te is az ágy alatt tartod? :)
- A hozzászóláshoz be kell jelentkezni
Ha vkit meg erdekelne esetleg az eredeti tema, a Linux Magazine foglalkozik vele, de a cikk nem annyira jo, igy nem linkelem lol
- A hozzászóláshoz be kell jelentkezni
Allitolag sok beagyazott rendszer meg a Linux 2.2 es 2.4 valtozatait hasznalja reszben emiatt.
- A hozzászóláshoz be kell jelentkezni