Re: Tentative summary of the amendments
On Fri, Oct 24, 2014 at 08:31:22PM +0300, Aigars Mahinovs wrote:
> First of all, Josh, thank you for the long and reasoned replies. I do
> hope this back-and-forth is useful for others as well in the context
> of this decision, that is why I am still keeping the debian-vote list
> in the CC.
Likewise.
> On 24 October 2014 19:18, Josh Triplett <josh@joshtriplett.org> wrote:
> > Aigars Mahinovs wrote:
> >> 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.
> >
> > 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.
>
> I am assuming that the person running the commands know about the
> dependencies in the services and starts them up manually and in the
> right order. Init system does *not* glue services together it only
> starts them in right order with right options - after that init system
> does not participate in the inter-process communication.
sysvinit doesn't, but then sysvinit knows very few ways to glue services
together. Other init systems (not just systemd) do in fact do more than
just starting services in the right order with the right options, and do
potentially participate in inter-process communication.
> > 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.
>
> That is what tools like start-stop-daemon or daemontools are for.
> There is no need to reinvent things for every daemon
Feel free to add more features to start-stop-daemon or daemontools, and
convince people to use them. Bonus if you do so with a compatible
interface to make it easier to convince people (for instance, passing
the same environment variables to daemons). To the best of my
knowledge, those tools don't currently support socket activation, nor
equivalents for 90+% of the directives in systemd.exec(5),
systemd.socket(5), and so on. (If you haven't read those manpages
recently, consider doing so, to get an idea of the number and variety of
such features.) There are some other tools that support other subsets,
such as minijail for security sandboxing features. So you could
probably assemble an array of substitutes for a decent subset of systemd
unit functionality, along with documentation for how to correctly use
them in combination (often non-trivial if they don't live in the same
tool). Nobody has done so yet.
Personally, I'd actually love to see a port of systemd (a *complete*
port of systemd) to be capable of running in system mode without being
PID 1. I don't think that's something systemd upstream will accept
patches for, but it might be a maintainable patch as part of a
downstream fork. While that certainly wouldn't make all systemd
opponents happy, it seems like that'd address your primary objection,
simply by making it possible to run systemd under sysvinit to launch and
manage systemd services. :) That would also have the major advantage of
not making *anyone* do duplicate work.
It might help to know that one of the motivations that *started* me down
the path towards FOSS was realizing how much needless duplication
occurred in the proprietary software world purely through lack of code
sharing. If someone *intentionally* wants to reinvent the wheel, fine,
and they might even manage to make a rounder wheel in the process.
However, I consider it completely unreasonable to *require* duplication
of implementation effort before using a new feature; that's a needless
waste of many people's time.
And I suspect, or at least hope, that you consider that unreasonable as
well. It seems to me that your objections lie more with not wanting to
use systemd as PID 1 yet wanting to run other software. I'd personally
be interested in your non-devil's-advocate reasons for caring, because
those seem likely to be solvable.
> and there is no
> need to hardlock them into the init system too.
I really wish you'd stop asserting this. You, and others, would
*prefer* that they're not part of the init system. That opinion (and it
is an opinion) on design and architecture is not universal, and there
are quite a few documented and frequently reiterated reasons to
integrate such features into an init system. You may disagree with
those reasons, or with the relative weight given to them compared to
others you care more about; that does not invalidate them. Other people
have legitimate technical requirements that differ from yours.
> >> 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.
>
> I can see how it is beneficial to use something like that by default,
> but if you remove, for example, the command line options for
> specifying port to bind to, then you loose all kinds of non-default
> functionality, like the ability to run the same or a different version
> of a service as a one-shot on high port by a regular user, to start up
> a debug version locally, .... Sure it is easier to write a daemon that
> can only be started as a systemd service, but along with loosing
> support for all other init systems you also loose a lot of
> flexibility.
On the contrary, you gain a great deal of flexibility, without having to
write any extra support for it. Want to run another instance on another
port? Add another .socket unit. And note that you can do so in a
systemd --user instance if you want, or ephemerally via systemd-run or
systemd-activate. Easy to start a debug version that way too.
> >> 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."
> [snip]
> > 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.
>
> Actually, we kind of do that - such things are detected by configure
> scripts, for example.
Only when applications actually support building without them. Many
applications do not.
> But all your examples (except GCC) are systems
> that applications have always been calling.
GCC as well; there are several pieces of software that rely on GCC
extensions and will only build with a compiler supporting those
extensions, which makes it that much harder to develop and promote a new
compiler.
> Applications have never
> been calling init system before. Try the same assumption with: bash,
> Metacity, gnome-shell. "When you application is started, it might be
> started by gnome-shell, in that case you may give gnome-shell an
> indication about your startup animation, but you may be started by
> something else, in that case you should still start, but it is fine
> not to provide the correct startup animation."
Talking about "startup animation" dismisses features and integration as
trivial frivolities. Since you mentioned gnome-shell and metacity,
let's talk about an analogous situation to the systemd case. Formerly,
in GNOME 2, you could run a "panel applet" on top of gnome-panel, and
run gnome-panel within any desktop environment and window manager you
liked. Neither gnome-panel nor those applets exist in GNOME 3; instead,
gnome-shell provides an extension API, and extensions use that API to
provide anything from "panel" applets to major redesigns of the UI.
Those extensions do not work without gnome-shell (they have a versioned
Depends on gnome-shell), and gnome-shell only works as the window
manager, which you can only have one of. You can choose to run a
different environment, in which case none of those extensions are
available at all. Seems pretty analogous, except that nobody is crying
bloody murder over the various packages that "Depends: gnome-shell" and
demanding that they work with KDE, or that someone reimplement the
gnome-shell extension API before those extensions can use it.
> I do like the kernel and architectures analogies. We don't have a
> policy requiring software to work on all kernels/architectures. I
> believe that this situation is different because of the difference in
> starting conditions - imagine if in previous Debian release *all*
> software worked on all architectures, including kFreeBSD and Hurd and
> then TC declared that Linux/amd64 is the new default architecture
> (like what architecture install image shows up on the homepage) which
> is quickly followed by people introducing new versions of important
> software that is "cleaned up and streamlined" by removing all that
> pesky support for non-default architectures. Sure it is much easier to
> support software that is written just for one kernel and one
> architecture. Sure, you can say that "patches for other arches and
> kernels are welcome". But if you "clean up" all the automake away and
> rewrite the app to use cgroups ... patches are not going to be easy to
> come up with. And people in other architectures and kernels might be
> reasonably annoyed.
I think your analogy paints an unrealistically nostalgic and idyllic
picture of life before systemd, as though there were a pile of equally
capable init systems sitting around and a pile of software that all
happily ran on all of them, until systemd came along and made everyone's
life miserable by being entirely too useful.
The situation is not static. Support for architectures, like support
for init systems, requires *maintenance*. And in particular, in the
upstream Linux kernel, it takes *work* by architecture maintainers to
add features that typically show up first on x86; for instance, wiring
up new syscalls, BPF support, KVM support, and hundreds of other
interesting features people care about, not to mention fixing bugs and
collaborating on interface design. If that work stops happening, or if
some architectures start vastly outpacing others with new features, I'd
fully expect the lagging architectures to bitrot, and eventually to be
removed. Furthermore, even before such removal, sofware would start
using new kernel features that only work on the architectures people
care about.
Similarly, in Debian, if an architecture or kernel doesn't keep up, the
release team will drop it from the release.
You're also implying that, out of a clear blue sky, the TC would declare
a new default, as though they weren't asked specifically to decide an
already contentious issue caused by a huge number of people *wanting* to
support a new init system and being FUDded away from doing so.
Finally, you're suggesting that code already exists that would be
"cleaned up" and removed, and assuming that's the only reason to limit
architecture (or init system) support. The common case here, however,
would be *new* code to implement some new feature, depending on some new
support provided by (for instance) a new service. *That* code
implements new functionality that won't necessarily work everywhere.
And it's not reasonable to assume that all new functionality is optional
functionality; see the portion of my response you snipped and didn't
respond to, regarding libraries introducing new functionality that
applications depend on.
> >> 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.
>
> I am all for common code and libraries. What I am *not* for is putting
> that common code into an *exclusive* system component.
You've made that opinion quite clear. Omitting further responses to
this bit because it duplicates multiple lines of discussion above that
I've already responded to.
- Josh Triplett
Reply to: