Linux 2.6 vs GCC 2.95

Miért "szerencsére"? Nem kötekedésből kérdezem. Van olyan terület, ahol a gcc 2.95 nélkülözhetetlen/jobb mint a 3.x?

véleményem szerint meg haladni kell a korral, ezért nem értem pl. azt sem, hogy miért még mindig 386-osokra lefordított csomagokkal jön egy csomó disztrib

Ahogy David S. Miller irta, a gcc 2.95 meg mindig a leggyorsabb, es ez fontos sok embernek. A VAX fejlesztok szinten mergesek lesznek, mert nekik kellene a regi verzio.

Persze van erv a regi verziok eltavolitasa mellett is. Pl. el lehetne tavolitani a kodbol nehany #ifdef-et es workaround-ot

Talán mert sokan használják régi gépeken is?

Mint pl. én Slackware-t 486-on. Szomorú is lennék, ha Pat úgy döntene, hogy mostantól i686 és kész. Állítom, hogy legfeljebb 5%-ot gyorsulna tőle...

hát akkor te majd nem fogsz kernelt frissíteni ;]

Hát akkor te meg fogod, és szépen újraforgatod a dolgokat. (;

Mert meg az uj processzorok kozott is vannak olyanok amelyek az i386-ra forditott kodot optimalisabban futtatjak mint a 686-ost, mint pl. a Via C3. Meg akkor is ha ez senkit nem erdekel :)

Nem mindenüt áll maximum 3 PC-ből a számítógéppark. Vannak géptermek ahol 50 80 gép is van. X terminálként, vagy Citix Metaframes "windows terminálként" jól használhatóak és nincs szükség őj gépre, mert

80 gép lecserélése sokba kerül,

80 db P4 jelentősen megnövelné a havi villanyszámlát,

ráadásul nagyteljesítményű ipari klímára kellene upgradelni a gépterem hűtését, hogy megfeleljen a "modern cool PC-knek" álcázott hálózati vasalók hődis*****ációs igényeinek :-)

Szóval maradjanak csak a 386-os csomagok.

sz írta:
> Hát akkor te meg fogod, és szépen újraforgatod a dolgokat. (;
Vagy választasz a >300 disztribből olyat, ami neked tetszik (tehát pl.
eleve i87986-ra van fordítva). ;)

disszipációs? lol

Most bontottunk szet egy nagy adag P1-es gepet.

TX-esek, VIA-sok, ATX, amit akartok.

Iszonyu allapotban voltak, igy azt hiszem a problema hamarosan megoldodik, mert az utolso 468-os is ki fog pusztulni...

Ha nem a gepek, akkor a tapegysegek kondijai fognak kiszaradni.

Mar nagyon varom :-)

Varni is fox abban a hivatalban ahol 486ost hasznalnak es pont mikor sorra kerulsz szal el a tap :D

Itt ha jól értem a 2.6-os kernelfáról van szó.

Most őszintén: létezik olyan elvetemült ember aki 386-osra 2.2-nél újabb kernelt rakna???

Ezt most nem igazan ertem ... Szerintem 2.6 megjelenesnel az egyik dolog pont az volt hogy "scale down too", tehat kisebb rendszerek jobb tamogatasa is, pl nezd meg a kernel config-ban e lehetosegeket ahol "butitani" lehet a dolgokon kisebb eroforrasu rendszerek szamara. Vagy milyen erveid vannak a 2.2 vs 2.6 386-oson temaban a 2.6 ellen?

Nekem nincsenek erveim, viszont erdekes, hogy minden linuxos embedded eszkozben 2.2 es 2.4-es kernelt latok es sehol sincs 2.6...

Hmm, lehet, nem sok embedded device-t lattam mostanaban az az igazsag, ezert is kerdeztem, mert tudtommal pont abban (is) hozott ujdonsagot a 2.6 hogy embedded cuccok jobb tamogatasa, eleve pl a no-mmu esetet ha nezzuk (bar ez nem 386-ossal kapcsolatos mar).

Apróságok. Pl 64 bites file pointer, default időzítés gyorsabb procikhoz, bonyolultabb felépítés ami szintén gyorsabb processzort feltételez, nagyobb méret. Lehet használni természetesen, de szerentem nem gazdaságos. Lehet ezt a teljesítményt másra is pocsékolni.

Az nem erv hogy a "default ...", mivel az atallithato, mintahogy a neve is mondja :) Foleg mivel egy desktop pc-re meg elmegy hogy valaki aki nem akar pepecselni az a disztrib altal adott kernelt hasznalja, de egy embdev. eseten imho nem szokas, ott azert nem az okozza a problemat hogy a default micsoda. Nekem - mint irtam - csak az tunt fel, hogy a 2.6 szeria mar eleve lehetoseget nyujt egy csomo olyan dologra, ami direkt az ilyen rendszerekbe kell, es regebben nem volt (foleg nem a 2.2 idejen), ilyen pl az ucLinux integracio, kulonbozo subsystem-ek "kihagyasnak" lehetosege stb. Tehat en pont forditva latom: ezekre ponthogy nem nyujtott lehetoseget a 2.2 de a 2.6 igen. Persze, lehet, hogy azt a megoldast valasztottak, hogy valami sajat agyonpatch-elt cuccot hasznalt a legtobb gyarto regebben, az persze nyilvan nem lehetetlen, de altalanossagban nehez errol beszelni

