Notices by Breizh (breizh@pleroma.breizh.pm), page 9

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

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

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.

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

@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

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

@metal3d Bah ou sinon tu fais pas la CI chez GitHub, en fait ? Ici on est une PME et on fait notre CI sur nos propres serveurs…

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

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

Et oui, le FHS je suis pour sa démocratisation aussi, mais Apache était pas dans le FHS aux dernières nouvelles (et encore heureux, ça dépends de l’admin ça).

@metal3d @dada Yep, mais il faut qu’il soit compétent là-dessus. Là il a fait n’importe quoi. S’il sait pas gérer 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à.

@metal3d @dada Après comme je l’ai dit j’aime pas trop Debian et le fait qu’ils customisent toutes les confs fait un peu partie du lot. J’aime bien la politique de Arch d’être le plus upstream possible par exemple.

Mais bon, ce sont les mainteneurs de la distro qui décident, soit ça te convient et tu fais avec, soit ça te convient pas et tu vas voir ailleurs, l’avantage c’est qu’il y a du choix 🤷.

Par contre je reste sur mes positions sur le fait que les choix qu’ils font n’ont aucune influence sur les autres distro, s’il y en a c’est de la faute à ceux qui mélangent tout, pas à Debian. À un moment faut savoir faire son job correctement.

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

N’est-ce pas tout ce qui compte ?

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

@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ées ou du moins obsolètes (un exemple frappant étant la swap ahah).

Je préfère me fier à mon jugement (même si bien sûr, j’écoute l’expérience des autres, et prends en compte ce genre d’échange – ce serait con de devenir moi-même un de ces vieux roublards dont je me méfie tant – mais je prends pas ça comme parole d’évangile non plus).

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.

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

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

@dlb @ButterflyOfFire Si tu le fais fonctionner uniquement quand l’imprimante fonctionne, vu que l’imprimante consomme à mon avis pas mal, c’est peut-être négligeable (dans le sens où c’est pas le fonctionnement du gyroscope qui va influer sur le fait que t’aies ou non assez d’énergie pour tenter l’impression d’un truc) ?

@Maryteax L'idée est intéressante, mais si t'achètes des madeleines dans ce rayon, c'est que t'as pas envie de les faires, végétaliennes ou pas, a priori 🤔.

@AzulCrescent All of them, mixed.

:yay:

@AzulCrescent The reality is more like "Okay, for the next part, I’m going architect. Well, factory is good enough. Oh, it ended up as an engineer. That's okay.

…ah, I'll have to modify this part after all. Well then, spaghetti it is."