Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register) [LWN.net]

Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)

Posted Jul 17, 2008 19:49 UTC (Thu) by jordanb (subscriber, #45668)
In reply to: Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register) by drag
Parent article: Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)

Breaking ABIs is no big deal. It's just a recompile. I agree that breaking APIs can be a
problem, but the guy's argument is to consider breaking them once every *five years*, and
doing so with a major version rev. The move from gtk+1 to gtk+2 wasn't particularly painful.
Gtk+2 came out and everyone had many years to upgrade while the distros continued to maintain
gtk+1 in their repos. The only projects that didn't make it were the ones who had long before
died for other reasons (like xmms).

Miguel seems most worried about proprietary software vendors *wipes tear from eye* and that
they're considering taking out code that was *really hard* for him to write back in the good
'ole days. The Mac stuff is a complete ad hominem too. I don't like the trend towards mac
usage, but Miguel doesn't offer any credible link between the proposal for a gtk+3 and the
fact that the developer was using a mac laptop.

(Log in to post comments)

He's right

Posted Jul 17, 2008 22:07 UTC (Thu) by khim (guest, #9252) [Link]

Breaking ABIs is no big deal. The fact is: you can not. Microsoft breaks the ABI, Sun breaks the ABI - even if they spend billions trying to support it. ABIs are fragile. They break easily. The only 100% fool-proof way to keep the ABI unbroken is to use the same binary. That's what Windows is doing - and it pays for it dearly.

The last sentence of cited article says it all: There are many famous examples in Win32-land where programs depend on bugs within the runtime, I claim that similar mistakes are strictly and significantly easier when source code is available. With FOSS such things are easy to create but equally easy to fix: if RPM refuses to work with GlibC 2.1 since it used some internal structures in GLibC 2.0 - it's trivial to recompile it. When some program does not work with new version of library in binary world - you are starting to add layers of emulation upon another layers of emulation. The end result is huge, unreliable, bloated mess. Like a Windows Vista. And there are no way to fix that. With source code there are at least hope...

He's right

Posted Jul 17, 2008 23:31 UTC (Thu) by zooko (subscriber, #2589) [Link]

I'm curious about your claim that Sun breaks the ABI.  I've often heard pro-Solaris folks make
comments like "Programs written for Solaris 2.5 thirteen years ago still work on Solaris 10
today and will continue to work on future versions of Solaris.".

But I don't see any sort of measurement or documentation of this on the web.  Do you know of
some examples of Solaris ABI breakage?

Thanks.

Speaking of solaris 2.5

Posted Jul 19, 2008 11:17 UTC (Sat) by k8to (subscriber, #15413) [Link]

Solaris 2.5.1 changed an environment variable export put out by the x library implementation
that provided a path to where various X resources were located.  Prior to 2.5, this
environment variable existed.  With 2.5.1, the variable was removed.

There were probably (other) portable ways to locate the resources, but Sun maintained that it
was not an interface change.  Basically, to them, ABI meant only the entry points.

So it all depends on how literally you want to treat things.  My experience is that they not
only break the interface, but they obtusely pretend they have not done so.  Others may have
had better experiences.  I haven't played with Solaris for a while.

Only if you payed attention to the ABI rules

Posted Jul 24, 2008 13:31 UTC (Thu) by alex (subscriber, #1355) [Link]

There are plenty of old Solaris applications out there that didn't follow the official library
ABI, and they will break when running on Solaris 10.

It's interesting the way Sun keep ABI compatibility. Basically nothing in the kernel is
guaranteed, all access to the kernel goes through the stable SUN/POSIX ABI in the libraries.
If applications follow the library ABI then all is good. This also allows Sun to tweak their
kernel layer and then apply fix-ups in the library.

It's in stark contrast to the Linux approach which has shifting internal kernel API's and
library API's but a solid syscall ABI. If you dig up statically linked a.out file from years
ago it will run fine on a modern 2.6 kernel.

Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)

Posted Jul 17, 2008 22:02 UTC (Thu) by bronson (subscriber, #4806) [Link]

> The move from gtk+1 to gtk+2 wasn't particularly painful.

Sure it was.  We lost Dillo, qiv, xmms, and a few other excellent utilities. I'm sure we lost
a number of good developers too.

Did you write much code against GTK+-1.0?  If you had, maybe your memory of the pain would be
a bit more acute?

The 1.0->2.0 API breakage was well planned and quantified in real code.  It was painful but it
was worth it.  Today, since no GTK-3.0 code exists, all this "break the API" discussion is
pure speculation.  And breaking the API merely to remove some deprecated interfaces?  You
gotta be kidding me!

Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)

Posted Jul 18, 2008 1:24 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link]

> Sure it was.  We lost Dillo, qiv, xmms, and a few other excellent 
> utilities.

I'm still using all 3 of these! I'm not sure "lost" is the right word - in that they haven't
actually stopped working.

Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)

Posted Jul 18, 2008 7:48 UTC (Fri) by seyman (subscriber, #1172) [Link]

> I'm not sure "lost" is the right word

I think Bronson means "lost" in the sense that development of those apps stopped once gtk+1's
did but even then, I'm not sure he's right. We "lost" xmms a long time before we moved from
gtk+1 to gtk+2.

Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)

Posted Jul 18, 2008 13:51 UTC (Fri) by colinleroy (guest, #40525) [Link]

The move from gtk+1 to gtk+2 wasn't particularly painful. Gtk+2 came out and everyone had many years to upgrade

Were you developing a GTK+ software at the time? If it took many years to upgrade, it was because developers were busy rewriting working code to switch to GTK+2, because it was clear that GTK+1 was going abandoned.

Breaking APIs and removing deprecated stuff for the sake of the embedded developers (the ones that do sponsor GTK+ development these days) is going to be just more of the same for developers of software that already has a lot of code, including deprecated code.

I'm not particularly fond of rewriting whole parts of my apps every few years just because a new widget is the new hotness and the one that existed when I coded my stuff is now deemed crappy and unmaintained.