Re: upstart: please update to latest upstream version
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.
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. 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.
MfG
Goswin
Reply to: