Re: Possibly offtopic : Binary only driver

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

 



On Sun, 2004-11-21 at 15:25 -0500, Alan Cox wrote:
> On Sun, Nov 21, 2004 at 08:21:09PM +0000, Mike Hearn wrote:
> > They won't. Why should they? Availability of source code is useful
> > primarily to those who can read and write programs. That's not the
> > majority of the worlds population.
> 
> Wrong. Simple rephrase   "The availability of plans of the house is useless
> except to builders". Now that should be obviously garbage to anyone. Its
> useful to you because it means you can pick your builder.  Imagine a world
> of "I'm sorry sir you'll have to phone ACME plumbing and pay whatever they
> care to charge you because thats a proprietary sink joint." "Can't you work
> out what it is doing" "Im sorry sir, it has a no reverse engineering clause"

These analogies don't match up in the real world.  A house is not an OS.
The entire usage cases and support structure are entirely different.
Normal computer users generally buy pre-built computer system from big
names and call them for support.  Houses do not, in most cases, work
that way.

Normal users don't give a flying hoot about open source.  It is
worthless to them.  Linux desktops have bugs and crash or glitch out
just as often as Windows - anyone who has ever looked at Red Hat's,
GNOME's, or KDE's bug trackers know this - and those are just the bugs
reported by users that know how and care.  Security issues mean
*nothing* to most users, who simply don't care or don't realize how
serious the issues are.  I've many times worked for some client who,
while I was removing a ton of viruses from their machine, was commenting
to me how security issues are such a farce and how average users would
never have to worry about that kind of stuff.

Computers are tools.  End of story.  People do not buy a computer to
make a statement, they do not buy a computer to express philosophy -
they buy a computer to complete tasks.  Those tasks are, for the vast
majority of users, simple Internet access (Web, e-mail, IM), basic
professional/school work, and games.

I have build, configured, and administrated numerous Linux machines for
friends and family over the last couple years, and *each* and *every*
single one of them are now Windows boxes.  And the exact reason why is
*entirely* because of the installation of software (ABI doesn't matter
to anyone but the end users, which Open Source developers don't ever
seem to care about) and driver installation.

Driver installation is only getting worse in Linux.  In-tree drivers are
only useful if the driver exists in the version of the tree the user
has.  Sure, some mythical company releases fully GPLd drivers, or usable
specs, a six months before their hardware is released.  The kernel has
it in-tree a couple months before the hardware is released.  Six months
after the hardware is released, a distro is released that actually *has*
that kernel.  Several months after that you might be able to expect 5%
of the non-uber-geek OS consumer base to have a distro using that
kernel.

Meanwhile, in the BSD, Windows, Solaris, whatever world, the company
releases a driver, and it works for 90% or more of the users.  Sure,
some drivers fail on XP, some drivers don't work on 95/98, but you are
still, with a single driver, hitting far, far more of the user base than
you can do with Linux.

I don't care about this proprietary vs open source issue.  I fully
believe that Linux can *thrive* with a policy stating that *NO* non-GPLd
modules may *ever* be loaded into the kernel.  That's what the Open
Source and Free Software activities truly want.

The problem is entirely that fact that even *with* a fully GPLd driver
there is no reasonable way for a user to be capable of using it without
living on the bleeding edge and suffering through all the instability
and work that requires, as well as having the knowledge to do it all.

A stable kernel ABI is not necessarily important.  I have argument for
it, but it's not paramount.  A stable API, which the kernel also lacks,
*is* important.  Alan mentioned DKMS - abso-fricken'-lutely useless with
an unstable API.  Sure, the vendor releases the driver source for DKMS,
a nice graphical install tool is written for DKMS - too bad the driver
only compiles and runs on a handful of kernel releases.  The new
"development model" just makes this problem even worse.

The big argument for a stable ABI, even with a "all drivers are always
GPL no matter what" system, is mainly during system install.  I have
some system-critical hardware (disk controller, say) that my OS install
CDs don't support, install CDs do not have the environment to compile
big drivers, a stable ABI would let the vendor ship some CDs/diskettes
that the install can pull the driver off of to install.  Again, very
rare situation, most users in the real world do not and never will
install an OS on their own, not that important.

At the very least, however, without a stable API, the Linux kernel and
its driver situation is just screwing users constantly.

General system ABI is another story.  If I can't install the app I
bought/downloaded/wrote even just a year ago because the glibc
maintainers decided to change something or the GCC developer found a way
to get a .05% performance boost with this piddly little ABI break then
there is a massive usability problem.  One could ship apps as source and
have them recompile on install, but for one, that is just far too slow,
for two, the system APIs change too, and for three, proprietary apps are
a reality that aren't going away anytime in the forseeable future.

No matter how much work the upstream people and distros puts into making
insanely usable GUIs, amazingly efficient systems, and superbly stable
and secure code, it's all fairly useless to anyone but a geek if you
can't install the OS or install any apps you want to run on it.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux