On Fri, 23 Oct 2020 09:27:53 +0200
Oliver Schad <oliver.schad_at_automatic-server.com> wrote:
> On Thu, 22 Oct 2020 20:03:17 -0400
> Steve Litt <slitt_at_troubleshooters.com> wrote:
>
> > But most of the other suggestions that in my opinion are just
> > answers to systemd weenie's "but s6 doesn't have _____" arguments,
> > and don't add nearly enough functionality or convenience for the
> > complexity, or just plain size added to the user manual, to justify.
> >
> > The OP already stated there's a way to do it currently. Why
> > complexify s6 to do something already doable?
>
> I just miss the elegance of the solution:
I get that. But there's a pretty significant cost. Every new feature
added to a piece of software makes it harder to understand, creates new
nooks and crannies for bugs to hide out in, and increases the number of
interactions very significantly. To see interactions at their worst,
see my systemd cartoon:
http://troubleshooters.com/linux/systemd/lol_systemd.htm
I'm not saying s6 is anywhere near that yet. But in my opinion, every
feature complexifies the software even more than the last one, and
every feature should be evaluated similar to a new purchase of a
possession:
1) Where am I going to keep it? How much will it clutter the house?
2) What will I not buy to free up money to buy this thing.
> I personally want to model
> one service with one s6 service.
I'm not sure what you mean by "model". I thought this was about
checking the health of each service. Anyway, I understand that you
personally want to match the healthchecks one to one with the services,
and that would be nice, but not if it adds complexity.
[snip the rest of the email, which I didn't understand at all]
I'm on probably 25 software mailing lists, and have this discussion on
every one of them. Somebody wants some feature. I write back that you
can already do that by doing <whatever>. They write back saying my idea
is a kludge. I write back and say I like a nice, simple program that
can be written and maintained by one person, features tend to wreck
that, all sorts of people want their pet features, and those features
are usually unimportant (for instance, way to do it with existing
software) to the suggester and *absolutely* unimportant to everyone
else. Features clutter up software, and should be done only if they're
very important to a large swath of users.
With healthchecks, it would be trivial for you to create a shellscript
called healthcheck in every service directory that required a
healthcheck, then have a program that loops around all the service
directories, runs the healthcheck shellscript, and if unhealthy,
performs actions listed in the healthcheck subscript. If you do this
for awhile, you'll slowly evolve the thing into a more and more
convenient form, until others use it. I mean, you'd need to roll it
into a tarball and write a bit of documentation, but nothing like
changing the whole program.
The real beauty of this approach is that, as more and more people use
your system and more and more people contribute feedback, sooner or
later it reaches a state where it would be much easier to add it as a
feature of the whole program, with an interface people like.
SteveT
Steve Litt
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
Received on Fri Oct 23 2020 - 09:15:22 UTC