id Software: Linux Hasn't Produced Positive Results

[russofris]

Well, I specifically remarked that Android would probably have been just as successful with any other kernel (like how Apple's OS X and iOS are also very successful while not using the linux kernel). So in my opinion it is not about linux in the first place. It's about creating a proper platform.

In the instance of android, I'm not certain I agree. In 2005, Google needed something that they could transform and release quickly. Using linux allowed them to leverage an internal talent pool that they already possessed. I'm not certain the same could have been done with Darwin/BSD/Mach/Syb/WinCE with the same time-to-market. So while I agree that a device can use any kernel, and that linux may not have been the best choice from a functional perspective, I do not believe that they could have attained the marketshare that they currently have. I think that it's called -- The law of Diffusion of innovation, where google grabbed a good portion of the early majority, and most of the late majority.

There was a Ted talk that touched on this, I think it was http://www.ted.com/talks/lang/en/sim...re_action.html , I think there was another one on android, I'll check.

If Google hadn't come out with android, we'd all have iPhones (that's not a horrible thing) and they would cost 25% more than they do now, and probably wouldn't be as good.

F

[Scali]

In the instance of android, I'm not certain I agree.

Well, I was talking from a technical point-of-view, not factoring in what kind of knowledge Google may or may not have already had access to.
My point is just that Android is something like this:
- A Java-like environment
- On top of a *NIX-like environment
- On top of the linux kernel

And as we all know, Java environments can run on a variety of OSes (*NIX or not).
It doesn't really matter whether a Java application runs on top of linux, OS X, FreeBSD, Solaris, Windows, or whatever other OS. The Java application will work, as long as the Java environment is compatible.

So in the case of Android, most of the lower layers could in theory easily have been implemented with something other than a linux-based environment (heck, a big reason for the popularity of *NIX was/is because you can easily recompile the same software on any *NIX-like OS, because they all support the POSIX and ANSI C APIs. A large part is completely interchangeable by definition). At least, from a technical point-of-view.
Whether or not linux was the best choice for Google from a business point-of-view is not something I can judge properly, nor am interested in. I can only assume that Google looked at various alternative paths, and used sound reasoning to arrive at their choice for linux.

If Google hadn't come out with android, we'd all have iPhones (that's not a horrible thing) and they would cost 25% more than they do now, and probably wouldn't be as good.

I doubt it. iPhones are still way more expensive than Android phones. As far as I can recall, there hasn't been a significant price reduction on iPhones since Android was launched. Certainly not anything in the range of 25%.
Would they not be as good? Again, I highly doubt it. All Android has done so far is to copy the iPhone. It's much like how most linux/open source applications are merely copies of commercial/closed source applications. They rarely reach a level of maturity where they actually compete with the original applications directly.
I feel the same way about Android. It's a budget iPhone, but not a direct threat to the real thing. I mean, I use an Android phone, but if there was no Android, I wouldn't have gotten an iPhone anyway. I simply don't want to spend that much money on any phone/gadget.
I think the same goes for most people. If they want to spend the money, they'll get the real iPhone anyway. I haven't heard anyone getting an Android phone "because it's cheaper". What I have heard however is people who went from an iPhone to an Android phone, and complaining that it's not as userfriendly, slick and well-supported as their iPhone was, and are likely to go back to an iPhone next time.

[crazycheese]

Not at all. It seems you have no idea about the point I'm making. Revisions have little to do with how 'fixed' a platform is. That is more about backward compatibility.
Take Windows for example, roughly we have the following revisions in common use today:
Windows XP RTM, SP1, SP2, SP3
Windows XP x64 RTM, SP1, SP2
Vista x86/x64 RTM, SP1, SP2
Windows 7 x86/x64 RTM, SP1

Mate, you just have forgot a shite of patches and changes. How many .net versions were released ALONE?
Windows is just as changing as Linux. Because its either this - or death from exploits.
The only difference between the two is that linux does not keep older versions around, together with all expoitable code.
And versions, that are straight easy to abuse, are patched - with lots of win* software getting BROKEN.

Quote from WINE: Bug-per-bug compatibility.

Remember "DLL hell"? Ditto!

Unlike Windows, Linux does not use outdated versions, but only ONE version - that is CURRENT STABLE version.

When newer version is released, applications that depend on it are required to UPDATE. This is constant unavoidable process. Code always changes, it is a process.
If, somehow, the application can't receive updates to adopt to newer stack - its dead. The only reasonable way to treat such an application, is setting up dedicated virtual environiment.

This is why Linux is much less susceptible to exploits - it carries no cruft around.

The lastest *innovation* from Microsoft on this front, after Dll Hell, is called "install all libraries from all applications in separate container".
Apparently, such method had a bug around Vista SP1, which made this container grow past 40 GiB of space.

Common, next talk how wonderful registry is, and how Linux looses here

Most software released in the past 10 years will run on ALL these OSes out-of-the-box. Because the Win32 platform itself is 'fixed'. New functionality is added, bugs are fixed, but there are rarely any changes that break current or even legacy software.

No big deal, when dealing with uncomplex compiled software.
As in my example, Urban Terror 4.1 was released several years ago, and still runs without any changes ON ANY KERNEL.
However, if you take Python 2->3 migration - all your stuff will break on Windows.

Yes, but those are the exceptions to the rule

There are a lot of exceptions. So much exceptions, that starting from XP, windows has "compatibility mode", which essentially links older libraries instead of the newer.
And it works so good, that its better to use old software under WINE, than under "native environiment".

Yes and no. For example, not all versions of GCC are binary compatible with eachother.
Eg, you cannot link 2.xx code to 3.xx or 4.xx code. This makes it a lot harder to distribute libraries in binary form.
Compare that to Microsoft Visual Studio, where Visual Studio 2010 can still use libraries built with Visual Studio 6 from 1998 (and perhaps even earlier).

Binary stability is exactly the same cruft as library/structure cruft.
But I think recently developers agreed to change ABI only at certain periods and stabilize it. All for the sake of lazy (proprietary) programmers, who are too bothered to update their *software*.
However, given the fact that source-based distributions exist and are quite popular for many years, it should not be a problem to recompile even LibreOffice for target platform in under several seconds, when having access to cloud-based services. The only factor is price (since we are talking about lazy proprietary developers), which is just several cents more to keep cruft and exploits (and all AV-stuff) away.
Speaking on libraries, you should never ever distribute any libraries. You should ONLY link to them.
But if you are taking disgusting proprietary approach, at least keep 'em together and minimize ABI calls. This applies for ALL OSes.

Perhaps, I'm not even going to bother to try, because even if it were true, it would be the exception to the rule. It is common knowledge that in general packages cannot easily be used among different distributions or older/newer versions of the same distribution.

Ok, then go download Alien Arena.. Or Nexuiz .. Or Tyrian2000.. Or Canon drivers.. The later being nice example of that libraries and drivers are better off opensource and submitted upstream, instead of proprietary, handled by 1-2 indian coders (stuff is even funnier with epson). Also, I don't understand you term "general packages", because nearly all of the software I use are handled by the package manager, that includes downloading, installing, matching requirements, keeping all up-to-date. Programmers do their job, I use the software for my tasks. I'm not manually click-installing/uninstalling-upgrading 10 different software types. There is no maintenance required, except when using something as customizable as emerge or cave - because those guys go far more than that - they cut any software exactly to users wishes from source code. Ofc, where software is modularized on binary level, no such cutting is needed or is done by them.

Not at all. As a developer, you target the most common version (or versions) of a library, so that you have the widest possible support.

I think this sentence is the epicenter of the misunderstanding.
Your assumption above is a direct result of applying broken windows methods - complete with bugs, version mess, DLL hells of varying degrees and similar joys.

If you are to claim this as an "advantage", thats a quite sarcastic one! Because your laziness results in problems inside user-land.

In Linux, you keep an eye on current library versions, and just release newer versions of your software when updates are needed. You don't care about "most common version" at all, or at least, till someone pays ya for "voluntary" port.

The REAL problem however is that the libraries themselves are not a 'fixed' target. The interfaces change (both at binary and function level), breaking compatibility with older or newer versions of software.
This is different on Android, or Windows for that matter. If you develop against a certain version of a library, you don't have to worry about newer versions breaking your code, because they will be backward compatible with the version against which you developed your software.

Thanks, this is exactly the reason why I migrated FROM windows. Thanks for trashing an OS! That breaks anyway! And occupying much more disk space! And introducing even more exploitable joys!
I have no idea of how garbaged Android now is, but if what you say is correct, its only a matter of time till Android becomes trashed beyond unusable.

Which is why software developed for Windows XP still works in XP x64, Vista, Win7 and Win8. Or why software developed for Android 1.x still runs on 2.x, 3x and 4x.

Only for open source, because everyone can build packages (re-inventing the wheel).
This shouldn't be a problem in the first place, since you should be able to make a single package that works on all distros. But that is exactly the problem we're pointing out here: there is no easy way to do this, because too many parts in the chain vary.

What does your "reinventing the wheel" mean here? You can get any package manager, any, inside your fresh installation of LFS and allow it do the job for you of installing all existing software fully automatic.
There are only situations, where you will need to "reinvent the wheel" as you say - but more exactly: to remake the package
- you are not using existing package manager, but using your own, because the former does not suit your goals
- you are not using existing package for existing package manager, but are building your own package, because you have modified essential OS components, resulting in deviation from ABI/API requirements.

In short, you used your freedom to deviate from world's defaults.
But you don't want to sync the rest of the world to your new "realm"?
Who's going to do this job for you then?

If you don't want this, then don't deviate. Don't make your own distribution - stick to existing one.

Trying to have an ABI/API that fits all is essentially wanting a key, that fits all locks in this world. Pardon me, but:
a) you are taking away the freedom to advance locks
b) you are removing security based on different lock designs
c) you are killing innovation by prioritizing existing, outdated solution - instead of a ground breaking newer one
d) you are endangering the sole existence of lock-makers(,because securing locks by changing them, will unavoidably break compatibility with your key) but instead proposing bodyguards (sounds familiar, AV anyone?)

In short, you want to live a perfect life and that forever. Might I note that a) world is always rotating b) symbol of "death" means "change" in tarot c) you can't see whats beyond the horizon.

You also can't use Android 4.0 functionality on 2.0. Is this somehow different?!

Yes it is. Becase you *can* use Android 2.0 packages on Android 4.0. All developers don't have to create a new package for their Android apps everytime a new Android version is released.
This is different from linux distros.

No you can't. Unless Google has secured services of Emmett Brown. Please reread my sentence.
Android currently is following very accurate, but windows-like scheme of "stabile ABI", which will lead to its trashing with only exact time question open. And even this scheme does not guarantee " All developers don't have to create a new package for their Android apps everytime a new Android version is released." On contrary, if you are a programmer (and not a coder), you MUST babysit your software.
There are only three types of software:
- maintained, as in babysat
- broken
- on 5,25 floppy discs for historical reasons

Don't argue with me about OpenGL. I write graphics software for a living. I've ported my OpenGL code to OpenGL ES 1.0 and 2.0, and know exactly what I had to change for it to work. Which is what I based my previous statement on.For example, OpenGL ES 2.0 does not have any fixedfunction pipeline anymore. It can only use shaders. And these shaders use a slightly different dialect of GLSL, with keywords that regular OpenGL does not support (google around to see how people try to find solutions with #defines and such to make the same code compile on both OpenGL and OpenGL ES).

Glad to hear you are gfx programmer, but I fail to understand what does this have to do with questions we argue about...
OpenGL ES 2.0 stepped into shaders because mobile hardware became stronger - didn't it?
Also, note they have cut backwards compatibility to ES 1.0. Looks like they have learned from OpenGL3, and adopted Linux approach instead? That is, breaking stuff now, instead of making it decay here till the rest of the days.

No, because Google knows the value of backward compatibility and having a stable binary platform. It is popular because it is easy for developers to develop for, and easy for users to install software for. Although it is not quite as userfriendly as iOS though, and as such, not quite as popular.

I leave this uncommented, because this was resolved in paragraphs above. Please inform me when the first exploit surfaces and Google starts breaking things.. a lot of things, usually unsupported ones.

[crazycheese]

Firstly, I would say that this forum is not strictly linux-oriented. Phoronix spends a healthy amount of time on BSD-related topics as well.
Secondly, this kind of attitude is exactly why developers don't like linux. The linux community cannot take any criticism, and instead of working *with* developers, and accepting suggestions that may actually be very good for the future of linux, they just start fighting with these developers instead. Heck, just look at how people have insulted John Carmack in this thread. That guy singlehandedly put OpenGL on the map as a gaming API. He also gave linux gaming a huge shot in the arm by releasing his engine code under GPL, and releasing linux ports of popular ID games.
I am not surprised he gave up on linux.

First of all, BSD systems are like 10 year old milk. Very good food for proprietary infections.
Secondly, the guy is a human, not an OS. You confuse reaction of a human with OS output.
And lastly,regarding Carmack, you have reversed implication and made a logical mistake. Also, the words in the article(s) did not belong to Carmack. Carmack's only response about Linux was that they(ID) are short on cash now.

[elanthis]

In the instance of android, I'm not certain I agree. In 2005, Google needed something that they could transform and release quickly. Using linux allowed them to leverage an internal talent pool that they already possessed.

Correct me if I'm wrong, but didn't Google buy out Android from another company after it had been in development for 2-3 years, and then take another few years to release the G1? It wouldn't have mattered so much what Google's engineers use (btw, OS X mostly) since they bought an existing talent pool.

[ворот93]

Mate, you just have forgot a shite of patches and changes. How many .net versions were released ALONE?
Windows is just as changing as Linux. Because its either this - or death from exploits.
The only difference between the two is that linux does not keep older versions around, together with all expoitable code.
And versions, that are straight easy to abuse, are patched - with lots of win* software getting BROKEN.

Quote from WINE: Bug-per-bug compatibility.

Remember "DLL hell"? Ditto!

Unlike Windows, Linux does not use outdated versions, but only ONE version - that is CURRENT STABLE version.

I.e. you never know when your software gets broken whenever distro pushes ANOTHER system upgrade. Hilarious.

When newer version is released, applications that depend on it are required to UPDATE. This is constant unavoidable process. Code always changes, it is a process.
If, somehow, the application can't receive updates to adopt to newer stack - its dead. The only reasonable way to treat such an application, is setting up dedicated virtual environiment.

Why the hell update code gazillion times (Linux) when you can have software running for 10+ years unupdated (Windows)? And you do not "treat" software, you "use" it for your needs. Unless you are Linux religious fanatic, of course.

This is why Linux is much less susceptible to exploits - it carries no cruft around.

The lastest *innovation* from Microsoft on this front, after Dll Hell, is called "install all libraries from all applications in separate container".
Apparently, such method had a bug around Vista SP1, which made this container grow past 40 GiB of space.

And all apps manage to run on Windows w/o having to keep up w/ Microsoft.

Common, next talk how wonderful registry is, and how Linux looses here

Gazillion .RCs scattered all over filesystem is definitely better (sarcasm)

No big deal, when dealing with uncomplex compiled software.
As in my example, Urban Terror 4.1 was released several years ago, and still runs without any changes ON ANY KERNEL.

As if Urban Terror is a very advanced game from tech POV
[QUOTE]However, if you take Python 2->3 migration - all your stuff will break on Windows.[/QUOTE
Ditto on Linux. Talking as a former Gentoo user.

There are a lot of exceptions. So much exceptions, that starting from XP, windows has "compatibility mode", which essentially links older libraries instead of the newer.
And it works so good, that its better to use old software under WINE, than under "native environiment".

And "compatibility mode" still does not require messing with terminal or installing Q4Wine

Binary stability is exactly the same cruft as library/structure cruft.
But I think recently developers agreed to change ABI only at certain periods and stabilize it. All for the sake of lazy (proprietary) programmers, who are too bothered to update their *software*.

At this point AAA developers say "fuck you" and bury Linux as a platform.

If you are to claim this as an "advantage", thats a quite sarcastic one! Because your laziness results in problems inside user-land.

He is no more lazy than a fanatic sitting in mom's basement wanking at portage compilation.

In Linux, you keep an eye on current library versions, and just release newer versions of your software when updates are needed. You don't care about "most common version" at all, or at least, till someone pays ya for "voluntary" port.

So a developer has to care about and test every FUCKING update that distro pushes? No thank you.

Thanks, this is exactly the reason why I migrated FROM windows. Thanks for trashing an OS! That breaks anyway! And occupying much more disk space! And introducing even more exploitable joys!
I have no idea of how garbaged Android now is, but if what you say is correct, its only a matter of time till Android becomes trashed beyond unusable.

Good luck wanking at sight of portage compilation.

NOT a standard Windows error message. It appears to be typed by hand. Try deceiving harder idiot.

What does your "reinventing the wheel" mean here? You can get any package manager, any, inside your fresh installation of LFS and allow it do the job for you of installing all existing software fully automatic.
There are only situations, where you will need to "reinvent the wheel" as you say - but more exactly: to remake the package
- you are not using existing package manager, but using your own, because the former does not suit your goals
- you are not using existing package for existing package manager, but are building your own package, because you have modified essential OS components, resulting in deviation from ABI/API requirements.

Pardon me, how many package managers for Unix-like systems are there? Yeah, exactly gazillion.

If you don't want this, then don't deviate. Don't make your own distribution - stick to existing one.

Which one exactly? Hundreds of distros out there.

Trying to have an ABI/API that fits all is essentially wanting a key, that fits all locks in this world. Pardon me, but:
a) you are taking away the freedom to advance locks
b) you are removing security based on different lock designs
c) you are killing innovation by prioritizing existing, outdated solution - instead of a ground breaking newer one
d) you are endangering the sole existence of lock-makers(,because securing locks by changing them, will unavoidably break compatibility with your key) but instead proposing bodyguards (sounds familiar, AV anyone?)

In short, you want to live a perfect life and that forever. Might I note that a) world is always rotating b) symbol of "death" means "change" in tarot c) you can't see whats beyond the horizon.

A lot of blah-blah on your side but Windows solution to API/ABI compatibility earned Bill Gates billions of net worth.

No you can't. Unless Google has secured services of Emmett Brown. Please reread my sentence.
Android currently is following very accurate, but windows-like scheme of "stabile ABI", which will lead to its trashing with only exact time question open. And even this scheme does not guarantee " All developers don't have to create a new package for their Android apps everytime a new Android version is released." On contrary, if you are a programmer (and not a coder), you MUST babysit your software.
There are only three types of software:
- maintained, as in babysat
- broken
- on 5,25 floppy discs for historical reasons

Lots of games built for Android 1.6 still run on Android 4.0. You are wrong.

Glad to hear you are gfx programmer, but I fail to understand what does this have to do with questions we argue about...

He codes using OpenGL every day. Perhaps a coder knows more than basement dwellers.

I leave this uncommented, because this was resolved in paragraphs above. Please inform me when the first exploit surfaces and Google starts breaking things.. a lot of things, usually unsupported ones.

Please inform me when desktop Linux distros become as popular as Android.

Now, continue stargazing at Portage and don't bother us with such an idiot attitude

[Ferdinand]

If Google hadn't come out with android, we'd all have iPhones (that's not a horrible thing) and they would cost 25% more than they do now, and probably wouldn't be as good.

What a weird thing to say. I can make it weirder! If the iPhone never existed nobody would have a smartphone with a touchscreen finger interface!

[asdx]

Not at all. It seems you have no idea about the point I'm making. Revisions have little to do with how 'fixed' a platform is. That is more about backward compatibility.
Take Windows for example, roughly we have the following revisions in common use today:
Windows XP RTM, SP1, SP2, SP3
Windows XP x64 RTM, SP1, SP2
Vista x86/x64 RTM, SP1, SP2
Windows 7 x86/x64 RTM, SP1

Most software released in the past 10 years will run on ALL these OSes out-of-the-box. Because the Win32 platform itself is 'fixed'. New functionality is added, bugs are fixed, but there are rarely any changes that break current or even legacy software.



Yes, but those are the exceptions to the rule



Yes and no. For example, not all versions of GCC are binary compatible with eachother.
Eg, you cannot link 2.xx code to 3.xx or 4.xx code. This makes it a lot harder to distribute libraries in binary form.
Compare that to Microsoft Visual Studio, where Visual Studio 2010 can still use libraries built with Visual Studio 6 from 1998 (and perhaps even earlier).



Perhaps, I'm not even going to bother to try, because even if it were true, it would be the exception to the rule. It is common knowledge that in general packages cannot easily be used among different distributions or older/newer versions of the same distribution.



Not at all. As a developer, you target the most common version (or versions) of a library, so that you have the widest possible support.
The REAL problem however is that the libraries themselves are not a 'fixed' target. The interfaces change (both at binary and function level), breaking compatibility with older or newer versions of software.
This is different on Android, or Windows for that matter. If you develop against a certain version of a library, you don't have to worry about newer versions breaking your code, because they will be backward compatible with the version against which you developed your software.
Which is why software developed for Windows XP still works in XP x64, Vista, Win7 and Win8. Or why software developed for Android 1.x still runs on 2.x, 3x and 4x.



Only for open source, because everyone can build packages (re-inventing the wheel).
This shouldn't be a problem in the first place, since you should be able to make a single package that works on all distros. But that is exactly the problem we're pointing out here: there is no easy way to do this, because too many parts in the chain vary.



Yes it is. Becase you *can* use Android 2.0 packages on Android 4.0. All developers don't have to create a new package for their Android apps everytime a new Android version is released.
This is different from linux distros.



Don't argue with me about OpenGL. I write graphics software for a living. I've ported my OpenGL code to OpenGL ES 1.0 and 2.0, and know exactly what I had to change for it to work. Which is what I based my previous statement on.
For example, OpenGL ES 2.0 does not have any fixedfunction pipeline anymore. It can only use shaders. And these shaders use a slightly different dialect of GLSL, with keywords that regular OpenGL does not support (google around to see how people try to find solutions with #defines and such to make the same code compile on both OpenGL and OpenGL ES).



No, because Google knows the value of backward compatibility and having a stable binary platform. It is popular because it is easy for developers to develop for, and easy for users to install software for. Although it is not quite as userfriendly as iOS though, and as such, not quite as popular.

You can ship your game with bundled libraries or statically compile the libs in the binary itself. Problem solved.

[Scali]

Mate, you just have forgot a shite of patches and changes. How many .net versions were released ALONE?
Windows is just as changing as Linux. Because its either this - or death from exploits.
The only difference between the two is that linux does not keep older versions around, together with all expoitable code.
And versions, that are straight easy to abuse, are patched - with lots of win* software getting BROKEN.

You are missing the point! It is not about how many patches and changes are released, it is about how they may or may not break existing software.
Also, .NET is a platform of its own. It has no effect on any native Windows software.

Quote from WINE: Bug-per-bug compatibility.

Aside from Wine not exactly being the most objective source of information... it is common knowledge that Microsoft actually maintains certain quirks for compatibility reasons. I suggest you read some of Raymond Chen's blogs: http://blogs.msdn.com/b/oldnewthing/
Again, the point is: backward compatibility

Unlike Windows, Linux does not use outdated versions, but only ONE version - that is CURRENT STABLE version.

Oh yea, everyone uses the exact same version of the exact same linux distribution with the exact same updates. Oh wait, they don't!

When newer version is released, applications that depend on it are required to UPDATE. This is constant unavoidable process.

Of course it is avoidable. Most platforms avoid this. That's the whole point. Linux is a crappy platform to develop for because it is one of the few platforms that doesn't put any effort in compatibility.

Code always changes, it is a process.

Changes don't have to break compatibility.

This is why Linux is much less susceptible to exploits - it carries no cruft around.

Lol, no it's not. Do you actually believe the shit you're saying?

Common, next talk how wonderful registry is, and how Linux looses here

No, let's talk about how linux advocates can't take any criticism and always start bashing Windows. This isn't about Windows, this is about linux, and how it is not a stable platform to develop for. The Windows registry is completely irrelevant in this discussion.
Windows itself is completely irrelevant in this discussion, aside from the fact that it is an example of a stable platform. But we could easily ignore Windows, and use another example of a stable platform. Such as Android.

I think this sentence is the epicenter of the misunderstanding.

What misunderstanding? That I am a professional developer, and you are just some loudmouth linux fanboy with no professional development experience whatsoever?

In Linux, you keep an eye on current library versions, and just release newer versions of your software when updates are needed. You don't care about "most common version" at all, or at least, till someone pays ya for "voluntary" port.

The point is: you should never even have to make ports for various versions. Write once, run anywhere.

There are only situations, where you will need to "reinvent the wheel" as you say - but more exactly: to remake the package

Package once, run anywhere. By your own admission this is not possible.

In short, you used your freedom to deviate from world's defaults.

The world doesn't have a default, that's the whole point.

No you can't. Unless Google has secured services of Emmett Brown. Please reread my sentence.

Yes you can. Older Android packages can be installed as-is on newer versions of Android. Stop arguing about things you don't even have a clue about.
I have written Android apps myself, and I have installed stuff I developed for 2.3 on 4.0 without making any changes to the package whatsoever.
This is what happens with most Android apps in the Google Play store. They just work. In fact, I wouldn't be surprised if a lot of apps haven't received an update since 2.3 was the current version.

On contrary, if you are a programmer (and not a coder), you MUST babysit your software.

That's not the same thing.
I 'babysit' my code in the sense that I test it whenever a new platform comes out.
However, that does not mean that I need to make changes. At least, not in the general case. Linux is different.

Glad to hear you are gfx programmer, but I fail to understand what does this have to do with questions we argue about...

I know you fail to understand it. But I've explained it, so the rest is up to you.

Also, note they have cut backwards compatibility to ES 1.0. Looks like they have learned from OpenGL3, and adopted Linux approach instead? That is, breaking stuff now, instead of making it decay here till the rest of the days.

Well, they were trying to adopt the Direct3D approach: new hardware us newer interfaces.
However, they messed it up, and in the end they just continued using the old interface, but with various functionality taken out.
Which is indeed similar to the linux approach: a very poor one. The OpenGL API has become a monstrosity.

[Scali]

And lastly,regarding Carmack, you have reversed implication and made a logical mistake.

What reversed implication? Be specific.