Articles précédents : Articles
- [26] Claws Mail abandonne son greffon ClamAV
- [5] Rétrospective April 2007 sur le logiciel libre et les sujets afférents
- [62] Un point sur le projet Nouveau
- [93] Les spécifications des formats Microsoft Office enfin publiées
- [117] Point sur l'EeePC, 3 semaines après son lancement
- [15] Sortie de Chronopolys 1.0 rc2
- [40] Picidae : Une nouvelle arme libre contre la censure de l'Internet
- [26] Prix Turing 2007 : le "Model checking" a vaincu
- [70] Le ministère de la Défense suit la voie tracée par la gendarmerie
- [49] Intel livre les spécifications complètes et sans NDA des chipsets graphiques récents
Liens connexes
- Annonce de LSB 3.2 (296 hits)
- Présentation des nouveautés (448 hits)
Dépêche modérée par
Dépêche éditée par
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.
Annonce de LSB 3.2 (296 hits)
Présentation des nouveautés (448 hits)
> Lire la dépêche (69 commentaires, moyenne: 3,3).
- 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.
Et dans les autres cas ?
"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 patrick_g (page perso, ) le 26/02/2008 à 15:07. (lien). É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
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 Gregory Auzanneau (page perso, ) le 26/02/2008 à 15:37. (lien). É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 oops (page perso, ) le 26/02/2008 à 15:51. (lien). Évalué à 10.>cela sera vraiment plus simple pour utiliser un soft binaire
Cela sera vraiment plus simple quand on pourra ne plus utiliser de logiciel propriétaire.-
[^]Re: La liste des critiques est incomplete
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 26/02/2008 à 16:07. (lien). Évalué à 4.pourra ne plus utiliser n'utilise pas
-
-
[^]Re: La liste des critiques est incomplete
Posté par Nicolas Boulay () le 26/02/2008 à 17:19. (lien). Évalué à 2.Si cela plante genre coredump, regarde a la loupe les versions de gcc/g++ utilise pour compiler les libs utilise par ton binaire. Si c'est du c++, les ABI ont beaucoup bouge ses derniers annees.
-
-
[^]Re: La liste des critiques est incomplete
Posté par cosmocat () le 26/02/2008 à 15:58. (lien). É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 Nicolas Legrand () le 26/02/2008 à 16:07. (lien). É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 reno () le 26/02/2008 à 16:50. (lien). É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 Nicolas Legrand () le 27/02/2008 à 20:45. (lien). Évalué à 1.Oui et on devrait aussi tous parler la même langue et arrêter avec tous ces dialectes.
Franchement, j'y crois pas.-
[^]Re: La liste des critiques est incomplete
Posté par cosmocat () le 28/02/2008 à 01:56. (lien). Évalué à 4.Ah, toi aussi tu parles l'esperento couramment....
-
[^]Re: La liste des critiques est incomplete
Posté par Nicolas Legrand () le 29/02/2008 à 08:40. (lien). Évalué à 1.:-D
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 () le 26/02/2008 à 22:03. (lien). Évalué à 2.Pis faut arreter l'informatique, c'est plié, merci au suivant.
De la diversité naissent les idées.--
o--weed-is-communism--o-
[^]Re: La liste des critiques est incomplete
Posté par Pierre Jarillon (page perso, ) le 27/02/2008 à 12:16. (lien). É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 bubar () le 26/02/2008 à 15:59. (lien). Évalué à 5.sources only
quoi on est pas vendredi ?-
[^]Re: La liste des critiques est incomplete
Posté par tuXico () le 27/02/2008 à 12:51. (lien). É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 ;) )--
Ce message aurait très bien pu être au second degré.
-
-
[^]Re: La liste des critiques est incomplete
Posté par IsNotGood () le 26/02/2008 à 16:27. (lien). É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 reno () le 26/02/2008 à 16:52. (lien). É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 IsNotGood () le 26/02/2008 à 17:30. (lien). É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 reno () le 26/02/2008 à 21:02. (lien). É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 Matthieu C () le 26/02/2008 à 22:10. (lien). É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 Neije () le 27/02/2008 à 08:43. (lien). É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.-
[^]Re: La liste des critiques est incomplete
Posté par boklm (page perso, ) le 27/02/2008 à 14:00. (lien). É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 Neije () le 28/02/2008 à 10:29. (lien). É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.-
[^]Re: La liste des critiques est incomplete
Posté par boklm (page perso, ) le 28/02/2008 à 12:01. (lien). É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 Xavier Teyssier (Jabber id, page perso, ) le 27/02/2008 à 11:28. (lien). É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 rewind () le 26/02/2008 à 17:21. (lien). Évalué à 1.Je n'échangerais deb pour rien au monde contre rpm...
-
[^]Re: La liste des critiques est incomplete
Posté par IsNotGood () le 26/02/2008 à 17:37. (lien). É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 rewind () le 27/02/2008 à 09:54. (lien). É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 boklm (page perso, ) le 27/02/2008 à 14:05. (lien). É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 Mathieu Stumpf (Jabber id, page perso, ) le 27/02/2008 à 15:21. (lien). É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 Barret Michel (page perso, ) le 27/02/2008 à 18:59. (lien). Évalué à 2.Il n'existe pas que deb, rpm et emerge dans la vie. Regardez conary par exemple
--
Debian Sid
-
[^]Re: La liste des critiques est incomplete
Posté par nigaiden () le 27/02/2008 à 19:50. (lien). É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 Benoît Guédas (Jabber id, ) le 27/02/2008 à 20:01. (lien). É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 Tanguy Ortolo (page perso, ) le 27/02/2008 à 21:29. (lien). É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 IsNotGood () le 27/02/2008 à 22:36. (lien). É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 Tanguy Ortolo (page perso, ) le 27/02/2008 à 23:30. (lien). É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
-
[^]Re: La liste des critiques est incomplete
Posté par CrEv (page perso, ) le 28/02/2008 à 07:54. (lien). É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 IsNotGood () le 27/02/2008 à 22:28. (lien). É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 Possum Marsupial Power (Jabber id, page perso, ) le 26/02/2008 à 18:05. (lien). É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.-
[^]Re: La liste des critiques est incomplete
Posté par Tanguy Ortolo (page perso, ) le 26/02/2008 à 19:02. (lien). É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
-
[^]Re: La liste des critiques est incomplete
Posté par IsNotGood () le 26/02/2008 à 19:15. (lien). É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 Possum Marsupial Power (Jabber id, page perso, ) le 26/02/2008 à 19:51. (lien). É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...-
[^]Re: /opt le foutoir :)
Posté par Tanguy Ortolo (page perso, ) le 26/02/2008 à 23:51. (lien). É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 IsNotGood () le 26/02/2008 à 19:10. (lien). É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 Possum Marsupial Power (Jabber id, page perso, ) le 26/02/2008 à 19:53. (lien). É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
-
-
[^]/etc
Posté par Kerro () le 26/02/2008 à 19:18. (lien). É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.--
Qui a existé en premier: le compilateur ou son code source ?-
[^]Re: /etc
Posté par Tanguy Ortolo (page perso, ) le 26/02/2008 à 23:53. (lien). Évalué à 1.Il y a parfois des scripts, là-dedans. Dans /etc/acpi, par exemple, là où acpid est installé.
-
[^]Re: /etc
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 27/02/2008 à 15:31. (lien). Évalué à 2.Ou /etc/init.d/* ?
-
-
-
-
[^]Re: La liste des critiques est incomplete
-
Compat binaire
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 Aris Adamantiadis (page perso, ) le 26/02/2008 à 23:12. (lien). É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 ♪♬♬♩ ♫♪♬♩ () le 27/02/2008 à 09:09. (lien). É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 folliked () le 27/02/2008 à 09:22. (lien). É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 boklm (page perso, ) le 27/02/2008 à 14:22. (lien). É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 mrlag (Jabber id, page perso, ) le 27/02/2008 à 14:37. (lien). É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.--
\_o<
-
-
[^]Re: Compat binaire
Posté par totoenstr (page perso, ) le 27/02/2008 à 10:44. (lien). É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 boklm (page perso, ) le 27/02/2008 à 14:12. (lien). É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 letsyl () le 27/02/2008 à 15:29. (lien). É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 Grégoire G (Jabber id, page perso, ) le 29/02/2008 à 06:01. (lien). É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 CrEv (page perso, ) le 29/02/2008 à 09:44. (lien). É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 Grégoire G (Jabber id, page perso, ) le 01/03/2008 à 00:42. (lien). É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 ?
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 ?
xmpp:ofaurax@jabber.fr
-
[^]Re: Quelles distributions pour quels logiciels ?
Posté par patrick_g (page perso, ) le 27/02/2008 à 20:07. (lien). Évalué à 3.Bon, ok, très bien.
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 () le 27/02/2008 à 22:42. (lien). Évalué à 2.La certification est payante.
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 (page perso, ) le 28/02/2008 à 14:41. (lien). Évalué à 1.Mais quelles sont les distributions qui supportent LSB
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.




Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.