Re: upstart: please update to latest upstream version
On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
> Roger Leigh wrote:
> > I certainly don't think it's fair for fairly niche platforms to hold
> > back Linux indefinitely. There is a high cost on maintainers to
> > support these platforms, and it would be an ideal situation if
> > systemd or upstart were sufficiently portable to run on them, even
> > if they didn't support all the Linux-specific features they offer
>
> Portability is not necessarily a positive attribute. When you're talking
> about standard functionality available on all platforms, it's cleaner to
> write it using standard interfaces that work everywhere. But if the
> platforms do not support the same things, then portability often
> requires platform-specific hacks, special cases and limitations. A
> systemd that tried to work on BSD kernel would be less reliable, less
> maintainable and harder to debug. I wouldn't want my Linux system to run
> an init process hacked for BSD portability.
All our software has some element of portability hacks in it.
Here's a trivial one from schroot:
#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
(this->get_device()).is_character()
#else
(this->get_device()).is_block()
#endif
Disc devices are character on FreeBSD, rather than block. So we
work around that fact. Big deal. Once that's done, it works
perfectly on both platforms.
Taking the stance that there must never, ever, be any platform-
specific hacks is both extreme and counter-productive. If you
want your software to be usable outside your own world, you have
to make some compromises.
> > [note: it's somewhat desirable for them to be optional on Linux
> > too, to prevent feature lock-in and future compatibility problems].
>
> Unix kernel development outside Linux is pretty limited, especially
> development for features other than server use. I think "avoid requiring
> Linux-specific features" would turn into "avoid technology developed
> after the 90s".
This is missing the point. I'm not saying "don't use Linux-specific
features", I'm saying that use of Linux-specific features should be
/optional/, even on Linux. Only use them if present.
Let's take cgroups as an example. They are an optional feature
even on Linux. By mandating them systemd may be painting itself
into a corner given that they might be removed or replaced with
something better in the future. If they are present, by all means
use the facility. But don't create the seed of a future maintenance
nightmare. This doesn't just affect systemd, it affects the kernel
indefinitely since we can't break working systems by removing the
feature. This applies to all use of Linux-specific APIs: don't be
too clever--it will come back to bite somewhere down the line.
Asking this sort of question about systemd isn't stupid--there are
long-term issues which could arise from short-sighted decisions by
the systemd developers in the short-term. It would greatly ease
its adoption if they would be given due consideration. And this
includes portability to other systems just as much as it does to
future versions of Linux.
I would love Debian to adopt systemd (or an equivalent). But I
really can't see that happening without a change in attitude by
upstream. Portability to other systems is really just a special
case of portability to future versions of the Linux kernel. Things
can and will change, and systemd needs to make sure it doesn't
break horribly when it happens.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: