Bernd Zeimetz <be...@bzed.de> writes: > On 11/15/19 3:06 PM, Ian Jackson wrote:
>> The problem with even your option B is that there is no effective route >> for non-systemd systems to "catch up" as you put it. > For some systemd Features there is no sane route to implement them for a > non-systemd system. Especially all the security features, private > directories and so on. They will never catch up as it is technically > impossible or an enormous amount of work. So not haveing a route here is > perfectly fine. It's clearly *possible* to implement all of those security features without systemd. There are standalone programs such as firejail that do many of the same things. Even for features that really need PID 1 support (which is rare for those sorts of security features), it's possible to add that support to other init systems. Obviously it's a very substantial amount of work, and one can be dubious about whether that work will ever happen or if some community has the resources required. The systemd project has attracted substantial contributions and has written and tested a large amount of code, and replicating that success will require a correspondingly large amount of work. But I think it's also important to note that this is (informed) speculation about resourcing, rather than a hard technical constraint. One very straightforward way that a non-systemd init system could implement all of those things is to start by forking systemd and then changing it to suit their differing objectives. No non-systemd init system has yet taken that approach, but there's no inherent reason why someone couldn't take that approach and rework the systemd code base to use a different design. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>