First, I want to address LLM usage. English isn't my native language, but no, I didn't use LLM for translation. In this case I used it for learning new things(C language, login/session/service management in linux), inspecting new codebases(s6 repos, systemd, dinit, elogind, turnstile, userspawn, etc.), and formatting my email.
Arguments in that email are made by me. LLM was inspecting several codebases and answering to my questions, while I was making schemes/diagrams/flowcharts for the problems and possible solutions of per-user service manager spawning and interacting with the instance with s6-frontend. If that can prove anything, I can make photos and send the links here. I asked LLM to make my initial text more readable, with examples, and with proper formatting for the mailing list. I also don't like writing long texts to other people, having to tickle human brains' erogenous zones(some people call it "making the text sound strong" or "sound polite/professional"). LLMs are better than me in that regard. For that reason I use LLM with emails. And while I use LLM for coding usually, I didn't use it in this case due to contribution rules. However, I'm new in C(only 1 month), my coding skills in this language are and will be influenced by LLM explaining it, and inspecting the existing codebases. I still hope I can contribute to your codebase, despite being new with C. > My position is still that "s6 --system" should be the default for > root, because the common case when making service manager calls as root > is that you want to address the system one, and "s6 --user" should be > the default for non-root, because the common case is you want to address > your own user services. Most "s6 --system" calls would be unavailable > to users anyway for lack of permission; but it would still be possible > for a user to "s6 --system live status", for instance, to read the > state of the current system services. > > I disagree. Adding a --system option is simple, and it is the better > choice if it allows users to have access to the shorter command in the > common case. I think UID instead of env only, makes it better, but personally, I disagree with `--system` flag, since it's kinda unobvious for a new user, and i think explicitness is better here. But you know this system better, so I won't argue. It allows to use distro-packaged per-user services anyway. > The suggested 'user=1' is only internal API happening between the 's6' > command, which selects and reads the config file, and the 's6-frontend' > command, which does the actual work. It does not appear in the user's > environment. It is not visible anywhere except the s6-frontend code. I missed that. I thought it was env variable. > That is addressed by the S6_CONF environment variable. A user who wants > to override their configuration is always free to do so by setting that > variable. I should probably make it S6_USER_CONF for this case, since > S6_CONF would override the system defaults, not the user ones. Fully agreed here, that's much simpler than what I was thinking. For me, the most important points are these: 1. Setting s6-user.conf path at compile time, like it is done with s6.conf 2. Reading the interpretable paths at runtime. And you seem to have added them in your last commit. Thank you for that, I'll try it out. On Tue, Sep 8, 2026 at 3:33 PM Laurent Bercot <[email protected]> wrote: > > >I think the second option is the right one: `/etc/s6-user.conf` > >should be shared by all users and needs a layer of XDG interpretation. > > Yes, that is reasonable. I will add an XDG interpretation layer. > > > >I disagree with removing --user flag. I think instance selection > >should stay explicit: > > Right, the --user flag should remain, and there should also be an > explicit --system flag to choose the opposite. The question still > remains: what should the default be? > My position is still that "s6 --system" should be the default for > root, because the common case when making service manager calls as root > is that you want to address the system one, and "s6 --user" should be > the default for non-root, because the common case is you want to address > your own user services. Most "s6 --system" calls would be unavailable > to users anyway for lack of permission; but it would still be possible > for a user to "s6 --system live status", for instance, to read the > state of the current system services. > > > >I don't think the login environment should silently change what plain > >`s6` means. > > I'm thinking more effective uid than login environment. > > > >$ s6 status > > -> user profile selector was lost > > -> silently loads system configuration > > That is why. The effective uid is a more reliable marker. And > --system or --user could be used to override that autodetection anyway. > > > >So I think one explicit `--user` flag is simpler than making plain `s6` > >context-dependent and then needing a second `--system` mechanism to > >escape that context. > > I disagree. Adding a --system option is simple, and it is the better > choice if it allows users to have access to the shorter command in the > common case. > > > >For the same reason, I do not think `user=1` is necessary. > > The suggested 'user=1' is only internal API happening between the 's6' > command, which selects and reads the config file, and the 's6-frontend' > command, which does the actual work. It does not appear in the user's > environment. It is not visible anywhere except the s6-frontend code. > > > >The current PR deliberately avoids making `/etc/s6-user.conf` > >XDG-aware. Because of that, I added compiled defaults such as: > > > >--user-conffile=/etc/s6-user.conf > > > >--with-user-store-list=/usr/share/s6/user/sources:/etc/s6/user/sources > >--with-user-source-subdir=/s6/sources > >--with-user-repo-subdir=/s6-rc/repository > >--with-user-bootdb-subdir=/s6-rc/compiled/current > > These are more complex than necessary, and I don't think I could, or > would want to, merge these changes anyway: see below. > > > >The config should be interpretable, and the compiled values should just > >remain defaults. > > This is reasonable, it will just require a little more effort; I'll be > on it as soon as I can. > > > >A user may eventually want to create their own user-profile override > >under `XDG_CONFIG_HOME`. > > That is addressed by the S6_CONF environment variable. A user who wants > to override their configuration is always free to do so by setting that > variable. I should probably make it S6_USER_CONF for this case, since > S6_CONF would override the system defaults, not the user ones. > > Now. > > This was a useful exchange, because it clarified what I need to > improve for proper user service support. > > However, the mail I answered to appears very likely to have been > generated by an LLM. > > You may have a good reason for this: for instance, if you're not > fluent in English and you asked an LLM to translate. But it does not > look that way. The arguments themselves seem to have come from the > LLM's "reasoning", and parts of the suggested changes (at least the > new configure options) seem directly LLM-generated. This is a violation > of the contributor policy: > https://git.skarnet.org/cgit/s6-frontend/tree/CONTRIBUTING > > Also, when I said I wanted a design discussion, I meant, and let me > make this very clear and explicit, a design discussion _between humans_. > I wish to have input from the community, not from what you can extrude > from an aggregate of unethically sourced data. > > As a consequence: > - I am closing the PR. > - I am keeping the discussion open in cases you, as a human being, or > other members of the community, want to participate. > - If you are using an LLM to participate, you are expected to disclose > it and to give your reasons for it. > - Any failure to disclose, or any insufficient reason (as decided by > me, > this is not a democratic process) will result in a ban. > > Please help me keep this space slop-free, and a place where we can > build > untainted future technology. (This is not an invitation to discuss > merits and demerits of LLMs on the list. If you feel the need to do so, > do so somewhere else.) > > -- > Laurent >
