Plus récents

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

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

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

On se lit à une distribution pour des raisons pratiques:

- avoir une image de base et pas 20, pour limiter le poids de ta base images
- avoir des versions de lib communes ou imposées par un client (genre, la libssl)
- avoir du support sur des paquets en dépendance

La distro compte

@breizh

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

Non, justement.

Quand tu package Nginx sur un conteneur, tu ne prends surtout pas les paquets de la distribution (qui implique des deps, des prefs, etc...)

Tu compiles et installes.

Or, si ta base d'automatisation part de Debian, tu as des soucis de compat sur 99% des autres distros. Or, Debian est utilisé de-facto (de moins en moins) - donc ça pose problème

@breizh @dada

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

Je ne te dis pas que Debian influe sur les autres distros. Je te dis qu'ils influent sur le travail des packageurs (que ce soit Docker ou pas)

Casser des standards, des normes, ne pas respecter la paroles des éditeurs de solutions (apache est un exemple parmis des centaines), c'est un "problème"

@breizh @dada

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

Et je ne te parle pas des délires avec le compte "apache" qui devient "www-data", et qu'ils ont appelé "httpd" => apache...

Apache n'est pas un serveur, ils n'arrivent pas à l'admettrre. Apache propose httpd et tomcat.

Foutre un utilisateur commun entre nginx, tomcat et httpd c'est délirant...

Bref, ils font un peu n'imp. On s'en sort hein, mais ils nous complique la tâche 🙂

@breizh @dada

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

Si tu veux des exemples:
github.com/nginxinc/docker-ngi

Si tu cherches "docker nginx issue site-available" tu vas voir le bordel que ça crée.

C'est une idée absurde, surtout qu'on leur dit depuis des années (à Debian) que faire un simple lien symbolique entre "sites-available" et "conf.d" pourrait déjà corriger un paquet de problèmes. Mais ils s'en tamponnent (position dominante)

@breizh @dada

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

@breizh @dada après oui bien entendu que l'habitude et les compétences dans telle ou telle distro comptent pour le choix. Et on est bien d'accord que je n'installe pas une distribution pour un client seulement à partir de les préférences.

Je dis juste, dans mon premier message, que je ne comprends pas l'engouement pour deb/buntu surtout pour leur manque de rigueur et de respect des conventions.

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

Par contre je vais préciser un truc: je suis souvent forcé d'utiliser Ubuntu ou Debian sur des images de conteneurs... parce que les devs ont réussi à nous pondre des trucs qui ne marchent que sur cette distro. Et le pire c'est que quand on prend le temps de faire la migration sur Rocky ou Arch par exemple, et bah on nettoie et ça marche mieux (et partout).

Moralité, je pense qu'il faut que Deb/Buntu fasse un effort de "conformité Linux"

@breizh @dada

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

Donc, pour reprendre tes termes, non... Debian ne fait pas "parfaitement le travail" 😜

@breizh @dada

Plus anciens
techlover

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