Spyhawk a écrit 1154 commentaires

Merci.

C'est un exemple pour montrer que la métrique choisie n'est pas forcément pertinente.

Oui, on est d'accord la dessus. J'arrive à imaginer l'intérêt (et les sous qui vont avec) pour une archi un peu "exotique" pour des super-calculateurs, mais sur un nombre de paquets restreint, pas Debian et ses 50'000 paquets.

Compiler sur plusieurs architectures permet de trouver des bugs

C'est vrai, d'ailleurs on a déjà du faire la remarque (que j'avais totalement oubliée). Question sérieuse: si un bug n'est pas détecté par les architectures les plus importantes, peut-on considérer qu'ils ne sont pas important? Au final, ça permet d'améliorer la "beauté" du code, mais c'est peut être inutile dans la pratique?

Par contre, j'ai de gros doute quand au gros budget amené par des petites architectures.

Quand je vois que 98.6% des installations Debian tournent sur arch i386 ou x86_64 (99.3% si on ajoute ARM) selon le pop contest, je me dis que le travail requis pour maintenir le reste est un sacré gâchis de ressources inutile.

Bref, quelqu'un connait le bon mail où je peux demander le numéro IBAN (ou leur demander de l'ajouter au site) ?

L'IBAN n'est pas utilisé partout, et dans ce cas précis pas aux Etats-Unis.

C'est fou comme c'est toujours la faute à la distro…

Ca dépend. Si tu attends de ta distro une stabilité sans faille, et qu'elle vise la stabilité à tout prix comme objectif, une mise à jour qui foire c'est entièrement sa faute. Si tu utilises une distro qui place la responsabilité de l'utilisateur comme pilier de la distribution, alors l'utilisateur est responsable quoiqu'il arrive.

Tout ça pour dire qu'on ne peut pas aborder Arch Linux avec la même attitude qu'une Debian stable, tant chacune vise un public différent.

Aucune raison, vraiment ? J'en vois plusieurs. Imagine que tu maintiennes le paquet Foobar. Ta version 1.0 est dans testing, mais comme il n'y a pas eu de gel, tu sors une 1.1 en unstable. Sauf qu'on découvre un bug critique en 1.0. Comment s'en sortir en gardant un historique linéaire ?

Qu'est ce qui empêche de maintenir les deux en parallèle, patcher Foobar 1.0 puis passer à Foobar 1.1 après le dégel? C'est ce que font bien d'autres distributions "stables" par ailleurs.

Garder un historique "linéaire" à tout prix un un peu idiot, surtout à l'époque du développement facilité par des VCS comme git.

Merci. Donc simplicité versus sécurité.

Va installer le logiciel que tu veux en dehors des dépôts des ces 3 OS, et reviens nous raconter ;-)
La seule différence, c'est que leur succès a attiré beaucoup de développeur […]

Il a besoin d'utiliser des libs partagées aussi? (c'est une vrai question, je n'y connais rien à l'écosystème des smartphones).

Au passage, Linus Torvalds avait abordé ce problème lors de la DebConf14 (par contre je ne sais plus exactement où dans la vidéo..)

Du coup il est légitime de se poser la question des avantages que peut voir le DoD dans une distribution telle que SuSe pour supplanter la suprématie d'une distribution bien de chez eux.

D'après l'article, il s'agit d'un choix d'OS pour un super-ordinateur. Il me semble que SUSE a toujours eu une longueur d'avance dans ce segment sur son concurrent.

Quand à la "nationalité" de SUSE, c'était quand même une filiale de Novell depuis 2003 (Utah), puis de The Attachmant Group en 2011 (Texas), et bientôt Micro Focus International (UK). Mais il est vrai que la distrib est principalement élaborée à Nuremberg.

Un avantage des outils deb, c’est la notion d’installation pour dépendance. Ça permet de ne pas conserver un tas de trucs inutiles quand on change de logiciels, voire d’éviter qu’un système qu’on maintient pas mise à jour d’une version à une autre de la distribution enfle indéfiniment.

J'ai l'impression que tu n'as pas utilisé de distributions RPM depuis trèèèès longtemps. Y'a quelques différences entre Yum et Zypp (par example, Fedora n'implémente pas de notion de dépendances suggérées ou recommandées, au contraire d'openSUSE et Debian), mais les outils .deb n'ont globalement aucun avantage sur les outils RPM.

Bon bah faudra arrêter un jour avec la fameuse superiorité des deb sur rpm, hein. Ce ne sont que des formats d'empaquetage, et ce qui fait la différence ce sont les outils autour.

Ce qui est intéressant avec le gestionnaire de paquet openSUSE, c'est la librairie libsolv (ex-libsatsolver) qui est un solveur sat qui explose tout ce qui existe au niveau résolution de dépendances, y compris ces algo heuristiques à la apt/aptitude. L'outil cli au dessus, zypper, est franchement pas mal, même si l'interface graphique et ncurse yast livrées avec ont un peu vieillies.

Aussi, Fedora va passer à libsolv prochainement (DNF remplacant Yum, Fedora 22), et le fait que SUSE devient l'upstream de Red Hat pour une fois est assez rare pour être noté.

Si, statique.

Ce problème n'est-il pas résolu sous, par exemple, OpenSuse, avec le 1-clic-install ?

Le OCI d'openSUSE apporte plus de problème qu'il n'en résoud, àmha. Les dépôts additionnels sont ajoutés trop facilement, les librairies qui vont avec finissent par provoquer des "dependencies hell" sans fin à cause de mauvaises priorités. L'une des features la plus demandée depuis très longtemps est un "One-Click-Uninstall", preuve qu'il y a bel et bien un problème pour l'utilisateur lambda.

La seule issue pour sortir de ce modèle monolithique des distributions Linux est à mon avis de proposer les applications compilées en statique, ou de se cantonner à une audience plus "power users" seulement.

J'aime Chakra aussi parce que c'est vraiment une des distribs qui pousse le plus loin la finition dans KDE.

Tu as entendu parler de KaOS? A lire la FAQ, ça ressemble à ce qu'aurait pu devenir Chakra avant qu'ils ne se perdent à réécrire des outils spécifiques ou des bundles CCR: simple, avec une sélection limitée mais bien intégrée d'applications Qt, sans être anti-GTK non plus.

Ce qui est un peu idiot, c'est qu'il n'y a pas d'alerte ni rien dans le gestionnaire de paquet

Il existe des wrappers pour ceci, comme pacmatic. C'est pas intégré dans pacman directement pour cause de portabilité. Tout les patches "distribution spécifique" sont refusés.

Oui, pour moi, être à jour niveau sécurité est important. Au même titre que je ne vois pas l'avantage d'être sur un Windows troué, une "rolling release" qui est moins à jour au niveau sécu qu'une vrai distribution stable ça craint.

Et c'est là que le bat blesse: Stabiliser une distribution, ça demande beaucoup de temps et de travail. L'effort de backport fait par Debian, Fedora et autre openSUSE est conséquent et une vrai distribution rolling release s'affranchit de celui-ci en s'appuyant directement sur upstream, en envoyant les nouveaux paquets corrigés upstream le plus rapidement possible dans les dépôts. Une "rolling release différée" comme Manjaro, pusique c'est de ceci qu'il s'agit, n'obtient au final ni l'avantage d'une rolling release, ni celui d'une distribution stable (les changements les plus importants demandent de toute façon une intervention de l'utilisateur).

Au passage, Frugalware n'est pas dérivée d'Arch (au plus inspirée avec un fork de pacman), et il y a longtemps que Chakra n'a plus grand chose à voir avec Arch. Reste Antergos, Bridge Linux et quelques autres moins connues qui elles ne sont pas différées.

Mais bon, si l'argument au dessus ne te concerne pas, peut être que le manque de sérieux de Manjaro te ferait reconsidérer la soit disante qualité de cette distribution. Commentaire de dev Arch, au sujet du choix de s'appuyer sur une fonctionnalité dépréciée:

Personally I find this just another example of the Manjaro developers incompetency. Relying on a knowingly broken feature in the package manager that has already been removed from the upstream git sources is nothing less that a spectacular failure. Especially given I have mentioned this many months ago and not a single Manjaro developer was ever seen in the #archlinux-pacman IRC channel or the pacman-dev mailing list to advocate why the feature should be kept.

J'ai l'impression d'utiliser une distro en Rolling Release. Et je me demande donc : est-ce qu'une arch est vraiment plus stable qu'une debian testing ?

Mais Debian testing est une rolling release, sauf en période de freeze :)

La réponse officielle à ta question serait quelques chose comme "Arch est aussi stable que tu la rends stable."

Arch n'est pas casse tronche si l'utilisateur adopte un comportement responsable - exactement comme celui que tu décris - puisque toute la responsabilité des mises à jour et autres intégrations complexes lui revient.

Bah on a pas du ẽtre dans la même réalité ces 8 dernières années, ou alors c'est l'interface chaise clavier qui bugge en faisant des updates les yeux fermés de ton côté.

Pardon, qu'est ce qui n'est pas clair dans "Ils essaient de stabiliser une rolling release en retardant les updates… et les plus importants bugfix de sécurité" (l'emphase est évidemment sur la fin de phrase) ?

Arch c'est stable quand tu ne fais pas de mise à jour.
Sinon, soit ça passe, soit ça casse.

La seconde phrase est un tantinet exagérée :), mais je suis d'accord avec la première: Arch n'a pas les moyens de faire le travail de stabilisation que les "grandes" distrib font, et ça se saurait si celui-ci était totalement inutile.

Je suis utilisateur de Fedora, mais je fais quelques incartades sur openSUSE, et un changement majeur est en cours : il va y avoir une version rolling release d'opensuse une fois la 13.2 sortie.

C'est pas plutôt un changement mineur, puisque Tumbleweed existait déjà, comme tu le dis? Juste plus de tests et un peu moins de flexibilité au niveau développement pour s'assurer que Factory est moins cassée?

Heu, Manjaro, c'est probablement la pire des distrib dérivée d'Arch. Alors oui, c'est joli avec un beau fond d'écran, mais le principe sur lequel elle se base est complètement bancal àmha.

C'est un journal très pertinents vu le nombre de personnes qui ont finalement amélioré leur opinion justement des contributeurs Debian.

Mouai, bof. Le journal lui même n'est pas pertinent du tout. Je l'ai plussé, mais après m'être rendu compte qu'on peut le résumer à un gros râleur (pardon) qui se plaint plusieurs mois après les faits parce qu'il est pas fichu de faire la distinction entre "should" et "must" (seule explication possible), ben je l'aurais descendu en flèche, et je pense que je ne suis pas le seul dans ce cas.

Perso, je n'ai pas une très bonne opinion de Debian à cause de sa lourde bureaucratie et son manque de pragmatisme à un niveau plus "politique", mais je n'ai jamais et de mauvaise opinion envers ses contributeurs et packageurs. Globalement, Debian fait du bon boulot de packaging par rapport à son objectif d'obtenir et de maintenir une version "stable" sur le moyen terme. Le packageur se montre courtois, fait quelques suggestions, bref, fait ce que l'on peut attendre d'un packageur. Au final, mes opinions de Debian et de ses contributeurs n'ont pas changées, tandis que le contenu de ce journal est simplement hors sujet.

Mouai, Manjaro c'est une fausse bonne idée. Ils essaient de "stabiliser" une rolling release en retardant les updates… et les plus importants bugfix de sécurité.

Fait est, soit un veut un système en rolling release et on fait de fréquentes mises à jour pour la sécurité, soit on reste sur une distribution plus classique et on backporte les fix de sécurité. Un des dev principaux d'Arch avait parlé un peu du cas Manjaro.

Et ça, c'est quand Manjaro ne base pas son fonctionnement sur des fonctionalités upstream qui sont dépréciées depuis longtemps, et qui ne sont soudainement plus disponibles.

Je conseillerai plutôt Antergos, qui est une Arch dont l'install est prémachée à l'avance avec l'aide d'un simple dépôt.