User: Password:
|
|
Subscribe / Log in / New account

Choosing between portability and innovation

Choosing between portability and innovation

Posted Mar 10, 2011 23:01 UTC (Thu) by phoenix (guest, #73532)
In reply to: Choosing between portability and innovation by paracyde
Parent article: Choosing between portability and innovation

Hrm, no, if you actually look back at the development history, you'll note that the Linux devs need to rid themselves of NIH Syndrome.

Working, stable, performant wireless networking stacks were developed on BSD first. How many wireless stacks has Linux gone through so far?

Working, stable, performant device detection and /dev filesystem was developed on FreeBSD first. How many /dev filesystem setups has Linux gone through so far, and still re-writing them to this day?

Working, stable, performant RC systems were developed on BSD first. How many RC init systems has Linux gone through so far, and is still re-writing them to this day?

Working, stable, non-root X setups were developed on OpenBSD first. Canonical got to brag about being the first Linux distro maker to accomplish that this past year. But it's still no working right.

Working, stable, performant and portable packet filtering was developed on BSD first. How many packet filters has Linux gone through now?

Working, stable, performant USB stacks were developed on BSD first. How many different USB stacks has Linux gone through now?

Working, stable, in-kernel multi-channel, no-locking, sound mixing was available on FreeBSD before ALSA was ever even thought of. How many
"sounds daemons", "sound servers", and sound stacks has Linux gone through now?

And the list goes on. Re-writing sub-systems with every release of the kernel is not "innovative".


(Log in to post comments)

Choosing between portability and innovation

Posted Mar 11, 2011 12:36 UTC (Fri) by nix (subscriber, #2304) [Link]

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds