Re: default init on non-Linux platforms
previously on this list heroxbd@gentoo.org contributed:
> > And grepping through the output of "ps" or similar is not what
> > I would consider reliable and robust either.
>
> Nod. grepping `ps` is what we should avoid at all cost.
All cost? While I like OpenRC and thanks to Gentoo for it and like
your mention of each to there own (I am no old-nerd by the way). I have
to disagree.
If a service fails I am more interested in why and what will happen if
it restarts and not is it back-up already. For that, I would use
redundant servers which in any way you look at it and especially for
high availability situations must be more reliable than trying to
restart a failed service blindly that may not operate as it should when
it does.
Functional externally generated tests like https returned this file are
most valuable for monitoring services and I don't really see your point
or the major benefit at all, especially if it involves increased kernel
complexity.
cgroups doesn't break that, worth it, question for me personally.
However whilst I have found the reasoning by the CTTE to have been
rather disappointing and superficial and I am unlikely to ever use
systemd due to having fundamental issues with it. If a major concern was
portability and many of you have your heart set on systemd then
although it goes against my desires and technical concerns then perhaps
pgroups are worth a mention.
________________________________________________________________________
http://marc.info/?l=openbsd-misc&m=135313692911156&w=2
how can someone write this and not explain why a process managing
pgroups can't achieve the same results?
pgroups is going to be the first alternative for someone instinctively
looking for a portable alternative, so i'm genuinely interested in
knowing why they've discarded the idea
i am, however, aware of differences *unrelated* to writing a systemd
like appliance. pgroups do not provide per item hostname and other
virtualization facilities in freebsd jails/linux cgroups, but what
about *relevant* differences? something weak like "the index for for
cgroups is wide enough to fit an UUID"? in other words, something that
*doesn't* require a completely new api?
http://marc.info/?l=openbsd-misc&m=135314269712851&w=2
therefore the requirement for cgroups is completely arbitrary
also of interest:
* early versions of systemd documentation advised daemon authors not
to double fork. presumably cgroups wasn't in the radar at the time
* several (all?) openbsd daemons have options for not double-forking.
some of these daemons have the gall of preceding systemd
--
_______________________________________________________________________
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
_______________________________________________________________________
Reply to: