Then why bother?
Then why bother?
Posted Jan 5, 2009 18:31 UTC (Mon) by drag (guest, #31333)In reply to: Then why bother? by khim
Parent article: Android netbook is a possibility (Inquirer)
LSB can't provide it because the people that produce the platforms can't agree on everything. It IS NOT IN LSB's CONTROL. They can only work with what they are given.
They can go around and wave their hands and try to make a 100% solution, but it's completely bullshit if nobody follows it, which nobody will.
As for 'Why bother?'.. there is a certain subset of Linux OS that people can agree on, more or less. So... LSB defines that for ISVs. It at least gives people something to work with.
LSB doesn't do the dictating to distributions. Distributions do the dictating and LSB has to work with what they can find in common and try to formalize it.
-----------------------------------------
What is required right now is to get people stop trying to make slightly-incompatible versions of Linux OS and make one based on the same core. Everything else you talked about is completely irrelevant and is not going to happen until people decide to grow up and start getting rid of competing 'mainstream' Linux distributions.
If I can't produce binaries that work on both Ubuntu and Fedora, then what is the point worrying about backward compatibility? Backward compatability with WHAT EXACTLY? Redhat? Fedora? Debian? Slackware? Suse? Ubuntu?
Hell I don't even have compatibility _right_now_. How the hell is anything suppose to be compatibility with software from 10 years ago with Linux software wasn't compatibility with anything from back then in the first place?
Posted Jan 5, 2009 21:34 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (3 responses)
So when Suse was derived from Slackware 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
Posted Jan 5, 2009 21:55 UTC (Mon)
by khim (subscriber, #9252)
[Link]
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. 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. Two possible solutions: 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...
Posted Jan 6, 2009 0:41 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted Jan 6, 2009 1:01 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
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
Posted Jan 5, 2009 21:41 UTC (Mon)
by khim (subscriber, #9252)
[Link]
If LSB can't provide then LSB
must die. It's as simple as that. LSB has no value, it gives you nothing -
except the raight to put yet another useless stamp on your
distribution. It's not used by ISV (how many LSB packages can you name?), it's huge
time sink for a lot of people - why does it exist? To pay salary for
"professionals" who create this stillborn standard? If you are big enough then there are possibility that people will
follow 100% solution. Time will tell if Google and OHA are big
enough. Nobody follows LSB so why are you still beating this dead
horse? Name one who bought this bull-shit and is still around to tell
the tales. There are some LSB packages - but they are made from native
Linux packages by companies who want one more stamp, not by companies who
foolishly tried to use LSB as platform. Easy: you make the platform, declare it "version 1.0" (or 2.0 or 10.0)
and say "we will support binary compatibility for this version...
Normal distributors can not work this way: if Ubuntu will try to limit
choices - free software developers will just declare jihad and refuse to
support such a distribution. And since there are no ISVs to fill the
void... the whole platform will just disapper. OHA does have weight to say
to developers "my way or the highway" - or so it looks today. If it'll
happen - we'll have linux (albeit not GNU/Linux, sadly) for consumer
desktop. If not... well may be someone else will do it... P.S. The really sad thing is that induvidual projects work this way
already. They just can not agree to do "big switches" synchronously - and
so we have major breakage twice per year instead of once per decade...
Then why bother?
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? Why?
Get rid of mainstream linux distributions?
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?
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.Then why bother?
Then why bother?
Please read what you wrote...
LSB can't provide
They can go around and wave their hands and try to make a 100%
solution, but it's completely bullshit if nobody follows it, which nobody
will.
As for 'Why bother?'.. there is a certain subset of Linux OS
that people can agree on, more or less. So... LSB defines that for ISVs. It
at least gives people something to work with.
Hell I don't even have compatibility _right_now_. How the hell
is anything suppose to be compatibility with software from 10 years ago
with Linux software wasn't compatibility with anything from back then in
the first place?
forever for 10 years".
It was done before. GNOME, KDE, etc - they all support backward
compatibility... but it does not really work. Why? Easy: system includes
some compatible components (GTK+ or QT) and incompatible components
(GStreamer, libstdc++, etc). Programs use both stable components and
unstable ones - and the end result is unstable system. The only way to
overcome this is to limit amount of stuff in your distribution. Zero
unstable components. You can not fix this or that problem without breaking
binary compatibility? No problem - fix it! We'll gladly include your
version in next release - expect it to be out 2018 or 2019. What? You can
not wait so long? Ok - then implement some workaround.