Cela fait maintenant 10min que mon PC tente de passer de la 22.04 à la 24.04.
Le suspens est à son comble.
@dada deux choix qui me rendent malade...
Je n'ai jamais compris cet engouement pour les distriq debian like. Rien que la construction non vérifiée de paquets est problématique.
Un jour faudra que quelqu'un essaye de me démontrer en quoi ces deux distros sont au dessus de Fedora (serveur ou desktop)
@metal3d @dada Et en quoi Fedora serait suffisamment supérieur pour y migrer quand Debian fait parfaitement le travail ? Parce que bon, ça marche dans les deux sens.
Au taf on a du Debian partout sur les serveurs, et je trouve Debian particulièrement adapté à l’usage qu’on en a.
En perso j’ai du Arch sur serveur comme sur PC, et je le trouve adapté à mes besoins.
Tu colles du Fedora partout et tu le trouves adapté à tes besoin.
N’est-ce pas tout ce qui compte ?
Ce qui compte, selon moi, c'est d'avoir des paquets avec une validation propre.
Prenons, `bpytop`, depuis des lustres si tu l'installes sur un env Ubuntu ou Debian, il ne marche pas, parce qu'à tous les coups ils oublient des dép (genre psutils)
Les versions sont souvent à la rue, `podman` est ingérbale, des paquets font doublons, etc...
Depuis 22 ans, j'ai testé, retesté, etc... c'est, à mon sens, fou d'utiliser Debian/Ubuntu sur un serveur de prod.
héhé, non mais qu'on soit clairs: je ne critique pas l'utilisation en soit, parce que oui: ça marche.
Mais ce que je dis, c'est que je ne comprends pas pourquoi tout le monde fonce tête baissée dessus alors qu'on est pas mal de "vieux roublards" à savoir que c'est pas du tout l'idéal.
PS: je ne mets pas de Fedora Server à mes clients, on passe par Rocky ou RH - pour l'heure ils sont tous d'accord avec moi sur le fait que Debian est "risqué" à leurs yeux
@metal3d @dada Les vieux roublards je m’en méfie, je suis trop souvent tombé sur des types avec des idées arrêtées au mieux bancales au pire erronée (un exemple frappant étant la swap ahah).
Je préfère me fier à mon jugement.
Après, je suis pas fan de Debian non plus, pas pour rien que je préfère Arch en perso.
Je constate simplement que bon, pour nos clients, j’irais pas leur coller du Arch. Du coup la question c’est Debian ou RPM, et j’étais plus compétent sur Debian, et la boîte où je suis tombé utilisais Debian depuis longtemps, et du coup… bah Debian, quoi. Et Proxmox pour les hyperviseurs.
Et ça réponds bien aux besoins à la fois les nôtres et ceux des clients, donc pas de raison de chercher à changer. Ce que je dis souvent, c’est qu’un gros changement est lié à un gros avantage, pas juste un léger.
Ou dis autrement, tant qu’on a pas de problèmes sérieux avec Debian, l’effort de faire un changement de distro ne vaudra pas le coup par rapport à juste améliorer ce qu’on maîtrise déjà pas mal.
Bah le fait est que ce sont les arguments qui comptent et que l'expérience en apporte.
Prend seulement les deux faits que j'ai expliqué, par exemple l'activation d'app nginx dans sites-available, et le nommage de comptes système et imagine qu'on est forcé de faire des tests à l'install pour être compatible deb vs le reste du monde. Rien que ça c'est induit par Debian et dérivés.
La nomenclature normalisée c'est un "conf.d" dans lequel tu poses tes fichiers de conf. Toutes les distros utilisent ça, sauf les deb like.
Du coup, par exemple, quand le mainteneur du conteneur NGInx a fait sa tambouille, il a laissé cette conf pour les "Alpine"
Résultat: les conteneurs ont tous pété à la tronche des utilisateurs
@metal3d @dada J’ai envie de dire, on s’en fous, t’es même pas obligé de faire comme la distro le propose par défaut, /etc c’est l’admin qui décide de comment il gère.
Et séparer les mods des conf des vhosts je trouve que c’est une plutôt bonne pratique au contraire, et si c’était pas par défaut sous Debian j’aurais sûrement fait un truc similaire.
Quand à ton mainteneur, s’il utilise Alpine pour ses docker sans connaître Alpine, et sans vérifier la conf qu’il déploie, c’est un branque, c’est pas de la faut à Debian…
@metal3d @dada Oui je botte en touche, et donc ?
Et nope, y’a aucune règle qui dit que toutes les distros doivent avoir la même conf 🤷.
Ni même tous les serveurs. Franchement, c’est un non problème à mes yeux, sérieusement.
Surtout que « les mainteneurs sont les gens de docker » oui mais les mainteneurs sont censés maintenir pour une distro, par pour un truc universel.
Les mainteneurs docker Debian devraient pas être les même que les mainteneur docker Alpine, sauf à maîtriser les deux bien sûr (ce qui n’est visiblement pas le cas).
Après j’aime pas Docker en premier lieu, ça aide sans doute pas. Mais chaque distro fait son boulot, et c’est la responsabilité des mainteneurs de chaque distro, et ça ne regarde que la distro et les admins.
alors si, y'a la FHS: https://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
C'est un exemple parmi plein de standard.
Quant à ta remarque sur les mainteneurs Docker, tu imagines que tu demande un nombre exponentiel de mainteneurs ?
Alors justement c'est pas la question.
Si tu normalises, tu dois pouvoir compiler et installer sur Arch, et le même script, ou presque, doit passer sur les autres distro. La seule différence va venir des install de package de dependances.
Or, comme je te le dis, si tu pars du principe que "sites-enabled" est un truc standard, alors tout pète sur les autres distros.
Debian donne des mauvaises habitudes, vraiment
Docker: je fais un Dockerfile avec un truc standardisé => ça compile partout sauf sur Deb/Like
Ansible, pareil, obligé d'avoir un detecteur "Debian" pour corriger des install
Debian est le seul qui nous impose d'être détecté pour faire "à leur manière". Donc je suis désolé mais c'est bien Debian qui pose problème. C'est le 1% qui a tort 😜
@metal3d @dada @breizh Tu va aussi me dire qu'entre Debian/Fedora/… qui utilisent systemd et notamment Alpine qui utilise OpenRC y'a aucun soucis ?
Ou pareil l'exemple que j'ai eu y'a quelques jours de considérer que resolv.conf est standard et non lié à la libc (historiquement libresolv d'ailleurs).
J'ai la désagréable impression que le standard doit être ce qui est apporté par un projet et pas l'usage validé par une majorité d'utilisateur. Ils sont gentils chez RedHat/CentOS/Fedora/etc mais ils peuvent bien déclarer ce qu'ils veulent, si l'usage n'est pas ce qu'ils prescrivent, c'est triste mais c'est comme ça.
Bah... c'est un peu normal qu'un projet, réfléchis par ceux qui le font, aient une bonne idée de comment on doit installer une app.
Par exemple la fondation Apache, elle le sait qu'elle propose plusieurs services (httpd, tomcat, etc...) - Il me parait évident de suivre leur reco en ayant un utilisateur "apache" et des confs placés dans le respect de leurs call.
Pourquoi Debian parle de "apache2" ?
Ce n'est pas une question de comment le monde tourne. C'est une question très intéressante de savoir les raisons qui poussent les gens à utiliser une distrib qui ne respecte pas les standard FHS, XDG, etc. Alors que 99% des autres font cet effort justifié.
On en arrive à des failles béantes créées par des patcheur Deb, à répétition, et tout le monde continue à y aller tête baissé.
Debian fait ce qu'il veut, mais ils n'ont pas raison de le faire.
Après, que tu estimes que c'est à la communauté Debian de packager la terre entière à sa sauce pour que tu puisses l'installer "à leur manière" et que tu ne te plains pas des failles c'est une autre histoire.
Moi j'ai posé une question simple: pourquoi choisir Debian "par défaut". Personne n'y répond depuis tout à l'heure, du mois, personne ne me donne d'argument valide qiu prime sur les autres distros
@metal3d @dada @lanodan Au final, Debian est pas beaucoup plus un choix par défaut que les autres, surtout dans le monde pro.
Côté utilisateur, c’est parce que Ubuntu a été la distro qui a popularisé Linux. Pourquoi Canonical a choisi Debian va savoir. Peut-être parce qu’ils voyaient Red Hat comme un concurrent ?
@metal3d @dada @lanodan J’ai pas connu cette époque.
Mais du coup, je sais pas. Personnellement, j’ai juste pas de raison d’utiliser autre chose que Debian dans le cadre pro, la moitié des raisons que t’as donné étant hors sujet à mes yeux.
Et l’énervement de la commu, la commu elle a toujours un truc sur lequel s’énerver, alors bon. Et Debian est toujours là et toujours aussi populaire. 🤷
@metal3d @dada @lanodan Tes arguments sur la sécurité ? Tu parles juste des failles créées par les mainteneurs, qui peuvent arriver sur toutes les distros.
Et les mainteneurs corrigent bien plus de failles qu’ils n’en créent, c’est d’ailleurs un des gros points fort du système de distribution, d’avoir des tiers qui valident les applications. Ça simplifie la confiance aussi.
Perso j’ai bien plus peur des upstream qui veulent mettre leur nez dans mon installation. Pire, les devs qui veulent bypasser mon taf d’admin. Brr.
tiens bah en voilà un super exemple !
docker, faille de sécu, tout le bazard. Un standard existe: OCI.Docker le respecte, Podman et runc aussi. Voilà, tout le monde peut travailler main dans la main sans se tirer dans les pattes.
Tu l'as ton exemple de "pourquoi faut respecter les normes"
@metal3d @dada @lanodan Respecter les normes discutées collégialement je dis pas, appliquer strictement ce que dis l’upstream qui n’a aucune idée de comment tu gères ton système en est une autre. Surtout qu’il me semble que Debian s’est mis à suivre le FHS par exemple (c’est ptêt pas encore le cas à 100 % parce qu’ils y vont progressivement, mais j’ai vu des changements en ce sens).
Y'a rien d'hybride dans ce que je dis. Bon sang, je pense que t'as pas compris mes arguments en fait.
Je dis que quand tu respectes des normes et/ou des standards, tu évites de patcher comme un bourrin et d'introduire des failles propres à ta distro. Que tu peux plus facilement suivre les fix du projets sans laisser tes utilisateurs avec des conneries introduites par tes choix.
Debian est dangereuse, plusieures rapports le démontrent, c'est pas rien
@metal3d @dada @lanodan Ce qui est hybride dans ce que tu dis c’est que la plupart des arguments que tu avances sont un cas d’usage où tu bypass les paquets de la distro, et te plains que tes paquets non-prévus pour Debian s’intègrent pas avec Debian.
Du coup t’as un truc hybride entre Debian et pas Debian. Mon point c’est que tu fais full Debian ou pas du tout, pas un mix.
Sérieux tu le fais exprès...
Tu fais comment quand Debian n'a pas de package ? Genre pour un PHP à jour, un Python 3.12 ou Go installé correctement (pas comme le font les packageurs Debian) ?
Explique moi comment tu répares une faille en moins de 2h si tu dois attendre 2 semaines qu'ils se sortent les doigts ?
Donc utiliser les sources du projet, donc le patcher si le mec respecte les standards qui ne sont pas ceux de Debian, et donc introduire des risques.
Je le répète: c'est un danger. Vous ne voulez pas l'entendre, vous vous foutez du fait que depuis 24 ans j'ai vu passer ça des dizaines de fois.
Ce que vous ne voulez pas entendre, tous les deux, mais aussi une grande partie de la commu Deb, c'est que la base de la base c'est qu'une app soit compilée proprement et s'installe de manière standard.
Si tu choisis, en créant ta distro, de modifier un truc standard, tu exposes tes users à des risques important. On leur dit depuis 20 ans, ils ont foutu des gens dans la merde, mais ils ne change quasi rien.
Donc, je demande pourquoi utilsier cette distro, voilà
@metal3d @lanodan @dada Mais je le répètes, c’est pas à l’upstream de faire le packaging. La sécurité du déploiement n’est pas de leur ressort, et au contraire, leur système de déploiement doit être considéré comme moins sécurisé que ce qu’un packager tiers fera.
C’est toute la force du système de distribution d’avoir des acteurs différents entre l’upstream et l’utilisateur final. Notamment pour éviter le conflit d’intérêt, genre l’upstream qui zappe certaines sécurités pour simplifier sa vie.
Et même si le script upstream fonctionne, il doit être vérifié et validé par les packagers.
Pour moi c’est une sécurité supplémentaire qui corrige plus de problèmes qu’elle n’en provoque. Et n’importe quel auteur du paquet, que ce soit l’upstream, une distro, une autre distro, ou un admin peut faire de la merde sur la sécurité, et c’est une chaîne complète avec chacun ses responsabilités.
Il existe des dizaines de trucs NON PACKAGE dans Debian ou RH, ou Fedora...
Dans une grande partie des cas, pour avoir une version corrigée, tu dois la compiler. C'est central dans nos métier de faire une install "à partir des sources". Tu te bases sur la distro pour les DEPENDANCES. je me tue à le dire
Mais tu crois que les normes dont je parle ne sont pas discuté depuis 1970 par des miliers de pros ?
Rien que XDG (freedesktop) c'est signé par des centaines de gens. Debian et Ubuntu (qui fait pire) font tout de travers
Et oui, ils ont fini par écouter pour la FHS, après plus de 15 ans de bataille. C'est anormal tout ce temps
J'ai cité ces exemples, tu sais très bien qu'il en existe d'autres.
Freedesktop c'est central sur des distro grand public, donc que Ubuntu ne sache pas le respecter pose de sérieux problèmes là. Surtout quand il s'agit des nommages dans DBus (j'en ai fait les frais en bossant avec le projet Fyne.io)
@metal3d @dada @breizh Les examples que tu as cité c'est :
• site-enabled: apache n'est pas un standard et l'installation de apache encore moins (d'ailleurs me souvient de OpenSolaris qui avait /etc/apache/2.2 et FreeBSD où c'est dans /usr/local/etc/apache)
• ~/.local/bin: D'où tu tire ça ? C'est dans aucun PATH par default.
Faut pas abuser sérieux... C'est la majeure partie des distros, et c'est une spec bien écrite:
https://specifications.freedesktop.org/basedir-spec/latest/
Du coup bah go bugs.debian.org hein.
Juste un PS: n'allez pas croire que je vous en veux ou que je suis en colère. J'écoute vos propos et je réponds. Croyez moi, je suis un vrai gentil dans la vie. Je suis juste passionné et très attaché à Linux.
Je vous le dis, je dois utiliser Debian et ça fonctionne. Ma question intiale est une vraie réfléxion latente depuis 2003 environ. Rien contre vous, vraiment.
@metal3d @lanodan Réflexion latente qui n’a visiblement rien changé. Ce qui veut pas dire qu’elle est mauvaise pour autant, mais pas si critique non plus.
Et surtout, les arguments annoncés sont pas du tout les bons pour moi. Tu peux reprocher le problème du respects des standards, je l’entends, mais les arguments que tu donnes sont pas contre Debian mais contre le principe de distribution, et ça me dérange.
Pas du tout, donc tu n'as pas compris ce que j'ai expliqué. C'est pas grave.
Quand tu fourniras un service sur Github ou autre, avec un Makefile qui installe dans "site-enabled" avec un chmod "www-data", et que t'auras je ne sais pas combien d'issues à ce sujet, peut-être que tu verras de quoi je parle.
Tu vois juste pour te montrer à quel point Debian est foireux, tu me dis que tu installes Apache. Alors que Apache, on ne l'installe pas. Apache c'est un éditeur, une fondation. On installe httpd, tomcat, etc...
Debian a fait beaucoup de mal en nommant n'importe comment ces services.
@metal3d @dada @lanodan T’as parlé plusieurs fois de Docker explicitement. Si tu me dis que Podman et runc sont meilleurs en sécurité que Docker, je ne peux pas te contredire, je connais pas assez.
(même si en règle générale j’aime pas trop les containers en production (pour de la CI/CD ou des tests c’est parfait par contre)).
Les devs fournissent un tarball source, point.
Ça me rappelle certains devs qui utilisent pas Gentoo mais qui voulaient quand même fournir pour, forcément ça finit mal parceque l'intégration est pas testé.
@metal3d @lanodan Je vois pas le rapport dans la discussion. Soit le paquet est adapté à la distro par les mainteneurs, soit il est adapté à la distro par l’admin. Que ce soit un deb ou autre chose.
(même si évidemment il est préférable de passer par le système de paquet de ta distro, c’est tout l’intérêt d’une distro. Même si tu passe pas par leurs dépôts)
J'ai l'impression que vous le faites tous exprès de ne pas comprendre la question...
Je fais une appli, je propose un Makefile qui utilise le standard (conf.d, XDG pour installer dans ~/.local/bin pour un user par exemple...) - ça marche sur 99% des distros **SAUF** Debian/Ubuntu.
Aucun packageur ne va s'intéresser à mon app qui a 10 stars sur github.
Je me prend des issues, je dois donc MOI faire un travail parce que la disto est naze... moi, le dev
Non c'est vrai, laissons les faire de la merde avec nos app, foutre des failles, casser les burnes aux mainteneurs de projets qui font le max sur leur temps libre pour proposer des choses aussi universelles... Les mecs qui pondent des RFC ils se font chier pour rien.
tiens je vais aller installer faire une distro qui installe tout dans "/WTF", et si je deviens dominant et bien tant pis pour les autres.
Super mentalité les mecs...
@metal3d @lanodan Bah tu peux répondre à ces issues « voyez avec votre distribution, pas mon problème ».
Je reconnais que c’est un problème les utilisateurs qui se plaignent à l’upstream au lieu de se plaindre à leur distro d’abord.
La distro devant alors se pencher dessus et ensuite venir dire « votre makefile il a pas les variables habituelles de configuration vous pouvez améliorer ça », et si tu réponds pas, patcher eux-même le makefile au besoin à leur niveau.
Un mainteneur à complètement le droit de dire "c'est pas mon bug, voyez avec Debian/Ubuntu ou appliquez un patch vous-mêmes".
En tout cas hors des distros pour lequel je fais des paquets (Gentoo et Alpine, paye ton idée de "choix par default") j'irais pas me faire chier en tant que dev pour faire de l'intégration pour des distros que j'utilise pas.
Ce qui derrière fait que les utilisateurs font leur choix suivant les logiciels disponibles et pourquoi pas si c'est chiant de faire des paquets, Debian pour le coup est pas terrible de ce coté mais c'est au utilisateurs d'assumer leur choix.
Mais justement ! je dis que si on respecte des normes, des standards, on a pas à se faire chier à viser des distros.
Or, avec Debian on est forcés de le prendre en compte parce qu'il foutent la merde.
Et je suis désolé mais je ne sais pas m'en foutre des utilisateurs qui utilisent une autre distro que moi. Et je pense que notre avis, à ceux qui gueulent contre Debian pour ça, en ont le droit !
@metal3d @lanodan Tu devrais t’en foutre. Au mieux ça forcera Debian à changer, au pire ça la fera disparaître. Et en plus dans l’intervalle ça t’enlèveras une charge que personne n’attends que tu supportes. T’as rien à perdre à t’en foutre un peu plus de Debian.
(et si ça évolue dans le sens que je souhaite, ça permettra d’avoir des bonnes pratiques un peu plus propres en production. Quoiqu’il arrive tout le monde sera content :D )
@metal3d @dada @lanodan Cette question n’a pas de réponse. Pourquoi prendre autre chose que Debian ?
Pourquoi Debian plus que Arch ? Parce que la gestion en version stables est plus adaptée au besoin dans certains cas.
Pourquoi plus que Fedora ? Parce qu’on préfère DPKG à RPM ? Parce qu’on préfère l’organisation de Debian à celle de Red Hat ?
Le choix d’une distro c’est pas un choix absolu et objectif, y’en a pas de meilleur que les autres. Y’a celles qu’on préfère, y’a celle qui est plus adapté à tel ou tel usage. Y’a celle qui est plus ou moins bien supporté pour l’usage qu’on en fait.
Y’a des tas de facteurs différents. Et si on préfère les modifs faites par Debian qu’on estime plus pratique que ce que l’upstream propose par défaut ? Après tout, c’est possible aussi. 🤷