Re: Tentative summary of the amendments
Aigars Mahinovs wrote:
> On 24 October 2014 17:14, Josh Triplett <josh@joshtriplett.org> wrote:
> >> 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.
>
> That is *not* what the discussion is about. It is *not* about init
> scripts. Forget about init scripts. Imagine booting up a system with
> "init=/bin/sh" - it should be possible to run a command to start your
> service from there (without any init system at all). If you depend on
> other services, then those should be startable with simple commands
> too. If that is possible, then all is fine.
"exec /lib/systemd/systemd". ;)
More seriously, no, your expectations are no longer realistic or
reasonable. It is already not possible *today* to run "simple commands"
and end up with a working system; many services depend on other running
services, and the thing gluing them together is an init system. You
cannot, for instance, just run "foo-daemon" or even
"/etc/init.d/foo-daemon start" for an arbitrary foo, not least of which
because that won't enforce the starting of things foo depends on. In
turn, those dependencies may include DBus services, or udev-managed
devices and device events. You can't run DBus services without DBus
(though systemd is actually working to fix that), and you can't generate
udev events without udev. Without such mechanisms, software may well
fail to launch or operate correctly. The world is more complex than
your model, and has been for far longer than systemd has existed.
Your init=/bin/sh system may well depend on an initramfs to successfully
boot. You may not be able to type on your keyboard without running a
daemon (e.g. for a Bluetooth keyboard). You might not even have a text
console without running a daemon. Those daemons themselves may depend
on other services.
It's perfectly reasonable, for instance, for a daemon to expect to be
run as a non-root user, and be handed a low-numbered socket that it
could not itself open. It's not reasonable to require every daemon to
reimplement that code itself, with all associated security requirements.
It's also reasonable for you to reimplement that functionality in some
other system, and convince upstreams to use your version instead. For
instance, you might adapt a piece of software to work with inetd rather
than a .socket file.
> If systemd adds socket activation and you daemon uses it it is fine
> for the start up of that daemon to use socket activation. If a user
> is running another init system it is fine for socket activation not to
> work, but a problem would be for your daemon to crash or hang on
> startup because of this.
Expect an increasing number of new upstream daemons to lack any code to
daemonize themselves, or to start as root and drop privileges, when a
perfectly reasonable and better-audited implementation already exists to
launch the daemon as non-root with no forking. And that's two of
several hundred features. You cannot expect all upstreams to
*duplicate* functionality that already exists, nor to maintain such
duplication indefinitely.
> > 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.
>
> Yes - the demand is to make sure that the least-common-denominator
> does actually minimally work.
I appreciate that you actually acknowledge this rather than avoiding it,
but nonetheless, no, arrogant demand refused; systemd, like the Linux
kernel and many other pieces of software, provides useful functionality
that other implementations do not have. Ask others nicely with
convincing arguments and see if they'll do the work for you (many seem
willing to), or do it yourself, or create other upstream software with
different requirements that does not need systemd and package that
software.
> You may use the advanced features, if they are available, but can't
> just assume that they will be. On the other hand it is fine to not
> provide some functionality if the advanced init system features are
> not available.
Consider how ludicrous this would sound about any other software:
"You may use the Linux kernel, if it's available, but you can't just
assume that it will be. On the other hand, it is fine to not provide
some functionality if Linux is not available."
"You may use glibc, if it's available, but you can't just assume that it
will be. On the other hand, it is fine to not provide some
functionality if glibc is not available."
"You may use the X Window System, if it's available, but you can't just
assume that it will be. On the other hand, it is fine to not provide
some functionality if X is not available."
"You may use GCC, if it's available, but you can't just assume that it
will be. On the other hand, it is fine to not provide some
functionality if GCC is not available."
Now, as a wishlist bug, sure, you could request fallbacks; some software
may implement them. Currently, some software in Debian has done so for
various dependencies. Huge parts of Debian, however, have hard
dependencies on Linux, glibc, X, and GCC, and those dependencies are not
in any way unreasonable.
> > 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.
>
> If some software used to work before systemd
Bad assumption. All useful software was not written before systemd, nor
did all software development halt when systemd was created. Software
develops new functionality.
> there is no technical
> excuse for it not working with other init systems after systemd
> integration.
There most certainly are good technical reasons, and you should already
be well aware of that. We create libraries and otherwise factor out
common code for a reason, and it's often to *throw away* duplicate
implementations in favor of a one or more well-maintained common
implementations.
Now, there may be *political* reasons for software to work with other
init systems. But "I don't like systemd" is not in any way a technical
argument. If you have any technical arguments for not running systemd,
report them as bugs on systemd (upstream, please) so they can be fixed.
> If there was no socket activation before, it can not be
> such an essential feature that you simply can not function without it.
Notice the vast set of software libraries in Debian with library minor
version numbers larger than 0, suggesting that they've added
functionality that old versions do not have, and enforcing that software
using those features will not run with old versions of the library.
Also notice the large number of new libraries that appear, and software
that depends on those libraries, which will not run without the presence
of those libraries. New features arise every day that other software
will wish to depend on. If you don't want those features used, create
even better ones to use instead.
- Josh Triplett
Reply to: