L'un des projets importants chapeautés par la Fondation Linux est le Linux Standard Base. Le but est d'améliorer l'interopérabilité entre les distributions afin d'éviter que les vendeurs de logiciels (les ISV) ne doivent compiler un binaire pour chacune d'entre elle. En théorie il suffit de compiler son binaire pour la Linux Standard Base et il fonctionnera sur toutes les distributions qui respectent ce standard.
La Fondation Linux a mis en place tout un un processus de certification afin de s'assurer du respect des spécifications (et de la norme POSIX). En outre la LSB assure une compatibilité complète avec les anciennes versions. Cela signifie que les nouvelles exigences des versions récentes ne font souvent que s'ajouter aux anciennes sans les remplacer. De cette façon un éditeur de logiciel est assuré que son produit restera compatible dans le temps. La nouvelle LSB 3.2 apporte plusieurs nouveautés :
- Prise en charge des langages interprétés Perl (au moins version 5.8.8) et Python (au moins version 2.4.2) ;
- La bibliothèque logicielle Qt4 est maintenant supportée par la LSB ;
- Prise en charge de la norme de composition graphique XRender ;
- La norme de rendu des caractères FreeType et la bibliothèque Xft font maintenant partie de la LSB ;
- Prise en charge de la norme d'impression CUPS ;
- Enfin l'architecture de gestion du son ALSA et l'interface xdg-utils d'intégration du bureau font leur entrée dans la section trial (modules à l'essai).
Afin de naviguer plus efficacement dans la spécification complète la Fondation Linux propose une très commode interface web de navigation. Une page récapitulative de l'état de la compatibilité pour les principales distributions est également disponible.
En dépit de tous ces efforts de soutien à Linux par la création d'un processus de standardisation le LSB a été fortement critiqué par divers acteurs du monde du logiciel libre. Ainsi la norme de paquetage logiciel est basée sur celle du format RPM ce qui a provoqué l'ire des partisans du format deb. Pour être compatible LSB, les dérivées de Debian doivent donc utiliser le convertisseur de paquet Alien.
De plus la suite de tests permettant de vérifier la compatibilité LSB a été critiquée vigoureusement par Ulrich Drepper. Selon lui cette suite est pleine de bugs et la certification LSB ne mérite pas qu'on y consacre autant de ressources. Le monde du logiciel libre se préoccupe surtout de la compatibilité au niveau source (API) et pas au niveau binaire (ABI). Seuls les grands groupes voulant distribuer des binaires sans le code source correspondant ont un intérêt crucial en l'existence d'une norme de compatibilité telle que LSB.
Du coté des défenseurs du standard on souligne que la fragmentation des UNIX propriétaires a provoqué leur affaiblissement et qu'il est important de s'assurer que Linux ne connaîtra pas le même sort. La standardisation basée sur LSB est donc conçue comme un effort dans ce sens.
Aller plus loin
- Annonce de LSB 3.2 (21 clics)
- Présentation des nouveautés (2 clics)
# Et dans les autres cas ?
Posté par windu.2b . Évalué à 5.
Et dans les cas pas couverts par le "souvent" ? Il se passe quoi ? Et quels sont ces cas ?
[^] # Re: Et dans les autres cas ?
Posté par patrick_g (site web personnel) . Évalué à 8.
Je ne voulais pas expliquer en détail toute la procédure (et j'ai mis un lien sur le mot compatibilité pour ceux qui veulent connaitre ces détails).
En gros j'ai employé le mot souvent pour souligner les faits que la LSB n'est pas que un empilage d'exigences qui se superposent à l'infini sans qu'on ne retire jamais les vieilles exigences.
Une procédure de nettoyage est prévue. On commence par marquer un truc comme étant deprecated et il reste dans cet état pendant au moins 3 versions successives (soit au moins 6 ans). Ensuite seulement on peut le retirer de la LSB.
Par exemple la LSB 3.2 a passé Qt3 en deprecated.
# La liste des critiques est incomplete
Posté par reno . Évalué à 4.
- utilisation d'une librairie pour tester le multithreading buggée qui ne fonctionnait bien que sur des ordinateurs pas trop rapide, un comble!
- spécification d'une version de librairie pour le C++ instable non utilisée..
Bon la, il faut dire que l'ABI liée au C++ arrêtait de bouger a l'époque ce qui fait désordre..
Pour le coup de rpm vs deb, c'est quand même un monde que les distrib Linux n'arrivent pas a utiliser un même format de package, ce n'est qu'un format de package quand même..
C'est dommage quand même toute cette perte d'énergie pour rien!
[^] # Re: La liste des critiques est incomplete
Posté par Gregory Auzanneau (site web personnel) . Évalué à 1.
Mon dernier exemple de cette incompatibilité : J'ai essayé d'installer un Oracle RAC (oui, je sais honte à moi d'utiliser une DB proprio... Mais on a pas forcement toujours le choix, décideur préssé, toussa...) sur une debian afin de remplacer un vieux solaris. Et bien, je n'ai jamais réussi. J'ai du me rabattre sur une RH.
PS: J'espère toujours : Quelqu'un a t'il réussi à installer un Oracle RAC (10GR2 ou 11G + clusterware) sur une Debian ? Espoir, espoir...
[^] # Re: La liste des critiques est incomplete
Posté par oops (site web personnel) . Évalué à 10.
Cela sera vraiment plus simple quand on pourra ne plus utiliser de logiciel propriétaire.
[^] # Re: La liste des critiques est incomplete
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: La liste des critiques est incomplete
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: La liste des critiques est incomplete
Posté par cosmocat . Évalué à 9.
Je suis tout a fait d'accord! Utilisons le meilleur format de package!!!!
---->[ ]
[^] # Re: La liste des critiques est incomplete
Posté par Nicolas Legrand (site web personnel) . Évalué à 9.
[^] # Re: La liste des critiques est incomplete
Posté par reno . Évalué à 7.
Mais sur un format de package (et je parle bien uniquement du format de package pas de la couche d'au dessus), ça devrait quand même être possible je pense..
[^] # Re: La liste des critiques est incomplete
Posté par Nicolas Legrand (site web personnel) . Évalué à 1.
Franchement, j'y crois pas.
[^] # Re: La liste des critiques est incomplete
Posté par cosmocat . Évalué à 4.
[^] # Re: La liste des critiques est incomplete
Posté par Nicolas Legrand (site web personnel) . Évalué à 1.
Non je suis pour la diversité, notament dans le libre, je trouve que c'est une richesse. Je pense que tous les développeurs ne peuvent pas se concentrer sur quelques projets. La diversité permet d'une part de choisir, de l'autre d'accueillir plus de monde. Ensuite on peut comparer et prendre ce que l'on préfère.
[^] # Re: La liste des critiques est incomplete
Posté par dragoonway . Évalué à 2.
De la diversité naissent les idées.
[^] # Re: La liste des critiques est incomplete
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Il est donc indispensable de réaliser un équilibre entre créativité et normalisation.
Il est intéressant de tester toutes les solutions jusqu'à ce qu'une d'elles se dégage et remplisse tous les besoins. Elle sert alors de socle aux innovations suivantes.
Le logiciel libre permet cela, bien mieux que le logiciel propriétaire où les décisions sont souvent dictées par des impératifs économiques à court terme.
Je souhaiterais bien que le LSB aille plus vite mais je dois reconnaître que le
Linux Standard Base remplit parfaitement son rôle de normalisation, ni trop rapide, ni trop lent.
[^] # Re: La liste des critiques est incomplete
Posté par bubar🦥 (site web personnel) . Évalué à 5.
quoi on est pas vendredi ?
[^] # Re: La liste des critiques est incomplete
Posté par tuXico . Évalué à 2.
Je ne Te crois pas ;-P
Par contre, c'est vrai que si sur les mauvaises distrib, il y avait des alias pour pouvoir installer les paquets avec les même ordres apt-get/aptitude, ça améliorerait globalement la communauté...
quoi on est pas vendredi ?
Si si (c'est tous les jours vendredis dans ma tête ;) )
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 0.
Alors que rpm est LSB, c'est un monde que deb existe encore...
Désolé, ce n'est pas vendredi.
Le paquet ce n'est qu'un petit problème. Pour preuve, le nombre de gestionnaire de paquet...
En passant, on n'a pas besoin de rpm pour extraire un rpm. Il y a rpm2cpio.sh. Un script shell de 26 lignes.
[^] # Re: La liste des critiques est incomplete
Posté par reno . Évalué à 6.
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 1.
Fedora et Mandriva utilise le même format. Es-ce pour autant qu'on peut plus facilement installer un paquet Fedora sur Mandriva que sur Ubuntu ?
Ce n'est pas mon impression.
Il y a alien pour utiliser un rpm sur les systèmes deb. C'est bien. Mais le problème de la différence de format est si faible qu'il n'y a pas d'outil pour utiliser un deb sur un systeme rpm (à ma connaissance).
Et pourquoi ne pas standardiser les archives ?
Pourquoi ne pas virer tar pour garder que cpio.
Pourquoi ne pas virer gzip pour garder que bzip2.
Etc.
> standardiser le format des paquets ce serait déjà un progrès, non?
Oui, c'est un progrès. On on peut aussi standardiser les gestionnaires de paquet (du moins ce qui est vu par l'utilisateur).
Mais c'est un petit problème.
Faut arrêter de voir les distributions quasi uniquement sous l'angle des gestionnaires de paquet. Pour l'utilisateur, c'est une commodité utilisé temporairement. Hors "yum update", je peux passer des mois dans utiliser le gestionnaire de paquet.
[^] # Re: La liste des critiques est incomplete
Posté par reno . Évalué à 4.
>Pourquoi ne pas virer tar pour garder que cpio.
Et pourquoi pas!
Tu as déjà reçu une archive dans un format inconnu?
C'est chiant..
Après cpio, je trouve les options de l'outil de manipulation peut intuitive comparé a tar..
>Pourquoi ne pas virer gzip pour garder que bzip2.
Pour les outils de compression, le problème est un peu différent: certains sont plus performants pour certains type de donnée donc et c'est une recherche permanente..
Mais on pourrait très bien avoir un seul outil de compression avec des algo différents, cela simplifierait les choses (c'était d'ailleurs plus ou moins prévu comme ça avec gzip, mais le mainteneur a foiré en ne tardant a integrer l'algo de bzip2 donc nouvelle outil, beurk).
Avantage: si tu recois un format compressé inconnu, uniquement a mettre jour ce 'méta-compresseur' pas besoin de se poser la question: comment s'appelle le nouveau package, comment fonctionne l'outil, etc.
>Mais c'est un petit problème.
Ah? Vu le nombre de distrib, je ne pense pas que ce soit un petit problème!
Et puis a l'heure actuelle, les distrib forment une barrière entre les utilisateurs et les projets sources: des outils de gestions distribuées, de rapport d'erreur *et* un format de packaging unifié permettrait de diminuer cette barrière..
[^] # Re: La liste des critiques est incomplete
Posté par M . Évalué à 4.
Au passage le format tar est defini dans posix, sa serait bete de le jeter...
[^] # Re: La liste des critiques est incomplete
Posté par Neije . Évalué à 3.
>Ce n'est pas mon impression.
Dans l'absolu, c'est quand même plus facile d'installer un rpm sur une distrib basée sur rpm que sur deb. Idem dans le cas inverse.
Et oui, on peu très souvent prendre un paquet fedora pour installer sur mandriva et ça marche ...
Je ne dis pas que ce n'est pas simple d'installer un rpm sur ubuntu mais il y a forcément au moins une étape de plus. Je trouve donc "l'impression" très subjective ici.
Et, amha, le débat, rpm vs deb est stérile. Les deux ont a peu près les mêmes caractéristiques et les nouveautés de l'un sont copiés chez l'autre et vice versa. L'émulation joue donc ici un rôle dans l'innovation.
Après quand qq dit préféré synaptic ou autre logiciel, cela n'a rien à voir avec le format de paquet. C'est sans doute plus une question d'ergonomie.
Donc on en revient au sujet, une standardisation des formats (deb ET rpm) pour les distribs est sans doute la meilleure solution.
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
[^] # Re: La liste des critiques est incomplete
Posté par Anonyme . Évalué à 2.
Ben non, tu fais "alien -i" à la place de "dpkg -i", et si c'est un package lsb, ca devrait marcher.
[^] # Re: La liste des critiques est incomplete
Posté par Neije . Évalué à 3.
Essayons de nous mettre à la place d'un utilisateur novice :
Je constate :
1) sur une distrib rpm (ou respectivement deb) les outils du type alien ne sont pas forcément installés.
2) une distribution moderne fournit aujoud'hui presque toujours un mode graphique.
De cet état de fait : pour installer un paquet "étranger" du style un deb sur une red hat ou sur une mandriva, il faut donc que le novice s'instruise et installe les outils adéquats au lieu d'aller cliquer dans son gestionnaire de paquets.
Donc non ce n'est pas évident et de façon générale, dire qu'il suffit de taper une commande à la place d'une autre n'est pas satisfaisant amha. Car c'est aisé uniquement pour celui qui a une certaine connaissance et à ce niveau, tu peux toujours compiler les sources donc exit la dépendance vis à vis du paquet.
Loin de moi l'idée de troller sur l'usage de la console, mais il faut accepter que tout un chacun n'est pas forcément un as de la ligne de commande.
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
[^] # Re: La liste des critiques est incomplete
Posté par Anonyme . Évalué à 2.
De cet état de fait : pour installer un paquet "étranger" du style un deb sur une red hat ou sur une mandriva, il faut donc que le novice s'instruise et installe les outils adéquats au lieu d'aller cliquer dans son gestionnaire de paquets.
Que tu sois une distrib basée sur rpm ou pas, quand tu dois installer un rpm étranger, tu ne passes pas parle gestionnaire de packages habituel.
[^] # Re: La liste des critiques est incomplete
Posté par Xavier Teyssier (site web personnel) . Évalué à 6.
En sortant un peu du monde Linux pour aller vers les BSD, OpenBSD pour être plus précis, on constate que pour la compression des paquets, bzip est préféré à bzip2 car certaines architectures supportées sont très peu puissantes, et bzip2 serait trop gourmand en ressource.
bzip reste donc le format de compression par défaut afin de rester utilisable sur un maximum d'architecture.
[^] # Re: La liste des critiques est incomplete
Posté par rewind (Mastodon) . Évalué à 1.
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 6.
Car il y a apt-get sur deb ?
Ben il y a apt-get sur rpm.
Je n'ai pas de problème à passer sur deb. Ce n'est pas le changement de format le problème, c'est ce qui construit le paquet le problème. Un truc invisible à 99 % des utilisateurs.
M'enfin, si tu crois que deb te donne une supériorité absolue, et que ce sentiment d'offre l'extase, ben je te souhaite de prendre ton pied.
[^] # Re: La liste des critiques est incomplete
Posté par rewind (Mastodon) . Évalué à 6.
Moi je trouve assez cocasse que les fanboys des distrib basé sur rpm nous disent qu'il faut unifier le format de paquetage (sous-entendu ne garder que rpm) parce que LSB toussa alors que les gestionnaires pour rpm ne sont même pas unifiés. Parce que ça, c'est bien ce que voit l'utilisateur, le format il s'en fout.
[^] # Re: La liste des critiques est incomplete
Posté par Anonyme . Évalué à 0.
[^] # Re: La liste des critiques est incomplete
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Cela dit, moi je n'y connais rien à ces formats de fichiers. Peut être que c'est une pure perte de temps et d'énergie, mais je doute que c'est en trollant ici que ça changera. :)
[^] # Re: La liste des critiques est incomplete
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La liste des critiques est incomplete
Posté par nigaiden . Évalué à 1.
Pourtant, moi je placerais rpm au même niveau que apt, et tous les outils utilisant rpm (urpmi, yum...) au même niveau que ceux utilisant apt (apt-get-deprecated, aptitude...).
Je ne connais pas apt, donc j'ai peut-être tort de le mettre dans le même niveau que rpm. Est-ce qu'il s'occupe du téléchargement et des dépendances ? Les outils utilisant rpm ne sont pas compatibles entre eux (en particulier les dépôts) ; est-ce que c'est mieux avec apt ?
[^] # Re: La liste des critiques est incomplete
Posté par Dr BG (site web personnel) . Évalué à 2.
dpkg, plutôt.
[^] # Re: La liste des critiques est incomplete
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Oui. À ma connaissance, ils utilisent tous la même liste de dépôts, et le même format de dépôt.
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 2.
Yum a fait un format de dépôt indépendant du gestionnaire de paquet. Debian a dit y être intéressé et il y a eu quelques échanges positifs. Mais au final Debian n'a rien fait.
Je ne sais pas ce qu'utiliser OpenSuSE/Novell mais ce n'est pas yum.
Mandriva utilise un truc à lui.
Quelques distribution rpm utilisent apt et donc le format de dépôt apt. En passant, c'est rigolo de voir des gens dire que deb roxe et rpm puxor alors qu'ils utilisent rpm...
[^] # Re: La liste des critiques est incomplete
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 0.
apt4rpm utilise un dépôt deb comme les autres. On peut les créer aussi pour des paquets rpm.
[^] # Re: La liste des critiques est incomplete
Posté par CrEv (site web personnel) . Évalué à 3.
Mais tous les urpm* aussi
et tous les yum aussi (entre eux hein)
Je ne comprend pas pourquoi il y a souvent comparaison apt/rpm (souvent venue de personnes utilisant apt)
Comparont rpm / deb (ou même dpkg)
comparont apt/aptitude à yum/urpmi/...
Mais c'est aussi oublier smart qui, si mes souvenirs sont bons, permet d'utiliser à la fois des rpms et des deb
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 4.
Ben il y a apt pour rpm.
Yum marche très bien et est blindé de plugin pour les plus exigents.
Synaptic existe aussi pour rpm. Pas aptitude à ma connaissance.
Ceci n'a rien à voir avec le format.
> Car contrairement aux distrib basés sur rpm qui ont chacune leur gestionnaire de paquetage, il n'y a qu'un seul (bon) gestionnaire pour deb, apt, et tout le reste (apt-get, aptitude, synaptic), ce ne sont que des front-end à apt, rien de plus.
C'est un problème de distribution et non de format.
> Moi je trouve assez cocasse que les fanboys des distrib basé sur rpm nous disent qu'il faut unifier le format de paquetage
Ce n'est pas ce que j'ai dit. J'ai dit que c'était un détail et qu'il y a plein d'autres choses beaucoup plus importante.
> sous-entendu ne garder que rpm
J'ai dit que je n'avais pas de problème pour passer au format deb.
Ce qui me pose soucis, c'est la construction des paquets, etc tout ce qui est bas niveau.
Par exemple lorsqu'on construit un paquet avec rpm, des paquets debuginfo sont aussi faits. Si un programme plante, on installe les debuginfo et on lance gdb. C'est super pratique.
Rpm a plein de chose de ce type (plus que) super pratique.
> alors que les gestionnaires pour rpm ne sont même pas unifiés.
Tu disais quoi déjà ?
Apt-get, aptitude, synaptic et Ubuntu doit avoir un truc spécifique en plus de synaptic. Faudrait aussi regarder si Xandros ou Linspire n'a pas un truc spécifique...
Bref, du côté de deb ce n'est pas unifié. M'enfin, je veux bien d'accorder que c'est plus unifié.
[^] # Re: La liste des critiques est incomplete
Posté par Fopossum . Évalué à 5.
Blagues à part, on devrait plutôt réfléchir à respecter le FHS (http://www.pathname.com/fhs/ // comment on fait un lien ??) déjà dans un premier temps !
Et se décider sur l'emplacement des fichiers en général. Ma dernière expérience Debian m'a fait râler comme un putois en voyant que mes aplis web étaient installées dans /etc et pas dans /var/www/ et le foutoir de la configuration de Bind avec des source named.conf.local à la c***.
Et ne parlons pas de la conf de Apache !
Dans le même genre d'idées, je bosse avec du Solaris et j'ai des pelletées d'applis qui s'installent dans /opt. Et vas-y que j'ai du /opt/csw du /opt/sfw etc, le tout ne partageant pas les libs ! Youpie !
Alors, déjà, essayons de mettre les choses au même endroit, avec le même format de fichiers, on gagnera un peu en harmonistation.
Après, le débat deb / rpm est aussi stérile que vim / emacs (oui, vim, pas emacs, vi est atroce !), gnome / kde !
De toute manière, si un format est choisi, y'aura toujours des râleurs pour dire que le leur était le mieux.
cd /pub && more beer
[^] # Re: La liste des critiques est incomplete
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Normalement, dans /etc, il ne devrait y avoir que leur configuration. Et le corps de l'appli devrait être quelque part dans /usr.
Quant à /opt, il me semble que c'est un foutoir pour applications indépendantistes.
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 1.
Top de wiki, tue dlfp.
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 1.
Le /opt était pertinent à une certaine époque. À l'époque où on ne voulait pas écraser un fichier lors d'une installation. À l'époque où on ne voulait pas être sûr d'avoir viré un programme en faisant "rm -r -f /usr".
Aujourd'hui avec les gestionnaires de paquet /opt est presque sans intérêt et ne doit être réservé qu'a des cas très particulier.
[^] # Re: /opt le foutoir :)
Posté par Fopossum . Évalué à 4.
Les applis de blastwave s'intallent avec pkg-get, qui fait même de la gestion de dépendance. Mais, dans /opt/csw. Et pour certains trucs, graphviz par ex que j'ai installé pas plus tard que aujourd'hui, c'est /opt/csw/graphviz2 ! Avec une sous-hierarchie /lib, /bin, etc.
Les applis de sunfreeware, elles, se collent dans /usr/local..
Les applis coolstack, qu'elle sont bien pour pas avoir besoin de recompiler php 5 et mysql 5, elles se collent dans /opt/coolstack ! Et le rep par défaut d'apache devient /opt/coolstack/apache2/htdocs !!
Les applis libres packagées par Sun, qui viennent sur le Compagnion, elles se collent dans /opt/sfw ! Alors, que d'autres applis libres, venues du pool GNU, type tar sont dans /usr/sfw/bin !
On se retrouve vite avec un $PATH qui fait des kilomètres ! Et ceux qui ont jeté un oeuil au .profile-EIS savent de quoi je parle !
Dans le même genre, n'oublions pas Oracle qui n'est pas capable de fournir un script d'init pour smf !
Grrr...
cd /pub && more beer
[^] # Re: /opt le foutoir :)
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Tiens, ça, ça me rappelle le cas d'un certain système d'exploitation qui, jusqu'à très récemment, ne supportait pas les liens symboliques, et devait avec une entrée de $PATH par logiciel utilisé…
[^] # Re: La liste des critiques est incomplete
Posté par IsNotGood . Évalué à 6.
Mais certains ne veulent pas la respecter... Ou trainent des quatres fers.
> Ma dernière expérience Debian m'a fait râler comme un putois
C'était il y a longtemps, mais pareil pour moi (sauf pour le putois, j'ai tendance à râler comme un porc).
> Alors, déjà, essayons de mettre les choses au même endroit, avec le même format de fichiers, on gagnera un peu en harmonistation.
Alors essayons de bosser upstream. Elle est ici la solution. Upstream c'est aussi fhs.
Alan Cox avait fait un excellent mail il y a longtemps sur ça (désolé, j'ai perdu l'url). Car GNU/Linux est du logiciel libre (ce n'est pas le modèle cathédrale), la LSB n'a pas à définir les standards. Les standards émergent d'eux même car GNU/Linux est ouvert. Certes, parfois, rarement, ce n'est pas le cas (voir deb vs rpm). La LSB peut "enregistrer" un état du logiciel libre pour assurer la compatibilité (fhs version 2.1, gcc v3.2, etc).
Pour ma part je pense qu'une certification ISO de la LSB n'a pas de sens. GNU/Linux est trop large, trop mouvant. Une normalisation pour un language, une api, un format de document à du sens. D'autant plus que c'est indépendant de l'OS. Mais rendre ISO un OS, c'est définitivement faire un truc dépendant de l'OS c'est contre les objectifs de l'ISO, ça peut bloquer l'innovation de l'OS sans que l'utilisateur y gagne. Ce que veut l'utilisateur, est que ses document soit lisible partout, etc.
> stérile que vim / emacs (oui, vim, pas emacs, vi est atroce !), gnome / kde !
Rien à voir. Ce sont des produits différents, avec des profiles d'utilisateurs différents. Ils n'ont pas qu'un objectif technique.
[^] # Re: La liste des critiques est incomplete
Posté par Fopossum . Évalué à 2.
Rien à voir. Ce sont des produits différents, avec des profiles d'utilisateurs différents. Ils n'ont pas qu'un objectif technique.
Troll inside: Je croyais que emacs c'était un OS :p
cd /pub && more beer
[^] # /etc
Posté par Kerro . Évalué à 5.
Si tu connais une distribution qui te met des applications (web ou pas) dans /etc alors il faut vite que tu m'en donnes le nom, histoire que je sache m'en écarter.
[^] # Re: /etc
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: /etc
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: La liste des critiques est incomplete
Posté par tuXico . Évalué à 2.
Désolé, ce n'est pas vendredi.
C'est sûrement de l'humour et du coup, c'est super drôle.
# Compat binaire
Posté par M . Évalué à 5.
He ben linux n'est pas prêt de devenir grand publique alors :
james veux essayer le nouveau jeu libre qui viens de sortir. Pas de chance, pour le faire marcher sur sa distro il faut le recompiler. Apres quelques heures a se battre pour faire compiler le bousin, il redémarre sous windows et fait marché la version windows du jeu en quelques minutes
delopman a fait une petite appli sympa (un jeux a la con ou un petit utilitaire) et voudrait la partager avec tout le monde. Il a soit le choix de fournir que les sources, mais c'est pas tres convivial. Il peut aussi faire un paquet pour chaque distro, mais c'est pas cool pour lui.
[...]
[^] # Re: Compat binaire
Posté par Aris Adamantiadis (site web personnel) . Évalué à 6.
Le mois d'après, Jean tape apt-get install <nom du jeu> et peut jouer 45 secondes après. (ou utilise une interface click click, auquel cas ça lui prendra 2 minutes)
[^] # Re: Compat binaire
Posté par Anonyme . Évalué à 5.
Pour que plein de monde apprécie le jeu de Martin, encore faut-il que tout ce monde ait répondu à la problématique qui était de parvenir à compiler le jeu après s'être battu pendant des heures et sans utiliser la solution de facilité qu'était Windows. :-)
[^] # Re: Compat binaire
Posté par folliked . Évalué à 4.
On est sensé s'aider les uns les autres dans une communauté !
Mais c'est vrai, j'ai l'impression que ça tourne à l'individualisme le monde libre
On va finir par s'auto-flageller !
Martin est un bon développeur, mais il a à sa disponibilité des bons packageurs dans chaque communauté.
Donc le linuxien lambda, n'aura aucune difficulté à faire tourner le jeu de martin !
On fait mieux que sous windows, pourquoi pas continuer ainsi même si ça prend du temps personnel pour aider la communauté à s'épanouir ?
[^] # Re: Compat binaire
Posté par Anonyme . Évalué à 4.
Oui, quand le logiciel est packagé c'est l'ideal. Mais il faut que le jeu soit vraiment connu pour qu'il soit packagé sur toutes les distributions (il y en a beaucoup), et puis il faut parfois attendre longtemps avant que la dernière version soit disponible en package. Il faudrait une solution intermediaire, plus simple que la compilation meme si pas forcement aussi pratique et performante que les packages. Et donc il y a klik, qui pourrait correspondre :
http://klik.atekon.de/
[^] # Re: Compat binaire
Posté par Vincent . Évalué à 2.
Je dirais en moyenne 3-4 mois ...
Imaginons un jeu qui se joue online et dont la version doit être synchro avec le serveur, la non mis à jour est problématique ...
En fait il faudrait que les distributions créent des dépôts de paquets spécialisés dans ce genre de programme.
[^] # Re: Compat binaire
Posté par totoenstr (site web personnel) . Évalué à 3.
He ben linux n'est pas prêt de devenir grand publique alors :
Je pense également que le compatibilité binaire est importante sous GNU/Linux et pas seulement pour les logiciels propriétaires.
Par exemple le logiciel klik a besoin de la LSB pour assurer la compatibilité entre les distributions. Il offre l'avantage de pouvoir avoir un logiciel libre ou propriétaire en plusieurs version et surtout de pouvoir s'installer sur n'importe quel Linux (pas besoin d'attendre le paquet, pas besoin d'attendre un packageur intéressé, ...).
Je pense qu'il faut a la fois un gestionnaire de paquet spécifique à sa distribution et en plus des binaires compatibles entre les distros. Ca permettrait d'avoir tous les avantages d'un système de paquet plus la souplesse de pouvoir avoir des binaires commun sur toutes les distribs.
[^] # Re: Compat binaire
Posté par Anonyme . Évalué à 2.
http://klik.atekon.de/
[^] # Re: Compat binaire
Posté par letsyl . Évalué à 1.
Et comme tu le dis ce système n'est pas destiné à remplacer un gestionnaire de paquets classique. C'est d'ailleurs ce qu'en disent les auteurs dans cette (intéressante) interview : http://fosdem.org/2008/interview/kurt+pfeifle+and+simon+pete(...)
[^] # Re: Compat binaire
Posté par GG (site web personnel) . Évalué à 2.
Ah, tu oublies que pour faire tourner un jeu sous Windows, il faut le compiler pour windows, tâche que tu laisses au développeur du "jeu".
Il y a un logiciel dont la version Windows est payante, tellement c'est pénible de compiler Xchat sur cette bouse infâme qu'est Windows.
Je me suis peut être trompé de logiciel, je suis sous Linux Debian, donc non concerné. (Ah oui, Xchat n'est pas vraiment un jeu...)
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Compat binaire
Posté par CrEv (site web personnel) . Évalué à 2.
perso j'en doute...
Compiler sous windows ou sous une multitude de linux, c'est un peu pareil, il suffit de le faire proprement à la base... (utiliser des outils portables, des bonnes libs, ...)
Mais rien qui ne nécessite un cout plus important... c'est plutôt de l'oportunisme ça...
[^] # Re: Compat binaire
Posté par GG (site web personnel) . Évalué à 3.
Tu peux les compiler pour Win et diffuser le binaire, non? Est ce que cela peut poser un problème de licence?
Sinon, donner le binaire aux créaterurs de xchat...
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Quelles distributions pour quels logiciels ?
Posté par Olivier Faurax (site web personnel) . Évalué à 0.
Mais quelles sont les distributions qui supportent LSB ?
Parce que si les distributions à base de deb font la gueule, ça en enlève 2 grosses.
Après, est-ce que les autres jouent le jeu et respectent la LSB ou s'en foutent au regard des applications qui se base dessus ?
[^] # Re: Quelles distributions pour quels logiciels ?
Posté par patrick_g (site web personnel) . Évalué à 3.
Mais quelles sont les distributions qui supportent LSB ?
Bien entendu avant de poser cette question tu a cliqué sur lien que j'ai mis sur le mot "disponible" dans la phrase suivante de la news :
"Une page récapitulative de l'état de la compatibilité pour les principales distributions est également disponible".
N'est-ce pas ?
[^] # Re: Quelles distributions pour quels logiciels ?
Posté par IsNotGood . Évalué à 2.
La _certification_ est une contrainte qui ne se justifie pas toujours et notamment pour les distributions communautaires.
M'enfin, Debian qui cible aussi les entreprises ne semble pas faire beaucoup de zèle dans ce domaine.
[^] # Re: Quelles distributions pour quels logiciels ?
Posté par totoenstr (site web personnel) . Évalué à 1.
http://www.linux-foundation.org/en/LSB_Distribution_Status
Il y a la plupart des grosses distribs.
Debian Etch n'a pas la certification mais bon elle passe quasiment tous les tests : http://www.noroyalties.org/lsb/tests_results.html
Quand à Gentoo je crois que la LSB est le cadet de leur soucis.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.