| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 12, 2012 13:39 UTC (Sun) by khim (subscriber, #9252)In reply to: Day: GNOME OS by epa Parent article: Day: GNOME OS
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.
(Log in to post comments)
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".
|
|||||||||||||