> Quid des relations avec des projets comme FreeDesktop ?
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 fabb . En réponse à la dépêche La norme Linux Standard Base s'enrichit. É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.