So with GCC 4.4 and glibc 2.10, C++ support went, once again, stricter. Now, leaving aside all my possible comments on a language for which there is still an absolute vacuum of actual implementations years after publishing, let just look at what the problem is this time around.

The main issue, in which glibc 2.10 is also related, is that the C-style string functions now return pointers with the same constant modifier as they are given; so if you look for a characters in a constant string, it’ll return a constant string pointer, and vice-versa if you give it a variable string, it’ll return you a variable string pointer (more here if you’re bored).

This means that the following code will build fine with either GCC 4.3 or glibc 2.10 but will fail when both of those (or more recent) versions are used:

#include <cstring>

int main() {
  char *foo = strchr("ciao", 'a');
}

% g++-4.3.3 test-const.cc -o test-const    
% g++-4.4.0 test-const.cc -o test-const 
test-const.cc: In function ‘int main()’:
test-const.cc:4: error: invalid conversion from ‘const char*’ to ‘char*’

The error from the compiler is quite real: you’re mixing up different type of variables, although in this particular instance you’re not doing anything wrong with it, but for instance take the following code rather than the one shown earlier:

#include <cstring>

int main() {
  char *foo = strchr("ciao", 'a');
  *foo = 'e';
}

This code is trying to change something that it shouldn’t; in particular, given the pointer is now pointing inside a literal, which is then inside the .rodata section of the ELF and in a shared, non-writeable area of memory, when executed this will cause a segmentation fault (a crash, for those not used to this terminology). But it can get less obvious and more sneaky, since instead of a literal, you could have a parameter, declared constant.

Of course, whenever you have a variable or a parameter that is declared constant, but is not actually residing in read-only memory areas (like .rodata), you’re just a cast away from having it non-constant. But then you’d be seeing the cast, and that would be like a yellow light sign. On the other hand, with the old method of just having the function cast away the constant modifier, it was less obvious at first sight.

Okay so we know what the problem is, why the error was introduced, let’s go down to business with what the problem is. I have seen more than a few patches out there that, to make software build on GCC 4.4/glibc 2.10 simply cast away the constant modifier, C-style:

#include <cstring>

int main() {
  char *foo = (char*)strchr("ciao", 'a');
}

This is wrong. You should not do that. Why? Because you’re hiding a problem; in more than half the cases, the solution is simply to change the declaration of the variable:

#include <cstring>

int main() {
  const char *foo = strchr("ciao", 'a');
}

Of course, this does not cover all the cases; there are a few when the pointer is actually used to change memory areas. In those cases, since fixing the issue might be overkill, I’d highly suggest a different syntax:

#include <cstring>

int main() {
  char *foo = const_cast<char*>(strchr("ciao", 'a'));
  *foo = 'e';
}

This uses the explicit const_cast keyword from C++, and the very fact that it’s an eyesore in the code should be enough to scream “Workaround!”, which is what it is in truth.

So please, don’t just cast it away C-style, give it a bit more thoughts, please!

Christian Ruppert (idl0r) asked me today whether --as-needed makes software faster or smaller. I guess this is one of the most confusing points about --as-needed; focus of tons of hearsay, and with different assertions all around the place. So I’ll do my best to explain this once and for all.

In perfect conditions, that is, if --as-needed were not doing anything at all, then it wouldn’t be changing anything. The flag is not magical, it does not optimise the output at all. The same exact result you would have if libtool wasn’t pushing all crap down the line, and if all the build systems only requested the correct dependencies.

When it does matter is when overlink is present. To understand what the term overlink refers to check my old post that explains a bit what --as-needed does, and shows the overlink case, the perfect link case, and what really happens.

Now, of course you’ll find reports of users saying that --as-needed makes software faster or smaller. Is this true, or false? It’s not easy to answer one straight answer because it depends on what it’s happening with and without the flag. If with the flag there are libraries loaded, directly and indirectly, that are not used (neither directly nor indirectly), then the process spawned from the executable will have less libraries loaded in the address space, and thus both be faster to load (no need to read, map in memory, and relocate those libraries) and smaller in memory (some libraries are “free” in memory, but most will have relocations, especially if immediate bindings (“now” bindings) are used, like happens for setuid executables.

Indeed, the biggest improvements you can have when comparing the with and without cases in a system, or in software, that uses immediate bindings. In that case, all the symbols from shared objects are bound at load, instead than at runtime, so the startup time for the processes are cut down sensibly. This does not only involve hardened systems, or setuid binaries, but also applications using plugins, that may be requesting immediate bindings (to reject the plugin, rather than aborting at runtime, in case of missing symbols).

Seems like even my previous post about PulseAudio got one of the PA-bashers to think I’m a nuisance for their “cause”, whatever that is. For this reason I’d like to try to explain some of the quirks regarding PulseAudio, distributions, quirks and so on. Let’s call this a bit of a backstage analysis of what’s going on about Linux and audio, from somebody that has little vested interested in trying to roll the thing for PulseAudio.

The first problem to address relates to the comments that KDE people find PulseAudio a problem; I guess this has to be decomposed in a series of multiple problems: Lennart is a GTK/GNOME guy, so he obviously provided the original tools for GTK/GNOME. For a while I was interested in writing the equivalents for KDE (3) but I never had the time; now that I also moved to GNOME independently, I sincerely have no intention to write KDE tools for PA… but one has to wonder why nobody in KDE went out of his/her way to try doing this before. It’s not like it had to be part of KDE proper, it would have been okay to be an unofficial standalone application.

There is also another problem: most of the KDE guys who do see problems with PulseAudio are most likely using Phonon with xine-lib backend, configured to use the PulseAudio output plugin. Given I’m the one I wrote most of it originally, I can say that it sucks big time. Unfortunately I have had no time to work on that lately, I hope I might have that time in the future, but the two years I spent between hospitals seriously indebted me to the point I’m doing about 18 hours of work a day on average. For those who do want to use xine-lib with Pulse, I’d like to suggest the long route: set up the ALSA Pulse plugin, and then let xine just use ALSA.

There is of course another problem for KDE: while GNOME historically had no problem with force in dependencies that are Linux-specific or that work most of the time just on Linux (think about HAL adoption for instance), and relied on the actual vendors to do the eventual porting, KDE strives to work most of the time on multiple operating systems, including as of KDE 4 also Mac OS X and Windows. Now you might like this or not, but it’s their choice; and the problem is that while there is some kind of PulseAudio support for Windows, at least OSX is pretty badly shaped (also on my radar).

For what concerns distribution support, it is true that Lennart usually just care about Fedora; you have to accept this as part of the deal given RedHat is – as far as I know at least, Lennart feel free to correct me if I’m wrong – the one vendor paying his bills. Now of course we’d all love to support all the distributions at the same time, but the only way that’s possible is if multiple maintainers do coordinate; I’ve been doing my best to pass all the patches upstream when I’ve added them to Gentoo, and I see Colin Guthrie from Mandriva doing the same. One thing I can “blame” Lennart for (and I told this to him before, too!) is not creating a GIT branch with the cherry-picked patches he applies on the Fedora packaging for us to pick up… and the fact that he doesn’t like neither making releases or leaving access to others to do so.

To be honest, there is little different in this from what other projects do with distributions like Ubuntu when they are paid by Canonical. I think this is obvious, everybody looks at their little garden first. But this is not something that should concern us I guess. Gentoo has been quite out of the loop for what concerns PulseAudio, and I’m sorry, that was mostly my fault. I’m doing my best to let us update as soon as possible, but it’s not just that simple, as I already explained .

Then let me just say something about Lennart’s refusal to support system mode (which is available and advertised in Gentoo since PulseAudio entered the tree): I can’t blame him for that. First, his design for PulseAudio is based on providing something that works for the desktop use case. Something along the lines of Windows’s or OSX’s audio subsystems, neither of which provide anything akin to system mode. And indeed PulseAudio, by design, can handle the same situations, including multi-user setups with fast user switching. The fact that a system mode exists at all is due to the fact that I for one needed something like it on my setup, hacked it around for Gentoo, and then Lennart made my life easier implementing some extra bits on PulseAudio proper, but it was certainly not his idea.

What people complain about usually is the need for an X session (not strictly true, PulseAudio will start just fine in SSH — it would probably be possible to even fix it up so that it would tunnel audio just like you can tunnel X!), and the fact that audio does not continue to work when X exits (also not strictly true, if your audio player is running in screen it would be working just fine; it’s the fact that the media player crashes that makes your audio stop). Additionally people complain about the security problem of wanting to have all the processes to run under the same user, rather than allowing them to be on different users, like mpd.

Well, some complains are valid, other are not: it is true that PulseAudio does not work in multi-seat-multi-user environments, at least not with a single audio device, it is unfortunate and I don’t know if it’ll ever do work in that situation without a system mode. It is also true that running processes as different users for privileges separation does not work without system mode. But both these options are walking quite away from the the desktop design that PulseAudio is implementing; sure they are valid use cases, just like embedded systems (Palm Pre uses PulseAudio if you didn’t notice that before), but they are not what Lennart is interested in himself; at the same time I don’t think he’d be stopping anyone to improve the system mode support for those, as long as it wouldn’t require the desktop setup to make compromises.

Because the idea is, as usual in any software design, the one that you have to take compromises; Lennart wants the best experience for what concern desktop systems, and he compromises that system mode is not part of his plan, and it shouldn’t be hindering him. At the same time, while he does get upset when people ask for support about it, and he wrote why it’s not supported he hasn’t removed it (yet — if I was him, at this point I could have just removed it out of spite!). So colouring him as the master of evil does not seem the very best idea — and especially that makes me picture him in the part of Warren in the Trio, from Buffy’s season six.

Oh and a final note: it doesn’t have to surprise that Lennart and Fedora don’t care about running mpd and other services as different users, there are probably quite a few reasons for this. I cannot speak for Fedora, given I’m not involved in it, but my suppositions are that firstly the ALSA dmix plugin is somewhat scary from a security point of view (for me too) because it uses shared memory between processes from different users to do the mixing, and the second is that Fedora does a lot to use SElinux even on standard desktops. This is much tighter than separating privileges with different users since it forces the processes to behave as instructed. Unfortunately on Gentoo the SElinux support seems to have gone for good, at least to me.

Just when I said that I was resuming my work as a PulseAudio maintainer in Gentoo, Lennart released a 0.9.16-test1 tarball. This was my cue to enter the scene upstream: the first test at packaging this in Gentoo failed, for a series of different reasons, some of which are internal (we don’t have the latest version of udev available yet, I hope we will by the time PulseAudio 0.9.16 final is releasd), but most are due to upstream changes that didn’t take into consideration some corner cases that Gentoo, as usual, gets to deal with.

So you won’t see the test1 (rc1) ebuild in the tree at all, you’ll probably have to wait for test2, and even that will require some work. For now I’ve fixed all the build- and run-time issues I’ve seen in the released tarball and git repository; plus I’ve been able to get it to properly build fully on both (Gentoo/)FreeBSD and OpenSolaris (with Prefix). I haven’t been able to experiment with actually having it playing yet, but it’ll come there at one point.

Unfortunately there are still a few shady details that I or someone else has to take care of. For instance, the tests still fail consistently: last time I tried them I got two failures on Yamato, one related to IPv6 enabled in PulseAudio build, but not enabled for the kernel, resulting in the IP ACL test asseting out (now I’ve fixed it, by warning of the case, and ignoring it as a failure); the other is the mixing test, which fails for everybody because it doesn’t know anything about the 24-bit and 24-bit-in-32-bit sample types; this I extended to support 24-bit, but was unable to do anything about the 24-bit-in-32-bit because I couldn’t grok it properly.

On non-Linux operating systems (FreeBSD and OpenSolaris), I had to work on a few more issues, like implicit declarations (there still is one in OpenSolaris), shadowed names, and of course there is some slight porting to be done, which I have nowhere near finished yet: the shm (Shared Memory) support in FreeBSD is imperfect, and for neither operating systems I’ve implemented the “get process name” function.

Okay I’m not able to provide a 100% porting to all the operating systems out there, but I still think I can do a bit to help out by making sure that PulseAudio won’t need to be extensively patched by all the porters out there. And until Lennart actually gets around merging my patches, you can find all them at gitorious so you can test them.

Thanks to Betelgeuse I finally have audio again on Yamato (again, thanks! — on a different note, this actually made me find out that there absolutely is a bug in ALSA that causes mmap to kill PulseAudio both with the ICE1712 and the HDA drivers), so I’m resuming my duty as PulseAudio maintainer. This is the reason why PulseAudio jumped to version 0.9.15-r50 in ~arch. So what’s up with that?

My current plans in respect to PulseAudio are trying to get 0.9.15 in stable to replace the ancient 0.9.9. What has stopped PulseAudio to go stable up to this point has been exactly two dependencies: OpenRC and libtool 2.2. Originally, the idea was to keep PulseAudio only compatible with OpenRC and no longer with baselayout 1; it was supposed to go stable pretty soon and the baselayout 1 init script was so scarily incomplete that we simply preferred not have to support it.

Unfortunately, there is still no date for OpenRC to go stable, if it’ll go at all in its current form. At the same time, Lennart has seriously warned against system wide mode (even though there are still valid use cases for which Gentoo often is used!) so keeping the new versions off from stable for a “minor” feature that is not even recommended to be used sounds like a bad plan.

For this reason I’ve now split the ebuild in two versions: one will keep the system mode support, with the system mode warnings, the init script and all the niceties, and the other won’t, and won’t depend on OpenRC at all; the latter is what is supposed to go stable and what stable users should locally unmask if they want PulseAudio.

Let me state again: if you want newer PulseAudio and you’re in stable explicitly request the -r1 version, not the -r50!.

Unfortunately while I should be able to ask for stable right away for what concerns time and bugs, there are a few dependencies, which include libtool 2.2 which is not stable yet (and I think it should be, the tinderbox haven’t found many libtool 2.2 bugs lately and quite a few packages started requiring that, rather than just a generic libtool that 1.5 is compatible with).

I still have no real plans for the realtime support; while Lennart released rtkit (does anybody find it concerning that Linux started having packages with names vaguely similar to those from Apple’s OS X?), it needs a patched kernel, which means I should probably be pestering our kernel team to get those patches included before we can actually provide it, even optionally.

This week I hope to be able to work on mpd too, so that the Gentoo packaging plays nice with PulseAudio (right now the fact that you have to run it with a different user forces you to use a systemwide instance).

So while I’ve got the tinderbox turned off I’ve been taking care of a few different QA duties that I’m probably not supposed to do but I’m sure to help Gentoo. I’m actually pretty sure that this kind of tasks might actually be even more interesting for users than what I’ve been doing with the tinderbox.

While the tinderbox’s main goal is to be able to find the broken software that is in the tree, this usually produces just a lot of work for other developers (bugs to fix) and a few extra side-effects like identifying smaller QA violations and some very broken package that I have been last riting and that will be removed over the course of the next two months.

On the other hand, the manual analysis I’ve been doing tonight aims to check the actual stuff that is added to the tree, like binary files or big files directories. For those wondering why I’m on a crusade against binary files in the tree, I have to say that first of all, CVS makes it difficult to handle binary files, and this makes them unsuitable for being added to the tree. Additionally, binary files in the tree often mean there is something else broken with the packages: compressed big patches (that still keep big) and huge, messed up files directory with unused content, and stuff like that.

I’ve been able to shave a few kilobytes off the tree by moving a few files on the mirrors and removing the big files from the tree; but I’ve also started sending last rites for the packages that have this kind of issues and I don’t see as being ready to be fixed sometime soon. Interestingly enough, it turns out like there is enough cross-over between the packages that fail, that have QA issues and that are polluting the tree with too-big files directories and so on.

So please don’t get mad at me again if I masked for removal a package you use: if you want to keep it in the tree, please get it fixed.

So I noticed tonight that yesterday a new Linux-PAM (in portage as a generic sys-libs/pam, even though I want to change it one day) was released: 1.1.0. I actually was scared that it was a big overhaul, it seems instead to be little more than a feature release of the previous release, so it’s fine.

All my patches from pre-1.0 (as well as the one to disable NIS support when not found) are still outstanding and they still apply cleanly. I guess I’ll have to harass upstream more about them and see that they are applied, maybe for 1.1.1 or something.

At any rate, the new release does have a few interesting changes, like a new pam_tally module that is now wordsize-independent (that is, it works the same way both in 32- and 64- bit configurations), for this reason I’m now preparing a new pambase to make use of it instead of the old one by default if present. Unfortunately I’m finding a couple of issues that make it not easy to solve.

There is another change that might be worth nothing: I have already blogged about the sha512 support that Linux-PAM 1.0.1 has provided us with. Well, with this new release, together with sha512, sha256 and md5 hashing… there’s blowfish!

But pambase is not going to provide a way to enable it. It’s not that I don’t want people to use blowfish, but rather that upstream relies on the crypt() function provided by the C library: when it supports the above algorithms, then pam_unix will support them as well, otherwise, you’re out of luck. Since Gentoo does not provide a blowfish-patched glibc, then it won’t support the blowfish method. Until that time, this post will serve as an answer for those interested in the matter, who think that by just using “blowfish” you can gain stronger hashing.

Since this is a minor version bump (compared to the previous 1.0), I’ve also decided to change a bit the ebuild too; I’ve removed the warnings for pam_userdb and other modules that have been moved in separate packages, since they were only checked for when updating from pre-1.0 versions. I’m almost tempted to remove the safechecks for pam_stack, pam_pwdb, and pam_console; the pam_timestamp checks have been dropped because that particular module, initially present in our older versions of PAM which applied RedHat-supplied patches, is now present upstream.

I’m going to try mediating with Kukuk about the patches we apply, dropping a few, merging a few more. It’s more time spent on stuff I don’t care much about (PAM is something people detest and I don’t really have a good use for it myself), but I guess it’s something that Gentoo needs. As usual, kudos and gifts are very welcome (the latter in particular because with the recent expenses I’ve had to take care of my leisure budget reduced considerably).

Time to get going to work then, I’m afraid I’ll have to bump the pambase version to 20090621, I don’t think I can fix it before night!

If you’re following me on bugzilla, or looking at the feed of new bugs reported, or just are watching the trackers for the bugs I usually report most often (gcc 4.4 and glibc 2.10 failures mostly), you might have noticed that I haven’t been opening new bugs for a few days already. Please note that this is not a stable situation, it’s just a temporary setback, caused by – you guess – an hardware failure (you could answer this more quickly if you were following me on identi.ca since I have been writing about it).

This time the problem is the UPS’s battery that have consumed after two and a half years (which actually explains pretty well how it was that this year I won two APC gadgets, after years of filing in questionnaires). As soon as the load reaches 40%, the battery charge result to last for 1 to 3 minutes max, which is not right and certainly not enough to shut Yamato down from a tinderboxing run. I have also to note that the power load on the UPS varies between 27% almost idle, and 60% during full-blown build of all the cores which is what the tinderbox does.

I’ve called my supplier on Wednesday night to order the battery, it’ll arrive to the shop next Monday, but I’ll only be able to pick it up on Tuesday (since I have a work appointment and I’ll be around that place). During this time, I’m trying to keep the load on the UPS to the minimum so that it has at least a few minutes to stop everything down; this obviously includes not having the tinderbox running full time.

Myself, trying not to load the box with my own usage, I’m trying to take a few days to work on my paid job (that requires me to use Merrimac instead, which is on a different UPS, which as far as I can tell, is for now still keeping up), reading and watching a few films I’ve gotten lately and haven’t had time to watch, maybe I’ll be able to play a bit too, but I’m not counting on it much, I have already a full weekend with my job tasks.

In the past ten days I was able to read from cover to cover John Grisham’s The Rainmaker – I don’t particularly like lawyers; I don’t particularly dislike them either. I don’t know why I tent to devour Grisham’s books this way (the first I read, in Italian, The King of Torts, I finished during a whole night!). At any rat eI’m trying to resume my average reading, in 2007 I read 19 books, last year just seven; while of course the reason why I read so many more in 2007 is tied to the 42 days of hospital I went through, and the months that it took for me to recover, I’d like to at least reach 13 books this year. It’s also a sort of way to try cooling off before I burn out.

Anyway, will be back soon.

Summary: this post is going to address a request from a reader, about the best way to implement plugins and builtins. If everything goes as I plan (but it really happens very rarely for multi-post topics!), I’ll be discussing today the actual differences between the approach (focusing mostly on explaining the correct reasoning behind the use of plug-ins), then I’ll move to giving a few pointers about their implementations in C, and finally write something about the needed build system changes (which are already partially documented in my guide ).

There is lot of software out there that makes use of plug-in systems of different kinds. For what concerns this blog post, I’m going to focus on plug-in systems where a main application or library loads smaller, semi-autonomous modules for executing primary or secondary tasks. But to be even more focused, I’m not going to talk about plugin systems for interpreted languages like Ruby, Python, Perl, or virtual machine languages like Java and C#/Mono. My reason to exclude these from the list is that they have different rules for loading code, and indeed for them the plugins come to be near-free. On the other hand, compiled languages like C, C++ and similar have harder barriers to work through.

If you follow my blog, are a Gentoo user, or have had to deal with libtool ever before, you probably know already that building shared objects (which is what compiled plug-ins are!) is not as easy as building a standard executable. Indeed shared objects at least in Linux and *BSD, require to be built with PIC, or will cause text relocations; in both cases they require more memory (they both are Copy-on-Write, the former for .data.rel relocations, the other for .text relocations). PIC code, also, require the x86 register ebx to be reserved for use as base pointer for the global offset table, which means that the compiler and the hand-written assembly code have one less register to use.

With plug-ins, you not only have to deal with the usual problems related to shared objects, like the already-mentioned copy-on-write sections and the loss of one register, but you also have a few more issues, which can make them pretty expensive in term of resources, just as a shortlist:

• you cannot mitigate the problem with prelink, as I’ve stated previously the current implementation of prelink does not take into consideration plugins at all, which not only means it won’t be able to reduce the copy on write caused by the actual plugin objects, but also that it cannot take the proper step to make sure that all the libraries don’t end up trying to use the same address (when trying to preserve the address space); this because it cannot understand that the libraries linked to by the various plugins will be loaded in the same memory area;
• the plugins will call into the dynamic loader and force it to load further libraries in the address space if they are not there yet, this actually requires a non trivial amount of work from one part of the operating system that usually stops after the program is loaded and running;
• plugins will require accessing otherwise private functions of the software that is loading them; this means that the library (or the final executable if there is no intermediate library) will have to export more symbols; exported symbols also have tighter rules for their optimisation (since they will be called form outside of the currently-built module), and require bigger PLTs (Procedure Linking Tables) as well as hash tables and so on;
• while plugins share the address space of the process loading them, they don’t share neither on-disk nor in memory sections; this can be easily seen in plugins like the one shipping with xine-lib: any process that will load them will end up wasting 4KiB of .data.rel per plugin as they declare an exported data structure (usually much smaller than 4KiB, but that’s the page size) which suffers from copy-on-write; since all the sections are mapped into multipliers of the page size (4KiB on mos systems), even if each plugin were to use just 1KiB of private memory areas it will end up using at least four times as much of resident memory;
• finding symbol collisions can easily become tricky when they happens between two libraries loaded by two different plugins since they might never seen to be loaded together, just by looking at the dependencies on the files, this is the same problem as prelink above.

At this point you might think that plugins are inherently bad and should always be avoided; on the other hand you might notice that, in a standard desktop system, you find lots of software that actually use plug-ins. Why is it this way? Well the problem is that while you do have lots of nasty side-effects with the use of plugins, they have lots of advantages over building all the support in the software, especially they can work when there is no way to build the support in the software itself.

For instance, browser plugins cannot really be built into the browser; things like the Flash Player or other similar tools need to be loaded from outside. Themes for Gtk+ and Qt that don’t ship with the libraries themselves cannot be built in them, since you cannot merge and separate the modules that easily, so they also need to be designed as plugins. But it does not stop here. If you do load the plugins conditionally, they can save quite a bit of memory.

If you think that simply linking against a library, without using it explicitly, can actually execute code that wastes cpu and memory resources, through constructor functions and static initializators, you can easily understand that being able to just load a subset of the modules at any given time can easily be a save in memory, both shared and static. For this to work, though, you need to make sure that the plugins are loaded only if explicitly needed, may it be via an explicit request to load them (themes, applets) or via smart databases (browser plugins). Just being able to unload them might not be enough: there are libraries that once loaded cannot be unloaded until the process completes; PulseAudio for instance does that. And xine, well, is a good example how not to do it: not only, as I said, each plugin uses up between 8 and 12 KiB of memory without compelling reasons but being the design of the plugin systems, but also lacks a proper way to decide which subset of plugins to load, which results in all the plugins being loaded at all time.

Of course, sometimes the plugins seem to just be pointless because, as for the case of xine, they are always loaded, or they are entirely shipped with the application, with no header or interface to actually add more. In this case, one would probably be expecting to just being able to choose which feature to build in (in Gentoo via USE flags) and be done with it. In cases like these, the choice of using plugins over optional build-ins can easily be more political than technical.

Once you think of it, USE flags in Gentoo are very easy to use to choose what to load and what not, but for binary distributions it’s not that easy to provide packages for an arbitrary number of combinations of selected build-ins for the same basic application; on the other hand for them is very easy to provide a number of sub-packages with the various plugins. In these terms, the ability to choose at build time whether to build multiple plugins or merge all them in a single executable is likely a desirable feature; source-based distributions like Gentoo, FreeBSD ports and pkgsrc will prefer the built-ins, providing their users with quite nicely optimised software, while