In article <42.49443@c.hup.hu>, LGB wrote:
> dolgokon kisebb eroforrasu rendszerek szamara. Vagy milyen erveid vannak a
> 2.2 vs 2.6 386-oson temaban a 2.6 ellen?

Egyebkent a VAX port is 2.6-ot hasznal, marpedig az altalanosan hozzaferheto
VAX-ok igencsak lassu joszagok.

Az általad említett fícsörök szerintem nem 386-os kopjúterszauruszra készültek, hanem modern beágyazott processzorokhoz, amiknek a teljesítménye legalább egy nagyságrenddel, ha nem többel meghaladja a leggyorsabb 386-osét. Ergo ezeket nem zavarja, ha kiszedik a 386-os miatt bent lévő kódszemetet.

A 'default' álíthatósága meg a legújabb kernelbe került vissza, mert sokaknak sírt a szája. Ki tudja milyen problémákat fog ez még okozni.

Pontosan forditva,hogy olyan dolgokra, amik nem felteltenul veszik fel a versenyt egy 386-os teljesitmenyevel sem! Pl a no mmu az tipikusan olyan feature ami nyilvan nem 386-osnak kell, abban ugyanis van mmu. Tehat pont arrol van szo, hogy a 2.6-os kernelkben olyan feature van ami lehetove teszi hogy olyan hw-n hasznaljuk amin elotte nem futott Linux (pl mmu hianya miatt). tehat a 2.6-os megjelenese pont az, hogy lehetove tesz olyan dolgokon valo futast ami 2.6 elott nem volt lehetseges, mert egyszeruen "nem volt eleg" neki a hw. Az persze mas kerdes, hogy az ucLinux pl nyilvan volt elotte is, csak "szeparalt" projectkent, tehat ha egy ceg agyonfejlesztett, agyonpatchelt stb egy rakat dolgot, osszehozhatta 2.6 nelkul is a dolgot, nyilvan.

A nem elég a hw sok mindent jelenthet. Szvsz ezek a cuccok nyers processing power-ből simán meg tudják oldani ezeket a feature-ket. Az, hogy egy adott területen nem kell mmu, mert minek, nem jelenti azt, hogy az a proci lassabb mint a 386. Ráadásul a 386-ban az MMU-volt a legszerencsétlenebb rész, a pentimra sikerült végre elfogadhatóvá tenni a teljesítményét.

Szerintem sokkal elegánsabb megoldás lenne a gcc-t valahogy pluginezhetővé tenni, hogy benne lehessen a régi procik támogatása is, mint programokat több c dialektusban megírni. Ez hosszú távon sokkal nagyobb káoszt fog okozni.

Na, ez azert nem olyan egyszeru mint hiszed :) A legtobb beagyazott rendszerben levo CPU-ban pont azert nincs mmu se, mert fontosabb az egyszeruseg es a fogyasztas, mint az hogy milyen full featured a cpu, vagy hogy van-e benne mmu, tehat az ilyen rendszerkben pontosan az, hogy mai szemmel nezve igen lassu cpu-kat hasznalnak, legalabbis ha a desktop rendszer cpu-khoz hasonlitjuk, dehat ez termeszetes is, hiszen nyilvan pl egy mobiltelefon eseten nem kell 2GHz-es orajel meg hasonlok. En errol beszelek, lehet hogy nem ugyanazt ertjuk beagyazott rendszeren.

Masreszt a "nyers processing power" nem segit semmit, mert ha nincs hw vedelem, mint amit pl a lapozas lehetove tesz, akkor nem lehet igazan biztonsagos OS-t se futtatni rajta (nincs memoriavedelem). Ez persze nem mindenhol olyan nagy problema mint egy multiuser server eseten lenne, termeszetesen :)

LGB wrote:
> Ezt most nem igazan ertem ... Szerintem 2.6 megjelenesnel az egyik dolog
> pont az volt hogy "scale down too", tehat kisebb rendszerek jobb tamogatasa
> is, pl nezd meg a kernel config-ban e lehetosegeket ahol "butitani" lehet a
> dolgokon kisebb eroforrasu rendszerek szamara. Vagy milyen erveid vannak a
> 2.2 vs 2.6 386-oson temaban a 2.6 ellen?
Nem lehet annyi memóriát beletenni egyetlen 386-os alaplapba sem,
amennyivel egyáltalán elindulna a kernel? :)))

Igazából azt hiszem, hogy ha valami nem egyszerű, akkor nagyon elkefélés gyanús.

Szerintem meg nem lassúak azok a moltelefon cpu-k, hiszen nem okoz nekik gondot egy mp3 lejátszás, vagy egy java virtual machine futtatása.

Ha meg egyéb ipari alkalmazásról beszélünk, akkor nem biztos hogy ott linux-al kéne bonyolítani az életet, két hőmérő, meg egy villanymotor összehangolására. Persze lehet mazoizálni, de nem sok értelme van, főleg nem emiatt hagyni hogy szétmocskolódjon a kernel forráskódja.