Názory k článku Co můžete čekat od Fishera?

Nevíte někdo, jak to bude s počešťováním (myslím na straně RH) ?

Sice se tu připravuje počeštěná verze, ale očekával bych, že některé z těchto principů budou postupně zahrnuty do distribuce, aby se práce (na jakékoliv) lokalizaci snižovala.

Jaký na to mají názor naši lokalizátoři ? Je podle vás lepší protlačit změny přímo do originální distribuce nebo je lepší úprava v domácím prostředí, aby "to bylo udělané pořádně" ?


Každopádně je RH moje _velmi_ oblíbená distribuce a děkuji tímto autorům jak původní tak i české verze.

RH nemá jen 2 CD. Dvě jsou instalační (tj. instalační program s nimi pracuje), pak je Developer archive Module (Perl, Python, Zope), Library Workstation (Powerotools), CD se zdrojovými kódy a CD s dokumentací. Ke komerčnímu balíku jsou ještě minimálně 2 CD s komerčními aplikacemi třetích stran.

Lokalizace probíhá přesně způsobem, který popisujete. Některé věci však do mezinárodní verze nemůžeme dostat (jsou třeba moc specifické). Nehodlám si samozřejmě přidělávat práci, takže se snažím co nejvíce věcí dostat přímo do US verze :-)

RH nemá jen 2 CD. Dvě jsou instalační (tj. instalační program s nimi pracuje), pak jsou Powertools, Developer archive Module, Library Workstation, CD se zdrojovými kódy a CD s dokumentací. Ke komerčnímu balíku jsou ještě minimálně 2 CD s komerčními aplikacemi.

Lokalizace probíhá přesně způsobem, který popisujete. Některé věci však do mezinárodní verze nemůžeme dostat (jsou třeba moc specifické). Nehodlám si přidělávat práci :-)

