Should BusyBox and uClibc also make a "flag version" like Embedded Linux?

[Rob Landley]

On Thursday 11 November 2010 01:06:35 Stuart Longland wrote:
> [Dropping uClibc as I am not subscribed]
>
> On Thu, Nov 11, 2010 at 07:57:30AM +0200, Baruch Siach wrote:
> > Hi Stuart,
> >
> > On Thu, Nov 11, 2010 at 03:27:47PM +1000, Stuart Longland wrote:
> > > On Wed, Nov 10, 2010 at 04:04:06PM -0600, Rob Landley wrote:
> > > > No, they shouldn't.
> >
> > [snip]
> >
> > > > Neither uClibc nor busybox has even 1% of the churn of the linux
> > > > kernel.
> > > >
> > > > Look: Linux has to deal with binary only modules, which the
> > > > developers hate. To compensate for this, they go out of their way to
> > > > avoid having a stable internal API (which could argualy be used as a
> > > > copyright barrier and thus prevent the modules from being derived
> > > > works of the Linux kernel to which GPLv2 must apply).  To avoid this,
> > > > they break internal compatability essentially every release.  They go
> > > > out of their way _not_ to make forward- porting modules easy
> > > > (otherwise they'd have a checklist each release saying do this this
> > > > and this, and you'll be up to date).
> > >
> > > Indeed... and a lot of these companies like playing these silly
> > > proprietary games wherein they don't want to contribute the code back
> > > to the community.  It's apparently licensed as "GPL", but it's kept
> > > under lock-and-key and one has to jump through several hoops to see it.

Oh sure, the unstable kernel internals are 100% intentional, and the kernel 
guys have reasons for what they do.  Their response to the problem (which is 
not a solution, more an ongoing treatment) has an awful lot of negative side 
effects, which aren't _entirely_ confined to the binary only module crowd 
they're aimed at.  The "flag version" thing is an attempt to mitigate those 
side effects.  I.E. it's a response to the linux kernel developers' response to 
the binary only module problem.

For the rest of the packages, "that's what distributions are for" generally 
seems to cover it.

And in the specific case of uClibc, "development moves too fast, we need to 
declare magic versions Long Term Support like Ubuntu does" is hilarous.  We've 
been waiting FIVE YEARS for TLS support to actually ship in a release.  
Development does _not_ move too fast in that context, trust me on this one.

In the case of BusyBox, development's quite reasonable but less than 1% of 
what goes on in the kernel.  We don't have a lot of pending out of tree 
busybox patches I'm aware of that people have trouble forward porting and are 
thus tying them to old versions, and if we DID the solution would still be 
"post them to the list so we can merge them", not "the busybox developers 
should put in extra effort to make it easier for you to use old versions which 
don't help us".

I.E. Bradley didn't read the darn FAQ:

  http://busybox.net/FAQ.html#backporting

Bradley?  Read that FAQ entry please.  I'd forgotten, we already had a FAQ on 
why we don't have flag versions.

> > > Yes, I'm looking at you, Texas Instruments and Freescale.
> > >
> > > The upshot is that those of us who are developing software, and by
> > > extension the end user, loose out... because the features they were
> > > hoping for don't exist in the prehistoric kernel supplied.
> > >
> > > Case in point:
> > > - A company I was working on wanted to develop an intercom station
> > > - They chose to use the Linux kernel
> > > - They evaluated a number of Linux-capable SoC devices and settled on
> > >   a SoM based on the Freescale i.MX27
> > > - For the audio CODEC, they settled on the TI TLV320AIC3204
> >
> > But they have made these two decisions before checking the state of
> > mainline kernel support. Big mistake.

The mainline kernel changes significantly every three months.  Checking doesn't 
_help_ if you make your decision when 2.6.28 is current and two years later 
2.6.34 is out.

The fundamental problem is tying yourself to a specific version, which is the 
price the kernel developers impose on binary only modules by keeping the 
kernel's internal APIs perpetually in flux and only partially documented.  

This does not apply to BusyBox, and does not apply to uClibc.  We don't have 
significant out-of-tree patches that prevent people from upgrading.  And if 
they don't upgrade, we aren't going to spend our volunteer development effort 
supporting old dead-end code we've already moved on from, as the busybox FAQ 
has explained for years now.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.