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.

@breizh @dada

@metal3d @dada J’ai jamais constaté ça, et ça marche nickel ici.

Perso j’ai à peine une dizaine d’année d’expérience, alors je te redis si j’ai eu des problèmes de ce type dans 12 ans ahah.

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

@breizh @dada

@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.

@breizh @dada

@metal3d @dada C’est quoi le problème avec sites-available au fait ? J’ai pas compris ce point.

Et puis je connais pas deux distros compatibles entre elles, c’est pas Debian vs. le reste du monde mais Debian vs. Arch vs. Fedora vs. Gentoo vs. Void, etc.

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

@breizh @dada

@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…

Tu bottes en touche. Le souci est réel. Les mainteneurs sont les gens de Docker, ils automatisent un pauquet de chose.

Or, des règles spécifique de Debian mettent à mal la symbiose des conf. C'est bien de la faute de Debian là.

@breizh @dada

@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: fr.wikipedia.org/wiki/Filesyst

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 ?

@breizh @dada

@metal3d @dada Oui, j’en ai bien conscience. Ou juste des mainteneurs plus compétents (c’est courant que les mainteneurs s’occupent de plusieurs distros à la fois).

Mais c’est eux qui se sont mis dans cette position.

Il est absolment normal que le mainteneur d'une solution se charge des distros.

Tu ne peux pas demander à un spécialiste Debian de packager 300 applications sur Docker.

Tu peux par contre demander à un spécialiste Nginx de packager pour 4 ou 5 distrso "demandées"

@breizh @dada

@metal3d @dada Yep, mais il faut qu’il soit compétent là-dessus. Là il a fait n’importe quoi. S’il sait pas une distro, qu’il ne s’en occupe pas. Ou qu’il apprenne, je sais pas. En tout cas la faute est de son côté là.

Suivre

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

@breizh @dada

@metal3d @dada Bah non. C’est le boulot de chaque distro de faire son propre script. Tu dois pas produire un truc universel. C’est le boulot de chaque distro de faire ce job pour ses spécificités.

C’est pour ça que ça peut être des personnes tout à fait différentes qui s’en occupent.

Je suis désolé mais je pense que tu as un biais d'utilisation.

Je prend un exemple: je code une app, je propose un truc qui ne marche que sur Fedora (pour faire chier le monde) - tu attends quoi ? que Debian fournisse un paquet modifié, ou que je fasse mon job et que je propose un mode d'install qui fonctionne partout ?

@breizh @dada

@metal3d Que Debian fasse son paquet modifié. C’est pas ton job d’être compatible avec toutes les distros (et heureusement vu le nombre).

Par contre tu dois avoir une procédure d’installation propre pour que celle-ci puisse être adaptée par les mainteneurs.

Mais du coup dans l’exemple de Apache, par défaut c’est conf.d, et derrière Debian fait sa modif, je vois pas le problème. C’est pas ton problème cette modif, c’est le leur. Ta doc elle dit conf.d, ta conf par défaut aussi, t’es même pas censé être au courant que ça a été modifié (on te demande pas de l’être en tout cas).

@metal3d Et perso je dis que si tu considères que site-enabled est standard, tu fais une faute qui t’es imputable. 🤷

Sauf que c'est le mode standard de Debian...

Et que quand un dev me donne un makefile qui utilises "site-enabled", je suis cramé pour l'install sur une RH.

Et si je modifie le script, pour utiliser conf.d, alors ça ne va pas marcher sur Debian. Debian est le seul à faire ça.

@breizh

Ce que beaucoup n'arrive pas à comprendre c'est que ce souci n'est induit que par une seule distrib: Debian. C'est la seule qui casse autant les standards.

Arch, Rocky, RH, Gentoo, alpine, etc... ne posent pas ces problèmes

@breizh

@metal3d Bah, j’entends, mais peu importe, une distro peut très bien faire ça, ça fait partie de ses responsabilités. Si t’aimes pas ça, l’utilise pas.

Oui elle peut, mais ça ne lui donne pas raison !

Et on a pas toujours le choix, coté pro, de la distro qui sera imposée.

Quand tu dois conteneuriser, Debian pose systématiquement un souci du moment où tu commences à faire des choses un peu plus poussées qu'un "apt install"

@breizh

@metal3d J’ai du mal à voir pourquoi un makefile est censé toucher à la conf apache, mais oui, c’est à toi en tant qu’admin de le modifier pour correspondre à ton installation. Et si t’as plusieurs machines avec des configurations hétérogènes, c’est à toi d’adapter le script pour les différents cas. Je vois pas le problème.

Non, un make install doit être fait par le dev ou le devops

Moi je fais en sorte que ça passe partout. Et je me bats tous les jours avec Debian

@breizh

@metal3d Bah, non. Le make install déjà est censé avoir des options, et généralement les packagers jouent sur ces options.

Si le make install est suffisamment spécifique pour que les options suffisent pas, y’a un problème du côté du dev, mais en tant que mainteneur (parce que l’admin n’est qu’un mainteneur local quelque part) c’est ton job de l’adapter.

Donc, selon toi, y'a 40 distros possibles, je dois faire 40 options dans le makefile ?

C'est étonnant que nos Makefiles ne fasses que "if debian, else" non ?

Tu ne vois pas que c'est la seule qui pose souci ?

@breizh

@metal3d Nope, une seule option. Et tu mets pas de if Debian, c’est à Debian de l’ajouter (ou à l’admin si tu passes par par le distro).

Donc tu pars du principe que pour installer mon programme, il faut qu'un mainteneur Debian fasse un paquet

Déjà, là, on est pas du tout d'accrord

@breizh

@metal3d C’est tout le problème. C’est ce que je dis on pourra pas être d’accord, parce que pour moi c’est indispensable que Debian ou l’admin fasse le nécessaire. C’est son putain de job. Pas celui du dev du programme.

Du coup, oui, je pars de ce principe, et on est pas d’accord sur ce principe, et tout le reste en découle. Donc on va tourner en rond. Contentons-nous de pas être d’accord :D

Je peux te donner un exempe tout con pour, potentiellement, que tu comprennes où je pense que tu te plantes.

On a fait un dev avec des pipelines de tests. Sur du GtilabCI, en mode "runner ssh". Les machines du clients sont en RH. Script avec les conf "standards des éditeurs"

Il nous a demandé de juste passer les pipelines sur Github... qui utilise ubuntu...

Tout a explosé... des jours de boulots à cause de noms de comptes et de répertoires non standards

@breizh

Y'a pas que des install à faire, on bosse sur des tests, des check d'install, des vérifications de sécu.

Quand tu dois passer par 3 ou 4 distros et que la seule qui te demande de tout changer est Debian, tu dois admettre qu'elle a un souci
@breizh

@metal3d Nope. Par contre j’admets volontiers qu’il y a un problème dans le monde de l’informatique et des tas de gens qui font n’importe quoi ce qui provoque cette situation. Mais le problème c’est pas la distro qui fait son job de distro d’une façon qui te plaît pas. C’est le fait d’attendre que toutes les distros soient identiques alors que… c’est le principe même des distros d’être différentes (sinon y’en aurait qu’une).

Mais... justement c'est bien la distro qui pose problème là.

Aucune autre ne fait ça...

Ou du moins, le souci c'est que trop de gens prennent Debian par défaut sans prendre conscience qu'elle ne respecte pas la FHS, ni XDG, ni les reco des éditeurs comme Apache, etc.

@breizh

@metal3d Je suis d’accord sur la seconde partie. Le problème ce sont ceux qui croient que Debian fait comme tout le monde ou inversement. Ou que tout le monde fait comme tout le monde en général.

Mais c’est pas parce que Debian fait pas comme les autres que c’est un problème. Le problème c’est ceux qui attendent que tout le monde fasse la même chose et soient surpris que les distros soient différentes, alors que c’est leur raison d’être.

Alors en soit, si Debian faisait ne serait-ce que deux ou trois changements qui n'a pas vraiment d'impacts profond, ça serait top. Genre le link site-enabled => conf.d tu n'imagines pas comme ça soulagerait.

Ce qui pose vraiment problème, c'est leur manque d'écoute de la commu. Dans un monde Linuxien où justement la commu est importante... c'est un comble à mes yeux

@breizh

@metal3d Bah après ça on peut en discuter, du manque d’écoute. Mais leur reprocher leur travail de distribution parce qu’il te plaît pas ou t’arranges pas, c’est passer complètement à côté du principe de distribution, pour moi 🤷.

Alors il faura répondre à ma toute première question 🙂

@breizh

@metal3d Oui bah la CI devrait être faite sur des machines RH. Quitte à la faire en interne au lieu de la faire chez GitHub. Le problème ici c’est de faire la CI n’importe comment pour des raisons financières (je présume).

"allo Microsoft, ouais c'est moi... bouge ton cul et mets des Red Hat sur GitHub"

@breizh

@metal3d Bah ou sinon tu fais pas la CI chez GitHub, en fait ?

Tu veux appeler mon client et lui expliquer ? Genre qu'il ne pourra pas proposer son app sur Github avec un package automatisé, et que son application ne sera testé que sur Ubuntu ?

@breizh

