Hi, Am 04.01.2018 um 05:12 schrieb Russ Allbery:
> I think the key to a good path forward is to recognize that systemd solved > some specific problems, and to build a roadmap of which problems do indeed > need to be solved and the alternate solutions to them, and which aren't > important enough to folks who don't like systemd to solve and therefore > will stay systemd-exclusive features until that changes. Then there can > be a sustained ecosystem, with a clear mission, alongside systemd, and > Debian can endeavor to support both. We still need a non-systemd ecosystem for everything that is out of scope for systemd. I've written a lengthy blog entry[1] about this in 2016. The condensed argument is that no init system can provide both an imperative and a descriptive configuration model at the same time unless it solves the halting problem and resolves the interaction between both configuration systems. For desktop environments, we need the configuration to be descriptive and machine writeable, otherwise the configuration dialogs will not work, but this comes at the price of the flexibility offered by an imperative language. Systemd and System V init are two fundamentally different approaches. Neither can replace the other without breaking core design principles and becoming completely useless in the process. Simon [1] http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html
signature.asc
Description: OpenPGP digital signature
