Day: GNOME OS [LWN.net]

Day: GNOME OS

Posted Aug 8, 2012 7:46 UTC (Wed) by epa (subscriber, #39769)
In reply to: Day: GNOME OS by cmccabe
Parent article: Day: GNOME OS

I understood the SDK partly as meaning they plan to stop breaking compatibility every couple of years. This blog post from Miguel in 2008 comes to mind: http://tirania.org/blog/archive/2008/Jul-15.html

Now this is a good intention, but you know what they say about those... It seems to be saying 'never mind all the past compatibility we have broken and the older code we are no longer msintaining - it will be different in future!' Which does not have a lot of credibility, since actions speak louder than words. It would be better to undo at least the more recent breakages (say, by continuing to actively support GTK2) rather than rush forward to yet another new rewrite cycle with the promise that this time things will be different. Who can say whether four years from now the developers will not have forgotten? Keeping compatibility is something you need to practise on a small scale from day to day, as the kernel developers do, not something you can simply declare to happen in the future while ignoring the present and recent past.

(Log in to post comments)

Day: GNOME OS

Posted Aug 12, 2012 13:39 UTC (Sun) by khim (subscriber, #9252) [Link]

It would be better to undo at least the more recent breakages (say, by continuing to actively support GTK2) rather than rush forward to yet another new rewrite cycle with the promise that this time things will be different.

This is not always possible. GLibC is one of the most stable pieces of Linux stack - yet it was broken horribly in Libc5-to-Libc6 (AKA GLibC 2) transition.

The fact that incompatible GTK 3.0 was ever released is a shame because GTK2 itself was pretty stable, but when you want to create stable ABI then often it's better to throw away existing unstable ABI and create a new one from scratch because ABIs designed to be stable and ABIs designed to unstable and efficient are fundamentally different. If your ABI is supposed to be evolving then you only pass the information you actually need around because you can always add missing pieces later. If your ABI is supposed to be stable then you pass more data then you need today because you are not sure if it'll be needed later or not. And this is just the tip of the iceberg.

Day: GNOME OS

Posted Aug 14, 2012 2:05 UTC (Tue) by paulj (subscriber, #341) [Link]

The Linux libc5 to libc6 breakage was not GNU libc being unstable. libc5 was not GNU libc, GNU had nothing to do with its development. Libc5 - "Linux libc" - was a separate code-base (an old fork of a much earlier GNU libc, apparently).

Day: GNOME OS

Posted Aug 14, 2012 17:41 UTC (Tue) by khim (subscriber, #9252) [Link]

You nitpicking is correct - but pointless. Many former libc5 developers are GLibC 2.x developers today. And the fact that they decided to pick up the GLibC 2.0 to use it as Linux libc (instead of trying to stabilize libc5) proves my point: they broke compatibility at least four times in a short while when Linux libc was developed as a fork but then they decided that they want to stabilize ABI and they were able to do this with a switch to GLibC.

Stable ABI is less of a technical phenomenon and more of a social phenomenon: if you want to have stable ABI then you must plan for the stable ABI and if you don't plan for the stable ABI then usually ABI can not be safely frozen.

Good example are Linux kernel developers: they are often accuses in various vices because they don't keep internal Linux ABI stable and usually people say that this happens because these guys just don't know how to program in general and how to program stable ABI in particular but these critics often forget that these same guys are designing and supporting kernel<->userspace ABI which may be not perfect yet is quite stable.

If you want to change a library and stabilize it's ABI then often the only sensible way to do it is to break it's ABI "just one last time".