One thing that might be interested to start doing in Gentoo to improve the users’ experience is to start playing with hidden visibility.
While I’ve already written before that hidden visibility is risky for most libraries unless upstream predisposed them to be used with hidden visibility (xine, most recent GNU libraries excluding glibc), it is usually a no-problem for final executables, as they aren’t supposed to export symbols at all, most of the times at least (there are some cases where binaries export symbols that they want to override from other libraries, like the C library or stuff like that).
Users should not play with -fvisibility=hidden flag as that might break badly; but we developers should know better. It woudl be nice to check if we’re using GCC 4.0 or later (you don’t want to use hidden visibility with older compilers), and then append the flag, for software we know is compatible with this. This software usually includes final executables (no shared objects) and static libraries (which usually should be linked without exporting the symbols, as otherwise you might end up breaking stuff badly, if two shared objects link two different versions of the same static library).
By using hidden visibility we should be able to reduce the amount of possible symbols’ collisions, we might be able to reduce the size of the applications, and finally we reduce startup, as the binary’s symbols are not resolved at runtime by the dynamic linker.
This combined with --gc-sections should also mitigate the problems caused by mishandled commodity libraries. The sad note is that using this my script won’t be able to identify the two problems anymore. I’ll have to upgrade it to use dwarf data one day or another.
On a few technical notes, I’ll have to rewrite the script not to sue sqlite but PostgreSQL instead; SQLite is way too slow and seems to waste too much space even handling my quite reduced set of 1006 packages, I don’t want to know what might happen to Patrick’s box if he runs it over the extracted binpkgs of his tinderbox. This will use up some of my free time during the week, but having it ran on a huge amount of packages might really help finding more cases like the ones I already documented and opened a bug for.
Considering that this is eating up the little free time I have at the moment (I can’t remember last time I had time to lay on the bed watching some good anime), I’d quite like at least some feedback from users, not only from developers 🙂 – especially considered the amount of ranting we have witnessed in the last weeks about developers not talking to users enough… I always ask for feedback but rarely get any!
Also my Sony Reader should arrive soon, so I’m considering the idea of buying something from O’Reilly to start looking at things I don’t know yet about; if somebody read those before, I’d gladly take suggestions: Linux System Programming by Robert Love (well, not an area where I know nothing, but it might be interesting to see if Love has any suggestion there that we don’t widely apply yet), Postfix: The Definitive Guide (I know nothing of postfix, so this seems a decent start, and I want to know about it as I’m using it on this server for the xine bug tracker), and CJKV Information Processing (I don’t speak any of those languages, unfortunately, but I find those problems interesting, as they reflect on a smaller scale for Italian and most of european languages too).