<[EMAIL PROTECTED]> scria la data de 14 Decembrie 2005:
> On Wed, 14 Dec 2005, Liviu Daia wrote:
>
> > Intr-un proiect serios versiunile declarate stabile sunt
> > suportate cel putin cativa ani, iar caile de upgrade _si_ de
> > downgrade sunt documentate in detaliu. Schimbarile incompatibile
> > in interfata cu utilizatorul sunt anuntate cu cel putin un an
> > inainte. Timp de un an functioneaza ambele variante; timp de inca
> > un an varianta veche scrie warning-uri dar continua sa functioneze;
> > de-abia dupa asta e eliminata. In acelasi regim intra si interfata
> > cu alte programe. In plus aceasta e documentata de-abia in momentul
> > in care este stabila, iar din momentul in care a fost documentata nu
> > se mai poate schimba. Evident, as putea continua.
>
> Funny. Poti sa ne dai si exemple de proiecte serioase in afara de
> postfix ?
Ce incercam eu sa spun era ca poti avea un proiect care se dezvolta
rapid si substantial fara sa-ti obligi user-ii sa faca upgrade-uri din
doua in doua saptamani doar pentru ca pe tine te chinuie creativitatea.
Iar asta nu tine de resurse, ci de management-ul proiectului si de
mentalitatea (si poate de experienta) developer-ilor. Am dat exemplul
Postfix pentru ca il cunosc bine, si pentru ca mi se pare ca ilustreaza
perfect aceasta idee.
Personal nu stiu absolut nimic despre proiectul Yate (de la care a
pornit discutia), si nu as putea comenta nimic despre el sau despre ce
se intampla acolo. Insa afirmatia "toate programele care au nevoie de
compatibilitate se schimba mai des de 6 luni" mi s-a parut deplasata.
lonely wolf <[EMAIL PROTECTED]> scria la data de 15 Decembrie 2005:
> plecind de la ipoteza ca ai intrebat fiindca vrei sa stii, nu doar ca
> sa te afli in treaba:
> aalib. alsa. at. bind. cups. db. dhcp. dialog. dosfstools. e2fsprogs.
> elfutils. exim. flex. gcc. glibc. httpd. iproute. lynx. m4. modutils.
> openoffice. samba. sed. sendmail. tar. vim.
De acord, dar cu cateva obiectii. :-)
(1) Sleepycat db este departe de a fi un proiect stabil in sensul de
mai sus. Problema acolo este ca au facut atat de multe schimbari
incompatibile de API, incat toate distributiile recente de Linux
vin cu cate 3-4 versiuni de libdb instalate. Si cum sub Linux
bibliotecile NSS sunt link-ate cu db, rezultatul este incarnarea sub
UNIX a "DLL hell" de sub Windows.
(2) Cam acelasi lucru este valabil si pentru gcc, de data asta din cauza
incodarii simbolurilor C++ in fisierele obiect (v-ati pus vreodata
intrebarea de ce programe ca Opera vin in cate 5-6 versiuni numai
pentru a suporta diferentele dintre distributiile de Linux?). In
sfarsit, o parte din problema are direct legatura cu modul cum e
definit limbajul in standarde si cu relatia acestuia cu STL-ul, dar
evolutia pare sa fie in rau.
(3) Despre problemele din Glibc (a caror aparitie a coincis cu preluarea
conducerii proiectului de catre Ulrich Drepper, acum vreo 10 ani)
as putea scrie o carte. :-) Voi spune aici doar ca sistemele care
nu sunt bazate pe Glibc sunt, in experienta mea, mai eficiente...
Evolutia aici pare insa sa fie spre bine.
(4) Flex-ul a avut si el cateva momente de ratacire in care a schimbat
interfata dupa 20 de ani, insa si-a revenit rapid.
(5) In sfarsit, multa lume continua sa nu fie de acord cu multe din
schimbarile din Apache 2.x, insa acolo branch-ul 1.x este suportat,
si probabil va ramane asa inca multa vreme.
> iti dau si exemple de chestii INSTABILE: autoconf. gaim. selinux.
[...]
Salutari,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
