[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: When is the Last Time You Booted to Windows?

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.

 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.

 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.


 > 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).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]