Plutôt que de proposer une unique norme LSB, le FSG va découper cette norme en différents modules. Ces différents modules se regrouperont pour former deux normes distinctes : «LSB server standard» et «LSB desktop standard». La séparation en modules est censée permettre à la norme de couvrir de plus nombreux domaines techniques, avec plus de précision.
Ainsi, du coté des ordinateurs de bureau, où GNU/Linux peine pour l'instant à s'imposer, le «LSB desktop standard» permettra à de plus nombreux éditeurs de rendre leurs logiciels compatibles avec le système libre.
D'autre part le LSB 2.0.1 a été soumis à l'ISO/IEEE pour normalisation. Le LSB 2.0 ayant été publié en septembre 2004, le LSB 3.0 est prévu pour mars 2005 incluant la crypto, et des mises à jour de bibliothèques centrales et C++. Le LSB 4.0 quant à lui est programmé pour la fin 2006 et LSB 5.0 en début 2008.
Aller plus loin
- Free Standards Group (11 clics)
- eWeek : « Group to Divide Linux Standards Base » (1 clic)
- FSG : « LSB 2.0.1 released; submitted to ISO » (6 clics)
# Angoisse
Posté par Guillaume Knispel . Évalué à 2.
J'espère qu'on pourra acceder gratuitement aux normes...
Les normes ISO sont payantes, se serait un comble pour les contributeurs, développeurs et packageurs de LL si ils devaient payer pour obtenir ces normes.
[^] # Re: Angoisse
Posté par Guillaume Knispel . Évalué à 1.
[^] # Re: Angoisse
Posté par Guillaume Lebigot (site web personnel) . Évalué à 0.
[^] # Re: Angoisse
Posté par David Sporn (site web personnel) . Évalué à 1.
Heureusement, l'informatione était dispo ailleurs...
[^] # Re: Angoisse
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: Angoisse
Posté par ashram4 . Évalué à 2.
Personellement j'ai un accès à l'ensemble des documents IEEE donc je préfère quand c'est l'IEEE que normalise.
# Quelle version ?
Posté par bmc . Évalué à 3.
Quid des relations avec des projets comme FreeDesktop ?
[^] # Re: Quelle version ?
Posté par fabb . Évalué à 10.
C'est une bonne question.
Le problème de la LSB que je perçois actuellement est qu'elle tente d'imposer des standards au-lieu de suivre les développements du libre (les "standards" du libre), faire quelques préconisations pour éviter des incompatibilités inutiles et pourquoi pas faire des propositions (qui bien entendus ne sont pas *encore* des "standard" LSB).
Pour la LSB 2.0, la LSB a fait "fort". A la sortie de la LSB 2.0 (ou vers les derniers brouillons), il fallait un compilateur qui n'existait pas encore !?!
De même, j'ai maintenant le répertoire "/srv" mais personne n'utilise ce répertoire.
Jusqu'à maintenant, la LSB "codifiait" des standards de fait du libre. Maintenant la LSB définit les directions des futurs développements.
C'est une attitude récente que je n'aime pas et je ne suis pas le seul. Les réactions des développeurs de gcc sur la LSB 2.0 montrent clairement que beaucoup n'aiment pas cette nouvelle direction.
Selon moi les distributions doivent permettre l'installation de programmes LSB et les distributions comme les développeurs du libre font les standards de fait que la LSB codifie de temps à autre pour "mettre tout le monde" et assurer l'intéropérabilité.
Les développements du libre doivent être menés/dirigés par le libre et pas par la LSB.
Pour revenir à la partition de LSB à FreeDesktop.
Deux possibilités :
1) LSB apporte ses compétences
2) LSB définit les futurs standards de FreeDesktop
Je ne veux pas du 2).
La LSB 2.0 est marquante dans cette nouvelle attitude. On a même vu une annonce de distribution dont l'un de ses principaux objectifs était d'être conforme à la LSB 2.0 !
Avant on pensait que si une distribution suivait grosso-modo les standards du libre il était facile de la rendre comforme LSB, maintenant c'est une autre histoire... Il faut faire du développement pour être conforme LSB et la création d'une distribution principalement pour suivre la LSB "ne fait pas rire". C'est une aberration.
L'annonce des dates des futurs LSB n'est pas un bon signe pour moi. Ça montre que LSB a des "objectifs" à long terme, une "stratégie" qui va au-delà de la codification des standards de fait du libre.
La LSB nie le libre. Le libre est libre ! Le libre n'est pas une entreprise avec des gens qui définissent un cahier des charges, etc ... et des développeurs qui travaillent pour appliquer ce cahier des charges.
En procédant ainsi, la LSB risque de diviser les distributions (ce qui n'est pas son objectif) et d'être un lieu où le lobbying va jouer un rôle. Chaque distribution voulant être conforme LSB, elle va faire "pression" pour que les futurs standards LSB suivent la "ligne" de la distribution.
On a maintenant une situation qui n'aurait jamais dûe arriver. Les distributions Red Hat (RHEL 4 et FC >=3) ne peuvent être compatible LSB 2.0 (à moins de faire des trucs tordus) simplement car elles suivent le "standard" libre et ont adopté gcc 3.4 (gcc 3.3.5 nécessaire à LSB 2.0 n'étant pas dispo vers la sortie de la LSB 2.0 ni à l'époque des premières beta FC3 (la base de RHEL 4)).
Red Hat fait (ou tente de faire) du compatible LSB. Pour une distribution suivante il assure la compatibilité. Pour bien faire il faudrait que Red Hat sorte pour la prochaine distribution : gcc 3.2 (compatibilité avec les anciennes versions), le nécessaire pour les normes LSB précédement supporté, gcc 3.3.5 + quelques librairies C++ (compatibilité LSB 2.0) et gcc 3.4 ("standard" actuel du libre).
On le voit, il y a deux branches (au moins pour gcc). La branche "libre" et la branche LSB.
Que doit faire Red Hat pour éviter ce problème à l'avenir (maintenir 3 branches de gcc) => faire du lobbying auprès de la LSB. C'est mauvais, très mauvais. Actuellement ça ne semble pas envisagé par Red Hat. Mais si à l'avenir Red Hat doit support X version précédente, X nouvelle version (en gros ce qui est upstream), X LSB 2.0 et X LSB 3.0, ça va les gonfler méchament.
La LSB n'a pas à se mélanger avec les besoins/plannings des distributeurs.
J'ignore actuellement si RHEL 4 sera compatible LSB 2.0. Mais si elle ne l'est pas, que vont faire les développeurs d'applis ?
Trois possibilités :
- suivre la LSB 1.3
- suivre le """standard""" RHEL 4
- suivre la LSB 2.0 et ne pas être compatible avec la distribution la plus utilisée en entreprise
- suivre autre chose
Si la cible du développeur est le marché de l'entreprise, il va suivre le """standard""" RHEL 4 si le standard LSB 1.3 ne répond pas à ses besoins (même si la LSB 2.0 répond à ses besoins).
Si RHEL 4 n'est pas compatible LSB 2.0, Red Hat aura mauvaise presse (et nul doute que linuxfr s'en fera écho comme il en a l'habitude) et les concurrents ne vont pas manquer de souligner ça.
Mais ça sera aussi une mauvaise presse pour la LSB :
1- Red Hat se justifiera avec des arguments qui ne pourront être ignoré
2- la LSB n'a pas tenu ses objectifs
NB : En entreprise, les gens s'en foutent d'être LSB ou pas.
[^] # Re: Quelle version ?
Posté par Hobgoblins Master (Mastodon) . É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).
[^] # Re: Quelle version ?
Posté par bmc . Évalué à 8.
La façon dont ça se déroule me semble plutôt être une tentative de contrôle des développements futurs par les membres principaux de la LSB (a priori Intel, HP, IBM) qu'une tentative de standardisation réelle... quand on voit les efforts faits par Freedesktop, que je trouve très intéressants et plutôt réussis jusqu'à maintenant (même s'il reste du boulot), je doute que la LSB puisse arriver avec ses gros sabots et dire « ok maintenant vous rentrez faire mumuse chez vous, on va faire de la vraie standardisation ».
Les éditeurs devraient avoir intérêt à se conformer à la LSB. Il faudrait pour cela qu'on évite de leur donner un boulot monstre. Le chemin doit être autant fait par la LSB que par les éditeurs : on ne peut pas standardiser dans le vent et théoriquement ! Il faut se baser un peu sur ce qui se passe réellement. J'ose espérer que le Free Standards Group empruntera cette voie.
[^] # Re: Quelle version ?
Posté par hervé Couvelard . Évalué à -1.
De là à voir un groupe de pression qui se crée pour assoir une domination sur le monde du libre par une "certification" LSB
(et pourquoi pas un petit logo sur les machines et/ou les boites des distributions "Design form Linux LSB 2" ou un autre du style LSB 2.0 Inside.
(toute ressemblance avec des logos déja existants de marques propiétaires étant bien entendue involontaire et entièrement fortuite. Vite, un psy je suis parano....
Vous arrivez à acheter une machine HP ou IBM desktop sans Windows ? facilement ? Et ils VEULENT aider le libre par leur compétence à gérer des normes pour le bien de tous ?
Vous arrivez à installer un linux sans trop de mal sur TOUS les portables ibm et HP ? Ils donnent les spécifications de leurs machines afin de permettre l'interropérabilité ?
Qu'ils respectent d'abord les lois en vigueur. Ensuite viendra peut être une écoute distraite ou ils auront le droit de parler tout doucement.
[^] # Re: Quelle version ?
Posté par fabb . Évalué à 2.
Les choix du libre sont faits par le libre. Les choix de RH sont fait par RH.
Le libre a fait le choix de gcc 3.4 et LSB demande de pondre gcc 3.3.5 alors que gcc 3.4 était sorti et gcc 3.3.5 n'existait pas !
Que LSB exige gcc 3.2 ou 3.3.4 (mais pas .5 qui n'existe pas). Si l'objectif est d'avoir une plate-forme pérenne il n'y a pas d'exigence urgente en produit dernier cri.
Si je parle de RH c'est car c'est un acteur important (dans l'entreprise).
RH a un aussi beaucoup beaucoup de développeurs gcc. Red Hat connait les orientations de gcc tout comme il influence gcc. Mais il est meilleur d'influencer un projet car on y contribue en ligne de code que d'influencer un projet indirectement car on a fait du lobbying auprès de la LSB.
> d'éviter à l'entreprise de se retrouver prisonnière d'un éditeur (tiens ça vous rapelle pas quelque chose???)
J'ai peur que la LSB ait déjà échoué dans ce domaine.
> 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...).
Merci de démontrer que les entreprises se foutent de la LSB.
Défit : Trouves une applie vendue avec "marche sur LSB 1.3" et non "requière (Red Hat)|(SuSE) X.Y".
Tu vas "ramer".
De même trouve un PLF/freshrpms pas pour une distribution spécifique mais pour LSB. Tu vas "ramer" très très fort et il est même probable que ça n'existe pas du tout.
En l'état actuel, tout le monde (entreprise, communauté) peut se pas passer de la LSB et d'ailleur tout le monde s'en passe. Si globalement ça passe, c'est grace aux standards de fait du libre.
En l'état actuel, il faut bien le reconnaitre, la LSB est un échec. La LSB est un "succès" seulement car beaucoup de distribution se font certifier. La certification des distributions est payante.
Notons aussi que beaucoup de distributions ne sont pas certifiées :
- Gentoo
- Debian
- Fedora
- Slack
- etc
[^] # Re: Quelle version ?
Posté par Emmanuel Seyman . Évalué à 1.
La LSB est un standard pour les applications propriétaires, pas les applis libres qu'on peut adapter spécifiquement à une distribution donnée.
Notons aussi que beaucoup de distributions ne sont pas certifiées :
- Debian
Conforme a la norme mais ne sera jamais certifié (la certification est chere)
- Fedora
Conforme et certifié LSB 1.3
[^] # Re: Quelle version ?
Posté par fabb . Évalué à 1.
Ça c'est fort.
Dans ce cas, je me torche de la LSB.
> - Fedora
> Conforme et certifié LSB 1.3
Peut-être conforme et pas certifié :
http://fedora.redhat.com/about/rhel.html(...)
[^] # Re: Quelle version ?
Posté par Emmanuel Seyman . Évalué à 1.
Dans ce cas, je vais t'avouer que je trouve que tu fais beaucoup de bruit pour rien.
[ A propos de la Fedora ]
Peut-être conforme et pas certifié :
Moi, j'ai ça :
[manu@lora ~]$ rpm -q fedora-release
fedora-release-3-8
[manu@lora ~]$ rpm -q --whatprovides lsb
redhat-lsb-1.3-4
[^] # Re: Quelle version ?
Posté par WH (site web personnel) . Évalué à 2.
[^] # Re: Quelle version ?
Posté par Sylvain Sauvage . Évalué à 4.
# N'est-ce pas qu'une proposition seulement ?
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 2.
Donc pour le moment, cette future LSB - si j'en crois ces articles [1] - n'est que plannifiée et donc il n'y a rien de définitif, peut-être cette idée sera mise de côté.
Le problème, c'est qu'il n'y a aujourd'hui aucun site officiel qui mentionne cette information.
Sur les 2 liens suivant je n'ai pas réussi à trouver d'information à ce propos :
Free Standards Group : http://www.freestandards.org/(...)
Linux Standard Base : http://www.linuxbase.org/(...)
Jean-Christophe
[1]: L'avenir de Linux: 2 branches séparées - http://www.pcinpact.com/actu/news/Lavenir_de_Linux_deux_branches_se(...)
Splitting up the LSB - http://blogs.zdnet.com/open-source/index.php?p=130(...)
# Bonne nouvelle
Posté par Zorro (site web personnel) . Évalué à 7.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.