Quotes of the week
Posted Aug 31, 2012 9:32 UTC (Fri) by ebassi
In reply to: Quotes of the week
Parent article: Quotes of the week
quoting myself from a comment on a different thread
that is definitely not what I was asking, and that's not even an answer in this specific context.
I'm talking about ABI and conformance for third party software, not performance.
given that I wasn't clear: let's assume for a minute that a fairy on night gave us an internal ABI for the core platform (libraries and applications) and an external ABI for the rest of the core platform consumers (i.e. developers); this split allows us to have the core platform moving without breaking third party applications ever: if something breaks in the internal ABI, it will be fixed on the gnome.org repository by the author of the change. mostly like how the kernel works.
now, what are the side effects? we effectively have two libraries, one for the internal and one for the external ABI. do we load twice the amount of shared objects? I mean, apparently Enlightenment convinced everyone that it's fine to have a bajillion DSO, as long as you keep repeating that it's fast (hint: it's really not, and anyone with a minimal understanding of how kernel and linkers work knows this), but I don't think it'll scale. do we compile stable and unstable symbols in the same shared object? that works, but it requires re-linking the entire planet because you really want to bump the SONAME so that applications using the internal ABI can actually be updated; if you bump the SONAME, though, applications linking against the external ABI will also need to be relinked, otherwise they won't be able to find the shared object - look at all the apps linking against boost, and breaking after 12 months because nobody ships the old version of boost they use any more.
so at this point third party apps are in the same situation as they are now, even if they use a supposedly stable ABI. what should they do? dlopen() the shared object? fun times - ask any GL developer how that works out - and it does not scale with a shared library of 5000+ symbols or more. ISVs tried to do that with gtk+ multiple times, it didn't work.
but all of this assumes that the ABI is just a bunch of functions - which is not the case in an object oriented environment like GNOME. if we have two ABIs, where does subclassing a GtkWidget live? the internal ABI, that we can break, or the external one? we cannot really change the size of structures in an ABI-compatible way, so it'll have to be in the internal ABI, for core libraries and apps; though that means that external libraries and applications won't be able to create their own third party widgets unless they use the internal ABI - which is utterly broken, because applications need to define their own widgets, as GTK+ cannot possibly ship all possible widgets needed by all apps for all eternity, and do that even before the apps have been written; and in some cases third party apps are closed source, so the authors cannot put their widgets inside an open source toolkit. the whole "non derivative work" status of some kernel modules is still pretty fuzzy, I don't think people want that fuzziness to extend to user space as well.
it's always easy to assume that people outside of your restricted area of interest are assholes that do not understand the problem space, especially if you spent about 15 minutes to think about it. I can assure you: we people working on the GNOME core platform discuss this shit all the time. there is simply no good solution, or good enough solution yet.
after reading the comments in Miguel's blog post I have to say, though, that it's always cute how kernel developers think they can solve the user space problems using their limited perspective, like they are the second coming of Jesus Christ; it does take its toll, though, given that we have to explain all this basic software engineering and release management stuff all the time. you'd think they'd get it.
to post comments)