Linux Standard Base 3.2

Posté par  (site Web personnel) . Modéré par Nÿco.
Étiquettes : aucune
0
26
fév.
2008
Linux
La Fondation Linux vient d'annoncer le 18 février la sortie de la version 3.2 du Linux Standard Base. Cette fondation Linux est un organisme à but non-lucratif qui est né en 2007 de la fusion entre l'Open Source Development Labs (OSDL) et le Free Standards Group. Selon ses statuts elle assure la promotion, le soutien, la standardisation et la défense de Linux à l'échelle mondiale. C'est notamment cette fondation qui paye le salaire de Linus Torvalds et de Theodore Ts'o. De nombreuses firmes sponsorisent la fondation et la liste de ses membres est très impressionnante.

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).
La norme LSB 3.2 constitue donc une avancée notable du standard puisqu'elle intègre de nombreux composants modernes faisant partie de toutes les distributions.
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

  • # Et dans les autres cas ?

    Posté par  . Évalué à 5.

    "Cela signifie que les nouvelles exigences des versions récentes ne font souvent que s'ajouter aux anciennes sans les remplacer."
    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  (site Web personnel) . Évalué à 8.

      >>> Et dans les cas pas couverts par le "souvent" ? Il se passe quoi ? Et quels sont ces cas ?

      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  . Évalué à 4.

    La liste des critiques est incomplète, entre autre il y avait:
    - 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  (site Web personnel) . Évalué à 1.

      C'est vrai que le jour où toutes les distribs seront harmonisées, cela sera vraiment plus simple pour utiliser un soft binaire et tous les petits scripts qui entourent ces programmes.

      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  . Évalué à 9.

      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..

      Je suis tout a fait d'accord! Utilisons le meilleur format de package!!!!


      ---->[    ]
      • [^] # Re: La liste des critiques est incomplete

        Posté par  (site Web personnel) . Évalué à 9.

        Profitons en aussi pour n'utiliser que la meilleure distribution qui propose le meilleur gestionnaire de bureau par défaut.
        • [^] # Re: La liste des critiques est incomplete

          Posté par  . Évalué à 7.

          Moui, la différence c'est que dans KDE/Gnome, vi/emacs, il y a plein de différence purement subjective.

          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  . Évalué à 2.

          Pis faut arreter l'informatique, c'est plié, merci au suivant.
          De la diversité naissent les idées.
          • [^] # Re: La liste des critiques est incomplete

            Posté par  (site Web personnel) . Évalué à 7.

            De la diversité naissent les idées et l'innovation, mais aussi la pagaille.
            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  . Évalué à 5.

      sources only
      quoi on est pas vendredi ?
      • [^] # Re: La liste des critiques est incomplete

        Posté par  . Évalué à 2.

        sources only
        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  . Évalué à 0.

      > 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

      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  . Évalué à 6.

        Il y a deux choses: les paquets et les gestionnaire de paquets, s'il est probablement impossible de standardiser les gestionnaire de paquets, standardiser le format des paquets ce serait déjà un progrès, non?
        • [^] # Re: La liste des critiques est incomplete

          Posté par  . Évalué à 1.

          C'est un problème mineur, une mauvais façon de voir le problème, etc...

          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  . Évalué à 4.

            >Et pourquoi ne pas standardiser les archives ?
            >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  . Évalué à 4.

            Pourquoi ne pas virer tar pour garder que cpio.
            Au passage le format tar est defini dans posix, sa serait bete de le jeter...
          • [^] # Re: La liste des critiques est incomplete

            Posté par  . Évalué à 3.

            > >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.

            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  . Évalué à 2.

              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.

              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  . Évalué à 3.

                non, dsl mais je ne pense qu'il soit juste de raisonner ainsi.

                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  . Évalué à 2.

                  Si le package LSB est installé, alien doit etre la. Après, ce n'est pas très compliqué d'associer les fichiers de type .rpm à alien pour les installer quand on double clique dessus, c'est peu etre meme deja le cas actuellement.

                  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  (site Web personnel) . Évalué à 6.

            Pourquoi ne pas virer gzip pour garder que bzip2.

            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  . Évalué à 1.

        Je n'échangerais deb pour rien au monde contre rpm...
        • [^] # Re: La liste des critiques est incomplete

          Posté par  . Évalué à 6.

          Et pourquoi ?
          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  . Évalué à 6.

            Une des raisons qui me font préférer deb à rpm, c'est surtout les outils qu'il y a au dessus, ou plutôt devrais-je dire l'outil qu'il y a au dessus : APT. 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.

            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  . Évalué à 0.

              Donc selon toi l'avantage de deb par rapport à rpm c'est qu'il n'y a pas le choix dans le gestionnaire de package à utiliser ?
              • [^] # Re: La liste des critiques est incomplete

                Posté par  (site Web personnel) . Évalué à 3.

                Je crois que ce qu'il dit c'est plutôt que les choix qui s'offrent à toi pour gérer tes deb utilisent tous une base commune, et si je comprends bien, ce n'est pas le cas des rpm qui n'ont pas d'équivalent à ce socle.

                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  . Évalué à 2.

                  Il n'existe pas que deb, rpm et emerge dans la vie. Regardez conary par exemple

                  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  . Évalué à 1.

                  Je crois que ce qu'il dit c'est plutôt que les choix qui s'offrent à toi pour gérer tes deb utilisent tous une base commune, et si je comprends bien, ce n'est pas le cas des rpm qui n'ont pas d'équivalent à ce socle.

                  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  (site Web personnel) . Évalué à 2.

                    Pourtant, moi je placerais rpm au même niveau que apt

                    dpkg, plutôt.
                  • [^] # Re: La liste des critiques est incomplete

                    Posté par  (site Web personnel) . Évalué à 1.

                    Les outils utilisant rpm ne sont pas compatibles entre eux (en particulier les dépôts) ; est-ce que c'est mieux avec apt ?

                    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  . Évalué à 2.

                      Malheureusement non.
                      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  (site Web personnel) . Évalué à 1.

                        Je me suis mal exprimé, je voulais dire qu'à ma connaissance, tous les outils APT (les vrais, pas les apt4rpm) utilisaient les mêmes dépôts, sur un système donné.
                        • [^] # Re: La liste des critiques est incomplete

                          Posté par  . Évalué à 0.

                          > Je me suis mal exprimé, je voulais dire qu'à ma connaissance, tous les outils APT (les vrais, pas les apt4rpm)

                          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  (site Web personnel) . Évalué à 3.

                          oui, tous les outils apt utilisent le même type de dépot.
                          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  . Évalué à 4.

              > Une des raisons qui me font préférer deb à rpm, c'est surtout les outils qu'il y a au dessus, ou plutôt devrais-je dire l'outil qu'il y a au dessus : APT.

              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  . Évalué à 5.

        Franchement, je sais pas pour vous, mais moi, je m'en contre-fiche du format des paquets. emerge rulez !

        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  (site Web personnel) . Évalué à 4.

          [cite]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***.[/cite]

          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  . Évalué à 1.

            > [cite]

            Top de wiki, tue dlfp.
          • [^] # Re: La liste des critiques est incomplete

            Posté par  . Évalué à 1.

            > Quant à /opt, il me semble que c'est un foutoir pour applications indépendantistes.

            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  . Évalué à 4.

              Faudrait leur sussurer ça au creux de l'oreille chez Sun :)

              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  (site Web personnel) . Évalué à 5.

                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 !

                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  . Évalué à 6.

          > 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 !

          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  . Évalué à 2.

            > 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.


            Troll inside: Je croyais que emacs c'était un OS :p

            cd /pub && more beer

        • [^] # /etc

          Posté par  . É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: La liste des critiques est incomplete

        Posté par  . Évalué à 2.

        Alors que rpm est LSB, c'est un monde que deb existe encore...
        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  . Évalué à 5.

    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.

    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  (site Web personnel) . Évalué à 6.

      Martin a fait un super jeu apprécié par plein de monde. Il contacte quelques distributions qui font les packages et integrent le jeu dans universe.
      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  . Évalué à 5.

        -> Martin a fait un super jeu apprécié par plein de monde.

        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  . Évalué à 4.

          Quand une communauté en est réellement une. Si le jeu est vraiment bon. Les gens qui ont des facilités pour packager un logiciel, se dépatouillent toujours pour remettre la version packagée d'un bon logiciel pour en faire profiter tout le monde ! Il me semble que ça se passe encore comme cela. Je vous trouve bien pessimiste !

          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  . Évalué à 4.

            Quand une communauté en est réellement une. Si le jeu est vraiment bon. Les gens qui ont des facilités pour packager un logiciel, se dépatouillent toujours pour remettre la version packagée d'un bon logiciel pour en faire profiter tout le monde ! Il me semble que ça se passe encore comme cela. Je vous trouve bien pessimiste !

            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  . Évalué à 2.

        Je trouve ton commentaire très pertinent, mais le délai est rarement de 1 mois pour que le paquet arrive dans une distribution stable.
        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  (site Web personnel) . Évalué à 3.

      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.

      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  . Évalué à 2.

        Effectivement, klik est interessant pour ca. Ca ne remplace pas un gestionnaire de packages classique, par ce que ce n'est pas aussi pratique et performant, mais ca peut etre bien d'avoir ca en plus pour utiliser un programme qui n'a pas encore été packagé, ou une version spécifique.

        http://klik.atekon.de/
        • [^] # Re: Compat binaire

          Posté par  . Évalué à 1.

          Je trouve klik (et notamment klik2) prometteur, il devrait trouver sa place entre les gestionnaires de paquets et l'installation par les sources.
          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  . Évalué à 2.

      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

      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
      • [^] # Re: Compat binaire

        Posté par  (site Web personnel) . Évalué à 2.

        c'est réellement la raison du prix de xchat ?
        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  . Évalué à 3.

          Il y a les sources.

          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...
  • # Quelles distributions pour quels logiciels ?

    Posté par  (site Web personnel) . Évalué à 0.

    Bon, ok, très bien.

    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 ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.