On Thu, 10 Jan 2002, Daniel Cordey wrote:
R�ponses group�es:
> Peut-�tre faudrait-il prendre aussi la SuSe... 7 CD ... 1600 packages...
La woody actuelle fait d�j� 7 CDs, sans sources, et sans `non-free' ni
`contrib'.
L'article parle aussi de woody, pour montrer que c'est encore plus �norme
(cela pose la question de la fiabilit�/maintenabilit�: car Debian c'est
aussi 7 architectures AFAIK). Un tel projet logiciel est absolument
effarant: et il est un fait qu'aujourd'hui aucune entreprise ne pourrait
se lancer l�-dedans.
La plupart des distributions (� part peut-�tre SuSE avec ses versions
SPARC, PPC, zSeries, iSeries et Intel/ia64) se concentrent sur une, voire
deux architectures.
On 10 Jan 2002, Jean-Albert Ferrez wrote:
> Et en vertu de quel principe se permet-on de comparer la valeur absolue
> d'un produit avec la valeur incr�mentale d'un autre ?
De rien, c'�tait le seul chiffre que j'avais en t�te (inv�rifiable!). Pour
des comparaisons un tant soit peu plus `tenant la route', cf cette �tude
compl�te.
Personnellement, je ne crois pas � ces �valuations en ann�e-homme et
encore moins en dollars, si ce n'est pour dire:
- la valeur de logiciels libres est grande (marketing)
- la complexit� de maintenance et de d�veloppement est immense
(pose des questions s�rieuses quant � la viabilit�/fiabilit�)
mais elle est aussi r�partie (dans l'espace, mais aussi dans les
comp�tences: les utilisateurs participent encore au test, voire
au d�veloppement). On voit quand m�me chez Debian de nombreux
packages qui sont `orphaned' -- pour �tre repris plus tard, mais
pas toujours tr�s vite.
- une distribution X a plus ou moins fait d'am�liorations, d'efforts de
packaging, etc (certaines ajoutent plus de 10% de valeur ajout�e
-- en ligne de code, param�tre dangereux).
Il pourrait �tre int�ressant de faire une autre �tude sur le th�me: les
modifications apport�es par les distributions sont-elles ensuite
r�utilis�es par le code `upstream' (original), voire d'autres
distributions ? Ou ces modifications restent sp�cifiques � la
distribution. Cela ne serait pas super-simple � �valuer.
Dans mon cas personnel, p.e.x. pour mgetty/vgetty, j'ai d� faire les
d�marches initialement pour prendre contact avec le mainteneur Debian, et
maintenant il y a de grandes chances pour que ses modifications et les
miennes soient plus synchronis�es: donc il y a un probl�me pour revenir
en `upstream'.
Dans le cas de SuSE, des modifications int�ressantes � la commande
`buffer' n'ont pas pass� chez le mainteneur non plus.
Ok, ce sont des exemples un peu tordus (pas des programmes tr�s end-user
p.ex.).
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.