Possibly offtopic : Binary only driver

[Sean Middleditch]

On Sun, 2004-11-21 at 20:26 -0500, Sean wrote:
> No i don't think you've listed the only options.   I've installed FC3 on
> two computer recently and they just simply worked.   No geek factor
> needed, put the DVD in the drive and follow the installation screens.  
> Done deal.   The fact that there are machines that don't go so easily will
> be resolved when more drivers come compiled in kernel and when hardware
> doesn't change quite so often.   Simple.

You have gotten the OS installed.  Congratulations.  If that is the
entire reason you own a computer - to install an OS on it - then you
*really* need something else to do with your time.  ;-)

> 
> > Yes.  Practically no-name brand computers that very few people buy, and
> > most who do are very likely to install Windows down the road.  I've
> > watches *many* people gladly pay $200 for a copy of Windows to install
> > on the dirt-cheap Linux-based computer provided them.
> 
> Windows is the dominant operating system with way more applications than
> Linux, I don't think they main problem is hardware support here.

No, it's application installation support, which is dependent on system
ABI stability.  There are two parts to my mail - system and kernel
interfaces.  Don't confuse them, they are *completely* separate issues.
One affects only drivers, while the other affects only applications.

So far as system ABI stability, the Linux kernel does a fantastic job of
maintaining the part of it that the kernel is responsible for.  The
things that do break are fringe elements that the vast majority of
applications never touch.  The Linux developers aren't hurting
application developers - the glibc, GCC, and various other library
developers and packagers are.

> 
> > Did you even read a single word in the above paragraph past the first
> > sentence?  You just asked a series of questions that the entire
> > paragraph is dedicated to.
> 
> *shrug*  So we need hardware developers to target Linux drivers sooner
> rather than later.   Again, they're welcome to do that today with no
> changes required.   Automatic updating of kernels can be built in to
> installation processes etc..

You want the hardware developers to target Linux several years before
the hardware is even released?  Can I have the pipe for a few
moments?  ;-)

> 
> > What fundamental things?  It being GPL?  There are dozens and dozens of
> > open source operating systems around these days.  Linux is only being
> > discussed on this list, and only of interest to those hundreds of
> > millions of people, because it got to a point of being actually useful.
> > Linux's fundamental point to many people is that it's a great OS from a
> > technical perspective that is usable to many people.  Open Source is a
> > means to that end.  It is not the end itself.  To some, perhaps, but not
> > all.
> >
> 
> That's fine, but the developers are involved because they are making an
> open source operating system.   They aren't making a closed source
> operating system.

Yes.  Thank you for pointing that out.  It's relevance to this
discussion is...?

> 
> > And this is where my point lies.  It is developers thinking like you who
> > are guaranteeing that Linux is a niche OS.  "Who gives a flying hoot
> > about users, let's just keep playing with our toy."
> 
> So it's a niche operating system in its current state, lets not waste any
> time going in the wrong direction.   Spend more time making a great
> operating system with huge amount of hardware support and the problems
> will eventually be much reduced.   To a point where more and more people
> can use Linux without a problem or thought.  Do you honestly think that if
> tomorrow Linux enforced an ABI that Windows would be supplanted any time
> soon?

Soon?  Not really.  Until a stable ABI *is* enforced, it won't happen.
Linux could get a stable ABI tomorrow and supplanting would be several
years away from tomorrow, or it get could a stable ABI a decade from now
and supplanting would be several years away from *then*.

You seem to think that hardware churn will decrease.  What makes you
think that?  Hardware vendors are in *no* hurry to commit corporate
suicide, trust me, and hardware stagnation would be exactly that.  New
hardware needs new features or nobody has any reason to upgrade.

> 
> 
> > No, they are not non-existent.  I run RHEL on many systems, and still
> > run into these problems.  Each version of RHEL is incompatible, and it
> > is not the only "enterprise" Linux OS in existence
> 
> Ever try upgrading Windows 2.0 to 3 ?  or  98 to 2000?   Same problems.

2.0 to 3 is irrelevant - they're over a fricken decade old!  Why don't
you try comparing Linux to the abicus(sp) next?  ;-)

I've not had many troubles installing apps on 95, 98, 2000, ME, XP, or
2003.  There are incompatibilities sometimes, yes.  There always will
be.  The difference is, Windows has a far, far, far smaller percentage
of users with compatibility problems on a day-to-day basis than Linux
does.

The differences between the six-month-apart releases of FC2 and FC3 have
caused me more compatibility headaches than upgrading between the many-
years-apart differences between Windows 98 and Windows XP.

I'm fine with that because I'm an uber geek and for all the headaches,
I'm personally happier dealing with them than the problems I perceive in
Windows.  Problems which, I'll note, no non-developer person I know
perceives.

> 
> 
> > Not if read the primary argument in my mail.  Source is useless to
> > people who cannot compile it.
> 
> Well, maybe looking at ways to get compiled source into the hands of end
> users would be more fruitful instead of demanding that developers change
> the nature of what they're doing.

Compiled source... binaries?

I'm thinking we're having a communication problem here.

a) How do you pre-compile source that will not compile because the
developers break the API, requiring the source to be modified, without
waiting for said modifications?
b) How do users use pre-compiled binaries that don't run because
developers break the ABI, requiring a different set of binaries and thus
requiring an enormous and completely unmanageable number of different
binaries to be built and exist for most users?

> 
> > And one of the prime points myself and others have been making is that
> > an open source operating system is useless.  It's a political toy.  Many
> > kernel developers do *not* share your vision, and very users do.  Linux
> > is interesting because it is a powerful UNIX-like OS that is stable,
> > secure, offers an excellent development platform, and has many
> > interesting applications and operating environments like KDE and GNOME.
> > The fact that it's Open Source itself isn't of interest - it's just
> > something that helped Linux get where it is.
> 
> Yes, and it's what will take it into the future successfully.   There's
> very little reason to think that making it more like the other operating
> system choices would make it better.   You say yourself BSD doesn't have
> this ABI problem yet it hasn't crushed Windows has it?

Excellent point.  I do wonder, honestly, why BSD lags behind Linux in
popularity.  I'd wager it's simply a matter of "luck" - Linux happened
to hit the limelight where BSD did not.

> 
> 
> > Absolutely *NOTHING* I argued for in my mail stops Linux from being an
> > Open Source operating system.  Nothing.  I even explicitly stated that
> > I'm fine with Linux (the kernel) becoming even *more* GPL-centric.  The
> > problem is that even *developers* have a difficult time because not only
> > to ABIs break, but APIs break.  You *have* be development-savvy and keep
> > on the bleeding edge to get anywhere with Linux in many cases.  And
> > there's *NO* reason for it.  None.   It is completely fixable without
> > breaking your vision of what is fundamental to Linux.
> 
> 
> Ok, then perhaps there's less that differentiates our positions than I
> thought.   The developers feel that having the flexibility to change the
> ABI is a net win.  Of course it creates problems for some, but over all it
> has allowed Linux to get where it is today, so it can't be all that bad a
> strategy.

The changing ABI hasn't in any way been responsible for anything.  The
ABI changes because the ABI wasn't designed properly in the first place,
and because people are lazy and would rather just make some small
changes to the ABI instead of introducing a new, parallel improved one.

Take the NVIDIA driver, for example, which is a huge binary-only driver
example.  The breaks it has had, with the exception of the 8k stack
issue, have been very, very minor changes in the kernel.  Functions
being renamed or parameters changing.  That is absolutely avoidable.
The kernel developers just don't want to.

Now take a project like GNOME or KDE.  Absolutely huge.  All GPL or
LGPL.  And they absolutely maintain strict API and ABI compatibility.
The only time you run into an ABI problem with those frameworks is when
the underlying OS or compiler breaks the ABI under them.

Between fixing the kernel and the main system libraries, I'll go for the
libraries.  I've seen far more problems due to application
incompatibilities than I have from hardware incompatibilities, no
question.  *Both* are fixable, however, and I see no reason why they
shouldn't be.

The people responsible just don't seem to care.  I'm hoping that'll
change.

> 
> Cheers,
> Sean
> 
>