From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2357 Path: news.gmane.org!.POSTED!not-for-mail From: "Casper Ti. Vector" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: [Announce] s6.rc: a distribution-friendly init/rc framework Date: Fri, 23 Mar 2018 12:00:22 +0800 Message-ID: <20180323040022.GA1737@CasperVector> References: <20180322132334.GA11596@caspervector> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: blaine.gmane.org 1521777510 23588 195.159.176.226 (23 Mar 2018 03:58:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2018 03:58:30 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) To: supervision@list.skarnet.org Original-X-From: supervision-return-1948-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Mar 23 04:58:26 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 1ezDqU-00063m-37 for gcsg-supervision@m.gmane.org; Fri, 23 Mar 2018 04:58:26 +0100 Original-Received: (qmail 2477 invoked by uid 89); 23 Mar 2018 04:00:58 -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 2470 invoked from network); 23 Mar 2018 04:00:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=XXhXoWON48k9yeq3JiJMJ+AhFz78qMf+8kocLNRDaPQ=; b=dCvyi0iHH10nwDLxYCnOx0li/rI8+bm9xJuI+BLhesvMj7NP77SbBX3mafTirJXM1N zbQWn+ED2nZu5BKcaF6Sx9mlguruQ4zo0GD4SUEEbsc77xrxvCfrXbuaa34zH+6+40SG Aqcpt1DS5x4dObp+nHfTM5SpMFapCqISNUXInf7V3QbPlg0Opc18wuT56DfHNwqAsNIx Y4MPRCuwjEMkX28voMNCAKRBhmLiPcqUPTXf1+KuRVNnI0hpTlZBAHz29CLypdFN5hiu 2/Og4Zt3Prty/co4scgc/1Z2jdyzkFHAw3ulAsPeze+eggM2UyEhaDPFjHA+nQ6JmDhY MgCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=XXhXoWON48k9yeq3JiJMJ+AhFz78qMf+8kocLNRDaPQ=; b=Qny26hcLkbYa9FXkxkXaxf2ZvSAqLnU3xm+ktwvzXc8ppPVHzSNiumxX6BuJxRCHWw sUbL0MmL+7wWn0zdt/VcM1WtOvaZkgZlNtwzB48nf+n1B/kYmTaHiy4C4+Qxam/NE3SZ Br/FnDI5LdEo6m/siLR6Uh7XYtK17Q15BdU67XhZ2CSVEzbx1niD6IUpo7pVOFXtwgYD naIbs1wMGLpojseG09BorKi1oZkmnrH7JqnR6VvNDEwR0Kwstp1Sp/PH6d7qM3A4VNFh wa6ouawTx/lRvTKz2Gutitu29LIiagrzgssrO1IruU+4akwdVnVZOxAWWY9S7Mm5Wnh+ h3Pw== X-Gm-Message-State: AElRT7GtYHN1xicxEe+Ue+kfbzmJD83mI59EDO/kBLvDaOZbhWkkxNYZ SYW9Ueml4nxRPkcF+oOAM/D/J3Jw X-Google-Smtp-Source: AG47ELsxdw34LSXPwXqhUw/tJOKMsY46QmL++M5zFgQ28KJcpFlasd4zu8KI+2NztRNodNGQKEzxYw== X-Received: by 2002:a17:902:3225:: with SMTP id y34-v6mr10997768plb.180.1521777628737; Thu, 22 Mar 2018 21:00:28 -0700 (PDT) X-Google-Original-From: "Casper Ti. Vector" Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2357 Archived-At: On Thu, Mar 22, 2018 at 05:10:58PM +0000, Laurent Bercot wrote: > would it be possible for you to change the name of the project? What about using "slew.rc" and changing the installation path from `/etc/s6' to `/etc/slew'? The change is not exactly trivial but already much smaller than the `/etc/s6-init' / `/etc/s6-rc' merge I did before releasing this project, and can be done in a few hours (the project itself is not complex; the complexity on my part comes from the several machines where it is delpoyed and has to be migrated :(). (Hint for the etymology: note how "6" is pronounced in Chinese ;) > - I now recommend using socklog[1] to implement syslogd. I see. > It will likely be called s6-frontend. It will be written in C, and > provide a user-friendly interface for setting up a complete init > system, as well as a one-stop-shop "s6" command; the goal is to > improve usability and simplicity for users who are not longtime > members of the process supervision gang. 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 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'. 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. Instead, I think a better way is to provide a full "reference implementation" of what you have in mind, with the code generation knobs converted into comments (cf. the `devtmpfs' line in `rc.boot' in my project) or notes in the documentation. Let distros (and some adventurous users), i.e. those who understand their requirements for init/rc systems better, decide how to customise their systems: after all, text editors are the ultimate code generators for plain text files. If it is agreed that the Unix philosophy is essentially about minimising the total complexity of a system, I guess people would consider this to be the more Unix-ish way. > However, if decisions about "where to put stuff" are easy enough > to take, decisions about "what init scripts should I provide, what > external software should I assume is present on the system" are > definitely not. > But there is a large gray area here: what is "reusable policy" (RP) > and what is "distribution-specific" (DS)? First of all, I would like to note that the files in my project are not to be used exactly as is; instead, they are intended as "reasonable approximations" considering a majority of use cases. I currently use Alpine and Void on my servers and desktops, and I deviate from the published version of my project, more or less, on each and every machine, and their versions differ from each other. I consider this phenomenon normal and healthy. Considering the adoption of systemd, I think most longrun definitions are reusable, at least in an approximate sense; oneshots can be more volatile, but most are still reusable with a reasonable amount of distro-specific customisation. 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. > If it involves choosing between several external software packages > that provide equivalent functionality, is it okay to hardcode a > dependency, or should we provide flexibility (with a complexity cost)? 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. 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. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C