Plus anciens

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

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

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

@metal3d @dada @lanodan (et d’ailleurs Docker est un grave problème de sécurité et ça semble pas te déranger plus que ça non plus, donc bon)

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"

@breizh @dada @lanodan

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

@breizh @dada @metal3d À ma connaissance Debian respecte complètement FHS.
Et XDG c'est surtout des standards pour les implémenteurs pas pour les distros.

FHS d'ailleurs n'étant qu'une faible partie d'un standard qui s'est complètement pété la gueule : Linux Standard Base.

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)

@lanodan @dada @breizh

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

Suivre

Faut pas abuser sérieux... C'est la majeure partie des distros, et c'est une spec bien écrite:

specifications.freedesktop.org

@lanodan @dada @breizh

De mémoire y'a déjà un BR ouvert à ce sujet, mais ils vont encore mettre 5 ou 6 ans à corriger 😋
@lanodan @dada @breizh

@metal3d @dada @breizh Donc du coup tu peux allègrement pointer les utilisateurs vers le rapport de bug et a eux d'assumer.

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.

@lanodan @breizh

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

@breizh @lanodan

@metal3d @breizh Perso je vois très bien le truc et à chaque fois c'est devoir expliquer qu'une personne avec la casquette de dev ne doit pas faire d'intégration système.
Fout le fichier de conf apache avec le reste de la doc en tant qu'exemple et c'est marre, surtout que derrière y'a sans doute des utilisateurs qui vont légitimement vouloir changer la config.

Voilà en gros c'est mon souci...

Et j'ai d'autres exemples. Tiens par exemple je maintien un OCI pour un projet super intéressant. Sauf que dans les sources c'est figé pour Debian. Sauf que y'a une lib plus supportée. Une faille apparait, je dois changer de distro de base (le FROM). Bah je peux pas..., le code est basé sur des règles de nommage Deb.

L'autre projet, standardisé, passer de Deb à Alpine c'était sans douleur...

C'est juste triste.

@lanodan @breizh

@metal3d @lanodan Bah oui mais ça c’est le problème du l’upstream qui s’est figé sur Debian. C’est lui qu’il faut engueuler, pas Debian…

En plus Debian peut ne même pas être au courant que ce projet existe…

Mais le dev ne va pas s'installer plusieurs distros pour tester... C'est déjà assez dur de développer un truc fiable...

Si Debian faisait un effort... bah ce serait ça en moins à gérer.

@breizh @lanodan

@metal3d @lanodan Bah s’il a hardcodé des trucs pour Debian ailleurs que dans le truc de déploiement (ce qui est déjà une mauvaise chose), c’est foireux à plus d’un titre…

@metal3d @breizh FROM du coup une dépendance sur une autre image, c'est littéralement la question éternelle de comment gérer les dépendances et comment pouvoir corriger les soucis quand une dépendance est pas maintenue comme il faut.
(Et pourquoi Docker est une purge pour moi mais c'est un autre sujet)
@metal3d @breizh D'ailleurs coté packaging un soft tiers qui veut modifier la config d'un autre… au mieux c'est modifié pour que ça le fasse plus au pire ça dégage de la distro.

Là à la limite vaut mieux le dégager de la distro.

Mais le souci c'est quand on parle de webapp qui ont besoin de httpd par exemple. Quand de base il essait de taper dans "conf.d" et que le dev te dit "bah démerde toi sur debian", y'a pas mal de gens qui ne savent pas faire...

Franchement c'est juste une hisoire de nom de rep, pourquoi Debian refuse de faire l'effort ?

@lanodan @breizh

@metal3d @lanodan Parce que c’est pas à eux de le faire. Si la personne ne sait pas faire pourquoi elle administre un Linux d’abord ? --’

@metal3d @lanodan Et le dev est pas censé taper dans conf.d, il est censé fournir une conf d’exemple et l’admin adapte au besoin de sa machine…

Tu sais que chez M. Dupont y'a pas forcément un admin pour installer l'app ?

@breizh @lanodan

@metal3d @lanodan C’est bien pour ça qu’il délègue le travail à la distro qui s’assure qu’elle s’installe automatiquement correctement.

Si ça demande du taf manuel parce que c’est du sur-mesure ou un truc de niche qui n’est pas dans la distro, il faut faire appel à un admin pour faire l’intégration.

Si y’a pas d’admin pour faire ça tu en contacte un ?

(spoiler : c’est mon job, d’être admin prestataire…).

Putain... tu le fais exprès...
Je ne vois pas autre chose, tu fais exprès d'oublier les explications.

@breizh @lanodan

@metal3d @lanodan Bah non, j’ai répondu point par point 🤔.

Mais on est visiblement pas d’accord sur le rôle de chacun dans la gestion d’un système dans le cadre d’une distribution Linux.

Y’a l’upstream, qui fait le code, les packagers qui font l’intégration, l’admin, qui ajuste la configuration locale (et peut faire de l’intégration quand la distro ne le fait pas pour son cas particulier), et enfin l’utilisateur qui lui n’a qu’un pouvoir limité.

Évidemment tu demandes pas à l’utilisateur ni à l’upstream de faire l’intégration, c’est pas leur boulot, et ils ont pas les infos et accès nécessaires pour le faire correctement quand bien même ils auraient les compétences.

Je te jure que tu n'as pas répondu point par point. Tu réponds à un truc, puis un autre, sans lien.

Mon argumentation est globale, elle prend en compte les normes, la sécurité, l'installation standardisé, l'isolation, le mode ISO fonctionnel, etc...

Je doute qu'un admin comme toi ne fasse que des installs de packages. Et en prenne pas en compte ne serait-ce que l'isolation d'install

@breizh @lanodan

@metal3d @lanodan En vrai perso j’ai pas l’impression qu’on se comprends pas, mais juste qu’on est pas d’accord. Bref.

Je remets quand même cet article, des fois que tu ne l’aurais pas lu, il est intéressant et probablement plus clair que je ne le serais jamais : https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html

Mais comme dit plus tôt, on peut pas être d’accord sur les conséquences des décisions de Debian si on est pas d’accord sur leur rôle en premier lieu.

Ce que tu n'as pas compris c'est que je ne critique pas l'utilisation de distributions. Je l'ai répété, expliqué, elles sont importantes et le choix est primordiale.

Et par conséquent, prendre un distrib qui ne respecte pas les normes est un problème. Pour les points que j'ai expliqué et qui ne représentent même pas le tiers des conséquences que ça implique.

Debian est une belle distrib, mais ses choix ont fait énormément de mal - revoir la faille SSL qu'ils ont intriduit

@breizh @lanodan

@metal3d @breizh Faille OpenSSL qui date d'il y a plus de 20 ans au passage et que OpenSSL eux-même ont fait pire ~10 ans plus tard avec Heartbleed (la faille aurait donné un crash au lieu d'une fuite de donnée si y'avais pas un malloc custom).

La faille SSL est un exemple, tu sais pertinemment qu'il y a eu d'autres failles induites par des patchs de packageurs.

Et pour la forme, cette faille a eu des rebonds encore en 2018 et 2021.

Tu as vu les rapports de sécu Debian vs RH (je ne suis pas fan de RH hein) ? c'est un peu inquiétant quand même...

@lanodan @breizh

@metal3d @breizh Oui je le sais bien, mais autant donner du plus récent, comme Jia Tan avec xz.
Debian est allé modifier OpenSSH pour rajouter libsystemd en dépendance et donc se retrouver avec une surface d'attaque beaucoup plus grosse, sur un service qui tourne en permanence tant que root et accessible via le réseau…
@metal3d @breizh M. Dupont utilise quelque chose comme Yunohost ou mieux un service d’infogérance si besoin.
@metal3d @breizh Et bon vouloir explicitement faire du support pour des admins incompétents… c'est pas l'idée du siècle, surtout quand ça risque de faire chier ceux qui sont compétents (et qui donc iront voir ailleurs).

C'est pour ça que quand tu standardise un minimum, tu assures que ça passe partout (ou presque) et tu soulages la vie des packageurs, admins, etc...

Ce qui me rend triste dans cette affaire c'est que Debian est une belle idée et que la commu est énorme. Le fait qu'ils compliquent la vie de pas mal de gens est un poil irrespectueux à mon gout. Et puis Ubuntu, je l'ai rodé, c'est un tout autre débat...

@lanodan @breizh

@metal3d @breizh Et quand y'a pas de standard propre ne pas hardcode comme ton chmod www-data, laisser les packagers/admins donner l'information.
Deux/trois lignes en plus dans une recette de paquets pour la config c'est pas un soucis, c'est d'ailleurs *beaucoup* plus chiant quand le buildsystem hardcode de partout ou essaye de faire de la détection magique et qu'il faut aller corriger derrière.

Ha mais c'est sûr que souvent les Makefile upstream sont dégeux hein.

Je ne dis pas que c'est pas possible de corriger en packageant, je dis que si on était sur un mode plus homogène on aurait moins de soucis à gérer.

J'en fais trop souvent les frais. Et je m'en prend à la distib qui est la plus marginale en terme de conf: Debian. Mais en vrai, y'en a d'autres. Et Fedora a aussi son lot de joyeuseté hein, ou Arch...

@lanodan @breizh

Si, c'est leur choix de nommer n'importe comment, donc c'est bien eux qui posent un souci à la commu.

Quand tu utilises une bagnole qui ne peut pas rouler sur une départementale, c'est de la faute du constructeur, pas du cantonnier

@breizh @lanodan

An,alogie absolument nickel.

La distro est une manière de construire un environnment.

La route c'est une voie normalisée pour utiliser ta distro

Debian fait une bagnole qui t'empêcche de suivre la route comme tout le monde, et te dis que c'est à toi, conducteur, d'aller étaler du goudron pour que toi tu puisse passer.

@breizh @lanodan

Inscrivez-vous pour prendre part à la conversation
techlover

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