Re: upstart: please update to latest upstream version
On Tue, Mar 06, 2012 at 02:46:44PM -0800, Josh Triplett wrote:
> 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.
I think it does.
> 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,
Yes you can.
It's possible to write an init implementation in such a way that it
provides more features on one architecture than on another. If there are
daemons that fundamentally depend on the functionality that isn't
available on non-Linux versions of systemd, then these daemons won't be
able to work on non-Linux, but that would be the case anyway.
> 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.
Yes, that's the cgroups feature.
> 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.)
Indeed. That means there would need to be multiple implementations of
the same functionality; one per supported OS. On some systems said
functionality wouldn't be available, and that'd be fine; on others, it
could behave slightly different in the undefined parts of the spec, and
that would also be fine.
Portability doesn't require you to limit yourself to POSIX, it just
means you should have all functionality covered everywhere. If you can
do that with POSIX, then do it with POSIX; if you can't, then you'll
require #ifdefs or parallel implementations. It also doesn't mean you
have to do *everything* yourself, and it's perfectly acceptable to
request that people who care about the architecture in question do the
bits specific to that architecture. However, systemd upstream has
expressed hostility to that concept, so I don't think it's going to
happen.
> > 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.
Again, portability doesn't have to imply you limit yourself to the lowest
common denominator.
> > 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.
These are definitely options, *if* someone can be found to do that. If
not, I don't think systemd can expect to be the default init
implementation in Debian. If systemd advocates want that, they should do
the hard work themselves, and not inflict such work on the kFreeBSD
developers.
> - 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.
There's a difference.
Udev was written so that some functionality which was statically defined
in the kernel could be moved into userspace. As a result, today it's
impossible to use Linux without udev if you want to be able to talk to a
number of devices. The userspace bits that depend on udev are still
replaceable, though I'll grant you that it gets harder as time moves on.
So, what makes udev virtually required today is the kernel, not
userspace.
Systemd isn't written to move functionality from the kernel to
userspace; instead, it was written to replace one userspace interface by
another. While it's possible that systemd may become the leading init
implementation on Linux, it wouldn't be the case everywhere unless it
gets ported; software that wants to be portable will have to support
other init implementations anyway. So I doubt that it will ever become
impossible to run a Linux system without systemd.
> > 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.
>From our constitution:
Nothing in this constitution imposes an obligation on anyone to
do work for the Project. A person who does not want to do a task
which has been delegated or assigned to them does not need to do
it. However, they must not actively work against these rules and
decisions properly made under them.
If you're saying "I want to do this work, but it introduces a problem
for those other people. Heck, I don't care, let them deal with it",
you're "imposing an obligation to do work for the Project" on others.
> 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".
I'm not saying the kFreeBSD people shouldn't have to do anything at all
to support systemd. However, given the above, I think it's only fair if
systemd advocates who wish to see systemd become the default in Debian
will do the hard work to make that happen, and not try to chicken their
way out because "kFreeBSD is a toy architecture".
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: