Discussion:
Linux in a binary world... a doomsday scenario
(too old to reply)
Arjan van de Ven
2005-12-05 10:52:32 UTC
Permalink
Linux in a binary world


What if.. what if the linux kernel developers tomorrow accept that
binary modules are OK and are essential for the progress of linux.

a hypothetical doomsday scenario by Arjan van de Ven

the primary assumption in this scenario is obviously not going to
happen, but all assumptions that follow are based things that are true
in some form or another, but of course the names of the "innocent" have
been omitted.




On December 6th, 2005 the kernel developers en mass decide that binary
modules are legally fine and also essential for the progress of linux,
and are as such a desirable thing. At first, the development process of
the linux kernel doesn't change much other than a bunch more symbols
getting exported, and EXPORT_SYMBOL_GPL removed.

Within 3 weeks, distributions like Red Hat Enterprise Linux and SuSE's
SLES distribution start to include a wide variety of binary modules on
their installation CDs. Debian renounces this and stays pure to the
cause, as do other open distributions like Fedora Core and openSuSE.

The enterprise distros don't just NVidias and ATIs modules, but include
all the OEM vendor "fakeraid" modules and the various wireless,
winmodem, windsl and TCP-offloading modules as well,. However, unlike
NVidia and ATI, most of the binary driver vendors do not provide their
drivers in a "glue layer" source form, they provide only the final
binaries.

Several hardware vendors that have been friendly to open source so far,
see their competitors ship only binary drivers, and internally they
start to see pressure to also keep the IP private, and they know that
they haven't used some features of the hardware because their legal
department didn't want that IP in the public. As a result they perceive
their competitors binary drivers to be at a theoretical advantage, or at
least their own drivers could be at an advantage if they were also
closed, because they then can use those few extra features to be ahead
of the competition. By February 1st 2006, about half the hardware
vendors have refocused their internal linux driver efforts to create
value adds in the binary drivers they will release in addition to the
open drivers that already exist. Some vendors even openly stopped
supporting the open drivers because they don't have enough resources
to do both.

March 1st. All the new server lines from the top tier hardware vendors
come out with the next generation storage and network hardware. This
hardware comes with binary drivers for the last 2 versions of RHEL and
SLES distributions, and these drivers are already integrated into the
February refreshes of these distributions. One of the storage vendors
releases their driver in a .o + glue layer format, the others doesn't
bother and only releases binaries for these two distributions. Two of
the network card manufacturers release an update for their open source
driver to minimally support the new cards, the others don't. Consumer
hardware is largely unaffected; most consumer chipsets standardize on
AHCI for SATA storage and keep the existing feature sets in networking
chipsets.

April 1st. 2 of the consumer chipset makers have upgraded their chipsets
to include a new and exciting audio feature that enables enhanced DVD
playback, but unfortunately this caused them to deviate from the
'standard' i810 audio hardware interface. One of them releases a binary
driver for a handful of distributions, the other doesn't consider linux
relevant for the desktop and hasn't bothered to do a linux driver yet.

May 1st All of the server class hardware you can buy requires at least
one but usually 2 or 3 binary modules to operate. While some of these
modules are available in blob+glue form, several are only available for
RHEL3, RHEL4 and SLES9 and sometimes the newly released SLES10. Linux
users will have the choice of 4 kernels for these servers at this time,
but no hope to run a kernel.org kernel on these servers. The Ubuntu
people are very upset and are trying hard, with varying success, to get
drivers available for their distribution. Due to this lobby success,
about 50% of the servers can be used with the Ubuntu kernel as well.

June 1st. A huge flamewar, the fourth on this topic since January,
happens on the linux-kernel mailing list. Users and some developers are
demanding that the kernel.org kernel adopts either the existing RHEL or
the SLES module ABI. Investigation shows that this is not possible, and
the thread turns into a discussion on designing a new ABI versus
freezing the existing one. Many kernel developers feel that the existing
ad-hoc ABI is not suitable for freezing and that a new ABI and API,
designed such that it can be kept stable more easily is the way to go,
while others say that this takes too much time and then won't help for
the next 2 years until RHEL and SLES have adopted this ABI, and at least
demand an immediate freeze of the kernel.org ABI so that the upcoming
RHEL5 release maybe uses it, and thus gets drivers written for it. Users
generally use RHEL or SLES for production servers, and clones like
CENTOS which have released binary compatible kernels.

July 1st. It's increasingly hard to run linux without binary modules on
most new consumer PCs. While a year earlier people would have to give up
3D acceleration for this often, now even 2D doesn't work without binary
drivers, nor does networking (both fixed wire or wireless) or sound. For
half the machines there is not enough linux support available at all,
while 20% use ndiswrapper like translation layers to run the Windows
sound and networking drivers. The Debian project, unable to run on most
machines now, is losing massive amounts of users to Ubuntu and
Ubuntu-Debian hybrids. Debian-legal and various other project lists are
impossible to read by people not interested in this particular
flame-topic. Most of the vendors who kept their open source drivers at
least somewhat updated have basically stopped doing so.

July 14th. Linus declares the kernel ABI stable but also splits off a
2.7 kernel and declares that the 2.8 kernel will have a different ABI.
In practice, only people who held on to their old machines can assist in
the 2.7 development, since none of the vendor drivers, not even the ones
who still have a blob+glue construct care about the 'too rapid' moving
development tree.

August 21st. A serious security flaw is found in the 2.6 series, which
turns out to be a design flaw in a key sysfs API. Fixing this flaw would
require to break the module ABI and practically all modules out there,
while not fixing this flaw leaves a potential roothole open. A quick fix
is made available under a CONFIG_ option, but users who need binary
drivers have no choice but leave their systems vulnerable. Flamewars on
lkml flare up again that say Linus made a mistake in freezing the
existing ABI rather than creating a new one designed to be frozen. 2.7
development has mostly stagnated and a patch is proposed to have 2.7
have the 2.6 ABI again, reverting several key VM subsystem improvements
and Ingo's realtime patches.

August 26th. A precooked exploit for the security hole hits bugtraq, and
has been sighted in the wild as used by various rootkits. A php exploit
uses it to go from the httpd user to root. Users are putting pressure on
module vendors to release modules for the new ABI, and several actually
do so in the next three weeks. Others, mostly in the consumer area, say
that the hardware in question is no longer sold and that they aren't
going to spend any time or effort on drivers for it.






Now this scenario may sound unlikely to you. And thankfully the main
assumption (the December 6th event) is extremely unlikely.

However, and this unfortunately, several of the other "leaps" aren't
that unlikely. In fact, some of these results are likely to happen
regardless; witness the flamewars on lkml about breaking module API/ABI.
Witness the ndiswrapper effect of vendors now saying "we support linux
because ndiswrapper can use our windows driver". I hope they won't
happen. Some of that hope will be idle hope, but I believe that the
advantages of freedom in the end are strong enough to overcome the
counter forces.
Dave Airlie
2005-12-05 11:39:42 UTC
Permalink
Post by Arjan van de Ven
Several hardware vendors that have been friendly to open source so far,
see their competitors ship only binary drivers, and internally they
start to see pressure to also keep the IP private, and they know that
they haven't used some features of the hardware because their legal
department didn't want that IP in the public. As a result they perceive
their competitors binary drivers to be at a theoretical advantage, or at
least their own drivers could be at an advantage if they were also
closed, because they then can use those few extra features to be ahead
of the competition. By February 1st 2006, about half the hardware
vendors have refocused their internal linux driver efforts to create
value adds in the binary drivers they will release in addition to the
open drivers that already exist. Some vendors even openly stopped
supporting the open drivers because they don't have enough resources
to do both.
This is pretty much how the 3D drivers has gone down (as I'm sure
Arjan knows) but just to back it up with others, ATI released enough
info to make a basic 3D driver for their hardware to do OpenGL, they
didn't give out any info on the "protected IP" like HyperZ, MPEG
decoder, SmartShader, the list goes on, a lot of this has since been
reverse engineered for the older chips, then NVIDIA didn't release any
open source drivers, then ATI decided to go close source as they
couldn't compete on the feature set they were willing (allowed by
lawyers) to put into the open source drivers. ATI engineers now use
the excuse well NVIDIA have a closed source driver so we have to have
one to compete. Again neither company is willing to put resources into
doing much on the open source scene due to lack of staff, reasons, and
neither company is willing to give info to open source developers
because they need to push it all past their legal departments (despite
this info existing and a number of open source developers having
access to it via $job).

Intel are now starting to think about doing closed source only drivers
from what I heard on the grapevine, and as their open drivers only
provide modesetting via the BIOS, their drivers aren't exactly useful
in many situations..

Its a slippery slippery slope and all you people that bitch and moan
about stable API really don't have a clue what it means, Arjans
scenario is quite practical (it may take longer to happen but I doubt
the future would be much different..)

You'd also have issues with two binary drivers doing things in the
kernel that might affect each other, like bad interrupt sharing or
messing with pci setups for higher speeds, and no chance of getting
them working in any controlled fashion together without vendor
support.

Dave.
Xavier Bestel
2005-12-05 13:55:29 UTC
Permalink
Post by Dave Airlie
This is pretty much how the 3D drivers has gone down
.. and it doesn't look like the Xorg people are willing/able to do
something against that: witness the current thread named "Official
method for determining modular X module path?" on Xorg's mailing-list
which deals *exactely* with Arjan's theoretical problems of
cross-distributions modules compatibility, with the same pragmatism that
made Linus choose Bitkeeper.
As one can consider Xorg as being a device driver, albeit in userspace,
you see that the 3D part isn't going up any time soon.
William Lee Irwin III
2005-12-05 12:18:51 UTC
Permalink
Post by Arjan van de Ven
Now this scenario may sound unlikely to you. And thankfully the main
assumption (the December 6th event) is extremely unlikely.
However, and this unfortunately, several of the other "leaps" aren't
that unlikely. In fact, some of these results are likely to happen
regardless; witness the flamewars on lkml about breaking module API/ABI.
Witness the ndiswrapper effect of vendors now saying "we support linux
because ndiswrapper can use our windows driver". I hope they won't
happen. Some of that hope will be idle hope, but I believe that the
advantages of freedom in the end are strong enough to overcome the
counter forces.
The December 6 event is extraordinarily unlikely. What's vastly more
likely is consistent "erosion" over time. First the 3D video drivers,
then the wireless network drivers, then the fakeraid drivers, and so on.
Each instance degrades Linux' capabilities without such drivers, and
incrementally reduces the userbase of newer releases. I doubt there will
be a "revolutionary" step at all, just progressively more erosion over
time. As things go, Linux gets "flakier" as binary modules break for
people when they upgrade, new versions support less hardware as the
binary modules hobble them, and so on. DRM even threatens to prevent
some machines from booting Linux in the categorical sense.

I expect the closed source IP affairs rather to keep chipping away
until Linux is dead, or they get tired and change strategies to kill it,
versus any sudden changes of course.


-- wli
Pekka Enberg
2005-12-05 13:07:30 UTC
Permalink
Post by William Lee Irwin III
I expect the closed source IP affairs rather to keep chipping away
until Linux is dead, or they get tired and change strategies to kill it,
versus any sudden changes of course.
Alternatively, take away ndiswrapper and binary-only ATI and NVIDIA
drivers, and perhaps the users will start to care and pressure their
vendor to open up. I know I have become a very disappointed ATI
customer after figuring out that they have zero interest in me using
the hardware I paid for on Linux...

Pekka
Alistair John Strachan
2005-12-05 18:44:56 UTC
Permalink
Post by Pekka Enberg
Post by William Lee Irwin III
I expect the closed source IP affairs rather to keep chipping away
until Linux is dead, or they get tired and change strategies to kill it,
versus any sudden changes of course.
Alternatively, take away ndiswrapper and binary-only ATI and NVIDIA
drivers, and perhaps the users will start to care and pressure their
vendor to open up. I know I have become a very disappointed ATI
customer after figuring out that they have zero interest in me using
the hardware I paid for on Linux...
The problem with this approach is the tiny size of the minority of customers
using ATI's video cards on a non-Windows OS.

I think the only way we can persuade vendors to not take the direction that
Arjan speculates they will, is to increase the Linux userbase (and therefore
ATI customers using Linux) by making "Desktop Linux" increasingly competent.

As easy as it is to be pessimistic about binary vendor lockin, there's still
places in industry, government and inevitably the general public where Linux
is slowly starting to take off as a real desktop alternative to Windows.

When this happens, vendors will just have to solve all the IP nonsense
associated with their hardware, or design hardware to be more dependent on
firmware so that largely open source drivers are more feasible for them.
--
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Gene Heskett
2005-12-05 19:47:41 UTC
Permalink
Post by Alistair John Strachan
Post by Pekka Enberg
Post by William Lee Irwin III
I expect the closed source IP affairs rather to keep chipping away
until Linux is dead, or they get tired and change strategies to
kill it, versus any sudden changes of course.
Alternatively, take away ndiswrapper and binary-only ATI and NVIDIA
drivers, and perhaps the users will start to care and pressure their
vendor to open up. I know I have become a very disappointed ATI
customer after figuring out that they have zero interest in me using
the hardware I paid for on Linux...
The problem with this approach is the tiny size of the minority of
customers using ATI's video cards on a non-Windows OS.
Hey, I resemble that remark. I've been using an ATI XTacy 9200SE for
a couple of years now, since an nvidia card crowbared the buss & blew out
a
motherboard. Needless to say, I wasn't happy with nvidia over that.
I bought a faster cpu & more ram on a different mobo for this machine.

But, get this: Another new board, with the same cpu & ram on it, is
now running that cpu 70F degrees cooler, at 200 mhz faster on the cpu
clock. With another nvidia card in it, running my milling machine.
Post by Alistair John Strachan
I think the only way we can persuade vendors to not take the direction
that Arjan speculates they will, is to increase the Linux userbase
(and therefore ATI customers using Linux) by making "Desktop Linux"
increasingly competent.
I'm not a 'gamer' so the last frame per second isn't that important
to me, but its close to 1000 on a small piece of a 1600x1200 screen.
Post by Alistair John Strachan
As easy as it is to be pessimistic about binary vendor lockin, there's
still places in industry, government and inevitably the general public
where Linux is slowly starting to take off as a real desktop
alternative to Windows.
Its been my alternative since 1998, never was windows here, coming in
from the amiga world.
Post by Alistair John Strachan
When this happens, vendors will just have to solve all the IP nonsense
associated with their hardware, or design hardware to be more dependent
on firmware so that largely open source drivers are more feasible for
them.
Don't hold your breath, its not healthy in the long view...
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Jeff Garzik
2005-12-05 17:18:34 UTC
Permalink
Post by Arjan van de Ven
Linux in a binary world
You forgot the effect of binary-only on non-x86 arches...

Jeff
Jan-Benedict Glaw
2005-12-05 17:29:16 UTC
Permalink
Post by Jeff Garzik
Post by Arjan van de Ven
Linux in a binary world
You forgot the effect of binary-only on non-x86 arches...
Um, let's write an binary emulator for those archs. It did work for
Alphas executing i386 code, so it'd work for PPC, too :-)

MfG, JBG
--
Jan-Benedict Glaw ***@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fÃŒr einen Freien Staat voll Freier BÃŒrger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Bernd Petrovitsch
2005-12-05 22:52:02 UTC
Permalink
Post by Jan-Benedict Glaw
Post by Jeff Garzik
Post by Arjan van de Ven
Linux in a binary world
You forgot the effect of binary-only on non-x86 arches...
Um, let's write an binary emulator for those archs. It did work for
Alphas executing i386 code, so it'd work for PPC, too :-)
And a few years later the PPC arch is also dead?

SCNR,
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Andrew Walrond
2005-12-05 18:26:06 UTC
Permalink
Post by Arjan van de Ven
a hypothetical doomsday scenario by Arjan van de Ven
Can I ask what prompted your post?
Post by Arjan van de Ven
On December 6th, 2005 the kernel developers en mass decide that binary
modules are legally fine and also essential for the progress of linux,
Has anyone (influential) actually being toying with this idea? I hope not, but
if they are, I'd like to know who to lobby...

Andrew Walrond
Arjan van de Ven
2005-12-05 18:34:01 UTC
Permalink
Post by Andrew Walrond
Post by Arjan van de Ven
a hypothetical doomsday scenario by Arjan van de Ven
Can I ask what prompted your post?
I got one too many hatemails from a "nvidia fanboy" who blamed me for
just about anything wrong in the world.... I fear that most of these
people have no idea why open source drivers matter, or at least what the
consequences are for not caring about drivers being open or not.
Post by Andrew Walrond
Post by Arjan van de Ven
On December 6th, 2005 the kernel developers en mass decide that binary
modules are legally fine and also essential for the progress of linux,
Has anyone (influential) actually being toying with this idea? I hope not, but
if they are, I'd like to know who to lobby...
this part of the "story" is fiction. A lot of the rest is not. There are
already several servers that you can only use with binary modules..
modules only available in full binary form for RHEL and SLES kernels for
example.
j***@ns1.utah-nac.org
2005-12-05 19:41:49 UTC
Permalink
Welcome to reality.

Jeff
Post by Arjan van de Ven
Post by Andrew Walrond
Post by Arjan van de Ven
a hypothetical doomsday scenario by Arjan van de Ven
Can I ask what prompted your post?
I got one too many hatemails from a "nvidia fanboy" who blamed me for
just about anything wrong in the world.... I fear that most of these
people have no idea why open source drivers matter, or at least what the
consequences are for not caring about drivers being open or not.
Post by Andrew Walrond
Post by Arjan van de Ven
On December 6th, 2005 the kernel developers en mass decide that binary
modules are legally fine and also essential for the progress of linux,
Has anyone (influential) actually being toying with this idea? I hope not, but
if they are, I'd like to know who to lobby...
this part of the "story" is fiction. A lot of the rest is not. There are
already several servers that you can only use with binary modules..
modules only available in full binary form for RHEL and SLES kernels for
example.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Woodhouse
2005-12-05 21:19:35 UTC
Permalink
Post by Andrew Walrond
Post by Arjan van de Ven
On December 6th, 2005 the kernel developers en mass decide that binary
modules are legally fine and also essential for the progress of linux,
Has anyone (influential) actually being toying with this idea? I hope not, but
if they are, I'd like to know who to lobby...
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e3c3374fbf7efe9487edc53cd10436ed641983aa

Remember that the only distinction between EXPORT_SYMBOL() and
EXPORT_SYMBOL_GPL() is that the latter is a technological measure to
prevent abuse. The use of EXPORT_SYMBOL_GPL() cannot actually impose any
additional restrictions over and above what the GPL requires of
EXPORT_SYMBOL() -- because any additional restrictions would themselves
violate the GPL.

Thus, the only point in the above-linked patch is to remove a technical
measure which prevents abuse. I feel very strongly that it should be
reverted.
--
dwmw2
Arjan van de Ven
2005-12-05 21:24:38 UTC
Permalink
Post by David Woodhouse
Post by Andrew Walrond
Post by Arjan van de Ven
On December 6th, 2005 the kernel developers en mass decide that binary
modules are legally fine and also essential for the progress of linux,
Has anyone (influential) actually being toying with this idea? I hope not, but
if they are, I'd like to know who to lobby...
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e3c3374fbf7efe9487edc53cd10436ed641983aa
I think you're wrong on this. Not about thinking it should be reverted
per se, but in the big picture it's not linked to the scenario. One
export more or less doesn't matter at all.
David Woodhouse
2005-12-05 21:54:44 UTC
Permalink
Post by Arjan van de Ven
I think you're wrong on this. Not about thinking it should be reverted
per se, but in the big picture it's not linked to the scenario. One
export more or less doesn't matter at all.
Yeah, I suppose that's true to a large extent, but the fact that Linus
is actively aiding and abetting a licence violator by reverting this
particular symbol from EXPORT_SYMBOL_GPL() to EXPORT_SYMBOL() sends a
very strong message. And it's not one which we should be sending.

Linus chose not to collect copyright assignments; therefore this kind of
decision isn't his to make. We are bound by the GPL and (GPLv3 aside) we
have no practical option to change that -- by royal decree or otherwise.

I think it's time to recognise that there's no difference in licensing
terms between EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). The _only_
difference is that the latter will lead to harsher punishments for
violators because it needs to be actively circumvented.

We should switch _everything_ to EXPORT_SYMBOL_GPL(). It can't change
the licensing question at all -- if binary-only modules were legal
before they will _still_ be legal, because we're not allowed to impose
additional restrictions anyway. But the change does strengthen the case
against anyone found to be in violation of the licence, because they
have to deliberately circumvent the protection it implies.
--
dwmw2
Tim Bird
2005-12-05 23:56:06 UTC
Permalink
Post by David Woodhouse
I think it's time to recognise that there's no difference in licensing
terms between EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL().
I disagree. I think that has long since become the intent
of EXPORT_SYMBOL_GPL().

If the GPL covers interface linkages (whether static or
dynamic) then EXPORT_SYMBOL_GPL is redundant. If it does
not, in all cases, then EXPORT_SYMBOL_GPL is, as
an extension to GPL, therefore a GPL violation.

I believe there are cases where an interface could
be deemed not coverable by the GPL. Putting
EXPORT_SYMBOL_GPL around it would be an attempt
to extend GPL to where it otherwise might not reach.

DISCLAIMER: I'm not speaking for Sony here. Personally
I don't believe that most drivers are derivative works
of the operating systems they run with, and I don't
believe it helps Linux to assert that they are.
But, hey, it's not my kernel, and not my plan for
world domination. ;-)

To the larger argument about supporting binary drivers,
all Arjan manages to prove with his post is that,
if handled in the worst possible way, support for
binary drivers would be a disaster. Who can disagree
with that?

(I'm really not trolling or trying to start a flame
war here. It's just my 2 cents.)

Regards,
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
Dave Airlie
2005-12-06 00:10:08 UTC
Permalink
Post by Tim Bird
To the larger argument about supporting binary drivers,
all Arjan manages to prove with his post is that,
if handled in the worst possible way, support for
binary drivers would be a disaster. Who can disagree
with that?
And do you think that given the opportunity, any company is going
spend the extra money required to not do it in the worst possible
way?? Companies want to spend as little as possible on drivers, and
drop support as soon as it makes sense financially to do so, they
aren't going to come to the correct best possible way on their own, or
via consortia of companies ala CEL or OSDL, they require outside
pressure to make them change their mindset from the only example they
have which is developing Windows drivers..

Dave.
Bernd Petrovitsch
2005-12-06 00:14:43 UTC
Permalink
On Mon, 2005-12-05 at 15:56 -0800, Tim Bird wrote:
[...]
Post by Tim Bird
To the larger argument about supporting binary drivers,
all Arjan manages to prove with his post is that,
if handled in the worst possible way, support for
binary drivers would be a disaster. Who can disagree
with that?
And it is the to-be-expected way for all companies/corporations/
commercial entities where none-techies are the decision makers (the
condition is a sufficient one but not a necessary one) - ethics and/or
fairness are pretty irrelevant there if there seems to a problem with
sales, stakeholders value, bonuses of management and especially the
deciders themselves etc.
Yes, that may be rude. Sorry, that is reality.

In one word: It will doubtless go that way because only short-term
"success" is relevant (i.e. just to get as much money as possible out of
it *now*) and the devil may care ....

Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Matthieu CASTET
2005-12-05 23:24:42 UTC
Permalink
Post by Arjan van de Ven
Linux in a binary world
=20
=20
What if.. what if the linux kernel developers tomorrow accept that
binary modules are OK and are essential for the progress of linux.=20
=20
[...]
Post by Arjan van de Ven
Now this scenario may sound unlikely to you. And thankfully the main
assumption (the December 6th event) is extremely unlikely. =20
=20
However, and this unfortunately, several of the other "leaps" aren't
that unlikely. In fact, some of these results are likely to happen
regardless; witness the flamewars on lkml about breaking module API/A=
BI.
Post by Arjan van de Ven
Witness the ndiswrapper effect of vendors now saying "we support linu=
x
Post by Arjan van de Ven
because ndiswrapper can use our windows driver". I hope they won't
happen. Some of that hope will be idle hope, but I believe that the
advantages of freedom in the end are strong enough to overcome the
counter forces.
And some embedded companies provide the minimal source code to put=20
in arch and everything else (ethernet, adsl, wifi, ...) is binaries
modules.
Continue reading on narkive:
Loading...