On Thu, Feb 16, 2006 at 05:51:49PM -0600, Les Mikesell wrote: > > Look at any OS that maintains such an illusion for proof of this. > > Every time a vendor has done this, there's been some internal struct > > or function that wasn't exported, that 3rd parties wanted to poke > > around with, which inevitably does completely the wrong thing when > > things are changed. > > Can you give examples of that 'any OS'? It certainly isn't > an issue with Windows or OSX. Windows: You've got to be kidding? Read the whitepapers on Microsofts site about driver reliability. They even have pretty graphs showing just how bad 3rd party drivers are. There's a reason why Microsoft has a driver certification program, and a lot of really advanced tools to try and get vendors to run their drivers through first to spot various failures. It's actually a must if you want to pass their qualification, however it's also easily subverted as documented by their own developers. Vendors submit drivers which pass the certification tests with flying colours, yet the drivers people end up with in a box run with different registry settings making them pull all their nasty hacks to gain that extra few fps in game of the day. Then people apply service packs, and watch reliability of their system go to the wind. OSX: The only 3rd party kernel driver my wife installed on her powerbook was the one that came with some antivirus crap that was bundled with it. After upgrading from 10.3 to 10.4, guess which part of her system is broken six ways to sunday ? It's a small sample, but it's not exactly a good start. > I personally maintain a few > hundred machines that have been through every vendor update > for years without a single problem I could blame on binary-only > drivers or modules. Congratulations. > Nothing is perfect, but I see this mentioned much more often > as a problem with Linux than an advantage. Can you give some > examples of drivers or modules that are better in the > second-guessed source versions than the vendor's own versions > that they do for the OS's that accept binaries? tg3 vs bcm5400. The broadcom driver was notoriously bad. The reverse engineered one actually works reliably. (Moreso once the developers finally got documentation on the chip errata) skge/sky2 vs sk98lin Syskonnect's driver works great for some cards, and appalling for others. The rewritten drivers aren't perfect, but they're getting better all the time. > I recall in > particular a lot of trouble with various aic7xxx linux modules > that didn't have equivalent problems in the binaries for Windows. historically the problems with AIC were mostly political. The maintainer wanted to do things in similar ways to how FreeBSD managed it's scsi layer (Odd that, him being a FreeBSD committer), and the Linux scsi maintainers disagreed. When he finally gave up, the Linux scsi maintainers took over maintainence of the driver, which is now seeing a lot of improvements previously blocked. As with all new code, sometimes there are regressions. It's not perfect, but again it's under constant improvement. Had this been a binary driver, we'd be stuck with something that worked on some older release, that would now be completly broken. Had we had a kernel-ABI in place, it would have prevented a lot of the improvements that have occured in the SCSI layer over the last year or so. > And I'm still not all that sure about the reliability of firewire > support even though it's sort-of back after months of not working > at all in FC4 kernels. You are right that perhaps somebody > 'could' fix it but it's not a win unless they actually do. The firewire drivers have never been particularly reliable, but again, slowly they are seeing improvements. It recently came to light that a lot of the problems people have experienced have been directly related to crap firmware on some enclosures (All of them seem to have exactly the same manufacturer, and aparently they don't work particularly reliably under stress in Windows either). Dave
