On Mon, 2002-01-28 at 00:46, radus wrote: > Si daca mi-as pune gcc 2.95 ori 3.0.3 in RedHat alea nu ar fi compilate tot cu > 2.96 si ar fi buggy ??
E interesanta forta de persistenta a mitului astuia despre "compilatorul buggy". Cred ca e un exemplu bun pentru a ilustra partea irationala a miscarii free software si cit de vulnerabila este la "credinte" ilogice, la lozinci. M-as hazarda sa fac o analiza a cazului astuia, pentru faptul ca ar trebui sa fie valabila in majoritatea celorlalte flamewar-uri stupide (dar asta e pleonasm: flamewar-ul e stupid din start). Amuzant este ca, de fapt, compilatorul in sine (gcc-2.96, aparut prima oara in RH 7.0, pentru ca despre el vorbim) nu e "buggy", in sensul ca executabilele generate cu el nu au probleme _in_sine_. De fapt, performanta executabilelor astora e chiar mai buna decit cea a celor generate cu gcc-2.95, deoarece 2.96 optimizeaza codul mai bine (nu stiu, totusi, cum s-ar compara cu 3.0). Atunci de ce totusi exista superstitia asta a "bug-ului in compilator"? 1. Diferenta principala intre 2.95 si 2.96 este ca ultimul urmareste mult mai strict standardul ANSI C. Gcc are o istorie lunga si trista de a nu face verificari prea stricte ale sursei. Vad asta tot timpul atunci cind compilez aplicatii open source pe Irix, cu MIPSPro (care e un compilator extrem de pedant, care protesteaza la orice iregularitati); daca compilezi Squid cu MIPSPro, te iei cu miinile de cap ce de-a mai mizerii gaseste (bucati de cod care nu sint niciodata "reachable", tot felul de asignari intre pointeri care nu seamana de nici un fel, etc.). Sint putine proiecte open source care au un cod curat (Pure-FTPd e unul din ele). Situatia asta e data tocmai de faptul ca gcc, pina la 2.95 inclusiv, e foarte "relaxat" in privinta codului. Cind 2.96 a introdus o strictete mai mare, o gramada de softuri nu s-au mai compilat (fapt care mi se intimpla mai tot timpul cu MIPSPro, care pur si simplu refuza sa joace ruleta ruseasca in stil gcc <=2.95, dar p-asta flamerii n-o stiu :-D). Dar asa e cind creierul se supune glandelor: o problema de curatenie a codului devine una de "firma mare si urita care nu poate face decit chestii stupide cum ar fi acest compilator buggy". ;-) In analiza ultima, problema era in aplicatii, mai precis in stilul dezordonat in care se programeaza in open source. Odata si odata, gcc tot trebuia sa devina mai strict, fapt care oricum se intimpla cu 3.0. 2. Majoritatea kernel-elor Linux s-au comportat mult mai bine compilate cu versiuni timpurii ale lui gcc decit cu 2.96 sau 3.0, spre deosebire de aplicatii (Apache, Sendmail, mutt, whatever), care par a fi la fel de stabile indiferent de compilator (intre anume limite). Motivul este ca aplicatiile sint in general portabile. Majoritatea ruleaza pe tot felul de platforme Unix, se compileaza si cu tot felul de alte compilatoare in afara de gcc, s.a.m.d. Cu timpul, un fel de "selectie naturala" le-a facut sa nu (prea) depinda de gcc, implicit sa nu (prea) depinda nici de versiunile acestuia. Pe cind kernel-ul Linux are portabilitate zero: dintotdeauna a fost compilat numai si numai cu gcc. Normal ca are tot felul de "gcc-isme" prin el. Normal ca "se simte mult mai bine" cu versiunile vechi de gcc. Normal ca, daca chiar vrei stabilitate, e bine sa stai departe de versiunile noi de gcc atunci cind compilezi kernel-ul. Nu a fost facut in ideea de a-l porta pe alte compilatoare. Evident, deci, ca primele patchlevel-uri de 2.96 au fost extrem de nerecomandabile pentru a compila kernele. Faptul ca asta a fost adevarat si pentru 3.0 e trecut sub tacere de "galeria hormonala", din motive evidente. Intre timp, atit 2.96 cit si 3.0 au devenit oarecum mai acceptabile in privinta compilarii kernel-ului, dar in continuare, pentru stabilitate maxima, e preferabil un gcc mai vechi, din motivele aratate mai sus. Sau iei un kernel, iei un compilator, oricare ar fi ele, si incepi sa rulezi teste la greu; a crapat? bun, il patch-uiesti; apoi teste din nou, si tot asa. In conditiile astea chiar ca nu mai conteaza ce versiuni folosesti. Dar asta nu mai are legatura cu discutia initiala. 3. Primul release de 2.96, cel de pe RH 7.0 (2.96-54) a avut intr-adevar bug-uri "adevarate"; zice pe site, la Errata, la RH 7.0, care sint bug-urile alea. Ar fi fost culmea sa nu fi avut, avind in vedere ca contine niste schimbari semnificative in cod (lucru care se intimpla cu orice software, nu doar cu gcc, nu doar cu gcc-2.96). Intre timp au aparut update-uri, care au corectat problemele. Versiunile din RH7.1 si 7.2 au fost bune de la inceput. Asta e partea tehnica a problemei. Ramine acum restul, partea "politica": decizia din spatele includerii lui 2.96 in distributie. 1. Probabil ca aceasta decizie a fost, intr-adevar, gresita. Avantajele aduse de 2.96 (performanta un pic mai buna, curatenie mai mare a codului) nu prea justifica problemele introduse (e adevarat ca codul open source e problematic, dar e tot atit de adevarat ca e dificil sa te apuci sa-l cureti pe tot dintr-o data). 2. La 2.96 au muncit o gramada de oameni, dar din cauza ca branch-ul respectiv de cod nu a fost inclus in 3.0, ramine munca pierduta. Mai bine mai "polizau" un pic 2.95, sau lucrau impreuna cu gcc-ul "oficial" si foloseau un prerelease al lui 3.0. In felul asta, munca depusa nu s-ar fi pierdut. In rezumat: Punind in balanta avantajele tehnice si dezavantajele "politice", probabil ca raspunsul global este ca da, a fost o greseala sa fie inclus in distributie. Insa, dupa cum se vede, raspunsul nu e de genul "e ori alba, ori neagra". E ceva de genul "pe ansamblu negrul predomina, dar exista o multime de situatii particulare in care e alba toata ziua". Problema este ca mentalitatea de flamer nu poate concepe decit "ori alb ori negru": ori ai aceeasi credinta ca noi, si atunci esti sfint si cunosti Adevarul, ori esti un afurisit de ghiaur si trebuie sa mori! :-D Pina la urma, daca chiar vrei rezultate ideale, astea nu pot veni din folosirea acelei "unice, oficiale si adevarate" versiuni a softului XYZ, pentru ca asa ceva nu exista. Valabil si pentru compilatoare, si pentru distributii, si pentru sisteme de operare, si pentru orice. Pentru cine stie ce face, nu e nici o problema in a avea citeva versiuni diferite de compilator pe sistem, si a o folosi pe cea potrivita la locul potrivit. -- Florin Andrei "The security of any corporate network is inversely proportional to the number of systems administrators on the network." - - Petreley's law of sysadmins --- Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to unsubscribe from this list.
