Re: upstart: please update to latest upstream version
On Tue, Feb 28, 2012 at 09:58:01PM +0100, Goswin von Brederlow wrote:
> Ben Hutchings <ben@decadent.org.uk> writes:
>
> > On Tue, Feb 28, 2012 at 04:51:18PM +0000, Roger Leigh wrote:
> >> On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
> >> > Roger Leigh wrote:
> >> > > On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
> >> > > > > [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.
> >> >
> >> > As are several fundamental POSIX features.
> >>
> >> POSIX features, optional or not, are standard and will not change
> >> incompatibly. If not present, one would expect an ENOSYS error return
> >> and the code should cope with that eventuality.
> >>
> >> cgroups is both non-standard, changing rapidly, and does not have a
> >> guaranteed future. It's somewhat controversial even amongst kernel
> >> hackers. Relying on it is, to put it mildly, short-sighted.
> > [...]
> >
> > This is FUD. The Linux kernel developers are very concerned with
> > maintaining compatibility with existing userland programs, and the
> > widespread use of systemd by other distributions means that the APIs
> > it uses must be maintained.
> >
> > Ben.
>
> Yeah right. As witnessed by the number of times udev broke because the
> kernel changed or udev forced a lock-step of both udev and kernel. Or
> any number of other APIs.
There has never been a requirement for lockstep upgrades, but yes
there have been incompatible changes in the layout of sysfs, and yes
that is annoying. As I understand it, the pain those changes caused
has led to rather more careful manageemnt of sysfs today.
> Linux kernel developers, at least some, don't seem to give a f**k. If
> they break something they use they fix the userspace too.
No, there are lots of kluges in the kernel to support old userspace.
For example, the order in which fork() parent and child run is chosen
to avoid breaking old versions of bash.
> IF they use it
> too. Distributions are left with having to support this by keeping APIs
> and user space in sync and doing lock-step upgrades. Something that is a
> huge pain with the kernel. Udev is the worst case example there since it
> doesn't support multiple API versions at all and is quite prominent.
Linux has config-time options to expose deprecated sysfs attributes
and udev has had transitional versions that work with or without them.
If a lockstep upgrade was required then it wouldn't have been possible
to do online sarge-etch and lenny-squeeze upgrades at all.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
Reply to: