On Wed, Oct 17, 2018 at 04:58:33PM +0200, KatolaZ wrote:
> On Wed, Oct 17, 2018 at 09:30:50AM -0500, Daniel Taylor wrote:
>
> [cut]
>
> > > c) where and how would you draw the line indicating what's unacceptable about
> > > systemd - in other words, what exactly do you mean by "the Unix paradigm" in
> > > your comment above?
> > Split out the PID 1 stuff to just the bare minimum of what needs to be
> > there, organize everything else into appropriate units.
> >
> > This is not a trivial project, which is why nobody has taken it on AFAIK,
> > but systemd must be doing something that package maintainers and developers
> > want. That suggests that the way to beat them is to do that, only better.
>
> The problem is exactly there: you don't really need systemd if you
> just need a reliable PID 1. What appeals systemd's enthusiasts is the
> process supervision and management system. Which is probably 90% of
> the reason why systemd needed to fagocitate the whole low-level
> user-space (please remember that the only way to reliably know that a
> process is dead under unix is to be the parent of that process....).
>
> I know the issue looks easy and straightforward on the surface. But
> when you start looking into it seriously, you quickly realise that
> things are not as straightforward as you thought ;)

To summarize (IIUC) the main beneficiaries of systemd are:

1) a few heavyweight desktop frameworks and tightly coupled applications
2) some heavy-duty system administrators who want to use systemd's process management

General-purpose applications (and daemons, etc.) that
attempt to do one (non-desktoppy) thing well either don't
require systemd, or systemd support is a compile-time option
that can be opted out of.

I, personally, see no single attraction in all of the
systemd bandwagon. But then I work in the terminal when
I can, and still type the u?mount commands every day.

Perhaps someone could implement a reasonable subset of
support for systemd unit files, but why bother? As
discussed here ad nauseum, you can get sufficient process
management abilities elsewhere, with less pain.
The others (please speak up if I'm mistaken) are mainly
interested in desktop environments, for which a subset of
systemd's abilities will likely never be good enough.

Devuan already provides DBus, which is magical enough
for a lot of GUI cleverness.

I will be interested to see if there are users for a process
management framework that supports systemd unit files.
Right now it looks like an itch that no one is interested in
scratching. More power to anyone who wants to take a stab
at it. I'm here with my popcorn to see what happens.

AFAIK, I have only a few daemons running on my system, and
would rather use some lightweight framework to start and
supervise them even if I had to write half a dozen scripts
myself.

Why would I want millions of lines of code developed by
someone whose agenda is so radically different from my own
goals and aspirations? Why would I want compatibility with
something fiendishly complicated and created for what
appears to be no more than creating jobs and breaking with
the battle tested philosophies of administering systems
under unix.

Well, there I am ranting again :-)

Have fun, guys and gals, keep coding and smiling.
Trolls are invited to sit down to lunch, and eat
politely :-)


> My2Cents

I consider my thoughts to be more like rounding errors,
based on bruises and hard-won lessons of trying to fit
square pegs in round holes :-)

Joel


> KatolaZ
>

> -- 
> [ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
> [     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
> [       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
> [     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
> [ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]

> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


--
Joel Roth