Lupta pentru utilizatorul final ( partea 1 )

Utilizatorii care care folosesc software opensource mai devreme sau mai tirziu ajung sa incerce sa compileze un software. De ce ?

Iata citeva motive invocate:

• Pentru ca distributia pe care o foloseste nu are programul respectiv
• Pentru ca software-ul este prea nou si nu exista pachet pentru el inca
• Pentru ca cineva a adaugat o modificare utila la un program dar patchul nu este aprobat de dezvoltatorii softului

Ce se intimpla in momentul respectiv ? In multe cazuri ./configure ; make ; make install functioneaza. Dar aceasta operatiune creeaza foarte multe probleme pe sistem deoarece nu foloseste managerul de pachete si pot aparea probleme mari in cazul rularii proceselor de update. De asemenea un program instalat din surse fara a folosi managerul de pachete nu va fi updatat. Ceea ce poate creea probleme mari de securitate.

Ce e de facut ?

Unii spun ca un manager de pachete standardizat ar rezolva multe probleme. Sint partial de acord cu asta. Sint foarte multe linux flavors. Unele cu kernele 2.4 altele cu kernele 2.6 , unele cu glibc 2.2 , unele cu glibc 2.5 , unele cu gcc 2.9x altele cu gcc 4.1. In aceste conditii sa generezi un pachet care sa mearga pe toate este o munca extrem de grea pentru ca pachetul ar trebui sa detecteze in ce conditii trebuie sa ruleze si abia apoi sa se compileze pe masina respectiva. Un alt aspect deloc de neglijat este diferenta mare intre distributii la nivel de “features”. Unele au suport de mp3 de exemplu altele nu. Iar un pachet de editare de sunet poate avea sau nu suport de mp3 functie de distributia pe care va rula. Este celebra problema de a impaca si capra si varza.

Pe 21 februarie Eric Raymond care a folosit timp de 13 ani Red Hat / Fedora a anuntat ca renunta sa foloseasca distributia in favoarea Ubuntu. Motivul care se pare ca a umplu paharul a fost exact manageru de pachete din Fedora . Adica rpm. Rpm-ul a perdut mult din popularitate de cind dezvoltatorul principal a plecat de la RedHat. Raymond spune despre rpm: “Allowing RPM development to drift and stagnate – then adding another layer of complexity, bugs, and wretched performance with yum.”. Eu spun altceva … in momentul in care incep sa plece oamenii vechi atunci chiar e un MARE semnal de alarma.