Podla toho, co som sa docital na redhat.com pokracuje aj verzia
7.1 vo velmi nestastnom napade zaclenit do distribucie
gcc 2.9.6 ako hlavny kompilator + vlastne redhatacke kniznice.
Podla toho, co som pocul a cital potom mnoho programov (vratane kernelu) nie je mozne korektne skompilovat, resp. po kompilacii (vdaka vlastnym knizniciam) nie je mozne binarky spustit pod inymi distribuciami. Hodla teda naozaj redhat pokracovat v tejto brain-damaged strategii (ako to nazval i Linus Torvalds), alebo sa konecne trochu umudril? Pretoze ak je to takto, tak pri najblizsom upgrade si uz urcite nebudem instalovat redhat a myslim, ze nas bude viac ;(

Iba pre precizosov - Linus pouzil vyraz "stupid" a nie "brain-damage" ( viac napr. na http://www.geek.com/news/geeknews/2000dec/gee20001218003385.htm )

Pravda, Linus se dokaze nastvat:-) a v RH 7.0 je skutecne gcc 2.96.
Nicmene posleze ho to ponekud preslo a vyzadal si patche (viz nekde kernel traffic, mozna na RedHat a mozna i na strankach projektu gcc). Kazdopadne RedHati gcc v prosinci 2000 opravili (glibc jeste jednou letos v lednu) a zatim jsem zadne potize nemel. Zkousel jsem kompilovat jak kernel, tak aplikace do X (napriklad) a jede to. Faktem je, ze pro 2.4.0 doporucuji autori gcc 2.91 nebo 2.95 s tim, ze nejstabilnejsi kod "vyrabi" gcc 2.91 a gcc 2.95 testovali mene.
Kazdopadne, od gcc 2.7.2 Linus chce upustit uplne (viz. manualy k 2.4.0)

Nejméně problematický kompilátor mezi všemi, které jsou nyní k dispozici, je právě GCC 2.96 a nové knihovny. Ostatní kompilátory nelze použít pro kopilaci nového jádra, nefungují na jiných platformách, nesnášejí se s nejnovějšími knihovnami (např. Qt), jsou zpětne nekompatibilní a nejsou kompatibilní ani dopředu. Vyžadují výrobu "přizpůsobovacích" patchů, což je krajně neproduktivní činnost. To, co přinese GCC 3.0 je z velké části už ve verzi 2.96, která je spolu s novými knihovnami bez problémů využita právě v RH 7.0 a celá distribuce prakticky bez problémů funguje (až na nějaké drobnosti, které jsou už dávno opraveny). RH testovali 2.96 dlouho před tím, než byl oficiálně představen v nové distribuci a o jeho kvalitě svědčí i to, že se běžně používá pro sestavení jádra 2.4.x.

Žehrat na nekompatibilitu binárek je absurdní, protože systém je vystaven na nových knihovnách Glibc 2.2 (a to žádná distribuce v současné době nemá, ale bude dříve nebo později mít). Binární kompatibilita s nadcházející verzí GCC 3.0 (kompilátor je těsně svázán s knihovnami) bude zachována na úrovni C, úroveň C++ nemá ještě standard, takže všechny teorie okolo kompatibility jsou jen spekulace (zbytečné).

Jednoduše řečeno - nadávat na kompilátor v RH 7.x nemá žádný racionální základ a jeho použití bylo velmi přínosné (RH na něm pracovali velmi dlouho a pečlivě) a všichni, kteří zaspali dobu budou v nejbližší době muset na něj (resp. jeho následovníky) přejít (včetně knihoven). Udržování starých bastardů nemá žádný význam a je jen velmi pochybnou rétorickou rozcvičkou na podporu marketingu (resp. popularity ostatních distribucí), na kterou doplatí jen uživatelé. Konečné slovo při rozhodování o použití GCC 2.96 v RH 7.0 měli vývojáři, kteří jej pro následující binárně kompatibilní cyklus distribuce (verze 7.x na cca 1,5 roku) označili poprávu jako nejsnáze podporovatelný (a užitečný). Jiné varianty by byly horší (např to, co produkuje kompilátor v SuSE je binárně nekompatibilní s RH 6.x a je to jen opětovný mezikrok, který nikomu neprospěje a zavedl by jen další binárně nekopatibilní balíčky do stavající řady distribucí RH - z toho vyplývá, že by uživatelé byli velmi brzi po uvedení distribuce 7.0 nuceni upgradovat na nějakou 8.x a takto se mohou v klidu těšit na téměř bezproblémové updaty na další minor verzi 7.1 a další se zachváním 100% binární kompatibility v následujících krocích po následující relativně dlouhou dobu - čili budou ušetřeni trablů, které vždy přináší (zde evidentně zbytečný) přechod na binárně nekompatibilní novou verzi).

Zabývat se Linusovými výroky nemá valnou váhu, protože jádro je cca jedna dvoutisícina distribucí a proto kompilátor vhodný pro jádro nemůže být brán jako měřítko pro potřeby ostatních programů v distribuci (navíc GCC 2.96 je pro nová jádra naprosto v pohodě a pro řadu 2.2.x je v distribuci speciální ověřený kompilátor kgcc - tak to dělají i ostatní distribuce).

Víte, když do toho nevidíte, radši si soudy ponechte mezi čtyři oči. Už mě unavuje vysvětlovat do zblbnutí kecy, které se nezakládají na znalosti reálných faktů (tj. souvislostí, výhod, nevýhod, trochy citu pro budoucí směr vývoje a reálné zhodnocení přínosu tolik proklamovaných kroků, které evidentně nejsou lepší).

Omlouvám se, ale dost mě mrzí tento přístup a jsem z něho dost rozmrzelý.

Vydrzte! Kdyby bylo o tomto vic informaci, treba zde na rootu, nebo na www.linux.cz, mozna by byl zivot snadnejsi, ne?

Tak tohle je na me trosku silny kafe. Pro informaci:
1) gcc-2.96 nebyl dlouho a peclive testovan -- je to proste vzato z HEAD vetve CVS gcc, bez vedomi autoru gcc
2) autori gcc se od tohoto paskvilu distancovali a durazne doporucuji okamzity downgrade na gcc-2.95.2
3) binarni kompatibilita na urovni C je samozrejmosti (je to ekvivalentni kompatibilite ELF formatu), nevim proc o ni mluvite
4) jako vyvojar muzu potvrdit, ze s gcc-2.96 *jsou* problemy. Napriklad ma problemy s nekterymi zcela legalni pouzitimi #pragma interface/implementation
5) kdyz je gcc-2.96 tak bezproblemove, tak proc RH7 obsahuje "kgcc"? Neni pravda, ze je tam proto, ze je to overeny kompilator, ale protoze jadro neslo 2.96kou zkompilovat (jinymi slovy, RedHat _vedel_, ze kompilator je zavsiveny). A ostatni distribuce to _nedelaji_.
6) "udrzovani starych bastardu"?! Asi jste to moc nepochopil -- neni spatne, ze RH pouzil novy kompilator, spatne je, ze pouzil hrube nestabilni verzi. Az vyjde gcc 3, tak se da cekat masivni prechod na novy kompilator.

