NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?

[Bill Hacker]

Martin P. Hellwig wrote:
Dimitri Kovalov wrote:
<cut>
You have it backwards. The reason BSD is all 'black boxes'
is that it is not competitive or good in the video area.
*I* have it backwards?

We should all be running WinWoes 'cos it is 'good in the video area?'

Apple can make it work because they sell the whole box and
can control the hardware.  But the open-source OSes don't
have the resources to support video.
Not so. You have cause and effect reversed.

The F/OSS folks who *must have* a good video and GUI to get some *other* set of 
tasks accomplished simply buy the commodity that suits them.

Lots of *n*x developers use a Winbox or Mac with nary a care for the politics or 
religion, just as they would a twist drill. Not throw-away, but expendable 
nonetheless.

The haven't time to play with these 'appliances', and begrudge even time wasted 
on updates and fiddling (hence my move form OS/2 to OSX).

Very much a minority market vs gadzillions of office-workers and home users.

Those who would *like to have* a good video and GUI for reasons *other than* 
getting some other job done, are more likely to use Linux, and DO spend a good 
deal of time modifying and updating their personal WS.

This attraction has created a huge pool of Linux-aware folks, the best of whom 
are very savvy coders, and the worst of whom can at least be trained to be 
better admins than Win-gulls, if only 'coz they actually give a damn.

That labor pool of trained-at-the-expense-of-others is what drives IBM, HP, Sun, 
etc. to embrace Linux, not technical superiority. All of these companies are 
*service* providers - hardware and software is incidental.

>> It would be a good
thing to have a model where vendors could easily take their
windows drivers and make them work with BSD as a module.
Decidedly NOT.

At NT4, MS moved video drivers into Ring 0 to optimize bloated code for the 
single-user GUI. NT 3.51 was far more stable, and MS struggled for years to fix 
all that.

Warp 4 left video in Ring 3, (ATI Mach 64 was an exception) - yet tested 40% 
faster on ONE CPU than NT 4.X on TWO (BTDTGTTS Tseng ET4000. ASUS dual PII 166 @ 
200 MHz).

Even if a single-user GUI-prioritized environment is what you *want*, other 
parts of the WinWay come at too high a price to go down that road.

Memory management, the fs, and other-than-video I/O need that sort of critical 
priority more than pretty pictures alone. Things that get costly in time and 
money if they do not have it.

Old or new branches of X are rooted in a very different architectural philosophy 
than Win vid, and would have to start over from a clean slate to even match the 
sort of performance of an Amiga, BeBox, Warp/eCS or OS X deliver(ed) on 
comparable hardware.

Note that many folks have been promising a Linux that used Win Vid drivers 
directly for years, but it has yet to take make a ripple.

You know that vendors will make drivers for windows, so
making it easy for them to port to your OS is good for
everytone.
That would require a major rework of the X environment, if not the OS itself.

Its time for open sourcers to realize they can't do
everything themselves. I don't care if a driver is binary
if it works. I want to have options.
Dimitri

Options to what end?

Apple, for example, have a very limited selection of video hardware, yet I can 
no longer see enough difference to care.

Only a 'game' machine or high-end studio-grade editing can justify the upgrade.
Not much else even stresses the low-end video.
Very small market, once purpose-built game boxes and 'good enough' commodity 
Winboxen are factored out at one end, and big-bucks studio gear at the other.

A binary driver on a system doing public services?
Not on my box! That's about the most important reasons why my windows 
servers are always in a DMZ and my OSS boxes are mostly not.

But for 
anything else I'll say yes that would be convenient. However I lost the 
faith in manufactures creating good drivers, whether they are windows or 
anything else, but I guess that most manufacturers don't want to provide 
too much specs or source because then it's quite easy to see what a mess 
they sometimes make of their hardware.

There are servers, and there are desktop/laptop 'productivity appliances'.

The entire 'available' market is too small for any of the *BSD's to focus on 
their weakest attribute - the GUI.

If DragonFly were to ignore - *totally ignore* video, USB, sound, etc. for (at 
least) a full 12 months, and concentrate solely on kernel, IP, fs, a few key NIC 
and storage-controller drivers, and the integration and security of all these,

. .. it would have a far better chance of carving out a respectable chunk of high 
ground sooner.

A 'differentiator' so to speak, where it could best demonstrate superior value.

A DragonFly Xen or VM 'host 0', for example, that could host other OS more 
efficiently and/or with superior portability across a high-speed 'fabric'.

All the rest would follow *eventually* - just as they did for Linus' kernel.

But that needs a well-respected and stable core before the big wave of interest 
and committment can afford to jump aboard.

So long as the project tries to incrementally drag all the *noisy baggage* along 
at the same rate as the vanguard, the never-ending rework of code and libs 
against a moving core target, coupled with the rapid external progression of 
hardware development, will prevent it catching up any time soon enough to matter.

The shortest distance between two points is not a straight line.

It is folding the paper so the points *touch*.

'Put the big rocks into the jar first'.

Bill Hacker