Ubuntu Still Talking About A Stable App API/ABI

[zxy_thf]

It looks like we're between a rock and a hard place here because:
A changing ABI is just unrealistic for most communities -- they really don't have so many people to maintain all the programs, packages when something changes to update them to the new ABI, API.

For API you might be correct. But ABI is another thing.
For example, C++ programs/libraries have different ABIs across different compilers.

[Thaodan]

I don't like the therm Ubuntu platform.

[rdnetto]

It's pretty clear what Ubuntu is thinking about - the people who benefit most from a stable ABI are closed source software vendors. All the open source packages are unaffected, because they can just publish the source code and let someone else (i.e. the distro maintainers) worry about recompiling it.

Note that this is part of the reason Steam uses its own set of libraries. Actually, using the Steam Runtime as the base for distro independent libraries could be quite a good way to go about this, especially given that there's already quite a few games using it and most distros have found ways to support it. I'd be surprised if they took this approach though, given their tendency to do things their way.

[dacha]

For API you might be correct. But ABI is another thing.
For example, C++ programs/libraries have different ABIs across different compilers.

Code in a managed language like Java or .NET only has one ABI across all architectures and operating systems, and the runtime is the one worrying about that, not the application. API compatibility between versions is also radically easier, eg. adding a method to a new version of class won't break the users of the old version of that class no matter where the method is added, whereas in C++ the ordering of methods in the vtable can make it incompatible.

While desktop distros seems to insist on using native code, there is a reason Android uses a lot of Java .

[anda_skoa]

well basically is really hard to accomplish, basically you have to freeze every library that will be exposed to devs forever and to reach ABI stability you cannot allow any new symbol to be exposed at runtime carelesly or the linker will throw exception due to undefined symbols in the binary.

Not necessarily.
Most of the libraries have API and ABI stability goals themselves, e.g. do not change API or ABI compatibility within a major release cycle.

The only thing they would need is an easy way for developers to build against the target version even if the current version is newer, in order to avoid new symbols slipping into programs on build.

The LSB has developed tools to check for ABI invariance in libraries, so Canonical could use those to ensure compatibility for their set.

Cheers,
_

[Mickabouille]

eg. adding a method to a new version of class won't break the users of the old version of that class no matter where the method is added

Thinak about : (java, for C# i don't know) adding a method to an interface or adding an anstract method to a (n evidently abtract) class.
Any implementer or inheriting class is automatically broken.
That's what "defender methods" are added for Java 8 (part of lambda). But that's evidently not usable yet (and won't be for some time in android where JDK6 is still officially required).

[dh04000]

It's pretty clear what Ubuntu is thinking about - the people who benefit most from a stable ABI are closed source software vendors. All the open source packages are unaffected, because they can just publish the source code and let someone else (i.e. the distro maintainers) worry about recompiling it.

Actually, the biggest winners would be USERS, because they could be reassured that the application they used last year will work this year...... which is sadly not the case for many applications.

[Pajn]

"Forever" is stupid, a smart promise is like 5-15 years.

When talking about software forever usually means somewhere between 5-15 years.

[jrch2k8]

Code in a managed language like Java or .NET only has one ABI across all architectures and operating systems, and the runtime is the one worrying about that, not the application. API compatibility between versions is also radically easier, eg. adding a method to a new version of class won't break the users of the old version of that class no matter where the method is added, whereas in C++ the ordering of methods in the vtable can make it incompatible.

While desktop distros seems to insist on using native code, there is a reason Android uses a lot of Java .

that will propose a very nasty performance hit to most application since to reach that level of stability the JIT systems have to either generate everything needed for an app on the fly at runtime or have some massive service at boot generating binaryish executable/libs after checking all possible dependencies are compatible every time.

in the case of android they freeze their java base code for an entire release to achieve stability[most phone/tablet OSes do the same]

[dh04000]

Fuck the users! The conspiracy theorists must be left to run amok! Do you actually mean that Canonical isn't hellbent on destroying FOSS? Do you realize the implications of your statements?

This is the first one of your posts BO$$ that actually made me laugh!