On 29 Jan 2002, Florin Andrei wrote: > 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.
Ok, baiatul a vorbit fara sa stie dar eu nu pe el o sa-l contrazic ci pe tine :) > 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. S-a miscat si kernelul, versiunile de 2.4.x > 9 se compileaza vine cu gcc-uri noi. > 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. [...] > 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. Te-am prins. Da luneta sa pun crucea pe el :) Deci: 2.96 care a aparut prima data in RH7.0 a fost _alfa_ release. Bine, hai sa-i spunem post-alfa sau beta1 daca iti place mai mult. Adevarul e ca intr-adevar avea probleme. Asta ai spus si tu ca au trecut apoi la Errata. Marea problema atuncea a fost ca au existat 2 probleme :) 1. Cei care fac gcc-ul nu anuntasera roadmap-ul si nu spusesera ca 2.96 nu va fi NICIODATA release ci ca este doar testing bed pentru 3.0 2. Cei de la RedHat s-au suparat ca in alte distributii apar chestii mai noi decat la ei (asta e inventata de mine ca efect secundar la pilulele pentru cauze sfinte) si datorita politicii de release-uri (asta e o explicatie data chiar de tine Florine pe RLUG ceva mai demult) au zis ca n-o sa poata trece la 2.96 cand va fi release decat daca o sa scoata RH8.0 ca nu schimba a doua cifra in cadrul lui 7.x (ma rog, chestii interne de-ale lor). Este foarte adevarat ca in 7.1 si 7.2, gcc-urile incluse, desi se cheama tot 2.96, sunt FOARTE BINE pieptanate. Eu personal cred ca din greseala asta a RedHat-ului a iesit ceva foarte bun (da, continui sa spun ca a fost greseala, contrazi-ma daca vrei). Ca sa-si spele fata, RedHat a investit foarte mult in 2.96 si asta insemna FOARTE MULT. Testari, peste testari asa cum putini mai fac ca ei, patch-uri, oameni alocati special pentru asta etc. De asemenea au investit mai mult si in kernel si au ajutat sa fie facut mai repede "portabil" (observati va rog ghilimelele si nu ma intrebati daca merge compilat cu VC++ pe windows). Asa se face ca la ora actuala, faptul ca avem un 3.0.x bun, scos la termen si cu care se poate compila cam orice misca prin zona mai putin softul scris cu picioarele din care este destul atat in zona free software cat si in zona comerciala (asta ca sa spar mitul cu free software are mult kkt iar ce e comercial e super, e plin de varfuri si de gropi peste tot pe unde sunt oameni). Si daca te bate cumva un gand sa ma contrazici cum ca 2.96 a fost altceva decat alfa si beta testing pentru 3.0 si sa te iei de gat cu mine pentru cauze sfinte, arata-mi la http://gcc.gnu.org/releases.html unde apare 2.96 si arata-mi ce scria pe ftp langa 2.96 (era "DONTUSE" sau nu era?). > Asta e partea tehnica a problemei. Ramine acum restul, partea > "politica": decizia din spatele includerii lui 2.96 in distributie. Asta a fost "greseala" despre care spuneam si ceea ce mai spuneam este ca de atunci au aparut inca doua release-uri la distributi de RH si deci asta deja e history. Ce rost mai au acum discutiile astea? > 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). Da, dar ca sa termini trebuie sa te apuci odata si de asta. Si ca orice schimbare, e dureroasa si aduce o gramada de fanatici care se dau cu capul de coltul mesei ca li s-a luat patutul caldut de paie in care dormeau linistiti fara sa faca nimic. > 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. Te contrazic cu ceea ce am spus mai sus. Intreaba-l pe Bero, pe Gafton sau pe cine vrei tu de la RH daca intr-adevar nu s-au folosit chestiile din 2.96 "polizat" in 3.0. Modificarile s-au facut in paralel. Pentru conformitate, indiferent de ce ti-ar raspunde Bero: bash-2.05# grep @ MAINTAINERS | wc -l 165 bash-2.05# grep redhat MAINTAINERS | wc -l 82 Asta e in gcc 3.0.3. 82 din 165 de maintaineri sunt de la RedHat. Adica jumatate dintre ei fara o jumatate de om :) Iar asta e din egcs 1.1.2: bash-2.05# grep @ MAINTAINERS | grep @ | wc -l 72 bash-2.05# grep redhat MAINTAINERS | wc -l 0 Si asta din gcc 2.95.3: bash-2.05# grep @ MAINTAINERS | grep @ | wc -l 90 bash-2.05# grep redhat MAINTAINERS | wc -l 3 Deci RedHat a ajutat IMENS la gcc 3.0 si, in acelasi timp, din cauze de politica de distributii, scot iei noi versiuni de 2.96 care sunt cvasi-identice cu 3.0 pe care il prezinta (probabil) in RawHide. Practic echipa de lucru la GCC s-a dublat datorita celor de la RH. Comunitatea Open Source poate sa aprinda multa vreme de acum incolo /lumanari si tamaie/ (inlocuiti cu ce se foloseste pe la fiecare dintre voi pentru multumiri) pentru cei de la RedHat care din cauza unei greseli, pentru a o repara, s-au dat peste cap si au alocat resurse imense pentru gcc si pentru kernel. Si nu doar comunitatea Open Source ar trebui sa le fie recunoscatoare ci toti programatorii si utilizatorii de soft in general pentru ca asta inseamna o experienta uriasa acumulata in timp foarte scurt si de pe urma careia beneficiaza cam toata lumea (aproape 6 miliarde de oameni, ca sa nu exageram spunand ca toti :) <teoria flame-urilor> > 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 Si nu e asa? :))) Din ceea ce spui tu toti musulmanii sun flameri, iar americanii n-au nici in clin nici in maneca cu asa ceva. Gresit. Aderarea _stransa_ la o cauza, nu te face flamer oricat de aprins ti-ai sustine cauza, atata timp cat o faci cu argumente si cat timp accepti sa auzi si argumentele celuilalt. Flamer esti cand arunci afirmatii neargumentate sau argumentate doar pe sentimentele personale si o mai faci si pe tonuri incendiare. </teoria flame-urilor> > 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. In momentul in care ajungi sa ai nevoie de "versiuni diferite" de compilator pe sistem, insemna ca ceva e putred. Prefer sa am compilatoare diferite, asa cum foloseam demult BCC-ul si Watcom-ul si eram unul dintre cei mai fericiti programatori ca ma durea in paishpe de VC (sau se scrie WC? :) Flower --- Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to unsubscribe from this list.
