Choosing between portability and innovation

Virtually of the things you whine about in this email haven't had any inkling of change in years, and to be honest it doesn't matter a damn who 'did it first', it matters which works better. And in many of these cases, BSD loses massively precisely because they don't reinvent.

- /dev filesystem: two implementations (you often have to write one and throw it away to learn how *not* to do it). One upstream, architecture pretty much unchanged since day 1 (though this all depends on what you mean by a '/dev filesystem setup': one of the lessons of devfs was to try to stick to the traditional /dev layout to avoid breaking things unnecessarily). But perhaps you're referring to the shift to a single upstreamed udev database? That's *optional* and several major distros (Debian for one) don't use it.

- RC init systems: again, ambiguous. sysvinit was *the* init system for many decades, but is terribly limited, so much so that most of its functionality is almost unused. Init scripts, well, we started with BSD's 'giant shell script' approach. The difference is, BSD stuck with it even though it sucks massively in systems with package managers. Linux moved on, and even now the init script format defined right after that is still accepted by the latest bleeding-edge init replacements.

- non-root X: BSD has revoke(). Linux doesn't. Not a problem of reinvention nor NIH, just 'this is a really hard problem'. Most of the BSDs still don't have non-root X because they are NIHing with respect to each other.

- Packet filtering: the last packet filter redesign was something like eight years ago. I know of iptables packet filters that've been working unchanged for all that time. Huge code churn this is not.

- USB stacks: how many? well, er, one (which didn't work very well until hotplugging worked properly: the same hotplugging you damn elsewhere). Yeah, we have support for things like USB 3.0. That's not a 'new stack', that's changes to an existing stack to support new hardware.

Sheesh.