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.
![[en]](../images/en.png)
Annonce de LSB 3.2 (290 hits)-
Présentation des nouveautés (444 hits)
> Lire la dépêche (69 commentaires, moyenne: 3,3).
Vous avez demandé le commentaire #908465.
Run by 
Cette page a été générée par Templeet en 0.1677s (dont 0.0443 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
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
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
>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
pourra ne plus utiliser n'utilise pas
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: La liste des critiques est incomplete
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
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
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
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
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
Ah, toi aussi tu parles l'esperento couramment....
[^]Re: La liste des critiques est incomplete
:-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
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
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
sources only
quoi on est pas vendredi ?
[^]Re: La liste des critiques est incomplete
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
> 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
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
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
>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
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
> >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
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
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
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
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
Je n'échangerais deb pour rien au monde contre rpm...
[^]Re: La liste des critiques est incomplete
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
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
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
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. :)
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: La liste des critiques est incomplete
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
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
Pourtant, moi je placerais rpm au même niveau que apt
dpkg, plutôt.
[^]Re: La liste des critiques est incomplete
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
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
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
> 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
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
> 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
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
[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
> [cite]
Top de wiki, tue dlfp.
[^]Re: La liste des critiques est incomplete
> 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 :)
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 :)
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
> 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
> 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
:-)
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
Il y a parfois des scripts, là-dedans. Dans /etc/acpi, par exemple, là où acpid est installé.
[^]Re: /etc
Ou /etc/init.d/* ?
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: La liste des critiques est incomplete
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.