[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Possibly offtopic : Binary only driver
- From: "Sean" <seanlkml sympatico ca>
- To: "Development discussions related to Fedora Core" <fedora-devel-list redhat com>
- Subject: Re: Possibly offtopic : Binary only driver
- Date: Sun, 21 Nov 2004 22:39:27 -0500 (EST)
On Sun, November 21, 2004 9:23 pm, Sean Middleditch said:
> 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. ;-)
Well in both the cases everything I needed was actually part of the
distribution. While rpm isn't perfect I find that many times finding a
precompiled rpm of 3rd party applications targetted for the distro isn't
hard. Installing the application is little more than a mouse click on a
> 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.
I was only talking about kernel interfaces.
> 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.
Yes, the kernel developers have done a great job protecting the end-user
from arbitrary changes.
> 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? ;-)
Heh, well I don't think it has to be that far in advance. With automatic
system updates etc, as long as theres a reasonable lead time before
product release things should all come together nicely for the end user.
Even if the particular hardware isn't supported in the kernel version on
the DVD platter s/he installs from.
> Yes. Thank you for pointing that out. It's relevance to this
> discussion is...?
Didn't do a good job of relaying my point. You were saying that
open-source was incidental to Linux and I was trying to show that in fact
it is fundamental. Any developer working (on the kernel at least) is
only doing so because the source is available. Thus everyone, whether
they're gung-ho open-sourcers or not, has benefited from the open source
nature of Linux.
I see now that you were speaking in broader terms than just the Linux
kernel and perhaps you were speaking less of open source per se and more
of solid API/ABI's.
> 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.
Well, things stabalize and get used for a long time. Look how SATA is
already supported in the kernel. It's hard to complain that something is
wrong with this situation at least at the kernel level.
> 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? ;-)
Damn, you just preempted my next example ;o)
> 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
Again, I wasn't talking about the application level in my previous email.
But what's wrong with the current focus on creating easy-to-use
repositories for applications? Binaries can be compiled for many
different distros and the proper version is selected without the end-user
having to have a clue.
> 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
Yes, Fedora is probably a bad example because it's not meant for the
people you're fussing over anyway ;o)
> Compiled source... binaries?
I was trying to make the distinction between binary-only modules and
> 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?
Presumably new versions will be released that target the new API. Until
then, the old libraries are often included along with the new. For
instance gtk 1.2 was including until recently even though things had moved
on to version 2.0.
> 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?
Repositories of software are becoming more popular and provide precompiled
versions for a wide variety of distros.
> 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.
Ok, but obviously such decisions benefit the developers. And there is a
long history of such decisions by kernel developers, back to ummm, the
start of Linux. And Linux has still managed to become successful.
Now binary-only people are complaining that their life is made more
difficult than what they experience in the Windows world. Well, I think
the needs of the open-source developers wins out here. They're the ones
contributing the most to the community.
Linux is getting in a stronger bargaining position all the time.
Eventually, the market will be big enough that the hardware vendors will
_have_ to play by the open-source rules if they want to compete in that
segment of the market. I see no reason for the developers to cave in and
make their lives more difficult for the needs of the closed-sourced
hardware manufacturers who offer nothing in return but demands.
Since more and more manufacturers are speaking chinese these days, it may
well be that we'll see a general warming to the open-source model in
general and Linux in particular. Who knows.
> 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
The people doing the work are serving their own needs. Open source works
because people contribute what _they_ personally need for themselves back
to the community. Obviously it's not pure altruism that drives open
You have to ask yourself why the developers should care? Are the
problems you describe an issue for open-source developers? If they are,
then you can be sure the open source developers will be solving the
[Date Prev][Date Next] [Thread Prev][Thread Next]