Re: Tentative summary of the amendments

[Josh Triplett <josh@joshtriplett.org>]

On Fri, Oct 24, 2014 at 03:50:48PM +0300, Aigars Mahinovs wrote:
> On 24 October 2014 15:40, Josh Triplett <josh@joshtriplett.org> wrote:
> > What makes the systemd case so drastically different that those who care
> > about alternative init systems cannot follow the same procedure?
> 
> The key difference is that until this year all packages worked on all
> init systems (as in you could start any service or application with
> any init system as PID 1, even with "init=/bin/sh").

Until recently, it was a painful endeavor to be the upstream of a daemon
package, because init scripts were not portable between Linux
distributions; each distribution tended to have to write their own.
systemd actually viewed that as a *problem*, and *fixed* it; it *is*
fairly reasonable now to ship a .service or .socket or other unit file
upstream and expect distributions to not need to change it.

And when functionality is missing, it's possible to get that
functionality added; how long has it been since sysvinit added a new
useful feature that daemons could use?

Until recently, if you wanted your service to be restarted if it
crashed, you had to use one of various separate packages to do so;
sysvinit simply didn't *do* that.  It *could* have; I'd love to know
where we'd be a decade ago if sysvinit had had an /etc/inittab.d.  A
quick search turns up people asking for that in *1999*.

There's a reason that systemd has had a meteoric adoption rate: it
provides a huge number of features people not only want, but have wanted
for years.

In practice, demanding that packages work with all init systems, or even
with *two* init systems, demands that they support the
least-common-denominator of functionality provided by those init
systems.  That effectively makes any new feature added to an init system
useless until duplicated.

> The fact that the regression is introduced by an architectural
> decision of systemd developers to tightly integrate system level
> services into the init system (and not by a decision in Debian) causes
> the feeling of loss of control.

That's a very legitimate and accurate feeling.  The people not doing the
work don't have control.  The people who are doing work on alternative
implementations do have control of those implementations, and can make
them as loosely coupled as they like.

> Then asking others to implement
> init-system-neutral versions of systemd-invented services just to keep
> using software that used to work before is ... raising some hackles.

"asking" for such alternative implementations isn't raising hackles;
*demanding* is raising hackles.  Even worse yet are the folks instead
demanding that upstreams simply not use such services, or who insist
that no possible use exists for such services.

And in many cases, the systemd-invented services and features fill a gap
for which no previously implementation existed, so "used to work before"
is quite inaccurate.  Not all features are optional; not every feature
needs fallback code to cope with its lack.  Doubly so if such fallback
code does not already exist.

- Josh Triplett