Re: Systemd, nightmare or opportunity?

On Thu, 2014-09-25 at 09:42 +0100, Thomas Leonard wrote:
> On 25 September 2014 08:33, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:
> > As those of you who use Linux may know, more and more Linux distributions
> > are moving away from their init systems, and are moving to systemd. A
> > consortium of interdependent system programs that replace not only
> > init/startup, but a whole range of other functionality that were
> > previously handled by independent software in the unix line (do one thing,
> > do one thing good) that I feel loosely forms the philosophy that also
> > underlies capability discipline. On one side, it would seem that a move
> > away from this philosophy would be a move away from anything POLA related.
> > On the other side however, this also might provide an
> > opportunity/challenge for people concerned with least authority on the
> > language level. If we could come up with a drop-in least authority rewrite
> > of systemd in a capability secure language (David-Sarah might have a clue
> > about what language to pick ;-) ), this could definetely become the basis
> > for a much more robust version of Linux, that could easily be addapted by
> > all those distro's now moving towards this horrible systemd architecture.
> >
> > Any thoughts?
> 
> What exactly is "horrible" about the architecture?

It introduces various configuration files that are located outside
the /etc directory.


> Before, SysVinit/Upstart ran everything as root, relying on each
> program to open the sockets it desired and drop privileges. Now,
> systemd opens all sockets and passes them (capability-style) to the
> programs, which are run under a limited user account (there are also
> quite a few sandboxing features offered, such as private /tmp, private
> network namespaces, containers, etc).
> 
> It also uses cgroups to group processes reliably (so killing a service
> really does kill all its processes), and (I think) provides reliable
> logging information (one service can't log messages appearing to be
> from another service).
> 
> Being written in C is disappointing, but I can't imagine that anything
> else would have been politically acceptable.
> 
>