>We now have two examples of application from the other mails.
And both can be solved without s6-rc in a simpler way than with it.
>When I talked about "users", I mean people actually *using* these tools,
>meaning s6, s6rc, execline, POSIX tools, ... hence power users and distribution maintainers.
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 therefore try to make life as easy as possible for power users
>and distribution maintainers, who manage their own supervision trees
>or setup the presets for said managed distros respectively.
If that really was what you're trying to do, you'd listen to me.
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.
>Assuming s6-rc is used for the main supervision tree and on login,
>which is fair, since the very thing we discuss about is part of my project
>doing all of that with s6-rc,
>this would cause users to need to learn s6 additionally to s6-rc,
>when s6-rc can be used for all cases.
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.
>This is an argumentum ad verecundiam.
Not at all. I never refer to systemd as an authority (lol).
It's just that systemd is maximalist: every use case they can think of,
they include. (Since the unit file format is extensive, they have to.)
They include way, way more than they should; they are by no means an
example to follow. My point is that if a use case isn't planned for in
systemd, there's a pretty good chance it's not a real one.
Anyway. You obviously think your design is superior, so who am I to
say otherwise. We're not going to agree on this, so, since it's the
person who does the work who has the final say, you're right. Write your
project however you want to. 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.
--
Laurent
Received on Fri Dec 06 2024 - 16:43:28 CET