Les différences peuvent se regrouper en quatre catégories : l'emplacement des fichiers, les divers systèmes de paquetages, les versions de logiciels, l'intégration dans les menus.
Une solution partielle que l'on attend toujours (en pratique) : le Linux Standard Base.
Un avis perso : il serait intéressant d'annoncer pour chaque nouvelle distrib sa compatibilité avec le LSB/FSH, et de promouvoir les plus respecteuses.
Aller plus loin
- Article LWN.net (2 clics)
- Article original ZDnet (2 clics)
- LSB/FSH (2 clics)
# Bah oui mais...
Posté par Wawet76 (site web personnel) . Évalué à 1.
Ce ne sont pas les logiciels commerciaux qui sont génés par cette diversité, ce sont les logiciels non-libres.
En effet coté logiciel libre il n'y a pas de problème : Les auteurs fournissent la plupart de temps un mécanisme basé sur autoconf qui marche du premier coup ou indique clairement ce qui manque.
Les binaires sont souvent spécifiques à une distrib, mais ils sont fait par le groupe qui édite cette distrib ou par des gens qui la connaissent très bien.
Je pense que cette séparation entre les gens qui écrivent les softs et ceux qui les packagent est la clé d'un système aisement administrable.
[^] # Re: Bah oui mais...
Posté par ufoot (site web personnel) . Évalué à 1.
Autoconf roulaize, voilà tout.
Si Oracle et cie veulent que leur softs s'installent comme il faut, z'ont qu'à changer de license et les éditeurs de distrib se feront un plaisir de faire eux-même le build des binaires.
Si les éditeurs de logiciels propriétaires ont du mal à maitriser la compatibilité entre les distribs, c'est leur faute à eux, pas celle des distribs.
En plus, les problèmes de compatibilité binaire ne sont pas le propre de Linux, les UNIX propriétaires qui l'ont précédé ne valaient pas beaucoup mieux. Genre n'importe quel soft devait exister en 50 versions pour pouvoir tourner sur Solaris, HP-UX etc... Evidemment je suis de mauvaise foi car les processeurs n'étaient pas les mêmes, mais bon, UNIX n'a jamais été champion dans le domaine de la compatibilité binaire.
"ouais mais les binaires ELF tralala compatible Solaris..."
Euh, lancer Solaris sur un i386, c'est vraiment une bonne idée? Hein? Laissez moi rire...
[^] # Re: Bah oui mais...
Posté par Anonyme . Évalué à 0.
# Toujours pareil
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Si c'est effectivement la diversité des développeurs qui a fait évolué Linux de façon très rapide, ce sera peut-être la diversité des distributions qui le conduira à sa perte. Mon avis à moi que j'ai, c'est qu'il est temps que le LSB sorte. Même si je ne suis pas contre les distribs, il faudrait que leurs concepteurs arrêtent un peu d'essayer d'être Bill à la place de Bill (Un seul, ça suffit amplement). Ainsi les très Windowsiens de Red Hat (Make money, make money) devrait trouver une hiérarchie de fichiers qui respecte quand même quelques conventions du monde Unix, ne serait-ce que ça. En effet, le système de paquetages peut rester propriétaires car il n'est pas nécessaire de le connaître pour faire de l'administration pure et dure (gestion des utilisateurs ...), je ne parle pas des versions de logiciels ni de l'intégration dans les menus car pour le premier point, si le logiciel est bien codé, il y a compatibilité ascendante entre les anciennes versions et les nouvelles. Pour ce qui est du second point, je trouve ça purement secondaire et que c'est une préoccupation de Window$ user. N'oublions quand même pas que Linux est avant tout un Unix-like et que même sur des Unix propriétaires vieux de trente ans mais possèdant depuis les années 80 des window managers, les incompatibilités entre window manager sont légion. Vouloir uniformiser l'intégration des menus, c'est vouloir faire coopérer les équipes de Gnome, KDE etc...
Un avis perso : j'utilise FreeBSD et même si les détracteurs diront qu'il n'y a qu'une version et pas plusieurs distribs, je répondrai qu'entre les *BSD et pour ce qui est du système pur, il n'y a pas de différence notable (gènante comme les fichiers de conf entre Slackware et Mandrake)
[^] # Re: Toujours pareil
Posté par Wawet76 (site web personnel) . Évalué à 1.
Voila un bel exemple de mon propos d'un peu au dessus.
Sur la Debian (je ne sais pas pour les autres, mais ca doit etre pareil), les menus sont uniformisés entre tous les WM. Et ce ne sont ni les developpeurs de Gnome ni ceux de KDE qui s'occupent de ca.
[^] # Re: Toujours pareil
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Personnellement, j'ai pas franchement envie de me colletiner toutes les distribs afin d'être capable de faire de l'admin partout sous prétexte que chaque distrib est devenue un os à part entière avec seulement le système de fichiers et le noyau comme point commun.
[^] # SysV/Mandrake
Posté par Rafael Pinilla . Évalué à 1.
Debian, c'est une seule distrib. Je ne crois pas que je vais tenter progeny car lors d'une dist-upgrade, un paquet unstable a écrasé le hostname de mon portable en progeny$ (avec les corrolaires, httpd qui tombe, etc). J'ai eu du mal à l'avoir, (c'était pas que /ets/hosts mais j'étais prévenu avec les paquets unstable)
Debian est il compliant LSB ?
[^] # Re: SysV/Mandrake
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: SysV/Mandrake
Posté par Ano . Évalué à 1.
Ayant été moi aussi victime des éxactions de Mandrake (ne serai-ce que pour choisir les services au démarrage: drakexservices vs. ntsysv), et de la hyerarchie non-standard de la Suze, je suis pour une standardisation poussée...
Vu le lien, ca sent la Debian... De toutes facons, qu'est-ce qui empèche d'installer rpm sur debian et de régler les pb de libs dynamiques par quelqes liens?
[^] # Re: SysV/Mandrake
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Je me rappelle l'époque où les seuls choses qui différenciaient les distribs, c'étaient les softs fournis avec mais que tout le monde utilisait encore un outil unique : le tarball (tar.gz ou tgz pour les incultes).
PS: J'arrête le pinard le midi parce qu'à chaque fois, je pars dans des élans lyriques.
[^] # Sujet polémique ? petit rappel, long.
Posté par Rafael Pinilla . Évalué à -1.
On peut en conclure que le sujet est d'actualité, polémique et important.
Sans vouloir provoquer des flame-wars, je considère que la conception générale de la Debian est une évolution d'un stade supérieur à celle des autres distributions (les commerciales).
Au début étaient les distributions TarGéZaides à la SLS, Yggdrasil, Slackware. On controle tout, on édite ses fichiers de config à la main, avec un bon vieux éditeur de texte. On est obligé de connaitre les syntaxes des fichiers en question. On se forme+++. Après celles-ci, on sait compiler même un package rare.
Désormais, les compilations sont simples (merçi autoconf). Le nombre des packages logiciels a subi une croissance exponentielle (à vue de nez, mais personne je crois ne me démentira, sourceforge, freshmeat et la démocratisation des CVS est passée par là, le bazaar s'agrandit). Les petits jeunes font du C à l'école, installent Linux sur leur vieux pentiums, quand ils ne se voient pas proposer des cours sur le développement de device drivers sous Linux (Paris 13, PUB).
Ensuite viennent Les Red Hat Packages. Ouais, c'est trop fort, ton pompes ton package, tu installes par un rpm -Uvh toto.rpm et puis c'est tout.
Erreur (que tout le monde à commis, enfin moi si, j'avoue), comme le système de dépendance rale dès que manque un package de librairie (cas le plus courant), à l'installation suivante d'une RedHat like, on installe tout, on a des Gigas partout, alors pourquoi pas. Problème: au bout de quelques mois, on se retouve avec les 72 versions de la libZorglub-2.Y.Z.T, qu'on a dû installer à chaque fois que l'appli Zorglub (qu'on aime bien, on ne se refait pas) est upgradée. Jamais on a effacé la LibZorglub-0.0.1 et les 70 suivantes, toujours inutilisées...
Et puis un jour, on découvre le système Debian, né dans l'esprit de réveurs, pour qui rien n'est trop dur. Debian, c'est un système de banque de package centralisé, mais poly-miroité-distribué-dans-ton-quartier, c'est 2 familles de packages (en gros), les stables pour les ceusses qui bossent en production, et les unstable pour les ceusses qui surfent on the top of the weave du dernier bidule qui tue. C'est l'installation automatique des dépendances, avec effacemement des vielles lib désuettes (si elles ne sont plus utilisées).
Debian, est objectivement à un stade d'évolution conceptuelle plus avancée que les autres distributions, parce que son système de package avec la Banque de paquet centraliséé, mais poly-miroitée-distribuée-dans-ton-quartier (indissociable) permet une évolution du système inventée par des ceusses qui en rêvaient.
Voilà. Je suis personnellement passé par les 3 étapes. Vous devinerez que j'ai rêvé de la troisième étape logntemps avant de me rendre compte qu'elle existait déjà. Debian, j'ai longtemps crû que c'était une distrib comme les autres, en fait non, elle est libre, communautaire, démocratique, à ta vitesse. Tu en fais ce que tu veux, comme tu veux.
Debian?, j'en suis heureux.
[^] # bug
Posté par Wawet76 (site web personnel) . Évalué à 1.
(D'ailleurs c'est bien apparu sur linuxfr.linuxfr-news)
# diversité
Posté par Anonyme . Évalué à 0.
La diversité n'est pas nouvelle, c'est pas le "phénomène Linux" qui l'a crée. Regardez il y a 10 ans, il y avait déjà pas mal d'Unix. Allez, donnez un chiffre, 20 - 30 en circulation ?
Ça voulait dire quoi ? Ça voulait dire que les développeur devait faire leur boulot proprement, il fallait ensuite consacrer un moindre effort au packaging qui lui était propre à un système donné (encore que ...).
Alors ce soit-disant problème de diversité n'existe pas, c'est un mythe.
Dans un script shell, `cat' c'est `cat', `sed' c'est `sed' ... En C read() et write() font ce à quoi tu t'attends. Est-ce vraiment nécessaire de développer ?
Oh, un exemple de boite produisant du logiciel de qualité sous Un*x (pas seulement GNU/Linux) : TrollTech avec Qt. Non, franchement j'ai bien d'autre exemples, mais ça devient ridicule : arretez de vous laisser ramolir le cerveau par des journalistes !
Bon, il me semble tout de même que certains essaient de montrer les bénéfices de la diversité ... mais tout de même.
[^] # Re: diversité
Posté par Sebastien . Évalué à 1.
Ohh le rêveur, il croit que le C est portable ! Write once run everywhere !
Oui oui bien sur 90 % d'un prog en C est souvent portable... mais cela ne suffit pas pour que ça marche partout. Regarde la complexité d'un makefile, penche toi aussi sur des outils comme imake, et tu verras que la portabilité est un pb complexe.
# diversité win32.
Posté par schyzomarijks . Évalué à 1.
Sans vouloir entrer dans le trol Win/Linux, je tiens à préciser que faire un programme d'installation sous win est loin d'être évident. Il existe une quantité de plateformes différentes. WinNT, 2000 95 98, Me XP, En plus les répertoires d'installations sont différent suivant la localisation de l'OS (common files/ fichiers partagés).
Viennent ensuite les dépendances de DLL et leur versions.(mfc42 pour ne citer que celle là)
Puis les enregistrements d'OCX. Que faire lorsqu'il y en a un qui ne veux pas s'enregistrer?
Ce n'est donc pas plus facile sous win* que sous les différentes distribs. Si l'on veut un prog d'install qui s'adapte sur toutes les plates formes, il faut une réel volonté et c'est une démarche fastidieuse.
Cependant,je suis d'accord que l'emplacement des fichiers, et l'intégration dans les menus sous Linux doivent être améliorer.
[^] # Re: diversité win32.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: diversité win32.
Posté par Sebastien . Évalué à 1.
C'est un boulot malheureusement pour l'utilisateur, heureusement pour les sociétés de services, qui est souvent negligé....
# Diversité
Posté par Frédéric Massot (site web personnel) . Évalué à 1.
Pour les administrateurs une base commune, un ensemble de régles d'organisation des distribs est a mon avis le minimum necéssaires. (C'est vrai que si vous n'utiliser qu'une seule distrib ...).
[^] # De toute façon diversité il y aura.
Posté par Wawet76 (site web personnel) . Évalué à 1.
Mais Alien n'a jamais convertit un package i386 en package PPC.
On touche là à un autre aspect de la diversité qu'offre les logiciels libres. (et où une uniformisation serait vraiment une grosse perte)
"(C'est vrai que si vous n'utiliser qu'une seule distrib ...)"
Ah ? Il en existe d'autre ?
;)
[^] # Re: Diversité
Posté par Anonyme . Évalué à 0.
Une langue commune à tous les Français est à mon avis "le minimum necéssaires". ("C'est vrai que si vous n'utiliser" pas les règles de grammaire/conjugaison/orthographe, on n'est pas sortis de l'auberge...)
[^] # Re: Diversité
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Merci d'avance de poster des choses intelligentes et nécessaires à la communauté.
# Banir ceux qui ne respecte pas la LSB
Posté par Anonyme . Évalué à 0.
Pour l'instant, seul SuSE (surtout), Caldera et Turbo sont fervent defendeurs de la LSB.
Mandrake et Redhat crachent dessus, a vous de decider ...
[^] # Re: Banir ceux qui ne respecte pas la LSB
Posté par schyzomarijks . Évalué à 1.
Mandrake a dit dans son interview dans linuxfr qu'il serait conforme au LSB.
[^] # Re: Banir ceux qui ne respecte pas la LSB
Posté par Ashimaru Cobaye . Évalué à 1.
http://www.linuxbase.org/(...)
tu verras que RH et MDK font partie des groupes de reflexion de la LSB.
Si tu n'es pas convaincu regarde les mails-archives....
[^] # Re: Banir ceux qui ne respecte pas la LSB
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Banir ceux qui ne respecte pas la LSB
Posté par Anonyme . Évalué à 0.
Imagine un newbie, qui charge une distib libre et qui est incapable d'installer son soft préferré.
=> effet garanti : Linux c'est de la merde.
Voila pourquoi il faut un minimum de standardisation (style LSB) pour toutes les distribs. Ca mange pas de pain et ca n'interdit en rien l'évolution des softs et du noyau. (Fixer des règles de grammaire n'a jamais empéché quiconque de créer un nouveau mot :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.