The archaeology of GNOME accessibility

OSKs using ibus might well be a result of the fact that few people understand AT-SPI, and those who do either associate it with more specialized assistive technologies (the Stephen Hawking use-case mentioned in the article), or have looked into its security properties and are scared of its attack surface, or both. For what it's worth, GNOME's "Caribou" OSK uses AT-SPI rather than ibus, so both ways seem to be possible.

More generally, there are broadly two ways the overall system can go to be more useful to you: it can get more integrated and tightly-coupled, or it can get more modular and loosely-coupled. Either of those might be good or bad for your goal, and it isn't obvious which. Choosing the right level of modularity is more art than science, and the right answer will be different for different parts of the system.

If the system gets more modular and loosely-coupled, you are more likely to be able to remove the components you don't need, while leaving the components that you do need, and giving other users in the same situation the ability to remove the components that *they* don't need (not necessarily the same components you remove). However, the price of a modular and loosely-coupled system is that you will not be able to get rid of the abstraction layer that links the components together (together with whatever workarounds and glue code are necessary to make them actually work), which might itself be of a significant size; and the other things you want from your system (features, bug fixes and security) will often advance more slowly, because changes require changing things on both sides of the abstraction layer boundary, and perhaps also the abstraction layer itself.

If the system gets more integrated and tightly-coupled (as in the work described in this article), then you will not be able to remove the components you don't need, because they're integrated into the components you do need. However, if they're more likely to actually work well enough that you can rely on them, and they don't have an abstraction layer getting in the way, that might well be a net improvement from your point of view.

You have to look out there, though. I think you might be dating yourself a bit. 25GbE (let alone 100) is still unequivocally "enterprise", but my desktop here has a 10GbE Intel X540-AT2 in it. It cost a bit over a hundred quid, and the switch it's attached to was only a bit more expensive. Yes, it didn't come attached to the motherboard by default, but 10GbE is definitely not "crazy expensive enterprise only" any more: it's perfectly practical if you just want your desktop's access to your home RAID array to be as fast as it is on the server itself. (Though this particular NIC, driven by ixgbe, doesn't need any firmware at all.)

... hm, a lot of the things that *do* need firmware are a bit on the pricey side, I'll admit. £590 for a 10GbE NIC? Uh no thanks, Myricom. But not all: Agilio CX cards are only about twice as expensive as the thing in my desktop. (Still not sure why it's worth paying twice as much as Intel charge, mind you.)

Firmware files can at least be pared down by mere mortals. Graphics drivers are in dire need of being separated into current, legacy and abandoned hardware support. Every other class of hardware in the kernel seems to get this right; Intel's 1MB-and-growing blob of mostly unused code is by far the worst offender.