@metal3d C’est ton job de faire ça, mais si tu veux, oui. Après j’ai déjà bien assez à faire avec les nôtres de clients, et je sais bien qu’ils en tiennent une couche, les clients. Mais le problème ce sont les clients, dans ce cas…

Tu réduis trop le problème. Je ne connais pas ton job, mais dans le miens c'est beaucoup plus compliqué d'aller dire à nos clients que nous voulons telle ou telle distro.

Et tu n'imagines pas à quel point certains deploiements sont complexe malgré des mois de boulot à les réduire.

On parle d'appli ayant parfois plus de 200 points de connexion hein

@breizh

@metal3d Je connais pas ton job non plus, mais si le client a des serveurs de prod en RH, faire de la CI en Ubuntu est complètement con.

Si le client veut être compatible avec RH et Debian, faut faire une CI Debian et une CI RH, ce qui demande plus de temps en effet.

Après là c’est le cas d’un client qui fait son app et gère les machines sur lesquelles elle tourne.

Parce qu’idéalement, pour une app qui est librement diffusée/utilisée derrière il fait son app’, et il déploie que dalle : chaque distro la proposera séparément, et fera le taf de déploiement.

C’est pourquoi en général un upstream s’occupe que de la distro ou des distros qui le concernent, et laisse faire les autres (voire, laisse ces distros faire le taf en parallèle parce qu’elles approuveront pas forcément sa méthode).

Il ont des serveur RH parce qu'ils ont du support.

On teste sur Rocky, tout va bien. Sur Arch, pareil, sur Alpine idem...

Il veulent des tests sur Deb/like parce que leur produit va bien entendu devoir s'installer sur ces distros

Donc, non, ce n'est pas con du tout
@breizh

@metal3d Sauf que c’est pas à eux de faire le déploiement sur ces distros, c’est à ces distros ou leurs utilisateurs de faire ce boulot. C’est le principe. Et c’est là-dessus qu’on est pas d’accord.

Plus récents

@metal3d (ou dit autrement, une distro qui ne suis pas l’upstream, c’est le problème de la distro et des admins qui la choisissent. Le reste du monde doit s’en foutre. Ce qui est pas le cas aujourd’hui, mais c’est bien là qu’est le problème pour moi)

@metal3d En fait idéalement le make install devrait se baser sur que l’upstream propose. Et ce sont les packagers et admins qui l’adaptent à leurs spécificités, vu que celles-ci sont inconnues du dev.

@metal3d Cas à la con, au taf on package nos propres versions de PHP avec la conf dans des endroits complètement différents, le dev d’un module PHP ou autre peut pas le deviner. Donc on l’adapte pour que ça marche sur nos confs.

@metal3d @breizh @dada Si on pouvais faire des recettes universelles ça se saurait, même dans le monde rpm chaque distro à ses spécificités, même si typiquement coté serveur c'est le plus RHEL-compatible possible mais c'est pas un truc auquel tu peux vraiment compter dessus sans avoir des problèmes de temps à autres.
@metal3d @dada @breizh Un Dockerfile c'est tout autant une recette, pareil pour genre Ansible.

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 😜

@lanodan @dada @breizh

@metal3d @lanodan Certainement pas non.

Et si tu appliques la même conf partout sauf pour Debian, t’as juste de la chance que ça tombe en marche (déjà les versions peuvent être différentes d’une distribution à l’autre, ce qui casse la compatibilité de certaines conf…).

@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).

Justement non, en ce qui concerne la conteneurisation, on n'utilise ni systemd ni openrc - on utilise le mode "standard"

@lanodan @dada @breizh

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.

@metal3d @lanodan @breizh

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" ?

@dada @lanodan @breizh

@metal3d @dada @lanodan Parce qu’ils l’ont décidé et ça ne regarde pas la fondation Apache. 🤷

@metal3d @dada @lanodan Nope. C’est ton avis le problème. Ils sont dans leur droit.

@metal3d @dada @lanodan (on peut tourner en rond encore longtemps comme ça. On est pas d’accord sur la façon dont le monde doit tourner. À partir de là on peut pas être d’accord sur les conséquences)

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.

@breizh @dada @lanodan

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

@breizh @dada @lanodan

@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. 🤷

@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 ?

Les raisons d'utiliser Debian était justement un énorme débat à l'époque. Tout une partie de la commu c'est énervé à cause de ce choix.

Donc, on en revient à ma question

@breizh @dada @lanodan

@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. 🤷

Mes arguments sur la sécurité ? et bé... tu m'excuses mais je comprends donc le "pas de raison d'utiliser autre chose" du coup 😋

@breizh @dada @lanodan

Plus récents
Inscrivez-vous pour prendre part à la conversation
techlover

Technology lovers, here we are — (development, digital artwork, science…)