Merci, je gère des infrastructures de plusieurs centaines de VM et différents orchestrateurs de conteneurs. Je pense savoir de quoi je parle et dans ce contexte professionel je n'ai pas de problème avec systemd.
Arrête le combat de coq. Je ne parle pas de ce que tu es mais de ce que tu exprime. C'est toi qui plus haut dit que linux c'est principalement du serveur et sous-entend que c'est de l'IP statique.
systemd n'a jamais apporté le moindre bénéfice aux nombreux cas d'usages que j'ai pu rencontré
Je ne comprends pas comment c'est possible. Je n'ai jamais su écrire un service correctement pour sysvinit et je ne me pose pas la question avec systemd. Ça marche aussi bien sur les RHEL du boulot que sur Debian à la maison. Sans que je ne rencontre le moindre breaking change.
Pour les tâches répétitives le simple fait de pouvoir utiliser autre chose que le format cron (par exemple avec une gestion de la tz), d'avoir une commande qui me dit quand il a été lancé pour la dernière fois et quand est ce que sera la prochaine fois et enfin le fait de pouvoir manuellement lancer exactement le même job.
Je n'ai vraiment eu besoin de lancer des centaines de VM pour voir le gain qu'il apporte et journald pareil. Je n'ai que rarement mis en place une centralisation de logs pour ce qui est vraiment système et pouvoir sans se prendre la tête avec les formats de dates, sélectionner des logs de périodes arbitraires est très pratique.
Je n'ai pas l'impression que l'usage que j'ai soit particulier. En fait j'ai même l'impression que c'est un passage obligé. Si peut être qu'openrc permet d'écrire des services aussi simplement, d'une part je ne l'ai jamais croisé et d'autres part ce n'est que le premier point dans ce que j'ai décrit.
incompatibilité avec les autres Unixes qui obligent les mainteneurs de FreeBSD, NetBSD et OpenBSD à s'arracher les cheveux pour intégrer certains logiciels.
Je vois pas en quoi ce serait bien pire sans. Le système d'init fait parti du packaging et il n'y a jamais eu de compatibilité là dessus avant. Quand aux nouveaux usages possibles qui demandent une interaction avec le logiciel, ils sont triviaux et ne devraient tout simplement pas se retrouver dans les builds autres que linux. Si un programme se rend dépendant de ça c'est au même niveau que pour dbus ou une api comme io_uring. Croire que les Unix souffrent depuis systemd c'est oublié qu'ils souffraient déjà beaucoup avant et que les évolutions de linux dans son coin leur ont toujours fais du mal.
systemd a été adopté par les utilisateurs uniquement parce qu'ils n'ont pas eu le choix. Typiquement lorsque Debian est passé à systemd. Lorsque systemd n'était disponible que sur Red Hat et ses dérivés, on n'a pas vu des masses d'utilisateurs se ruer sur CentOS et consorts. C'était plutôt le contraire.
Ça ne veut pas dire grand chose. Je choisi une distribution pour la confiance que j'ai en sa gouvernance et donc en ses choix.
[^] # Re: osctl
Posté par barmic 🦦 . En réponse à la dépêche Systemd v256. Évalué à 10.
Arrête le combat de coq. Je ne parle pas de ce que tu es mais de ce que tu exprime. C'est toi qui plus haut dit que linux c'est principalement du serveur et sous-entend que c'est de l'IP statique.
Je ne comprends pas comment c'est possible. Je n'ai jamais su écrire un service correctement pour sysvinit et je ne me pose pas la question avec systemd. Ça marche aussi bien sur les RHEL du boulot que sur Debian à la maison. Sans que je ne rencontre le moindre breaking change.
Pour les tâches répétitives le simple fait de pouvoir utiliser autre chose que le format cron (par exemple avec une gestion de la tz), d'avoir une commande qui me dit quand il a été lancé pour la dernière fois et quand est ce que sera la prochaine fois et enfin le fait de pouvoir manuellement lancer exactement le même job.
Je n'ai vraiment eu besoin de lancer des centaines de VM pour voir le gain qu'il apporte et journald pareil. Je n'ai que rarement mis en place une centralisation de logs pour ce qui est vraiment système et pouvoir sans se prendre la tête avec les formats de dates, sélectionner des logs de périodes arbitraires est très pratique.
Je n'ai pas l'impression que l'usage que j'ai soit particulier. En fait j'ai même l'impression que c'est un passage obligé. Si peut être qu'openrc permet d'écrire des services aussi simplement, d'une part je ne l'ai jamais croisé et d'autres part ce n'est que le premier point dans ce que j'ai décrit.
Je vois pas en quoi ce serait bien pire sans. Le système d'init fait parti du packaging et il n'y a jamais eu de compatibilité là dessus avant. Quand aux nouveaux usages possibles qui demandent une interaction avec le logiciel, ils sont triviaux et ne devraient tout simplement pas se retrouver dans les builds autres que linux. Si un programme se rend dépendant de ça c'est au même niveau que pour dbus ou une api comme io_uring. Croire que les Unix souffrent depuis systemd c'est oublié qu'ils souffraient déjà beaucoup avant et que les évolutions de linux dans son coin leur ont toujours fais du mal.
Ça ne veut pas dire grand chose. Je choisi une distribution pour la confiance que j'ai en sa gouvernance et donc en ses choix.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll