Re: upstart: please update to latest upstream version
Roger Leigh wrote:
> On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
> > 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.
> Taking the stance that there must never, ever, be any platform-
> specific hacks is both extreme and counter-productive. If you
I'm not taking a "never, ever any" stance. But portability can be
negative, and things like "support case without cgroups" go far beyond
your example.
> > > [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.
I didn't miss that difference. That's why I phrased it "avoid requiring"
rather than "avoid using". I don't think "it only has to be optional"
helps all that much.
> Let's take cgroups as an example. They are an optional feature
> even on Linux.
As are several fundamental POSIX features.
> 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.
What's your problem scenario here? That kernel upstream suddenly decides
it's OK to completely break systemd? I don't think it's that much more
likely than them deciding to break POSIX functionality. If they want to
tweak the APIs, then that can be coordinated with systemd without
causing any catastrophic breakage. Even without Debian, the install base
for systemd is already large enough to ensure that the kernel can't just
ignore backwards compatibility.
Reply to: