Re: Systemd, nightmare or opportunity?

On Sat, 2014-10-11 at 18:03 +0200, Valerio Bellizzomi wrote:
> 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.

Probably under /etc/systemd, there are many configuration files
(.service) that are a terrible thing to write and manage.


> 
> > 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.
> > 
> > 
> 
> 
> 
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk