gnome-hello

[Mike Hearn]

George Kraft wrote:
> One OS on one hardware architecture is easier than 100+ GNU/Linux 
> variants on a dozen different architectures which are built on
> infinite possible permutations of upstream open source packages.
> The API/ABI must be precisely specified for binary application
> stability.

Actually Windows isn't one OS. It's many, many subtly different
variations on the same theme: ensuring that a program which worked in
Windows 98 still does on XP is a very tricky thing which takes large
quantities of manpower at Microsoft. They aren't all busy writing specs,
as they already attempt to maintain perfect compatibility. They are
finding out what apps really do, and finding out why they stopped
working. They already have an ABI spec in terms of the documentation,
but that isn't enough.

> If you are depending on "what bugs shine through the interface", then
>  you are not writing portable code and your binary will definitely
> not be compatabile from release to release or distro to distro.

Unfortunately experience with many apps (random example: Sim City) is
that people write buggy code often without realising it until years
after the fact and they found themselves depending in subtle ways upon
implementation details. To run these programs did not require "any
libfoo.so.X compatible library", they actually *required* that library.

A recent example in the Linux world would be the construct-only params
change in GObject which broke amongst other things gnome-panel and the
GTK Perl bindings. Nobody knew about these "bugs" until the change had
been made, at which point programs had been broken.

These are extreme examples but I hope you see my point. An ABI spec does
not allow you to maintain perfect compatibility, though we all wish it did.

I do not know what the solution is, as it's unlikely open source
maintainers would ever be willing to delay bugfixes or put short term
hacks into their code to maintain app compat, even when those hacks
could be removed at the next major version bump. Likewise, a spec that
gives exact versions of exact codebases seems too restrictive. I guess a
middle ground is the best possible.

To save two emails, I'll reply to this as well:

> They are not the same, because I cannot go into CompUSA to buy a
> GNU/Linux application then take it home and just install it.   What
 > would be the system requirements?

OK, so it's not CompUSA, but you can buy or download binary portable 
Linux software today in quite a few different web stores, eg tuxgames, 
codeweavers.com,  skype.com, Opera, etc etc

Typically their requirements go something like:

- Any glibc 2.2 or higher distro
- An X server

and sometimes

- Qt 3.1 or GTK >2.0

And this works, though it's not ideal and it's not as robust as we'd 
like. So, I'd say they clearly are the same OS - otherwise it wouldn't 
work, right?

Unfortunately things that commonly break aren't really under the control 
of the LSB anyway, for instance shell scripting tools (already specified 
by POSIX but a lot of scripts were broken by POSIX compliance 
improvements in recent revisions), kernel behaviour like 
LinuxThreads->NPTL/execshield, and bugfixes to binutils that happen to 
break stuff as well like the one which broke old static binaries on the 
grounds that they were produced by a buggy version of binutils.

Short of mandating "the LSB version of tool X may not contain bugfix Y" 
at which point you're specifying implementation details anyway, I don't 
see how to solve issues like these.

thanks -mike