Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 02:21 AM, Steve Langasek wrote:
> But unless you've only ever used Debian on systems with a flat
> partition:filesystem structure, with no network filesystem mounts, no
> LVM/RAID/LUKS, and no networks more complicated than a single interface,
> you've either been affected by these race conditions, or you've been relying
> on the chewing-gum-and-baling-wire workarounds that Debian has in place to
> paper over these races. The problems are pervasive and systemic, and have
> become progressively more severe over time as hardware becomes faster. An
> init system that has not *fundamentally* addressed this class of problem
> with its design is not bringing anything interesting to the table.
>
> [...]
>
> I got as far as this:
>
> sysvinit Upstart systemd OpenRC SMF
> [...]
> Device-based Activation no no[4] yes ?? ??
>
> ... and stopped reading.
> [...]
> This is such a fundamental gap it's not even funny.
Hi Steve!
This is one of the rare posts that does make sense to me. I do agree
with that fixing race conditions is a major issue. Though I remember
having a discussion with Patrick Lauer about OpenRC support for socket /
device activation. I'm CC-ing him, maybe he can reply about this
specific point.
If OpenRC isn't what we need (I still believe it does address a bunch of
problems and that the fact it can work for non-Linux port is a key
factor), then I'd be for Upstart. I do maintain my packages so that they
work for both Ubuntu and Debian, having to write things for 2 init
systems would be useless added work.
So that brings me to ask: do you have an idea of how much work it would
be to have Upstart ported to kFreeBSD or Hurd (even if that would mean
loosing some of the functionality (obviously cgroups comes to mind))?
Thomas
Reply to: