LWN: Comments on "Android netbook is a possibility (Inquirer)"

Visit any newbie forum, please.

khim — Thu, 08 Jan 2009 14:00:22 +0000

Please demonstrate one of these real existing users that switched to Linux, but then switched back when they could not run 10 year old Linux programs.

These people don't really create a lot of noise (who will admit they made a mistake?) but you can find a lot of horror stories related to distro upgrade (use Google is you wish) - usually it ends with Switch back to Windows? No way! (or something similar) but that just means guy is geeky enough to actually stick with Linux.

The argument about the forward direction you just added is more reasonable, but still -- please demonstrate one of these real existing users who switched to Linux, and was desperate to have the latest and greatest version of random apps like Python 3 and OO.org, *but* was scared of upgrading to the latest and greatest version of their distro.

Visit any newbie forum. Usually such people are ridiculed and ostracized, so you'll only ever find one or two messages from them and then long thread about virtues of the system upgrade - you can safely presume at this point person in question either gave up on Python3/OO.org/whatever and may be on Linux is general. I can name one such guy with 100% certainity however: myself. I'm using Linux on my "server system" but stopped trying to switch to Linux on my main system. Too much hassle. It was fun to tweak this and that 10 years ago - and Windows was pretty unreliable back then. Today Windows is pretty reliable, I can throw random stuff on it (including OO.org 3.0, Firefox 3.0 and so on) and it usually lasts 2-3 years before it becomes totally unusable - at which point it's just reinstall and start from scratch. I personally know quite a few Linux administrators who are using Windows (or sometimes Mac) on desktop "because it's easier to support"! If you can not convince guy who's work is to support thousand of Linux systems to use Linux on his/her desktop because "it's too much hassle" - who can you convince?

Microsoft did not spend billions developing Wine.

Microsoft spent billions developing backward- compatible system. Emulation is not invention. It's hard work, but if you manage do it - you get all properties of the original for free. There are free emulators for most consoles (except latest generation), yet there are zero free consoles in the world.

The reason no-one spends much effort on compatibility for Linux apps because if they did, *under present circumstances* -- which are different from the circumstances for Windows and Mac OS! -- no-one would use it anyway, and it would have no positive effect in the real world.

Sorry, but this is bull-shit. People do try to solve this problem (there are a lot of failed solutions like Autopackage or 0install) - but without organized effort from distributiors it's impossible. That's one of the reasons of low Linux penetration in my company, for example. We have choice of OS here: Linux, Mac or Windows on laptop (desktop is always Linux because a lot of our developer tools work only under Linux and only under one particular version of Linux). Most choose Windows (including me, of course), roghly 1/4 choose Mac and less then 5% choose Linux. Why? Too much hassle. Programs don't play well with others: flash can be blocked by acrobat reader, for example. This is result of backward compatibility neglect mostly: both flash and acrobat reader use OSS and linux still does not support such programs right on modern hardware.

Then why bother?

njs — Thu, 08 Jan 2009 13:21:20 +0000

>But without expected ability to run newer programs on older systems and older programs on newer systems you are losing what little consumers you manage to gain!

Please demonstrate one of these real existing users that switched to Linux, but then switched back when they could not run 10 year old Linux programs.

The argument about the forward direction you just added is more reasonable, but still -- please demonstrate one of these real existing users who switched to Linux, and was desperate to have the latest and greatest version of random apps like Python 3 and OO.org, *but* was scared of upgrading to the latest and greatest version of their distro.

Unless you can demonstrate that such users exist and are the normal case, then your claim that this is the actual cause of Linux's failure to dominate the desktop is simply inaccurate.

>Windows and Mac apps are supported well because Microsoft and Apple spent billions on solving this problem

Please read harder. Microsoft did not spend billions developing Wine. The opposite, if anything. Wine's existence disproves your argument that wah-wah FOSS people cannot achieve compatibility with anything -- they can do pretty amazing things, in fact, so long as doing so actually accomplishes something useful. The reason no-one spends much effort on compatibility for Linux apps because if they did, *under present circumstances* -- which are different from the circumstances for Windows and Mac OS! -- no-one would use it anyway, and it would have no positive effect in the real world.

Then why bother?

rwmj — Thu, 08 Jan 2009 12:45:18 +0000

The console makers know that back compat is mostly a marketing bullet point, customers (particularly the most profitable ones who buy lots of new games) don't really use the back compat.

That's a joke right? The Wii has backwards compatibility with about a half-dozen consoles. Nintendo sell the older games by the bucketload through their online service.

Rich.

Then why bother?

khim — Thu, 08 Jan 2009 12:11:15 +0000

So, umm, your argument is that the reason the consumer market has not switched en masse to Linux is that lots of people would like too, but have decided to wait because they have piles of Linux software from 1998 sitting around, and modern Linux can't support it so they just stay with... Windows?

Nope. My argument is that it's the reason few "early adopters" return back in frustration. "The ability to seamlessly run 10 year old apps" and "the ability to run apps 3-5 year newer than your distribution" are necessary features, not sufficient. Transition is inherently slow and constly process process: Microsoft spent many billions and over 10 years to switch consumers from DOS to Windows - and it was in control of both DOS and Windows back then! But without expected ability to run newer programs on older systems and older programs on newer systems you are losing what little consumers you manage to gain!

Backwards compatibility of the sort you mention will start mattering a few years after Linux becomes mainstream and there are lots of funky binary-only apps being distributed through non-distribution channels -- if that day ever arrives.

Actually such compatibility matter here and now. How can I use Python3 on my Ubuntu 8.04 desktop? How can I use OpenOffice3 on Ubuntu 8.04 desktop? The answer is "there are no easy way" and frankly it's insane. The ultimate goal must be 8-10 years back and 3-5 years forward, but so far you don't have even few month compatibility in forward direction and 1-2 years in backward direction. That's not consumer-acceptable rate.

Until then, basically no-one cares about that lack of functionality, because no-one needs it, and community-developed FOSS is never written before there is user demand.

Then it just means that community-developer FOSS can not ever produce consumer desktop. Not a big deal, we have big companies for that. May be it'll be Android, may be it'll be something else - but eventually someone will produce FOSS consumer desktop, but it'll not be community-developed...

There's a separate question of whether we'll be able to provide compatibility then, when it does start mattering, but given our excellent support for *Windows* apps from 1998 (and for that matter, Mac apps, and I bet some of those consoles too), I'm not staying up nights worrying about our ability to make frikkin' ELF-with-some-old-libraries work.

Windows and Mac apps are supported well because Microsoft and Apple spent billions on solving this problem. They planned in advance (applications from pre-planned era are not well-supported at all) and while the did few mistakes then never suggested recompilation as solution for compatibility problem.

I think that eventualy we'll have FOSS consumer desktop, but it'll never be GNOME/KDE/etc desktop. They respect rights of developer more then rights of user and so they can not cover this niche.

Then why bother?

njs — Thu, 08 Jan 2009 11:25:23 +0000

>As long as Linux does not offer [the ability to seamlessly run 10 year old apps] - it's non-conteder for Consumer Desktop.

So, umm, your argument is that the reason the consumer market has not switched en masse to Linux is that lots of people would like too, but have decided to wait because they have piles of Linux software from 1998 sitting around, and modern Linux can't support it so they just stay with... Windows?

Backwards compatibility of the sort you mention will start mattering a few years after Linux becomes mainstream and there are lots of funky binary-only apps being distributed through non-distribution channels -- if that day ever arrives. (Personally I sort of hope the latter part never happens, but anyway.) Until then, basically no-one cares about that lack of functionality, because no-one needs it, and community-developed FOSS is never written before there is user demand.

There's a separate question of whether we'll be able to provide compatibility then, when it does start mattering, but given our excellent support for *Windows* apps from 1998 (and for that matter, <a href="http://gwenole.beauchesne.info//en/projects/basilisk2">Mac</a> apps, and I bet some of those consoles too), I'm not staying up nights worrying about our ability to make frikkin' ELF-with-some-old-libraries work.

Android netbook is a possibility (Inquirer)

endecotp — Wed, 07 Jan 2009 15:24:30 +0000

> Having to cross-build and then dump to real hardware to see whether
> you've fixed a bug is intensely frustrating compared to being able to
> run it locally.

My slow systems (e.g. ARM embedded devices) normally NFS mount a filesystem that's shared with the x86 build machine. So I type "make" in one shell, move the mouse pointer to a terminal that's running on the ARM board, and run the executable. It's virtually indistinguishable from native development; there is no need for cross development to be "intensely frustrating".

Yes, there is: it's the difference between corporate desktop and consumer desktop...

khim — Tue, 06 Jan 2009 11:00:02 +0000

there is a difference between things not being able to work and things requiring effort to make work (by loading the appropriate libraries).

Of course! And that's exactly where split between consumer desktop and corporate/geek desktop lies. Company does have guys dedicated to this process, geek can do it with Google's help, but "normal consumer" can not do it at all.

there can be new tools written to assist in loading the appropriate libraries without requiring any changes to either the old binaries or the new systems.

Sure. Microsoft does it too. The catch: such tools must be employed automagically and work "behind the scenes" without help from user. If you ask for manual intervention - you've lost.

I also think that you are very mistaken if you think that the right thing to do is to make linux work like windows.

There are no need - Windows does the required thing via band-aids over band-aids and this approach is failing them: Windows Vista was mostly rejected by consumers (where they had choice) for this very reason.

we already have many things that are designed in much more robust ways

Sorry, but no. Linux breaks significantly easier than Windows. It's easier to fix, of course - but as I've said: there are noone who can do it behing the keyboard! If we are talking about consumer desktop, that is.

This is where Ubuntu has done such a good job, they have written a lot of these tools (or at least put them togeather in ways that no other distro ever dis) to make things easier for the user.

Yes - but these tools fail constantly and need manual intervention. This is not consumer desktop.

If running old binaries is so valuble then someone will eventually write tools to automate the library discovery/install process for them.

By this time Linux, of course, is abandoned and mark "for geeks only" is applied to it for the next ten years. Backward compatibility matter, forward compatibility matter. The consumers are using computer in a "simple" way: they buy it with the system pre-installed, install stuff accomulated over years (sometimes stuff is thrown away - but it takes years, not months), then expect to download/buy/find new stuff and install it there. Often when Windows is finally broken enough to be totally unsable system is just replaced with a new one! OS is never updated (unless autoupdate does it) and is never upgraded. Linux fails on both fronts: old stuff does not work, new stuff can not be used too! I've tried to help my friend to install Skype year or so ago: Skype was already abandoned Dapper by then - before Hardy was out! So much for "long term support"...

As far as consumer desktop is concerned Windows is poor choice, but Linux is not even a contender! Android... may be... time will tell. Ubuntu? No - not even close...

Then why bother?

jspaleta — Tue, 06 Jan 2009 01:01:24 +0000

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

Then why bother?

dlang — Tue, 06 Jan 2009 00:41:04 +0000

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.

Get rid of mainstream linux distributions? Why?

khim — Mon, 05 Jan 2009 21:55:26 +0000

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...

Please read what you wrote...

khim — Mon, 05 Jan 2009 21:41:47 +0000

LSB can't provide

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?

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.

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?

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.

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.

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?

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... ~~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.

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?

jspaleta — Mon, 05 Jan 2009 21:34:38 +0000

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

Have you checked?

dlang — Mon, 05 Jan 2009 21:14:17 +0000

yes, this is experiance not hearsay.

there is a difference between things not being able to work and things requiring effort to make work (by loading the appropriate libraries). there can be new tools written to assist in loading the appropriate libraries without requiring any changes to either the old binaries or the new systems.

I also think that you are very mistaken if you think that the right thing to do is to make linux work like windows. we already have many things that are designed in much more robust ways, what we need isn't to throw away what we have to chase windows, but to get new tools written that take advantage of what we already have.

This is where Ubuntu has done such a good job, they have written a lot of these tools (or at least put them togeather in ways that no other distro ever dis) to make things easier for the user. If running old binaries is so valuble then someone will eventually write tools to automate the library discovery/install process for them.

Then why bother?

mjthayer — Mon, 05 Jan 2009 20:58:36 +0000

> You are missing the point completely. Yes, it should be possible to run
> Android applications under GNOME or KDE. But this is not the solution. It
> looks to me that you don't even understand the problem.

That could actually be the point. Getting "native" Linux applications to work in a plug and play way when you stick in a CD is more or less impossible as things are. However, getting Windows applications to plug and play under Linux via Wine actually seems more realistic (if the application works at all of course - persuading Windows application authors to test under Wine might be the best hope for that). The same might apply for Android applications.

Then why bother?

drag — Mon, 05 Jan 2009 18:31:08 +0000

> No? Why bother then? ISV need 100% solution - and it's not LSB. Time will tell if it's Android or, not but LSB failed so far.

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?

Android netbook is a possibility (Inquirer)

ballombe — Mon, 05 Jan 2009 18:06:33 +0000

Personnaly I found that the best way to cross-compile something not supporting cross-compilation out of the box is to use qemu plus distcc pointing to a cross compiler (maybe on the same host). (distcc under qemu call native distcc that call a cross compiler)

Bullet point?

khim — Mon, 05 Jan 2009 13:11:11 +0000

The console makers know that back compat is mostly a marketing bullet point, customers (particularly the most profitable ones who buy lots of new games) don't really use the back compat. So it's important to have some sort of offering, but you can't afford to spend much R&D money on it. If it falls out naturally from evolving hardware, great. Otherwise, too bad.

Sorry but the fact that XBox360 and PlayStation3 (both with radical changes in hardware from predeccessors) support any backward compatibility means developers spend millions and millions of dollars to achieve that. Backward compatibility is easy way to solve checken and egg problem: nobody buys your console because there are no games for it - and game developers don't create games because there are no buyers for said games! Microsoft decided to solve the problem by other means: just give money to game deveopers directly - this should be incentive enough. SONY decided that "it's not so important" - and PlayStation3 became a pariah.

Linux developers don't have money to solve the problem "Microsoft way" so the fact that they ignore compatibility problem and talk about "Linux on consumer desktop" is puzzling. There are no way to achieve it - at least with LSB/GNOME/KDE/etc => Linux on consumer desktop is a non- starter. With Android... there are a chance. Small chance to be sure, but a chance...

I think the "enterprise" Linux distributions can do a pretty good job of supporting the same binaries for 10 years or so, via compat packages, configuration of the environment (with judicious symlinks etc.) and so on. It shouldn't be a huge surprise if the same isn't true in Fedora 11 where the OS itself has a life of only 12-13 months.

I don't fault Fedora at all - it's not the system for a consumer desktop, so this level of compatibility is not a requirement.

Have you checked?

khim — Mon, 05 Jan 2009 12:44:23 +0000

for the game consoles there is basicly zero compatibility between games produced for one piece of hardware and the new models

It used to be true. Ten years ago! SONY changed the trend with PlayStation2 - almost 100% compatible with original PlayStation (only some accessories can not be used). SEGA and Nintendo had "new and improved incompatible consoles" (SEGA Dreamcast and Nintendo GameCube) but they had no compatibility with previous models - and as result SEGA gone bancrupt while Nintendo survived only because of success of GBA... compatible with original GB and GBC!

Surprisingly enough XBox360 and PlayStation3 are bad with backward compatibility where Wii can support games from GameCube (no charge), NES, SNES, Nintendo64, Sega Master System, Sega Genesis, TurboGrafx-16, Neo Geo, Commodore 64 and MSX (for a fee)! Of course it's not the only reason to the run-away success of Wii, but SONY found that PSP gained in popularity significantly once support for original PlayStation titles was added.

Sorry, but times are changed. Backward compatibility is the king today. And Linux does not support it. Heck: today old Windows programs are more compatible with latest version of Linux than old Linux programs.

for windows the compatibility was really good up through win 98, but since then microsoft changed a bunch of stuff, so a lot of win98 and earlier software won't work without re-writing it.

Have you actually tried to use it or is it hearsay info too? Compatibility is certainly not perfect but Windows XP and Windows Vista include A LOT OF stuff intended to make software compatible. Ironically enough worst compatibility is with Microsoft's packages: because Microsoft can just push updates. Even there: basic functions of MS Office 97 work perfectly fine with Windows Vista - but some obscure features are broken. If you install some old program Windows XP knows how to handle it. Sometimes it just uses "fixed" version of some .dll transparently for the old program!

haven't you ever heard of 'DLL hell' (where one piece of software needs a new version of a DLL and another need an old version of the same DLL)?

Of course I've had! I reinstall my niece's Windows system regularly - it's the only way to keep it working after you've installed/deinstalled hundred different programs or so. But you miss the point: dll hell is certainly VERY bad thing. But alternative (you can only install something if you know how the thing works) is totally unacceptable for consumer desktop. If you can eliminate dll hell and keep system backward compatible - it'll be great (Google tries to do exactly that with Android) but if you can not provide compatibilty - don't even start. Dll hell is infinitely preferrable to unusable program in non-IT person POV.

for linux most old software will just work on new versions, the only issue is that you may have to get copies of older libraries as well (and unlike windows, *nix has provisions for having multiple versions of a library and letting the software specify which one it needs)

Sorry, but "will just work" have different meanings for geek and normal person. For geek "will just work" == "will need some tweaks here and there and after that it's half-usable". For normal person "will just work" == "I insert CD or start install program, wait 15 minutes and use it". Anything else means "it does not work"!

the problem isn't that the linux software won't work, it's that there is no easy way to setup the appropriate libraries for it to work.

It does not matter. It does not work - that's what matters. And libraries are pretty minor thing. Think about it: if you install program and it does not add icons to the "Start Menu" - is it working or not? My niece will say: "of course not - how to run it? well... too bad - I'll try to install something else". Yes, it looks insane for a geek, but that's how non-IT person perceive stuff: even "minor" issues are perceived as insurmountable...

even with OSS (which you posted the link to), the issue isn't that the software doesn't run, it's that it doesn't play nicely with other things using sound at the same time, but that software never did, so while that's not nice for a modern desktop, it's no worse than the software was 10 years ago when it was first written.

Sorry, but no. It worked perfectly 10 years ago with "SoundBlaster Live!". It does not work today on today's system. Again: does not work == I've installed it, started and can not use it. It does not matter WHAT EXACTLY makes it unusable - I've installed it and it does not work, period.

Now, don't get me wrong: I know old stuff on Linux is usually in state "you only need to tweak it a big, may be change permissions and voila" - but it's not in the working state from the non-IT person POV...

P.S. Recall what was really-really wrong with Windows Vista? High system requirements? Nope: KDE4 is in the same league. Hardware compatibility? No: today Windows XP is worse for the new hardware yet people are asking their friends to somehow make a miracle and install Windows XP on thus %@###!%@! "Windows Vista capable laptop". Then what? Simple: it broke a lot of stuff and showed a lot of scary warnings when you've done things "as usual". As long as Linux does not offer smoth upgrade path - it' non-conteder for consumer desktop...

Android netbook is a possibility (Inquirer)

xylifyx — Mon, 05 Jan 2009 11:55:23 +0000

Perhaps Qemu could be a solution to tedious dump to real hardware. Though I would still cross compile because it is faster.

http://909ers.apl.washington.edu/~dushaw/ARM/

Then why bother?

tialaramex — Mon, 05 Jan 2009 11:39:23 +0000

It's important to look beyond the headlines.

There's a difference between the marketing bullet point "backward compatible" and actual backward compatibility. After all, the Linux kernel's continued support for early ELF binaries with the original system calls means in theory you can run a 13 year old Linux program on today's Fedora, but no-one pretends (as the grandparent poster does for consoles) that means 99% compatibility.

The Wii plays Gamecube games, mostly. I'd buy the idea that it could even be 99% of them (not that anyone can think of more than ten decent Gamecube games). The 360 plays /some/ Xbox titles, but notably not several best selling ones that people are most likely to own (it's all very well having a big list of titles like "Barbie Horse Adventures" and various movie tie-in generic platformers, but no-one actually owns those, they're shelf-filler). Microsoft claims that overall "more than 50%" work, but they count a game as "working" even if it's noticeably slower and has visual defects.

The PS3 is even worse - some models, those released early in Japan and North America, had expensive compatible hardware to run most of the GTA games (with "some issues" ie you'll probably still wish you were using a real PS2) but those released later (e.g. in Europe) rely purely on software emulation. Which basically isn't adequate for any of the top-selling games on the PS2. This means even if a game works on your friend's PS3, it may not work on yours. You have to compare the model of hardware you have to a compatibility list...

The console makers know that back compat is mostly a marketing bullet point, customers (particularly the most profitable ones who buy lots of new games) don't really use the back compat. So it's important to have some sort of offering, but you can't afford to spend much R&D money on it. If it falls out naturally from evolving hardware, great. Otherwise, too bad.

I think the "enterprise" Linux distributions can do a pretty good job of supporting the same binaries for 10 years or so, via compat packages, configuration of the environment (with judicious symlinks etc.) and so on. It shouldn't be a huge surprise if the same isn't true in Fedora 11 where the OS itself has a life of only 12-13 months.

Then why bother?

dlang — Mon, 05 Jan 2009 02:48:56 +0000

the different so names do the job today.

I ran into this yesterday on my Dad's laptop.

he installed mulberry (precompiled binary) and it wanted libstdc++.so.5 and his system has libstdc++.so.6

first try, make a symlink to .6, result: additional errors

second try, use the ubuntu package manager to install the .5 version (in addition to the .6 version), result: a system with both versions installed and apps depending on each one working happily.

I've dealt with this for several other libraries over the years, and in almost every case there have been no problems having multiple versions of the libraries on the system.

a year or so ago I dug out some ancient linux binaries (wordperfect and the first Civ game that was released for linux, both from an early Caldera release), and was able to get them both running without much hassle

Then why bother?

Kit — Mon, 05 Jan 2009 01:37:22 +0000

>for the game consoles there is basicly zero compatibility between games produced for one piece of hardware and the new models

Not true in the slightest for any of the major current generation systems. The Wii can play Gamecube games, the Xbox360 (tri-core PPC) can play Xbox (x86) games, and the PS3 (Cell) can play PS2 ("Emotion Engine", vaguely MIPS-like), as well as PS1 games (MIPS).

>and unlike windows, *nix has provisions for having multiple versions of a library and letting the software specify which one it needs

I'm not sure I've seen any support for multiple versions beyond simply changing the .so's name with every version (which you could do with .dlls on Windows).

Then why bother?

dlang — Mon, 05 Jan 2009 00:51:58 +0000

your sucess numbers are highly suspect.

for the game consoles there is basicly zero compatibility between games produced for one piece of hardware and the new models

for windows the compatibility was really good up through win 98, but since then microsoft changed a bunch of stuff, so a lot of win98 and earlier software won't work without re-writing it. and even without that, haven't you ever heard of 'DLL hell' (where one piece of software needs a new version of a DLL and another need an old version of the same DLL)? that doesn't require 10 year old software to trigger, it can be triggered by conflicts in brand-new software from different vendors.

apple has done a good job (they had to, they've changed hardware platforms enough that anything less would have put them out of business)

for linux most old software will just work on new versions, the only issue is that you may have to get copies of older libraries as well (and unlike windows, *nix has provisions for having multiple versions of a library and letting the software specify which one it needs)

the problem isn't that the linux software won't work, it's that there is no easy way to setup the appropriate libraries for it to work.

there are some exceptions (mostly in terms of interpreted languages that I know about) but not that many.

even with OSS (which you posted the link to), the issue isn't that the software doesn't run, it's that it doesn't play nicely with other things using sound at the same time, but that software never did, so while that's not nice for a modern desktop, it's no worse than the software was 10 years ago when it was first written.

I agree that the LSB is basicly meaningless, but the overall compatibility in linux is actually pretty good.

Then why bother?

khim — Sun, 04 Jan 2009 22:51:15 +0000

Well you can't expect LSB to do everything.

No? Why bother then? ISV need 100% solution - and it's not LSB. Time will tell if it's Android or, not but LSB failed so far.

It's not LSB's fault that the problem is so difficult and such a mind blastingly waste of time and effort compared to getting people to agree with each other... but it's something that is required anyways.

The problem is not difficult at all. You need some standard and some way to ensure that people will create products compatible with said standard. And in real world that means money.

Each Android application runs as it's own entire 'fork()', right? So it shouldn't be very difficult to be able to integrate Android apps into a desktop situation.

You are missing the point completely. Yes, it should be possible to run Android applications under GNOME or KDE. But this is not the solution. It looks to me that you don't even understand the problem.

The problem is: usability of the old software on modern system. Basically I take the CD with 10 years plus program (Neverhood or Office 97, WordP erfect or Chrono Cross), put it in drive, start the program - and use it. What is the success rate? The story goes more or less like this:
1. PlayStation/Wii/etc - 95-99% success (even on newer console versions).
2. Windows - 90-95% success.
3. MacOS - 80-90% success.
4. Linux - 5-10% success.
As long as Linux does not offer such capability - it's non-conteder for Consumer Desktop. But you often only need few tweaks! Right - and that means Linux is close to being ready for Enthusiast Desktop or may be even Enterprise Desktop. But for consumer desktop - you need something usable without HOWTO or tweaks. Android promises this. Will it fulfull this promise or not - time will tell. But so far it looks fine: when it was found that you can call some undocumented features via reflections - Android developers pulled the plug. SONY/Nintendo/etc achieves it's success in the same way: developers are punished quite severely if they go beyond spec, but as result - programs (mostly games, of course) are usable for decades...

Just like how the barriers between 'CPU' and 'GPU' and how they are handled are slowly being erased (See also Intel Larrabee and AMD/ATI's Fusion), the differences in mobile phones, internet-focused netbooks, and even general purpose computing systems are going to be eliminated.

Yes, but if Linux community will not produce something usable in 100% plug-and-play mode - it'll not be Linux-based. So far there are very few contenders - and Adroid is amongst them while LSB is not.

As for broader Linux community... what can you say when vital compatibility stuff is unmerged for years? Clearly situation is perfectly hopeless there - not even worth discussing...

Android netbook is a possibility (Inquirer)

Kit — Sun, 04 Jan 2009 22:39:48 +0000

>Kernel modesetting brings decent (unaccelerated) framebuffer support out of the box, but getting Android to run well would require acceleration and an EGL implementation. Intel has (so far, at least) shown no sign of being interested in working on those.

Isn't Gallium3D basically the other part of this pie? IIRC, it's not actually Xorg specific and could be used to accelerate even applications simply running on the framebuffer.

LSB is a hoax - on desktop at least

drag — Sun, 04 Jan 2009 19:52:33 +0000

see here is a OMAP3 platform being used for some Demos:
http://www.youtube.com/watch?v=FuVwh_VrIxk

You can get that board for 150 bucks, which is deadly cheap considering it's a developer's board. Oh, and did I mention it power usage is around 2-watts?

By the end of this year I expect people are going to be running around with Cell phones with as much or more power then what is being used to drive that Ubuntu desktop with 720p display.

This is the sort of thing that Android is designed for.

LSB is a hoax - on desktop at least

drag — Sun, 04 Jan 2009 19:42:57 +0000

Well you can't expect LSB to do everything.

The easiest approach, of course, would be to convince everybody to stop with the competing implementations of the 'same software slightly differently configured' that we call 'distributions' and convince everybody to use the same core 'linux plumbing' and then build their individual systems from that in a modular fashion.

However that is not going to happen any time soon, so you have completely second-rate things like the LSB being implemented. It's not LSB's fault that the problem is so difficult and such a mind blastingly waste of time and effort compared to getting people to agree with each other... but it's something that is required anyways.

Why?

Because nobody else is doing it. And standardization needs to be done.

...............

But for desktop applications you have the freedesktop.org specifications, which are all pre-LSB essentially drafts. And those take care of the desktop stuff.

But anyways...

Each Android application runs as it's own entire 'fork()', right? So it shouldn't be very difficult to be able to integrate Android apps into a desktop situation.

It won't be perfect.. but I figure with a composited desktop you just have the android display stuff being rendered off-screen then have the pixmap (or whatever) rendered along with the rest of the desktop.

Like what you can do with Redhat' Wayland display stuff. It's not a X Server, but a new thing. But it can be used with X by running a X server in a off-screen buffer and compositing those applications into the display.

Then you need a sane way to handle input redirection, window management, copy-n-paste, drag-n-drop and whatnot and you have a integrated solution that can work with multiple types of display technologies.

I don't know if that makes sense to do or not....

-------------------------------------

But this is the sort of thing that people are going to want to be thinking about.

In the future your going to see a huge blurring of the roles that computers play in people's lives.

Just like how the barriers between 'CPU' and 'GPU' and how they are handled are slowly being erased (See also Intel Larrabee and AMD/ATI's Fusion), the differences in mobile phones, internet-focused netbooks, and even general purpose computing systems are going to be eliminated.

Hell, you have the Texas Instrument's ARM OMAP3 platform, which is designed for hand-helds like cell phones and whatnot... These things are capable of running Quake3!! With all the power savings you get from a traditional ARM platform..

And Intel is shrinking down the x86 platform to handset dimensions with the Atom and it's associated chipsets (not the desktop oriented 945 platform in today's Atom-based netbooks) and those are going to be capable of running close to Atom-power savings and are going to be just as powerful (and have multiple processing core) as today's Netbooks.

(In fact things like the Beagle and the Atom MID use the same video acceleration devices... even though they are different platforms. Unfortunately proprietary drivers...)

Then you have folks like Nvidia that are displaying mobile handset chipsets that are capable, with proper GPU acceleration can decode and render 720p and even 1080p video.

Android netbook is a possibility (Inquirer)

mjg59 — Sun, 04 Jan 2009 19:26:53 +0000

Kernel modesetting brings decent (unaccelerated) framebuffer support out of the box, but getting Android to run well would require acceleration and an EGL implementation. Intel has (so far, at least) shown no sign of being interested in working on those.

As for developing on ARM - having a port to x86 means that your developers can implement the majority of the stack on generic hardware that will build stuff quickly. Having to cross-build and then dump to real hardware to see whether you've fixed a bug is intensely frustrating compared to being able to run it locally.

LSB is a hoax - on desktop at least

khim — Sun, 04 Jan 2009 17:12:25 +0000

I'd rather they target the LSB, personally.

Are you serious are is it a joke? Let's take a look on simple program. Mmm... uTorrent. What do we need for a usable Linux port?
1. A way to add program to the programs menu.
2. A way to add icon to the system tray.
3. A way to call system browser with given file selected.
4. A way to register program as handler for application/x-bittorrent files.
5. A way to start process in the background when system starts.
And few other similar items. Nothing is standartized with LSB (first item is poorly handled by few latest versions, but the rest is not handled at all).

LSB is total disaster on desktop - not even worth trying.

Android netbook is a possibility (Inquirer)

endecotp — Sun, 04 Jan 2009 15:22:00 +0000

> it's a framebuffer-based system and so gains no benefit from Intel's
> work on X drivers

Hint to Intel: there are people who care about non-X systems, so please don't abandon those drivers.

> doing OS development on ARM is slow and dull

Others might disagree.

I'll pass

leoc — Sun, 04 Jan 2009 11:40:12 +0000

I'd rather they target the LSB, personally. Is Android LSB compatible? If not this would seem to be another step back for Linux on the 'desktop'.

I'll pass

bronson — Sun, 04 Jan 2009 06:07:19 +0000

That's true. But how many developers target Xandros? Or Debian? RHEL? Fedora? Ubuntu? SuSE? Mandriva?

It's very difficult to make a piece of software deployable to a large number of Linux desktops. Xandros alone can't solve this.

Android netbook is a possibility (Inquirer)

mjg59 — Sun, 04 Jan 2009 01:16:10 +0000

A lot of the speculation seems to be based on the idea that "MID" refers to netbook-style devices. My understanding was that MID generally referred to devices approximately the size and form of the Nokia internet tablets. A distinction usually seems to be drawn between these two classes of device.

As of right now, Android on an x86 netbook is going to have sufficiently poor power management to be practically useless. Never mind the fact that it's a framebuffer-based system and so gains no benefit from Intel's work on X drivers, or that Intel's working on its own netbook and MID optimised Linux varient. Could there be Android running netbooks in the near future? Yes, absolutely. But the fact that the code happens to build on x86[1] is hardly evidence for that position.

[1] It turns out that doing OS development on ARM is slow and dull, and it's a lot easier to handle if your OS also runs on big fast computers with sensible keyboards. Who'd have guessed?

I'll pass

drag — Sat, 03 Jan 2009 18:22:02 +0000

What single company?

Google started it, to be sure... but it's open source! With the open handset alliance you have almost 50 members, many of whom do support running open source software in their neck of the woods and have contributed code to the kernel and other projects in the past.

Saying that we should not use Android because it's controlled by a single company is like saying we should not use GNU userland because it's controlled by a single organization, or nobody should use KDE because QT and related tools are now owned by a phone making company.

It' a bit silly, I think, to be paranoid about it.

What it is is a new operating system for Linux. It's not POSIX, but it's something more like the old LISP machines or whatever... It's definately worth looking into.

Linux itself has always struggled to come to grips with making Unix user friendly. With Android you don't have Unix... you have something new. And it can run beside and with Unix environments if you want so your not going to give up much.

Having something that is designed from the ground up for user interactivity may be what the doctor has ordered.

I'll pass

epa — Sat, 03 Jan 2009 17:08:21 +0000

Android has one package manager and one window manager/desktop environment.

So does, say, Xandros. I fully agree that just picking one of each is the right choice. But it's hardly exclusive to Android.

I'll pass too

asamardzic — Sat, 03 Jan 2009 14:09:53 +0000

I think they work with Linux but haven't bothered to check, since I don't need one. But with one of these babies there is no reason not to be connected all the time.

Most of these devices behave as plain USB modems, but usually there is a twist: there exists also some small flash storage, with Windows driver and dialer application sitting there, so the device presents itself to the system as USB storage device first, and then the dialer application is sending device-specific USB command to switch the device to the modem personality before dialing. All in all, quite a moronic setup (even for Windows users I guess, because indeed they have the driver and the application nicely installed automatically upon connecting the device to the computer for the first time, but afterward they have to use supplied dialer application) making them unusable directly under Linux. Luckily, it's not that hard to snoop USB traffic to find mode-switching command, which could be then utilized along with libusb and some udev rules to automate switching device to the modem mode each time when the device connected to the machine. See here for the fully wrapped solution (including corresponding "hacks" for many alike devices).

In any case, once you get over this hurdle, this kind of setup works really great - rates are usually reasonable (20-30 euros for at least couple gigabytes, if not even flat rate, of traffic per month), and having both full mobility (when you're in part of the world where 3G, or EDGE or even GPRS, coverage is much better than Wi-Fi coverage) and full comfort of notebook/netbook screen size is really sweat on some occasions.

I'll pass too

man_ls — Sat, 03 Jan 2009 13:07:48 +0000

Well, over here they sell these USB modems with 3G broadband for about 30 a month, flat rate. E.g. (in the UK), they revert to GPRS if there is no 3G network available. Surely there is something similar in the US?

I think they work with Linux but haven't bothered to check, since I don't need one. But with one of these babies there is no reason not to be connected all the time.

I'll pass

tzafrir — Sat, 03 Jan 2009 13:06:34 +0000

No. I don't assume a single company needs to do all the development.

I would really hate to rely on the development efforts of a single company. That company might lose interest in the project, or sell it to someone else with different interests.

I'll pass

tzafrir — Sat, 03 Jan 2009 13:01:39 +0000

If you're always connected (through a cellular network. At least as a backup) you can rely on the communication to the big brother. But I'm not sure this applies to a netbook.

I'll pass

nhippi — Sat, 03 Jan 2009 10:48:07 +0000

I guess you live in United States, rather than in, say, Kenya?