Nechcel by som sa tu stale ohanat Linusom ;), ale chcete tvrdit, ze
aj on `do toho nevidi`? A nie, ja si nemyslim, ze by jeho vyroky a nazory
nebolo treba brat do uvahy a ze nemaju ziadnu vacsiu vahu. Naopak, Linusove nazory boli (z mojej skusenosti) vzdy najnestrannejsie a najpragmatickejsie.
A btw, bolestivy prechod z 2.x kopilatora na 3.x kompilator bol nevyhnutny tak ci tak - tak preco redhat nepockal, az bude na tento krok naozaj spravny cas a vydal verziu s nepodporovanou a problemovou verziou hned teraz? (resp. pred par mesiacmi)

>> Víte, když do toho nevidíte, radši si soudy ponechte mezi čtyři oči. Už mě unavuje vysvětlovat do zblbnutí kecy, které se nezakládají na znalosti reálných faktů (tj. souvislostí, výhod, nevýhod, trochy citu pro budoucí směr vývoje a reálné zhodnocení přínosu tolik proklamovaných kroků, které evidentně nejsou lepší).

Omlouvám se, ale dost mě mrzí tento přístup a jsem z něho dost rozmrzelý.

Víte, únavné je právě to, že i když se snažím něco vysvětlit, vždy se najde někdo, kdo si donekonečna melduje svou (jako kdyby se nic neřeklo). Pokusím se opět vyvrátit všechny zde vyskytnuvší se připomínky.

GCC 2.96 byl dlouho a pečlivě testován právě u RH. K současným programům musely být dodány úpravy syntaxe, použití maker, hlavičkových souborů a podobně. Stejné opravy byly dodělány do knihoven i do kompilátoru. Při vydání verze 7.0 bylo u RH v balíčku s aktuální CVS verzí GCC navíc přes 80 patchů (a prakticky všechny byly také přijaty do CVS). Team okolo GCC o použití zdrových kódů z CVS věděl (zejména proto, že někteří vývojáři z RH jsou zároveň vývojáři GCC). Verzi si nevymysleli, byla v aktuálním CVS. V poslední době je běžné, že se zdrojáky (nebo části) berou z CVS (např. KDE, XFree86, atd) a není na tom nic špatného (prostě se styl vývoje a uvolňování kódu se za posledních 10 let dost změnil - a to k lepšímu zejména díky CVS - tak proč by se tedy neměl tento mechanismus využívat).

Autoři GCC se distancovali od podpory (a řekněme záruky). Veškerá podpora je na bedrech RH, který ji samozřejmě akceptoval (GCC 2.96 bude provázet distribuci celou dobu existence řady 7.x a podpora samozřejmě funguje). Doporučení o použití staršího kompilátoru se vztahovalo spíše na odkaz na dobře otestovanou verzi (bohužel pro potřebu nové Glibc, platforem Sparc a Alpha naprosto nevyhovující).

Binarní kompatibilita na úrovni C není ekvivalent ELFu. To by všechny binárky ze všech systémů používajících ELF a také binárky pro Libc 5 byly navzájem kompatibilní (což je nesmysl). Takže budete spíš muset opravit svůj (nebo cizí) zdrojový kód.

Je otázka, co myslíte pojmem "zcela legální" použití #pragma. Pokud je to chyba, bude opravena. Spíše však půjde o věc, která ani v následujících kompilátorech nebude podporována (výklady norem syntaxe nejsou jednoznačné a GCC 3.x se snaží přiblížit jejich všeobecně přijatelné podobě, přičemž jde zejména o dosažení maximální přenositelnosti).

RH 7.0 obsahuje kgcc proto, že to je dlouhodobě prověřený kompilátor a zdrojové kódy jádra jsou mu ušité na míru. Použité jádro 2.2.16 (obecně jakékoliv jádro 2.2.x) není upraveno pro syntaktické požadavky vycházející z přiblížení k normám. Je to totiž zbytečná práce (a navíc by mohla zavléct do kódu zbytečné chyby). Novému kompilátoru je naopak přizpůsobena řada 2.4.x, která v době vydání verze RH 7.0 nebyla ve finální podobě. Použití speciálního (a prověřeného) kompilátoru není v distribucích vyjímkou a v RH nebyla tato varianta využita jako první. Proto nemá smysl z toho něco dedukovat. To, že se 2.96 používá pro kompilaci jádra 2.4.x v připravované verzi RH 7.1 svědčí dále o jeho kvalitách.

GCC 2.96 je s použitými patchi stabilní. Nedovedu si představit lepší test stability, než je kompilace distribuce obsahující více jak 1500 balíčků, které jsou navíc *funkční*. Pokud se chcete ohradit tím, že se nějaké nedostatky našly (spíše v Glibc, než v kompilátoru), uvědomte si statistický význam objevených chyb (a navíc jejich reálný vliv na funkčnost programů). Řekl bych, že stejné nebo větší procento problémů najdete i ve starších kompilátorech a starší Glibc. Takže to zase není argument.

Také bych chtěl vidět masiví přechod na GCC 3.0, zejména jak píšete: "až bude". Možná nepamatujete přechod na Glibc a tehdy proklamované výkřiky, které jsou velmi podobné zde prezentovaným názorům na nový kompilátor. Uvědomte si, že kdyby RH nechtěli nové GCC mít, nebylo by ani za rok. Současné zpoždění verze 3.0 je způsobeno zejména neexistencí normy API a ABI pro C++, část pro C je již finalizovaná a konečná (přesně podle oficiálního prohlášení GCC teamu). Kdy bude a jestli vůbec bude je ve hvězdách a za současného stavu věcí bylo nejlepším možným východiskem právě použití toho, co v RH 7.0 najdete. Pokud by tomu tak nebylo, bylo by to mínus zejména pro uživatele, což jsem už vysvětlil minule. Také si povšiměte varchalatosti zde použité argumentace, kdy se za modlu vydává verze 3.0 a zároveň je požadováno "rozsáhlé testování". Jedno bez druhého nemůže existovat. Pokud bych to měl uvést do logického souladu, musel bych tvrdit, že neověříte-li kompilátor na distribuci, nelze vydat finální verzi. Pokud bych připustil, že se 3.0 nebude důkladně testovat a uvěříme vývojářům, pak bychom byli ve stavu jako dnes s jádrem 2.4.1, které je v podstatě nepoužitelné. Ne že by za to mohli vývojáři, ale prostě nelze na stole vývojáře nasimulovat všechny varianty podmínek jako v reálném nasazení. Musíme počítat s tím, že teprve široké používání odhalí skryté chyby v kódu (a nelze předpokládat obrácený postup, protože vývojářů je méně, než uživatelů a prostě nelze vše vyzkoušet předem). Z toho vyplývá, že modla označení jakéhkoliv produktu verzí 3.0, 4.0 (nebo jakkoliv jinak kulatým číslem) je falešná (a nemá reálnou vypovídající hodnotu, i když vývojář bude polobůh). Objektivní je pouze prokazatelně ověřené delší používání tohoto produktu (což třeba RH prokázal, protože distribuce je funkční) a proklamované "čekání na GCC 3.0" je nesmysl, protože byste měl tvrdit že si máme počkat tak půl roku až rok po vydání 3.0. Jenže kdo tedy bude testovat? Dost to připomíná válku a to, co bylo dřív - zda vejce nebo slepice. Takže opět - je to logický nesmysl. Kompilátor je funkční, vše se před tím testovalo a čtyřměsíční provozování distribuce potvrdilo, že se testovalo dobře (oprav bylo minimum - ale opravy jsou vždy, i když zrovna není nový kompilátor).

Všiměte si prosím, že jsem se v tomto příspěvku opakoval. Vše již bylo řečeno a přesto se zde vyskytly reakce, které to jaksi "ignorovaly". Ty samé argumenty jsem už několikrát použil v naší linuxové konferenci a na LinuxWorldu (myslím, že i zde na Rootovi). To je právě absurdní. A ne to, že bysem o tom nechtěl psát, jak mi zde kdosi podsunul.

Taky prosím rozlišujte mezi jádrem a ostatními programy. Jádro je speciální aplikace napsaná na velmi nízké úrovni a je velmi citlivá na jakékoliv jemné nuance kompilátoru i samotného kódu. Protože se chyby v jádře obtížně hledají (na rozdíl od aplikací, kde je to snazší), jsou chyby způsobené kompilátorem ještě více zákeřné a ještě obtízněji lokalizovatelné. Právě proto se na jádro obvykle používá jen "doporučený" kompilátor a ne jakýkoliv (zejména ne nový). Linusovy výbuchy jsou v konferenci linux-kernel v tomto ohledu určitým koloritem a je je nutné chápat v tomto kontextu (tj. zejména ve vztahu k jádru). Jakékoliv další vývody (tj. když není kompilátor vhodný pro řadu 2.2.x, je to blbý kompilátor) jsou NAPROSTO zcestné a z výše uvedených důvodů naprosto logicky nesprávné.

O nestrannosti Linuse bychom si také zde mohli dlouho povídat (sledujete třeba konferenci linux-kernel alespoň pět let?). Naštěstí pro nás je to člověk inteligentní a dokáže přijmout protiargument nebo odlišný názor (i když to někdy dost trvá). Je to vidět i v jeho zde již zmíněném odvolání jeho příkrých slov samotným. To je další důvod, proč jakákoliv kontrukce o postoji Linuse proti kompilátoru GCC 2.96 je v těchto intencích zcestná (o rozdílu s aplikacemi jsem již psal).

Doufám, že jsem to vše trochu prosvětlil a zejména doufám, že když budu muset něco vysvětlovat, nebudu se již muset opakovat :-)

No, takze asi nebudem sam, kto vam dakuje za skutocne vycerpavajucu odpoved (v dobrom slova zmysle ;)

Predchadzajuce diskusie na linuxworld.cz a rootovi som bohuzial necital, co bolo asi dovodom, preco som celu tuto redundantnu diskusiu vyvolal (diskusie na geek.com a podobne bohuzial ziadne hlbkove rozbory neobsahovali ;)

Takze este raz vam dakujem za vas cas a sypem si popol na hlavu... (bez ironie ;)