• [^] # Re: moi c'est l'inverse

    Posté par (site web personnel, Mastodon) . En réponse au journal Linux ne m'intéresse plus. Évalué à 10. Dernière modification le 10 décembre 2020 à 02:44.

    Quant à l'init: c'est OpenRC mais System V m'irait aussi.
    Car oui, un autre point, si pour les utilisateurs de 20ans, écrire un service en sh est pénible, changez d'OS à tout jamais. :)

    On dit jeune con et vieux fou, mais j’ai envie de dire que ton commentaire mélange les deux, en plus d’introduire un conflit inter-générationnel stupide (et sympa l’entre-soi à base de « cassez-vous© »)

    Personnelle j’ai commencé Linux il y a 16 ans peut-être, mais ma première expérience informatique était une console DOS avec un éditeur modal appelé TED et un compilateur C K&R (pré-ANSI, c’est à dire pré-C89, la syntaxe du C était différente), à l’époque même Word (pour DOS) était un éditeur modal... mon premier compatible PC était propulsé par un compatible 8086 d’AMD. J’ai toujours vécu dans un terminal et je pisse du shell tous les jours.

    Exemples de trucs en shell / bash que je peux montrer parce que publics:

    Note que quand je parle d’écrire des services en shell, je parle pas du script de démarrage, je parle du service, le logiciel qui rend le service.

    Là j’en ai pas à montrer parce que non-publics, mais j’ai des services en shell qui écoutent des ports réseaux pour recevoir des commandes et qui gèrent eux-même d’autres services, qui gèrent des certificats pour des centaines de sites-web, ou encore des proxy tcp pour faire rebondir des applications, en shell. Si tu regardes mes scripts en shell tu verras des classes primitives, de la gestion d’argument avancée et même dans un cas une forme primitive d’introspection de fonction...

    Défi : explique moi où est le problème dans ce script, et comment le corriger, c’est pour savoir si tu sais de quoi tu parles quand tu parles de shell :

    while read file
do
 otherscript "${file}"
done

    Et bien tu sais quoi ? Il y a quelque chose comme 15 ans, j’utilisais Gentoo et je faisais des unité de service en shell. Un jour j’ai posé une question à un ami concernant le démarrage de services, et j’ai compris à son regard que ma question n’avait pas de sens pour lui et n’avait rien à voir avec Linux mais était spécifique à Gentoo. À partir de ce jours j’ai terminé d’écrire des unités de services en shell et quelque soient les distributions que j’ai utilisé (comme Debian avec sysv-init) je me suis religieusement tenu loin de tout ça, quitte à faire du rc.local dégueulasse. Ce jour d’il y a 15 ans j’ai arrêté d’écrire des unités de services en shell et je me suis mis à attendre systemd.

    Bon, en fait, systemd ou n’importe quoi d’autre, je doute que systemd était déjà en projet à l’époque, mais c’est ce genre de changement en profondeur que j’attendais. Une unité de service n’est pas un script putain ! Le script c’est le service à la rigueur, mais pour configurer le contexte de ton service c’est de la description, pas de la programmation.

    On peut mettre des scripts shell voir du shell directement dans une crontab, mais tu ne fais pas de crontab à base de while sleep j’espère ??? Les systèmes d’init en shell que j’ai expérimenté c’était ça. Je n’exclus pas qu’un système de gestion de service utilise le shell pour lire des variables, mais par pitié brûlez vos unités en script c’est horrible.

    En vrai je m’en moque de systemd, ce qui compte c’est que le service soit rendu, et si quelqu’un écrit une alternative je pourrai bien l’utiliser, mais mince... j’ai commencé à utiliser systemd il y a trois-quatre ans quand j’ai jugé qu’il était prêt, ça signifie que j’ai attendu 12 ans que les distributions Linux fournissent un service correct pour les besoins réels !

    En dehors de cas bien spécifiques comme de l’embarqué, jusqu’à aujourd’hui je n’ai jamais vraiment rencontré un détracteur de systemd qui fasse autre chose que geeker sur son pc perso.

    Ça me rappelle ce développeur de Devuan qui militait pour faire tourner toutes ses applications en root sur sa machine « parce que c’est ma machine tu vois », même pas capable de contextualiser que l’utilisateur de la machine c’est pas lui c’est le développeur des logiciels qu’il utilise (ou des sites web qu’il visite). 🤦‍♀️

    C’est comme les trucs à la pam, il parait que c’est mal foutu, qu’il y a plein de problèmes structurels, et je veux bien le croire, mais il n’y a tout simplement pas d’alternative viable aujourd’hui pour répondre à certaines problématiques.

    Va gérer des parcs de centaine de personnes avec, par exemple, une ouverture de session SSO avec création automatique des dossiers locaux à l’ouverture de session et ticket d’accès aux disques réseaux (et authentification hors-ligne) sans configuration de la part de l’utilisateur ni de spécialisation de ta part, avec des scripts shell. Contrainte : pas de systemd, pas de pam.

    J’aurai aucun problème à utiliser autre chose, encore faut-il que cela réponde aux besoins.

    C’est facile de se satisfaire de scripts shell quand on ne geek que sa propre machine.

    Comment se fait-il qu'avec OpenRC je n'ai pas ces problèmes de: démontage réseau; de bloguage avec timeout infini; de reprendre la main (sysrq mon q) sans redémarrer contrairement à systemd?!

    Si tu as ces problèmes je ne te mettrai pas 100 utilisateurs dans les pattes.

    En fait comme diagnostique je commencerai par te demander : c’est quoi ta distribution ? Une distribution ce n’est pas qu’un dépôt de logiciels, c’est un référentiel de méthodologies. Les distributions ne se valent pas, il ne suffit pas de distribuer les mêmes logiciels, ce qui fait la différence sont l’efficacité des méthodologies mises en œuvre par la distribution.

    Par exemple pour répondre au besoin que je viens de décrire, utiliser un dérivé de Debian serait plus efficace qu’un dérivé de Red-Hat (à la Mageia) parce que la gestion de la configuration de pam est bien meilleure, quand bien même il y aurait un un nombre incalculable de distributions qui empaquettent des trucs comme samba, winbind, etc. La différence ce sont les méthodologies proposées.

    Je suis près à remplacer systemd par autre chose qui serait objectivement meilleur, mais en attendant Debian a énormément gagné en sérieux en intégrant systemd. Avant cela la gestion des services était une blague, je crois d’ailleurs que c’est un très bon point pour Debian d’avoir réussi à tenir une distribution aussi fonctionnelle malgré l’infâme sysv-init, ça dit à quel point les gens qui conçoivent Debian savent comment traiter les problèmes et sont de vrais solveurs de casse-tête de compétition.

    Car oui, un autre point, si pour les utilisateurs de 20ans, écrire un service en sh est pénible, changez d'OS à tout jamais. :)

    Es-tu vraiment certain que tes problèmes sont une question de conflit inter-générationnel ou bien que supposer l’incompétence des autres soit significatif ? Es-tu vraiment certain que la vocation de Linux soit d’être une forme de synthwave pour geek en mal d’années 80, ou une forme de rétro-computing ?

    ce commentaire est sous licence cc by 4 et précédentes