> Ta réponse est une bonne illustration de ce que Ian Murdock critique.
Tu peux expliquer ?
> En fait, il propose de considérer Linux comme une infrastructure et non pas comme un produit.
Je pense qu'il faut considérer Linux comme les deux. On développe un bon produit dans une bonne infrastructure. Une belle infrastructure qui n'accouche pas d'une bon produit est sans réel intérêt.
> Dans la mesure où Murdock est lui-même administrateur de Progeny, un distributeur commercial de Linux, ses remarques méritent vraiment qu'on y réfléchisse.
Mais j'y ai réfléchis (dans la mesure de mes moyens :-)).
Je ne pense pas que sa "vision" est fausse. Mais actuellement je ne la vois pas concrêtement et certaines critiques me paraissent excéssives.
Par exemple :
> puis controler les standard en "capturant" les client aux moyens de technologies propriétaires
Y a SuSE avec YaST. C'est tout pour le propriétaire (j'oublie volontairement les Linux/Xandros etc).
> de contrats de support englobant les standards existants et s'étendant jusqes aux bonnes pratiques"
Qui peut fournir du support qui couvre toutes les fantaisies de l'utilisateur ? Ce serait un support extrèmement cher.
On peut retrouver dans cette critique le fait, par exemple, que RedHat ne supporte que ext3. Mais c'est un ext3 standard. Ce qui compte, c'est qu'il y ait d'autres distributeurs pour supporter reiserfs, xfs, jfs. J'ai un peu dit dans mon précédent post.
> Les incompatibilités introduites par certaines sociétés [de distributions Linux] conduisent, à nouveau, à un verrouillage par ces sociétés au moyen des services et du support.
Il y a épisodiquement des incompatibilités qui apparaissent. Mais c'est pas le bout du monde. Prends RedHat avec gcc 2.96. C'est incompatible binaire mais compatible source. Donc pour tous les projets LL, ça roule. De plus c'est pas une volonté de faire incompatible mais plutôt l'adaptation de gcc pour répondre à un besoin. D'ailleur maintenant RedHat à un compilo tout ce qu'il y a de standard. Puis RedHat et un gros contributeur de gcc...
Il y a aussi la LSB que les distributions majeurs respectent.
Les paquets sont lisibles partout. Je peux voir un .deb et un utilisateur de debian peut voir un .rpm.
RedHat a aussi introduit nptl. Es-ce un problème ? C'était plannifier pour Linux 2.6 et ça suis les standards.
Une évènement interessant est le projet rhl. En gros redhat est plus ouvert au contributions extérieurs et veut être plus synchronisé avec l'upstream des projets.
Tant que les contributions extérieurs (boîtes commerciales comme Sun/IBM ou les bénévoles) ont un apport significatif pour un distributeur, les distributeurs n'auront pas envis de s'éloigner de ce qui est réalisé par les projets. Par exemple RedHat a dit qu'il intègrerait reiserfs, si c'est supporté (dans le cadre de la distribution, je ne parle pas du noyau). C'est à dire qu'ils ne veulent pas s'occuper de reiserfs, mais accèpte toute initiative extérieur qui permet de supporter reiserfs.
Bref, ce que je veux dire, sans nier la pertinance du raisonnement de l'article, c'est qu'actuellement je ne vois pas de dérives significatives et il me semble que la possibilité de """monopole""" de certains distributeurs est plus préoccupante.
[^] # Re: Linux n'est pas un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à 1.
Tu peux expliquer ?
> En fait, il propose de considérer Linux comme une infrastructure et non pas comme un produit.
Je pense qu'il faut considérer Linux comme les deux. On développe un bon produit dans une bonne infrastructure. Une belle infrastructure qui n'accouche pas d'une bon produit est sans réel intérêt.
> Dans la mesure où Murdock est lui-même administrateur de Progeny, un distributeur commercial de Linux, ses remarques méritent vraiment qu'on y réfléchisse.
Mais j'y ai réfléchis (dans la mesure de mes moyens :-)).
Je ne pense pas que sa "vision" est fausse. Mais actuellement je ne la vois pas concrêtement et certaines critiques me paraissent excéssives.
Par exemple :
> puis controler les standard en "capturant" les client aux moyens de technologies propriétaires
Y a SuSE avec YaST. C'est tout pour le propriétaire (j'oublie volontairement les Linux/Xandros etc).
> de contrats de support englobant les standards existants et s'étendant jusqes aux bonnes pratiques"
Qui peut fournir du support qui couvre toutes les fantaisies de l'utilisateur ? Ce serait un support extrèmement cher.
On peut retrouver dans cette critique le fait, par exemple, que RedHat ne supporte que ext3. Mais c'est un ext3 standard. Ce qui compte, c'est qu'il y ait d'autres distributeurs pour supporter reiserfs, xfs, jfs. J'ai un peu dit dans mon précédent post.
> Les incompatibilités introduites par certaines sociétés [de distributions Linux] conduisent, à nouveau, à un verrouillage par ces sociétés au moyen des services et du support.
Il y a épisodiquement des incompatibilités qui apparaissent. Mais c'est pas le bout du monde. Prends RedHat avec gcc 2.96. C'est incompatible binaire mais compatible source. Donc pour tous les projets LL, ça roule. De plus c'est pas une volonté de faire incompatible mais plutôt l'adaptation de gcc pour répondre à un besoin. D'ailleur maintenant RedHat à un compilo tout ce qu'il y a de standard. Puis RedHat et un gros contributeur de gcc...
Il y a aussi la LSB que les distributions majeurs respectent.
Les paquets sont lisibles partout. Je peux voir un .deb et un utilisateur de debian peut voir un .rpm.
RedHat a aussi introduit nptl. Es-ce un problème ? C'était plannifier pour Linux 2.6 et ça suis les standards.
Une évènement interessant est le projet rhl. En gros redhat est plus ouvert au contributions extérieurs et veut être plus synchronisé avec l'upstream des projets.
Tant que les contributions extérieurs (boîtes commerciales comme Sun/IBM ou les bénévoles) ont un apport significatif pour un distributeur, les distributeurs n'auront pas envis de s'éloigner de ce qui est réalisé par les projets. Par exemple RedHat a dit qu'il intègrerait reiserfs, si c'est supporté (dans le cadre de la distribution, je ne parle pas du noyau). C'est à dire qu'ils ne veulent pas s'occuper de reiserfs, mais accèpte toute initiative extérieur qui permet de supporter reiserfs.
Bref, ce que je veux dire, sans nier la pertinance du raisonnement de l'article, c'est qu'actuellement je ne vois pas de dérives significatives et il me semble que la possibilité de """monopole""" de certains distributeurs est plus préoccupante.
PS : Bravo pour la traduction.