Re: upstart: please update to latest upstream version
Wouter Verhelst wrote:
> On Tue, Mar 06, 2012 at 02:08:00PM +0000, Jon Dowland wrote:
> > On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> > > But I do think that writing portable software isn't that hard, and that not
> > > doing it is pure lazyness.
> >
> > It's not about difficulty, systemd isn't not-portable simply because the
> > authors haven't got around to it yet; it fundamentally relies on a Linux-only
> > technology.
>
> This is wrong. An init implementation is not fundamentally Linux-only.
> No matter how they chose to implement it, no matter what they've ended
> up with, it is fundamentally possible to write an init implementation
> that will work on more than just Linux.
You've said something entirely different here that doesn't refute the
point you replied to. systemd fundamentally relies on Linux-only
technologies, because it specifically provides access to those
technologies, takes full advantage of those technologies, and uses them
to provide an init system capable of doing things that sysvinit can't
do. What you said remains true: you *can* write an init implementation
that will work on more than just Linux, and sysvinit provides an
existence proof backing up your claim; that doesn't mean you can write
systemd or an init implementation with equivalent functionality, just
that you can write a least-common-denominator init system as capable as
sysvinit. This thread exists in large part because many people want an
init system more capable than sysvinit.
To give one particular example: systemd uses Linux-specific features to
accurately track all the processes started by a service, which allows
accurate monitoring and shutdown of processes which could otherwise
disassociate themselves from their parent processes via the usual
daemonizing trick. POSIX doesn't provide features that allow this in
general, but Linux does. (Quite possibly other OSes provide those
features too, but not in a standardized way.)
> It is perfectly possible to make an init implementation that uses
> Linux-only technologies on Linux, but which falls back to a different
> mode on non-Linux. The reasl reason why systemd is Linux-only is because
> systemd upstream decided it would be easier to implement systemd that
> way, and because they didn't care about non-Linux. I find that to be
> lazyness; but that is, of course, their prerogative.
You've got your cause and effect backward here. systemd specifically
provides access to Linux-only features to provide functionality it
couldn't otherwise provide. *Given* that systemd already needs
Linux-specific functionality, upstream figured that they might as well
continue using other Linux-specific functionality that makes things
easier, rather than writing everything to the lowest common denominator
of what a pile of OSes support.
> At any rate, I think the only solution to the dilemma here would seem to
> be if someone were to port systemd to kFreeBSD. If neither the kFreeBSD
> people nor the systemd people are willing to work on that, then we can
> discuss and talk about this into eternity, but it will be highly
> unlikely that we'll ever arrive at a solution.
You've missed several other possibilities here:
- kFreeBSD implements a systemd-compatible init system that doesn't
necessarily represent a port of all of the systemd codebase. I
suspect that systemd wouldn't object to making a few library bits
portable, such as code parsing systemd service files, to allow sharing
that between implementations.
- kFreeBSD implements kernel APIs compatible with the Linux APIs that
systemd requires, drastically reducing the amount of porting work
required, and turning it into a configuration problem. That would
benefit many more pieces of software, not just systemd. Note that
kFreeBSD has a huge headstart here, because it already uses glibc, and
thus doesn't need to worry about all the glibc-specific APIs. One of
systemd's major development tenets roughly amounts to "fix bugs, don't
work around them, even when those bugs live in the kernel (because we
can fix that too)"; that tenet represents a large part of systemd's
non-portability.
- systemd continues to become more popular, and upstreams start
depending on it inherently and using systemd features that make it
non-trivial to write a simplistic init script with equivalent
functionality. Debian eventually finds the rug pulled out from under
it. See udev for a successful application of this strategy, with
exactly the same rationale: static /dev doesn't give you the
capabilities required to implement interesting functionality, such as
hotplug and event-driven device handling. Net result: Debian ends up
in the same place, but after inflicting sysvinit on people for much
longer.
> kFreeBSD is already part of Debian. Systemd is not. The answer would
> seem to be obvious.
"First come, first served" does not inherently represent a sensible
problem-solving strategy, and in particular it has no ability to escape
local maxima. As this thread has demonstrated, people can very sensibly
argue that both kFreeBSD and systemd have value; kFreeBSD does not
automatially win that argument by saying "frist psot".
- Josh Triplett
Reply to: