Bon en fait tout ça c’était pour dire que Bash c’est un langage de script, et on l’a utilisé pour faire un système d’init complet, plusieurs milliers de lignes qui à priori était difficilement maintenables vu la rapidité à laquelle il a été adopté sur différentes distributions
Ce serait un argument acceptable (au delà de l'effet de mode, souvenons-nous de KDE4, et rappelons qu'un démarrage plus rapide est très vendeur pour les distros grand public) si udev était resté une brique indépendante. Ceux qui auraient voulu maintenir un init à base de scripts aurait pu le faire sans problème exactement comme avant et ça aurait àmha été beaucoup moins polémique (alors que là, couplé avec une certaine... attitude à la tête du dev de systemd, ça ne pouvait qu'être détonnant).
Bah donc systemctl --list-dependencies --reverse foobar.service, non? L’option --reverse ça fait bien le contraire.
Bah non :
Yes, I tried it with the --reverse. That still doesn't help me if I am trying to design a target which is shutting down services. It doesn't take conflicts into account.
And indeed, that's not really what I needed. What I really needed is a "what will happen if I run 'systemctl isolate battery.target', given my current system state vis-a-vis what services are currently running?"
Et la suite qui enfonce le clou :
And in turn, I need this because I want to shut down a number of services when I do the equivalent of "enter runlevel N" in sysvinit speak, where I created runlevel N by first cloning runlevel 3 via something like "rsync -avH --delete /etc/rc3.d /etc/rc4.d" and then manually adding and deleting some symlinks. From looking at the contents of /etc/rc4.d, it's immediately obvious what will happen when I enter runlevel 4, both in terms of which services will get started, and more importantly, which services will get stopped.
From looking at the contents of battery.target and related systemd config files, it is NOT obvious, especially with how the /etc/init.d backwards compatibility feature seems to create implicit phantom services files and phantom multiuser.target.wants entries.
Et donc systemd prend en charge les touches de changement de luminosité?
[^] # Re: Portabilité et forçage
Posté par Ignatz Ledebur . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Ce serait un argument acceptable (au delà de l'effet de mode, souvenons-nous de KDE4, et rappelons qu'un démarrage plus rapide est très vendeur pour les distros grand public) si udev était resté une brique indépendante. Ceux qui auraient voulu maintenir un init à base de scripts aurait pu le faire sans problème exactement comme avant et ça aurait àmha été beaucoup moins polémique (alors que là, couplé avec une certaine... attitude à la tête du dev de systemd, ça ne pouvait qu'être détonnant).
Bah non :
Et la suite qui enfonce le clou :
C'est ce qu'il aimerait comprendre justement.