>- A Users might want to achieve a state of the user-tree on boot, which is impossible without s6-rc
> Though I have to admit that I can not find concrete examples of application.
Exactly. That's the YAGNI principle: don't try to solve problems you
haven't encountered yet. Chances are you'll actually never encounter
them. Adding complexity in the name of "just in case" is overengineering
and it will only worsen your design.
And if I have learned anything about users, it's that most of your
users will have trouble understanding what a supervised service is,
and if you start talking about them about s6-rc services, their brain
will start melting and they'll run away from your system as fast as
they can. And they won't be wrong.
>- B Imagine the following scenario:
>
> A user wants to run a script every day at 12:00 and sets up a snooze user-longrun for that,
So far so good (I understand Brett's point, but that should not be
the basis for an argument, because there are other things that can
only be achieved via a longrun, crontab is only an example here)
> which he installs and starts using s6-rc-init and s6-rc respectively while logged in,
... and here you lose me.
The user has a supervision tree. They can install their longrun
directly
in it. They don't need s6-rc for that. Pure s6 is enough.
Their service will run as long as they keep it there. They can stop
it with s6-svc. Or s6-svunlink.
s6-rc is good when you have an intricate mix of longruns and oneshots.
This is the case in a boot sequence. This *might* be the case for a
user login sequence. And this is almost certainly *not* the case for
a set of user services that you would hypothetically start at boot time
and do stuff with before a user even logs in, wtf.
You want to run s6-rc at login time, sure, I can totally see where i
can be beneficial there. But earlier? Even systemd doesn't run user
stuff before a user logs in. And if *they* don't do it, it means that
there are ZERO use cases.
| Now the server reboots, brings up the user-tree again, but
without the snooze user-service of course.
And what is preventing that? The fact that your default bundle does not
include the services that the user has defined themself. This should
give
you a hint that this design goes against what supervision is supposed to
be doing, and thus, that it's not a good design. Whatever longrun the
user wants to have survive a reboot should survive a reboot and the
user shouldn't need a PhD to accomplish that.
If the user has installed their service in the pure s6 way with e.g.
one (1) call to s6-svlink, it works: after a reboot, the snooze will
be back up.
>All in all this would make things more complicated,
>in that users have to learn and consider more things while distribution maintainers have more work.
Exactly. You're *so close*.
>So while I agree to you, that until I find a concrete examples for A,
>s6-rc during "non-login" time is technically not necessary,
>lacking it makes many things more inconvenient, complex and inconsistent.
It's more inconvenient, complex and inconsistent because you want to
keep the framework that makes it so. Remove a little more and you'll
have something elegant again.
>On the other side, why not have it? It is a feature that is probably going be
>useful at some point and comes with little to no cost.
Little to no cost? This whole thread is about the costs! And from my
perspective, "probably going to be useful at some point" is a pretty
light argument, it's definitely not going to outweigh "too complex to
make work properly".
>Finally, I want to say that I really admire you being very conservative on adding features,
>it is great to know that s6/s6-rc will stay sleek and efficient.
Thank you. Now take inspiration from that for your own designs. ;)
--
Laurent
Received on Fri Dec 06 2024 - 00:03:30 CET