rh 7.0, gcc a problemy

[Milan Kerslager]

On Thu, 4 Jan 2001, Ing. Pavel PaJaSoft Janousek wrote:

> 	Pruzkum? Pokud je to v danem programovacim jazyce povolena konstrukce
> (s implementacne nezavislym vysledkem (nejlepe definovanym)), je to opet
> problem kompilatoru. Pokud je to implementacne zavisly vysledek, nema v

Pruzkum proto, aby se vedelo, kde je problem. Neznam nikoho, kdo od boku
streli bez premysleni a hledani v dokumentaci, co je vlastne spravne.

> 	Zajimalo by mne, proc se jadro tak svazalo zrovna s GCC, neni prece
> tajemstvim, ze firemni kompilatory Intelu (nejen pro I-64, ale napr.
> Pentium a vyssi) jsou o dost optimalnejsi nez jakekoli i komercni
> prekladace... jenze tyto Intelovske kompilatory nejsou bezne rozsirene a
> bezne je vyvojari nepouzivaji (dodnes nevim proc..:-() a radsi pouziji
> zprasene volby a patche napr. do VC++ aby meli 'udajne' optimalizovany
> kod pro UniCPU Celeron apod.

No nevim. A jsou zadarmo? Josu dostupne? A bezi ten kompilator kdekoliv? A
cti vubec poradne normu?

> 	Je hezke, ze Intel spolupracuje s vyvojari Linuxu na jadre pro I-64,
> ale proc? Protoze se ho snazi prosadit na trhu (resp. zacina
> marketingova rez), kdyby jadro bylo skutecne psano tak, jak by melo
> vypadat (a jak IMHO jeste rada 1.2. vypadala), takova podpora ze strany
> Intelu by nebyla nutna a kernel by po upravach a doplneni sekce

No, jenze bysme meli jadro, ktere toho zrovna moc neumi....

> 	Takze z toho celeho vychazi, ze problem je zejmena v GCC (pry nejlepsi
> soucasny kompilator - to je ftip, ze?) a v kernelu, ktery se k nemu
> uplnul a ted se mu to velmi vymstiva...

Uprava pro jine kompilatory je mozna, ale to je taky nekdo musi pouzivat a
pak se to musi testovat. Pokud bude kompilator delat chyby, tak to je na
odstreleni....

> 	Ono cele Open source zacina vypadat podivne... podivame-li se na
> vehlasne projekty (vim, nekde se zacit musi, ale proc se sakra nepouci z
> chyb!?) je to k placi... Nekde jsem cetl myslenku, ze Linux a vse okolo
> tohoto boomu je hezke, je mozna moderni, ale stavi na starych (byt
> odzkousenych) principech. To je pravda, bohuzel zacina si tim velmi

Myslite Plan9 ??? Hmm, asi by to bylo hezke, ale zatim se to moc
neprosadilo...

> jen na na x86 paltforme? Prislo PCI2.0 a hle mame tu novy interface (tim
> padem minimalne nutnost prepsat vsechny PCI sitove ovladace), USB taky
> neni vykrik posledniho roku a v oficialnim jadre jeste neni, sitova cast
> pokud se nemylim se kompletne prepisuje po ctvrte, o jinych perifernich
> zarizenich (nemyslim proprietalni reseni, ale treba stredni tridu (na
> hi-end bych Linux nedal ani omylem)) radsi nemluve...

No nevim. Vsechno jde napsat lepe nebo s ohledem na novinky. Co IPv6? Taky
se to pak musi prepsat... ovladace nemusi vyhovovat novym potrebam (SMP,
interrupt versus pooling rizeni, ....)

> 	Byl jsem a jsem velky fanda Linuxu, ale to co zacina zejmena Red Hat,
> Kernel a Linus predvadet v poslednich 2 letech je skoro k nevire. IBM se
> vycital prosustrovany rok v OS/2 oproti Windows95. Jaky mel Linux naskok
> oproti WinNT (odmyslime-li GUI, myslim po serverove strance) jeste v
> roce 1997 a jaky ma nyni? Neprosustrovava nyni Linux jako OS daleko
> vice?

Eee? Aplikace a jadro jsou naprosto nezavisle svety. O co konkretne tedy
jde?

-- 
                        Milan Kerslager
                        E-mail: milan.kerslager na spsselib.hiedu.cz
                        WWW:    http://www.spsselib.hiedu.cz/~kerslage/