Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?

["Dmitri Nikulin" <dnikulin@xxxxxxxxx>]

On 7/16/06, James Mansion <james@xxxxxxxxxxxxxxxxx> wrote:
> So please, don't respond to customer/user suggestions that
> way, unless you want to be treated like an amateur having a
> play to see what you can do.  I didn't think that *was*
> what you wanted.

What's he supposed to say? "Sure, I'll put down the important work I'm
doing to make this system unique and directly applicable to an
important niche market, and work on creating Yet Another Linux with no
hope of surviving"?

> Do you want a user community?  You need to respect users who
> have no intention of developing your system.  They might have
> enough on their plate solving their own development problems.

The developers here are very respectful of users, but they can't
reasonably chase every tangent. I do not necessarily agree with the
wording, but the point is correct - the developer resources are spread
too thin already, and following questionable technical decisions
(explained further down) is the last thing they want to do.

> As it happens, I agree with the original post: if you are
> too small to define de facto standards, and there is no
> de jure standard to hide behind (not that they always matter
> that much in reality) then practicality says that its
> necessary to go with the flow and find a way to use whatever
> is there, and if that's an NVidia blob for Solaris or Mac or
> even Windows, then so be it.

I really wish it was that simple, but if we want open source code, we
need an immediate problem rather than a long-term one. The long-term
problem is that binary blobs might not be supported any more since the
profitability for the company drops over time. The short-term problem,
which is the good one because it encourages preventing the long-term
problem, is that here-and-now a lot of devices simply don't have any
driver available.

If developers do not see the long-term problem, as has so often been
the case, they might decide it's 'good enough' to have the binary blob
as the workaround for the short-term problem.

Bad enough that these blobs, even now, can have unspeakably terrible
security holes, even some deliberate ones, and short of an inhuman
reverse engineering effort we'll never really know.

OpenBSD's Theo is the most outspoken on the issue of binary blobs - it
might be nice for the popularity of a system to support every device,
but it's absolutely terrible for the durability.

Linux in particular is *already* a tightly knit mass of bugs, hacks
and security holes, and when they finally see the terrible situation
they're leaving themselves in by actually thanking vendors for binary
blobs instead of sending them packing. They have good people on their
side - the reverse engineering nForce ethernet driver is what helped
OpenBSD folks write nfe(4) which is quite good - but the spirit there
is to do everything possible even if it is going to hurt later.
They've been re-writing major parts of the kernel between every one or
two minor releases, because somebody didn't think ahead. Vendors have
to keep up with all of that mess when releasing drivers. BSD in
comparison is very easy to develop for, but it's not as profitable,
and it's hard to imagine vendors would care about much more.

Even if the entire BSD community announced its united love for a
single graphics vendor and only bought from them, it'd still be less
of a profit gain than releasing a slightly superior device with only a
Windows driver and some form of Linux adaptation which works okay on
Thursdays, thusly turning over some of the much larger market share
from a competitor. Hard to say which would be more expensive to
implement, but chances are using the existing masses of hardware and
Windows+Linux experts they have is cheaper than the overhead to even
get an NDA out to a BSD developer. At no point is releasing
documentation viable just because their business is secrecy, so even
if we did have vendor support it'd be just like with Linux, with
either really poor quality drivers (the Intel PRO Wireless ones) or
entirely closed and brittle ones (anything released from ATI or
nVidia, ever).

> In the particular case of graphics drivers, its very much
> more attractive to target a system which can also be the
> desktop of choice.  Maybe second best would be decent Xen
> guest support, but it surely must be a distant second.

Agreed, I too would really like having an operating system for
everything. But as long as vendors, hardware and software alike,
refuse to support BSDs, I am often limited in how I can run them as
workstations - and as long as Linux is absolute garbage in security,
stability and administrative sanity, I will hardly consider running it
as a server. Does it matter? Not much, I'm content to Linux as a
desktop (I don't, but I imagine I will later), and it's not as though
doing so will somehow prevent me from running a BSD server.

Remember that it's unreasonable to expect that BSDs could stay as
clean and robust as they are now if commercial vendors put their lust
for money into them. FreeBSD was severely hurt by rushing to implement
whatever SMP sounded best, and that's why DragonFly is here now. It
has virtually no vendor support and an extremely small developer base,
but it's already a much cleaner system all-around just because
everything is meditated and not just rushed into for market share.
Even if it somehow fails to achieve a significant user base, it'll
forever be a technological example for other systems, in a way like
Inferno.

> I can see that in a security oriented appliance there may
> be a good case against using a blob for verifiability, but
> for a desktop developer environment?  The arguments against
> in that case look like sour grapes about the perceived
> inconvenience.  I don't have access to the guts of the
> Triarch and Tibco libraries we use, nor the Sybase and Oracle
> clients, and it doesn't stop me from doing my job.

Like I said long before my massive forest of text, the *durability* of
the code is just as important. If we don't replace the blobs with code
we can maintain once the vendor gives up on it, we put ourselves in a
very uncomfortable position for the future. Somebody in the future
will have to replace the blobs of today, but it's a lot better to
start now so they'll be a lot more mature by then, saying nothing of
the potential of using the same driver on other architectures.

Let's return to your key point - that practicality suggests going with
the flow. These days, the flow for desktops and servers is Windows,
Linux and MacOSX. Nothing else commercially matters. Solaris, BSD,
etc. are technically magnificent, and people will continue using them
when they recognize a practical benefit. These projects gain nothing
useful from supporting vendor hardware through fragile, unmaintainable
binary blobs. Sure, more users will run them on their systems, and so
what? These users rarely contribute to the projects and often enough
simply clutter up the bug reports with bikeshed issues.

At this point, there are much more significant issues to be dealt with
in DragonFly than hardware support, namely that it's not yet
compelling to many besides the developers. We curious non-project
coders can't even prepare now for the clustering we'll have in a year
or so, nor can we start developing for the userland VFS system which
isn't implemented yet. Once DragonFly becomes a truly compelling
platform, it'll be time to question whether hardware support is a real
issue. It might not ever be, because other projects are doing a
magnificient job of creating free drivers for the hardware that
matters, and the 3D accelerated video drivers hardly matter because
the few things we need 3D acceleration for are better run on other
systems anyway.

---
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

email: dnikulin@xxxxxxxxx