From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2359 Path: news.gmane.org!.POSTED!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: [Announce] s6.rc: a distribution-friendly init/rc framework Date: Fri, 23 Mar 2018 10:51:57 +0000 Message-ID: References: <20180322132334.GA11596@caspervector> <20180323040022.GA1737@caspervector> Reply-To: "Laurent Bercot" NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1521802195 19632 195.159.176.226 (23 Mar 2018 10:49:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2018 10:49:55 +0000 (UTC) User-Agent: eM_Client/7.1.31849.0 To: supervision@list.skarnet.org Original-X-From: supervision-return-1950-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Mar 23 11:49:51 2018 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ezKGc-00051I-MN for gcsg-supervision@m.gmane.org; Fri, 23 Mar 2018 11:49:50 +0100 Original-Received: (qmail 8010 invoked by uid 89); 23 Mar 2018 10:52:24 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7999 invoked from network); 23 Mar 2018 10:52:24 -0000 In-Reply-To: <20180323040022.GA1737@caspervector> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrvddugddvudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucfrrghrrghmpehmohguvgepshhmthhpohhuthenucevlhhushhtvghrufhiiigvpedt Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2359 Archived-At: >What about using "slew.rc" and changing the installation path from >`/etc/s6' to `/etc/slew'? That's all fine with me, but it may have connotations in English that you don't want to associate with a project aimed at stability and friendliness :) >To be honest, I find the idea not very appealing to me. I did not want >to say about this before, but now I find it necessary before more=20 >energy >is spent in goals that I consider less meaningful. Fortunately, only >`s6-linux-init-maker' is affected by this issue as of now, and I will >use it as an example. > >I think the direct downstream of init/rc systems is distributions, not >end users which demand "usability" in the usual sense (actually, one of >the many problems with systemd is that it attempts to bypass distros >and directly provide "unified" features to end users). After s6/s6-rc >becomes mainstream, `s6-linux-init-maker' will perhaps have, IMHO, an >embarrassing role: most end users would begin with scripts provided by >their distros, which might often be very different from those generated >by `s6-linux-init-maker'. Yes, but I don't see this as a problem. The target audience for s6-frontend would precisely be *distributions*, not end users; the goal is to factor the work of putting all the s6 pieces together and make it easier for distributions to tailor those pieces to their own policies. For instance, instead of having to provide s6-rc source definition directories for services, they would provide a descriptive file, similar to systemd unit files, that would then be automatically processed and turned into a set of s6-rc definition directories. So they can focus on the functionality they want to achieve in the service without having to learn the nuts and bolts of the s6 mechanisms. Bear in mind that - this is a simplified, but descriptive enough view of the political landscape of the current Linux ecosystem - distribution maintainers are *lazy*. They already know systemd, or openrc, or sysvinit; they don't want to put in more effort. They don't want to have to significantly modify their packaging scripts to accommodate a wildly different format. They don't want to have to learn how things operate under the hood. Ideally, they don't want to have to come up with policy decisions themselves! You may not find the idea of s6-frontend appealing, but distro maintainers really do. I've had distro maintainers say to me verbatim that the *main*, and in some cases *only*, obstacle to s6 adoption was its interface and how different it is from what they already have; but apart from that, they love the idea. Remember that a few years ago I started a quest to learn what kind of functionality people wanted in s6 in order for them to switch to it? I expected technical answers, I expected weird systemd features; I got literally none of those. What I did get, though, is requests for a friendly UI and accessibility for "average" users (read: lazy distro maintainers included). This is not the answer I wanted, but it's the crystal clear answer I got; so it would be foolish of me to ignore it. I don't like it any more than you do, and interface work would definitely not be my first choice, but there it is. However, I'm absolutely committed to keeping the individual s6 pieces independent and maintaining them separately, and the frontend will always be optional. So, power users like you will always be able to use s6-linux-init, s6 and s6-rc separately, with your own scripting around them; slew.rc or similar initiatives will not be obsoleted. I'm not turning s6 into a monolithic behemoth, don't worry. ;) >And the difference is not only in the utilities used, but also in the >functionalities offered: eg. conditional (re-)mounting of `/run' >according to results of `mountpoint -q /run', loading/saving the clock, >saving the "uncaught" logs. This is honestly not to show off the >features provided by my project, but to show that attempts to encapsule >factors in real-world use cases of an init/rc system into a code >generator can be largely unproductive. Well, obviously the frontend should offer knobs and settings to allow customization of those aspects. And in the worst case, there should be a "run this user-provided script as is" function, which allows users to bypass the UI and provide snippets of code themselves. >Instead, I think a better way is to provide a full "reference >implementation" of what you have in mind, with the code generation=20 >knobs >converted into comments (cf. the `devtmpfs' line in `rc.boot' in my >project) or notes in the documentation. These two approaches are not mutually exclusive. :) > I do not consider package dependencies >to be a big problem: distros (and those adventurous users) will >naturally handle them when customising the init/rc system. No better >way has been proposed to my knowledge: `s6-linux-init-maker' basically >solves it by depending on skaware, and systemd "solves" it by using its >own extremely bloated implementations. That is precisely the discussion that I want to have. To a distribution, dependencies are not a problem because they know what they are packaging and they are responsible for their integration choices. To a software author, however, dependencies are an issue - because I can take responsibility for software I provide, but I cannot take responsibility for external software; this is why s6-linux-init depends on skaware, because I cannot depend on, say, a coreutils implementation - but I'm well aware that distributions will choose to depend on some coreutils instead, and they will be right; so obviously distributions will probably not depend on the verbatim output of s6-linux-init-maker, and that's okay. systemd has the exact same approach to external dependencies: it provides all the functionality itself so it doesn't depend on anything else. The difficult part is that writing an integrated init system is riding the fine line between "software author" and "distro packager". At one end of the spectrum, you have s6, which is pure mechanism, self-reliant, but that needs to be paired with other programs to get a complete turnkey init system; at the other end, you have kitchen sinks like systemd that include everything they need by reinventing the square wheel. To provide a reasonably lightweight but immediately usable and distro-adoptable init system, there is a golden mean to be found, and I think it's important to find it. >Regarding networking, I consider netifrc to be, though bloated, a >successful example. As I mentioned, the functionalities of netifrc can >in principle be implemented using preprocessors in much cleaner ways, >and I guess the complexity cost that comes with the flexibility would >not be too big in this case. But is it the software's job to determine the format of the network configuration file, or is it purely the distribution's? Is it an advantage for an init system to come with its own network configuration format, or a drawback? Is it possible, and worth it, to write hooks that call pre-existing network scripts, or should the whole network interface config mess be torn down and rebuilt from scratch? Those are the exact kind of questions we need to ask ourselves. >Of course, this means you probably cannot use C exclusively. If Unix >used a small language with S-expressions that can be both compiled and >interpreted, and with garbage collection enabled at >compile/interpret-time but optional for compiled binaries, we would be >perhaps free from those "flexible {whatever language} or efficient C" >dilemmas. Unfortunately, no such language exists, at least to my >knowledge. Language is an implementation detail. I usually go for C because it doesn't depend on anything and keeps things lightweight, so it's a natural choice for low-level software, but obviously when doing integration you need a lot of scripting. I will go with autogenerated execline scripts, in the spirit of s6-rc; you chose to use the rc shell, which is a small, acceptable dependency; all this is fine, and it's really not worth spending time on. -- Laurent