J'ai la très nette impression en lisant ton post que tu n'as strictement rien compris aux objectifs de la LSB.
C'est très clair tout au long de ton argumentation et c'est flagrant dans ton Nota Bene.
D'où parles tu de standard du libre en ne citant que RH ? Ca voudrait donc dire qu'aujourd'hui, pour toi, ce sont les choix faits par RH qui orientent les objectifs de l'ensemble des développeurs de logiciels libres ???
Tu dis que l'entreprise se fout de LSB, détrompe toi, beaucoup de monde l'attends avec impatience...
L'objectif de LSB n'est pas de dire aux développeurs vous devez suivre ça... Le but est d'éviter au libre de faire les mêmes erreurs que les Unices ont fait d'une part (devenir imcompatibles entre eux...) et d'éviter à l'entreprise de se retrouver prisonnière d'un éditeur (tiens ça vous rapelle pas quelque chose???). Aujourd'hui, l'entreprise à encore besoin d'un certain nombre de logiciels propriétaires (qui fonctionnent sous Linux). Hors pour la plupart d'entre eux, les éditeurs ne supportent leur produit que sur 1 ou 2 versions d'une ou 2 distributions (RH et Suze...). Je fait comment moi si dans ma boite on a défini que pour toutes les raisons (valables ou non), nos serveurs d'applications étaient sous Mdk et nos serveurs de sécurité sous Debian et tous en version N-1 (le temps de tester la non régression lors des mises à jour) si il faut installer un progiciel qui ne supporte que RH 7.2 pour le serveur d'application et RH 7.3 pour le serveur de DB ???
Ce dont a besoin l'entreprise aujourd'hui, c'est de pouvoir s'assurer qu'elle ne sera pas maquée de force avec un éditeur de distribution et une version qui date de trois ans uniquement parce qu'une appli propriétaire critique et qui n'a pas encore d'équivalent libre ne supporte que cette distro. Et je comprends tout a fait les éditeur propriétaires, ils ne peuvent pas certifier toutes les versions (de moins de 2 ans) de toutes les distributions...
C'est l'objectif de LSB que de dire voilà, nous avons ici une base commune, vous éditeurs propriétaires, assurez vous que vos produits fonctionnent sur cette base et garantissez y le support à vos clients. Vous éditeurs de distributions, arrangez vous pour que d'une manière ou d'une autre (surcouche, version modifiée) vos distibutions puissent garantir la compatibilité.
Après effectivement, les choix de versions et d'architecture faits par LSB ne sont pas forcément judicieux, mais pour moi c'est un autre débat (qu'il faut certainement engager et suivre d'ailleurs).
[^] # Re: Quelle version ?
Posté par Hobgoblins Master . En réponse à la dépêche La norme Linux Standard Base s'enrichit. Évalué à 7.
C'est très clair tout au long de ton argumentation et c'est flagrant dans ton Nota Bene.
D'où parles tu de standard du libre en ne citant que RH ? Ca voudrait donc dire qu'aujourd'hui, pour toi, ce sont les choix faits par RH qui orientent les objectifs de l'ensemble des développeurs de logiciels libres ???
Tu dis que l'entreprise se fout de LSB, détrompe toi, beaucoup de monde l'attends avec impatience...
L'objectif de LSB n'est pas de dire aux développeurs vous devez suivre ça... Le but est d'éviter au libre de faire les mêmes erreurs que les Unices ont fait d'une part (devenir imcompatibles entre eux...) et d'éviter à l'entreprise de se retrouver prisonnière d'un éditeur (tiens ça vous rapelle pas quelque chose???). Aujourd'hui, l'entreprise à encore besoin d'un certain nombre de logiciels propriétaires (qui fonctionnent sous Linux). Hors pour la plupart d'entre eux, les éditeurs ne supportent leur produit que sur 1 ou 2 versions d'une ou 2 distributions (RH et Suze...). Je fait comment moi si dans ma boite on a défini que pour toutes les raisons (valables ou non), nos serveurs d'applications étaient sous Mdk et nos serveurs de sécurité sous Debian et tous en version N-1 (le temps de tester la non régression lors des mises à jour) si il faut installer un progiciel qui ne supporte que RH 7.2 pour le serveur d'application et RH 7.3 pour le serveur de DB ???
Ce dont a besoin l'entreprise aujourd'hui, c'est de pouvoir s'assurer qu'elle ne sera pas maquée de force avec un éditeur de distribution et une version qui date de trois ans uniquement parce qu'une appli propriétaire critique et qui n'a pas encore d'équivalent libre ne supporte que cette distro. Et je comprends tout a fait les éditeur propriétaires, ils ne peuvent pas certifier toutes les versions (de moins de 2 ans) de toutes les distributions...
C'est l'objectif de LSB que de dire voilà, nous avons ici une base commune, vous éditeurs propriétaires, assurez vous que vos produits fonctionnent sur cette base et garantissez y le support à vos clients. Vous éditeurs de distributions, arrangez vous pour que d'une manière ou d'une autre (surcouche, version modifiée) vos distibutions puissent garantir la compatibilité.
Après effectivement, les choix de versions et d'architecture faits par LSB ne sont pas forcément judicieux, mais pour moi c'est un autre débat (qu'il faut certainement engager et suivre d'ailleurs).