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 <j...@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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024201635.GA11472@cloud
