Re: Proposal: General Resolution on Init Systems and systemd Facilities
Bernd Zeimetz <bernd@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: