Posté par Moonz .
En réponse au journal Debian à l'heure du choix.
Évalué à 1.
Dernière modification le 03 février 2014 à 22:29.
Avant une solution portable était possible mais tout le monde s’en foutait (la preuve, initng n’a jamais décollé alors qu’il était là des années avant même que upstart soit en discussion, qui lui-même est antérieur à systemd...)
Maintenant une solution portable est juste impossible.
J’ai du mal à voir l’amélioration sur cet axe d’analyse...
C’est pas grave hein : comme je l’ai dit, en pratique tout le monde s’en fout (tout simplement parce que les distribs tiennent à garder le contrôle de leurs scripts d’init, cf debian qui refuse d’utiliser des unit systemd dans lesquelles les chemins seraient hardcodés, et upstream sait que c’est pas son boulot de fournir 200 scripts d’init mais celui du packageur). Tout ce que je dis c’est qu’il est naïf de croire l’excuse que « systemd c’est fait pour simplifier la vie des mainteneurs upstream ». Ça n’a jamais été son but de toute façon, les buts affichés de systemd c’est :
un démarrage rapide (parallélisation des serveurs)
exposition de fonctionnalités Linux-centric peu utilisées à cause du manque d’outils en userspace (typiquement les cgroup)
à plus long terme, intégration des services de bas niveau (init & udev c’est fait, logind va rejoindre bientôt, à terme wayland va probablement l’être)
[^] # Re: dépendance à un système d'init
Posté par Moonz . En réponse au journal Debian à l'heure du choix. Évalué à 1. Dernière modification le 03 février 2014 à 22:29.
Avant une solution portable était possible mais tout le monde s’en foutait (la preuve, initng n’a jamais décollé alors qu’il était là des années avant même que upstart soit en discussion, qui lui-même est antérieur à systemd...)
Maintenant une solution portable est juste impossible.
J’ai du mal à voir l’amélioration sur cet axe d’analyse...
C’est pas grave hein : comme je l’ai dit, en pratique tout le monde s’en fout (tout simplement parce que les distribs tiennent à garder le contrôle de leurs scripts d’init, cf debian qui refuse d’utiliser des unit systemd dans lesquelles les chemins seraient hardcodés, et upstream sait que c’est pas son boulot de fournir 200 scripts d’init mais celui du packageur). Tout ce que je dis c’est qu’il est naïf de croire l’excuse que « systemd c’est fait pour simplifier la vie des mainteneurs upstream ». Ça n’a jamais été son but de toute façon, les buts affichés de systemd c’est :
Pas vraiment non.