Then why bother?

Posted Jan 5, 2009 21:34 UTC (Mon) by jspaleta (subscriber, #50639)
In reply to: Then why bother? by drag
Parent article: Android netbook is a possibility (Inquirer)

So when Suse was derived from Slackware that was childish?
When Ubuntu was derived from Debian that was childish?
When Mandrake was derived from RHL that was childish?
When Debian was founded as an alternative to SLS that was childish?

Get rid of mainstream linux distributions? What exactly would you replace the linux distribution concept with? Which diamond in the rough out of the hundreds of non-mainstream linux distributions would you hold up as the core platform that everyone needs to target? Perhaps we should de-contruct the last 16 years or so of distribution development, and go back to Slack or SLS as a core platform and live with the frustrations thereof?

I think you grossly over-simplify the problem. Is there any linux distribution of merit which does not include out of linux kernel tree patches of significant value to its userbase? Or other patches in the plumbing layer around the kernel?

Hell which upstream projects would you even include in that core platform? And how would you get the upstream projects to agree to hold their API and ABI stable long enough to give the core platform any significant longevity while also pledging the manhours to keep the platform patched for vulnerabilities and bugfixes that do not jeopardize the platform stability?

The entire open software project model is a whirlwind of individual moving pieces, with very different rates of development. You are only going to impose order on how projects interact and form a core platform by injecting significant manpower across a number of key projects with the express purpose of making consistent ABI and API stabilization a priority ahead of other interests.

Perhaps projects are manpower strapped and they don't have the ability to push forward and keep a shared platform specification maintained. Its not a matter of "growing up" its a matter of making choices to use limited resources among competing priorities. The people doing the development of the kernel and associated plumbing do not necessarily put ABI and API stability at the forefront on competing interests when it comes to how they burn manpower. The people looking for a core platform are going to have to pony up that additional manpower to make the core platform happen..its as simple as that. Implying the current project developers are childish is a gross over-simplification of the problem. Developer time is limited and platform stability commitments require manpower resources which compete with active development interests.

For an individual corporate entity its far easier to take a limited snapshot of that storm, fork it off, and then impose API and ABI stability on that snapshot..slowing down the rate of development significantly in their walled garden..and increasing the maintenance burden with regard to bug fixing and vulnerability patching.

-jef

Get rid of mainstream linux distributions? Why?

Posted Jan 5, 2009 21:55 UTC (Mon) by khim (subscriber, #9252) [Link]

Get rid of mainstream linux distributions?

What's the point? Mainstream linux distribution work just fine for geeks - why kill them? The fact that mainstream linux distributions can not produce consumer desktop does not mean they are useless.

Hell which upstream projects would you even include in that core platform?

None, of course. May be kernel - because it's too big and relatively well-supported. The core platform must be the ultimate upstream. Packages and libraries must be brought in the core distribution when core distribution is ready to include them, not the other way around.

And how would you get the upstream projects to agree to hold their API and ABI stable long enough to give the core platform any significant longevity while also pledging the manhours to keep the platform patched for vulnerabilities and bugfixes that do not jeopardize the platform stability?

Two possible solutions:
1. Don't expose underlying projects in your core distribution API.
2. Be ready support packages which must be exposed in your API without help from upstream.

So far Android team did everything right: they refused to provide "C ABI" (despite outcry from public) and I hope when/if they'll provide such ABI it'll be as restrictive as their Java ABI...

Then why bother?

Posted Jan 6, 2009 0:41 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

who are you and what did you do with the real jef spaleta? ;-)

that post was logical and relativly calm, and it even mentioned Ubuntu without bashing it.

posts like this are very welcome. thanks for changing your attitude a bit.

Then why bother?

Posted Jan 6, 2009 1:01 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

For the record....I make it a point to consistently bash "Canonical".. not "Ubuntu" Canonical!=Ubuntu

And since bashing Canonical is what is expected of me...I'll go ahead and do just that. I'm more than happy to live up to your expectations of me. There's so very very much to find fault with in Canonical's approach to doing things.

If we are talking about trying to create a usable platform experience... it doesn't not help when corporate entities like Canonical commit to pushing experimental features into distributions they control which deliberately break the consensus based cross desktop specification work going on at freedesktop.org. Specifications which application developers rely on to form the basis of interprocess UI services.

Its perfectly fine to want to experiment with different UI approaches, but to commit to shipping that UI experiment in the community distribution you manage as a corporate entity, that impacts how multiple applications work..as a default in an OEM customized distribution...without first reaching a consensus with upstream on how to minimize disruption to existing upstream application functionality...does not help create a cohesive multi-project based "platform" environment that non-Canonical employed application developers can rely on.

-jef