Linked by Thom Holwerda on Thu 5th Jul 2007 09:11 UTC, submitted by Tim Alson
Permalink for comment 253306
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
More News »
Sponsored Links



Member since:
2006-04-21
Frankly, I believe it is the fault of the hardware vendors in both cases. Btu in the end, if stuff doesn't work, then the reason really doesn't matter as far as in end user is concerned. It either works or it doesn't. If it doesn't, then somebody needs to fix it.
Actually, in the case of an incomplete, in-kernel, open source hardware driver, with Linux you'd be justified in (mostly) blaming the kernel developers. Not that that happens often, and this is where open source really comes into its own - because the Linux kernel devs have control over the kernel, because they have control over open source drivers, and because they demand high quality in their software, you don't get the situation where high-quality, production code suffers because of some crappy 3rd party driver. Of course, mistakes can happen, and I doubt pre-release code is that stable, but the only time I have ever seen a kernel panic on Linux that wasn't due to my own stupidity passing the boot flags was, indeed, a case of a crappily-implemented or unmaintained part of the kernel. Since that experience with ReiserFS3, I have since sworn off ReiserFS!