First of all, if you get tired of this discussion, just tell me and I
will stop bothering you.
I, for my part, experience great joy from this discussion!
If you are still interested, here you go:
> And both can be solved without s6-rc in a simpler way than with it.
Why do you think it is simpler?
It is one oneshot less, at the cost of running s6 only and s6-rc
services side by side
and lacking dependency management (see Hoël's mail).
Besides, I suppose one being this:
>> fusermounting some network/encrypted filesystem comes to mind.
>> e.g. mount a NAS share so that a longrun snooze "cronjob" can record a
>> livestream to it.
>
> Okay. I'd argue it's still under the complexity line where doing
> this manually - fuser(un)mounting at snooze service (de)installation
> time - is easier and faster than setting up an s6-rc infrastructure.
But this to me seems like saying "why not mount devfs in the longrun
starting mdevd/udevd?"
> Yeah. So do I. Do you have any idea how difficult it is to make
> distribution maintainers adopt the s6 paradigms? Change their habits
> even a little bit? Do you have any idea of the inertia I've had to
> bump against, again and again? When I tell you "make this simpler",
> it's not because Joe Schmoe won't understand your stuff. It's because
> Power Maintainer Dan J. Hacker won't want to jump through two hoops
> so you better make sure there's only one.
I can only imagine. But that's why I am doing this,
so that everybody like minded can have a working base structure to use
s6/s6-rc.
> If that really was what you're trying to do, you'd listen to me.
I listen to you and I really try to understand your point,
I am just not convinced (yet?).
> Look, I *like* s6-rc. I'm happy that you like it too. I'm happy that
> you want to use it. I'm happy when people use my stuff. Don't get me
> wrong. But what I like even more is when the right tool is used for a
> job, in the right place, with the right glue. That's what makes life
> simpler for everyone, truly.
I wholeheartedly agree, our disagreement lies somewhere else.
> The vast majority of services a user will want to have are longruns.
> And longruns are run under s6; longrun service definition directories
> are pretty much s6 service directories. I don't think it's honest to
> say "you only need to learn s6-rc, not s6"; the s6-rc learning curve
> *includes* learning at least the fundamentals of s6.
I fully agree, scrap what I have written concerning this.
I want to mention though what always using s6-rc makes the experience
more consistent.
> But I'm not adding hooks to s6-rc to
> support notification of intermediary states to external programs, because
> I simply don't believe it's how it should be used.
I respect that.
I would be interested in what you think about the other points in my
previous mail, especially:
> I have assumed that the scan-directory of the user-tree is mounted tmpfs.
> This would require additional support in 1a/2a
> to save the state of the scan-directory on shutdown and load it on boot.
> Or let s6-rc-init and s6-rc do this work, by adding the service to the
> user-tree bundle "default"
> and running s6-rc for each user-tree at boot.
> What is the "little more" you are talking about?
> I do not see where this exceeds "little".
and whether:
> I have assumed that the scan-directory of the user-tree is mounted tmpfs.
Is a good idea in the first place.
Finally, I believe to have found (thanks to our discussion making me
think) an even better solution:
(note the paths / filenames being only exemplary)
1. Have a system-longrun create/mount /run/user/${USER} tmpfs and
start s6-svscan on /run/user/${USER}/service
2. Have an (optional) oneshot do the following:
a) Take a lock on /run/user/${USER}/s6-rc-lock
b) If { /run/user/${USER}/s6-rc does not exist } s6-rc-init
c) s6-rc start default
3. Have the login script
a) Take a lock on /run/user/${USER}/s6-rc-lock
b) If { /run/user/${USER}/s6-rc does not exist } s6-rc-init
c) s6-rc start login
This does not require waiting for a system-oneshot,
it allows people like you to not have s6-rc run for users on boot
and allows people like me to manage it everything with s6-rc.
Additionally it cleanly decouples boot user-s6-rc from login user-s6-rc,
in that the latter do not require the former to be prepared.
> so who am I to say otherwise.
You are the creator of the best pieces of software I could discover on
the internet so far.
Thank you for writing it!
Regards
Paul
Received on Fri Dec 06 2024 - 18:14:10 CET