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.
> 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.
On Mon, Dec 05, 2005 at 11:52:32AM +0100, Arjan van de Ven wrote:
> 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
On 12/5/05, William Lee Irwin III <[email protected]> wrote:
> 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
On Mon, 2005-12-05 at 12:39, Dave Airlie wrote:
> 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.
Arjan van de Ven wrote:
> Linux in a binary world
You forgot the effect of binary-only on non-x86 arches...
Jeff
On Mon, 2005-12-05 12:18:34 -0500, Jeff Garzik <[email protected]> wrote:
> Arjan van de Ven wrote:
> >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 [email protected] . +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));
On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
>
> a hypothetical doomsday scenario by Arjan van de Ven
>
Can I ask what prompted your post?
>
> 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
On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
> On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
> >
> > 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.
>
> >
> > 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.
On Monday 05 December 2005 13:07, Pekka Enberg wrote:
> On 12/5/05, William Lee Irwin III <[email protected]> wrote:
> > 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.
On Monday 05 December 2005 13:44, Alistair John Strachan wrote:
>On Monday 05 December 2005 13:07, Pekka Enberg wrote:
>> On 12/5/05, William Lee Irwin III <[email protected]> wrote:
>> > 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.
>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.
>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.
>
>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.
Welcome to reality.
Jeff
On Mon, Dec 05, 2005 at 07:34:01PM +0100, Arjan van de Ven wrote:
> On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
> > On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
> > >
> > > 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.
>
>
> >
> > >
> > > 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
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
> > 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
On Mon, 2005-12-05 at 21:19 +0000, David Woodhouse wrote:
> On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
> > > 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.
On Mon, 2005-12-05 at 22:24 +0100, Arjan van de Ven wrote:
> 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
On Mon, 2005-12-05 at 18:29 +0100, Jan-Benedict Glaw wrote:
> On Mon, 2005-12-05 12:18:34 -0500, Jeff Garzik <[email protected]> wrote:
> > Arjan van de Ven wrote:
> > >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
Le Mon, 05 Dec 2005 11:52:32 +0100, Arjan van de Ven a ?crit?:
> 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.
>
[...]
> 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.
And some embedded companies provide the minimal source code to put
in arch and everything else (ethernet, adsl, wifi, ...) is binaries
modules.
David Woodhouse wrote:
> 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
=============================
> 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.
On Mon, 2005-12-05 at 15:56 -0800, Tim Bird wrote:
[...]
> 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
Dave Airlie wrote:
>>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??
I meant "handled in the worst possible way by
the kernel developers". It *is* possible to define
stable APIs and have them used successfully.
POSIX is not the greatest example, but it seems
to work OK. I realize that drivers are more
tightly bound to the kernel than are libraries
or applications, but sheesh, this is not rocket
science.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
Tim Bird wrote:
> I meant "handled in the worst possible way by
> the kernel developers". It *is* possible to define
> stable APIs and have them used successfully.
>
> POSIX is not the greatest example, but it seems
> to work OK.
Oops. I should have said "the syscalls supporting POSIX"
to refer to the kernel binary API for applications.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
On Mon, 2005-12-05 at 15:56 -0800, Tim Bird wrote:
> 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.
You seem to be agreeing with me to a certain extent. What I'm saying is
that there _can_ be no difference between EXPORT_SYMBOL() and
EXPORT_SYMBOL_GPL(). We might as well stick to one or the other.
As you say -- if the GPL covers modules, EXPORT_SYMBOL_GPL is redundant.
If it does not, then EXPORT_SYMBOL_GPL in itself is a GPL violation.
The point of EXPORT_SYMBOL_GPL, however, is that it is a technical
restriction which needs to be circumvented in order to load a non-GPL
module. That does affect the outcome of a court case when the licence is
violated, and that's why I think we should it throughout.
However, if your lawyers promise you that the court won't rule that the
GPL covers modules, then you have nothing to fear from EXPORT_SYMBOL_GPL
because (according to your lawyers) the court will rule that it means no
more than EXPORT_SYMBOL does. That's your risk to take; there's no
reason why we should use EXPORT_SYMBOL _anywhere_ until/unless a court
actually makes that ruling.
--
dwmw2
On Mon, Dec 05, 2005 at 03:56:06PM -0800, Tim Bird wrote:
> 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.
The last time I spoke with Linus about this, what I understood can be
described in two points:
1) EXPORT_SYMBOL_GPL is an hint: if you have to circumvent it, there are
high chances that you're creating a derivative of the linux kernel and
in turn there are high chances that you're illegal
2) The fact you're illegal or not, has nothing to do with the _GPL tag
in the exports, the illegal usage is when the module create a derivative
of the linux kernel.
Now I don't know for sure myself (I'm not a lawyer) what is a derivative
of the linux kernel (don't ask me), but the two above points are quite
clear to me.
I always thought the _GPL tag could have no direct legal implications
and Linus confirmed it. The kernel is GPL so everyone can modify the
exports or re-export symbols as usual, the exports are GPL code too. The
guy who re-exports or remove a _GPL tag is just modifying a GPL code, so
he's ok.
The _GPL tag is useful as an hint to binary only vendors as as such it
makes perfect sense.
On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
> 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.
I agree about the erosion.
I am convinced that the only way to stop the erosion is to totally stop
buying hardware that has only binary only drivers (unless you buy it to
create an open source driver or to reverse engineer the binary only
driver of course! ;).
For example if a laptop has an embedded wirless or 3d card not supported by
open source drivers, buy a laptop without any wireless card or without
3d, instead of buying one with the not-supported hardware without using
it (I can guarantee there are still laptops that requires no 3d
binary only drivers and no wirless cards drivers, even for the winmodems
you can choose the ones supported by alsa). We literally have to refuse
buying those cards with binary only kernel drivers.
Every time we buy a piece of hardware with binary only drivers we admit
that the binary only driver vendors are doing the right choice for their
stockholders. Only when we refuse to buy it, we can make a slight difference.
When we don't buy hardware without open source drivers, we send the
message to the shareholders that the management is causing them a loss.
It's market forces controlling which drivers are open sources and which
aren't (the risk of being sued and the cost of the laywers is only part
of the more complex equation), and the customers have an huge strength
in controlling those forces (we effectively control 50% of it).
The fact Arjan got the "nvidia fanboy" complaining, is the sign that
some people just don't care. This understandable for a 3d kind of
product which is 90% for entertainment (nobody loses money when it
crashes), and we generally can't expect everyone to care about the long
term kernel development.
But at least for all more business oriented usages of linux, linux users
should understand the erosion they create by funding companies that
requires binary only drivers.
Every time we buy an hardware with a binary only driver, we effectively
increase the erosion, or we give a sound reason to those company to keep
eroding.
I think messages like the one from Arjan are very positive to let people
understand the long term effect of binary only drivers, but this should
be combined with the strategy to use to reduce the erosion (i.e. not to
buy hardware that has binary only drivers).
Perhaps we should add a printk that points to an url on kernel.org
including Arjan's message every time a non-gpl module gets loaded by the
kernel. I think it's a matter of educating the customer too or they can
do mistakes, creating a blacklist would help too.
I don't believe in the breaking of the 3d drivers gratuitously, it
should be market forces deciding which drivers have to be open sources
and which not. But our side of the market (i.e. the buyers) must be
educated properly.
Andrea Arcangeli wrote:
> On Mon, Dec 05, 2005 at 03:56:06PM -0800, Tim Bird wrote:
>
>>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.
>
> The last time I spoke with Linus about this, what I understood can be
> described in two points:
>
> 1) EXPORT_SYMBOL_GPL is an hint: if you have to circumvent it, there are
> high chances that you're creating a derivative of the linux kernel and
> in turn there are high chances that you're illegal
>
> 2) The fact you're illegal or not, has nothing to do with the _GPL tag
> in the exports, the illegal usage is when the module create a derivative
> of the linux kernel.
>
> Now I don't know for sure myself (I'm not a lawyer) what is a derivative
> of the linux kernel (don't ask me), but the two above points are quite
> clear to me.
This interpretation puts kernel developers in the
position of making the legal decision about which
interfaces cause derivate-work risk and which
do not. That's hardly a recipe for legal clarity.
(Not that legal clarity is a goal of Linux
kernel development... :-)
Different developers are likely to have
different viewpoints on which interfaces pose risks.
I guess Linus gets the last call (as usual),
so there's some possibility of some amount
of uniformity here.
Most kernel developers will naturally tend
towards making more symbols EXPORT_SYMBOL_GPL,
whether there's valid legal basis for it or not.
(Please let me know if there's a lawyer somewhere
reviewing the insertion of EXPORT_SYMBOL_GPLs)
David currently suggests that *all* interfaces
be so designated. I suspect he strongly believes
that any use of a kernel interface creates a
derivative work. I have a different opinion.
...
> The _GPL tag is useful as an hint to binary only vendors as as such it
> makes perfect sense.
Well, if it makes sense to have developers giving out legal
advice, then I guess so.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
On Mon, Dec 05, 2005 at 05:20:16PM -0800, Tim Bird wrote:
> This interpretation puts kernel developers in the
> position of making the legal decision about which
An hint can hardly defined as a "legal decision".
An hint _only_ means "be careful you _might_ be illegal".
"might be" is hardly a "legal deicision", infact it's not decision at
all.
It's like a "you should check your stuff to be sure you're ok".
This is the way I understood it at least...
> Different developers are likely to have
> different viewpoints on which interfaces pose risks.
The way I understood it, is that you may be breaking the GPL even if you
don't circumvent any _GPL tag. You've to check your stuff yourself, and
if you have troubles because of a _GPL tag, it means you must check it
even more closely because you got an explicit _warning_. A warning isn't
a "legal deicsion", it's just a warning.
> I guess Linus gets the last call (as usual),
> so there's some possibility of some amount
> of uniformity here.
agreed.
> Most kernel developers will naturally tend
> towards making more symbols EXPORT_SYMBOL_GPL,
> whether there's valid legal basis for it or not.
Could be, but then those developers would be wrong. We're not required
to make a symbol as _GPL to make the module illegal. So we should be
reasonable.
> (Please let me know if there's a lawyer somewhere
> reviewing the insertion of EXPORT_SYMBOL_GPLs)
I don't think there is one, and there needs to be no one, because the
_GPL tag is not a legal decision, is an hint given from programmers to
lawyers. Programmers may be totally wrong, but we do our best to help on
the legal side too.
> David currently suggests that *all* interfaces
> be so designated. I suspect he strongly believes
> that any use of a kernel interface creates a
> derivative work. I have a different opinion.
This question I don't want to answer because I'm a programmer, this
requires a lawyer because this is the real _legal_decision_: what is a
derived work of the kernel is the only thing that decides what is legal
and illegal.
> Well, if it makes sense to have developers giving out legal
> advice, then I guess so.
;) Of course I meant it makes perfect sense that it's _only_ an "hint".
Andrea Arcangeli wrote:
> On Mon, Dec 05, 2005 at 05:20:16PM -0800, Tim Bird wrote:
>
>>This interpretation puts kernel developers in the
>>position of making the legal decision about which
>
>
> An hint can hardly defined as a "legal decision".
>
> An hint _only_ means "be careful you _might_ be illegal".
>
> "might be" is hardly a "legal deicision", infact it's not decision at
> all.
Correct. It's largely a demonstration of "intent" -- which is both a
legal and a common sense concept. It's not a legally binding <anything>.
IANAL, of course.
Jeff
On Monday 05 December 2005 19:10, Dave Airlie wrote:
>> 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..
>
Which is the best reason in the world to buy and use, the open source
video card now under development, and I hear its less than 3-4 months
from production status now, and at a competitive, sub $150 USD price.
If 50% of nvidia's currant linux market share were to dissappear a month
after this card becomes available for purchase by those whom one might
categorize as believers, I'd think that would send a message loud enough
to be heard.
Particularly if windows drivers are available, open sourced, and
installable on a winderz box using the normal install wizard, and
promoted as such to the joe six-packs of the world. At the right price,
that would send an even louder message to both nvidia and ati, who so
far, seems to be all hat & no cattle. While the drivers in x.orgs code
seem to be working fairly well, and absolutely stable, I'm sure there
are hardware things in this 9200SE I have here that are not being used
by x.org's code. It works well enough to play tux-racer, but not well,
keyboard response acts like the machine is being hogged by the video.
>Dave.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
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.
Andrea Arcangeli wrote:
> On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
>> 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.
>
> I agree about the erosion.
>
> I am convinced that the only way to stop the erosion is to totally stop
> buying hardware that has only binary only drivers (unless you buy it to
> create an open source driver or to reverse engineer the binary only
> driver of course! ;).
>
> For example if a laptop has an embedded wirless or 3d card not supported by
> open source drivers, buy a laptop without any wireless card or without
> 3d, instead of buying one with the not-supported hardware without using
> it (I can guarantee there are still laptops that requires no 3d
> binary only drivers and no wirless cards drivers, even for the winmodems
> you can choose the ones supported by alsa). We literally have to refuse
> buying those cards with binary only kernel drivers.
>
> Every time we buy a piece of hardware with binary only drivers we admit
> that the binary only driver vendors are doing the right choice for their
> stockholders. Only when we refuse to buy it, we can make a slight difference.
> When we don't buy hardware without open source drivers, we send the
> message to the shareholders that the management is causing them a loss.
The problem with this statement is that Linux users are a drop in the
bucket of sales for this hardware. Boycotting doesn't cost the vendors
enough to make them care. And this does nothing for people who are
converting over to Linux, and didn't buy hardware with that
consideration in mind.
The only way to break the stalemate is to reverse engineer drivers.
Turning the screws tighter isn't going to make open drivers magically
appear. More likely, the vendors will abandon Linux as being too
hostile and/or too costly to support, leaving everybody back at square one.
--
Brian Gerst
Hi Arjan,
You know I like to chime in from time to time on this subject, mostly for
fun.
Inside the your position, many (non-linux people) have seen a position
which appears to be acceptable when added with the classic "IFF" or
"If and only IF" conditionals.
Binary Blob + source glue layer == psuedo module.
The arguement implies this is okay in theory but practice has proven it
falls apart. However, the remander represents a snap back direction to
the otherside. This make one wonder if server hardware direction goes
this way regardless of the opensource ideas, what really prevents the
hardware vendors from abandoning Linux. Does anyone really know what the
actual percentage is for a given company's topline v/s bottom line revenue
broken down as a ratio of open source customers revenue/totals v/s other
customers revenue/totals.
If there was some way to obtain such information, this could lead credence
or negate the arguement about open source drivers.
Please know the comments are about "open source" only and does not take a
position on any given license associated to the work.
Cheers,
Andre
PS this is for the arena of ideas and not material to flame.
On Mon, 5 Dec 2005, Arjan van de Ven wrote:
> 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.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, Dec 05, 2005 at 09:31:30AM -0500, Brian Gerst wrote:
> The problem with this statement is that Linux users are a drop in the
> bucket of sales for this hardware. Boycotting doesn't cost the vendors
> enough to make them care. And this does nothing for people who are
> converting over to Linux, and didn't buy hardware with that
> consideration in mind.
Effectively this is why 3d drivers are the only thing we litearlly lost
control of. But my email was general. I wasn't only speaking of 3d
hardware.
For 3d you're very well right, but once linux becomes mainstream in the
desktop, things could change.
Also note, I've some 3d on my laptop but I need no binary only drivers
for it, so there's some option.
Currently in KLive I can see there are about 44% of the users with the
nvidia driver loaded (once I have time to work on klive again, I'll
make the new data browsable on the web, I had to query the db by hand to
see it right now, ironically there are about 80 sessions where the
_only_ driver loaded is the nvidia one and everything else is static ;).
> The only way to break the stalemate is to reverse engineer drivers.
> Turning the screws tighter isn't going to make open drivers magically
> appear. More likely, the vendors will abandon Linux as being too
> hostile and/or too costly to support, leaving everybody back at square one.
Let's not forget they make money selling the hardware, the binary only
driver is free. And releasing an open source driver if something will
decrease their maintainance costs. The only thing this binary only
driver does is to avoid them _risks_, but they gain no money by keeping
it binary only. So the day they will be losing money by keeping the
driver binary only, I expect they may open it. They simply have no
reason to do it right now.
However this will only work out if we exercise our buyer rights (again
in general). To make the counter example, if we would suddently start to
prefer hardware with binary only drivers, then the doomsay scenario may
materialize with quick erosion.
In the meantime I don't like gratuitous breakages, I prefer that they
open it because it makes sense for them. Breaking it gratuitously is
what could make linux hostile and too costly to support IMHO.
On Mon, 5 Dec 2005, Gene Heskett wrote:
> Which is the best reason in the world to buy and use, the open source
> video card now under development, and I hear its less than 3-4 months
> from production status now, and at a competitive, sub $150 USD price.
>
> If 50% of nvidia's currant linux market share were to dissappear a month
> after this card becomes available for purchase by those whom one might
> categorize as believers, I'd think that would send a message loud enough
> to be heard.
>
> Particularly if windows drivers are available, open sourced, and
> installable on a winderz box using the normal install wizard, and
> promoted as such to the joe six-packs of the world. At the right price,
> that would send an even louder message to both nvidia and ati
Do you think this opensource hardware could keep up with nvidia and ati
hardware development? Joe sixpack is all about the fastest hardware.
On Mon, Dec 05, 2005 at 04:23:57PM -0800, Tim Bird wrote:
> Dave Airlie wrote:
> >>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??
>
> I meant "handled in the worst possible way by
> the kernel developers". It *is* possible to define
> stable APIs and have them used successfully.
>
> POSIX is not the greatest example, but it seems
> to work OK. I realize that drivers are more
> tightly bound to the kernel than are libraries
> or applications, but sheesh, this is not rocket
> science.
For people to think that the kernel developers are just "too dumb" to
make a stable kernel api (and yes, I've had people accuse me of this
many times to my face[1]) shows a total lack of understanding as to
_why_ we change the in-kernel api all the time. Please see
Documentation/stable_api_nonsense.txt for details on this.
thanks,
greg k-h
[1] My usual response is, "If we are so dumb, why are you using the kernel
made by us?", which usually stops the conversation right there.
On Mon, Dec 05, 2005 at 03:56:06PM -0800, Tim Bird wrote:
> 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. ;-)
Why do people bring up the "derivative works" issue all the time. Are
they so blind to the very simple "linking" issue that all kernel modules
do when they are loaded into the kernel?
That's the much simpler reason for why numerous IP lawyers of big
companies that do Linux work feel that closed source Linux kernel
modules are not legal.
thanks,
greg k-h
On Mon, Dec 05, 2005 at 04:23:57PM -0800, Tim Bird wrote:
> I meant "handled in the worst possible way by
> the kernel developers". It *is* possible to define
> stable APIs and have them used successfully.
>
> POSIX is not the greatest example, but it seems
> to work OK. I realize that drivers are more
> tightly bound to the kernel than are libraries
> or applications, but sheesh, this is not rocket
> science.
You do realize that any attempt to create a stable API (which would
reduce the amount of exported symbols by factor of 50 to start with)
will have the parties currently advocating interface stability screaming
bloody murder?
Who do you think had been responsible for current mess? The people
who kept adding random exports with no rationale beyond "it's needed
for our code", that's who...
Greg KH <[email protected]> writes:
> On Mon, Dec 05, 2005 at 03:56:06PM -0800, Tim Bird wrote:
> > 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. ;-)
>
> Why do people bring up the "derivative works" issue all the time. Are
> they so blind to the very simple "linking" issue that all kernel modules
> do when they are loaded into the kernel?
Most likely people bring up the "derivative works" issue because
that's what the GPL says it affects. The FSF contends that linking
creates a derivative work, but is curiously quiet when people ask for
statutory or case law to support that claim.
Besides, if the act of linking is what makes the derivative work,
there is no problem: The GPL allows a user to make any modifications
or combinations or derivatives whatsoever, and only imposes
requirements when the result is distributed. The linking of the two
works occurs only on the end user's machine.
Michael Poole
Andrea Arcangeli wrote:
> On Mon, Dec 05, 2005 at 09:31:30AM -0500, Brian Gerst wrote:
>> The problem with this statement is that Linux users are a drop in the
>> bucket of sales for this hardware. Boycotting doesn't cost the vendors
>> enough to make them care. And this does nothing for people who are
>> converting over to Linux, and didn't buy hardware with that
>> consideration in mind.
>
> Effectively this is why 3d drivers are the only thing we litearlly lost
> control of. But my email was general. I wasn't only speaking of 3d
> hardware.
>
> For 3d you're very well right, but once linux becomes mainstream in the
> desktop, things could change.
>
> Also note, I've some 3d on my laptop but I need no binary only drivers
> for it, so there's some option.
Intel? That's all nice and dandy if and only if you have an Intel CPU.
Not an option for AMD users, for obvious reasons.
--
Brian Gerst
On Monday 05 December 2005 22:56, Zwane Mwaikambo wrote:
>On Mon, 5 Dec 2005, Gene Heskett wrote:
>> Which is the best reason in the world to buy and use, the open source
>> video card now under development, and I hear its less than 3-4 months
>> from production status now, and at a competitive, sub $150 USD price.
>>
>> If 50% of nvidia's currant linux market share were to dissappear a
>> month after this card becomes available for purchase by those whom
>> one might categorize as believers, I'd think that would send a
>> message loud enough to be heard.
>>
>> Particularly if windows drivers are available, open sourced, and
>> installable on a winderz box using the normal install wizard, and
>> promoted as such to the joe six-packs of the world. At the right
>> price, that would send an even louder message to both nvidia and ati
>
>Do you think this opensource hardware could keep up with nvidia and ati
>hardware development? Joe sixpack is all about the fastest hardware.
That I've no knowledge of. The developers are claiming pretty decent
performance from the breadboards now, in the top 85% I'd guess, but go
check their site for clarification on that. As to keeping up with new
hardware, if the sales support it, then even newer ones will always be
in the pipeline. The key to success is as always, sales propaganda in
Joe Six-packs face, and that, no surprise, costs money. So when it is
released, support it if you want to keep it alive. To me, thats a no
brainer. But who am I but an old fart on SS... If I can afford it,
certainly lots of you younger folks can too. Putting our money where
our mouth is makes perfect sense to me and I'll do it at least once.
Maybe 3 times as I have 3 boxes here.
--
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.
On Mon, Dec 05, 2005 at 08:08:20PM -0800, Greg KH wrote:
> For people to think that the kernel developers are just "too dumb" to
> make a stable kernel api (and yes, I've had people accuse me of this
> many times to my face[1]) shows a total lack of understanding as to
> _why_ we change the in-kernel api all the time. Please see
> Documentation/stable_api_nonsense.txt for details on this.
It's not about being dumb, but this problem is -I think- what prevents
some companies from releasing drivers for their hardware (when they
don't consider that opening it will give their IP away). I've played
several times with opensource drivers for ADSL modems, LCD modules,
watchdogs, ethernet adapters, IDE drivers, etc... and their problem
was that what worked well in 2.4.21 did not even build in 2.4.22
and became difficult to fix starting with 2.4.23. Most of those
small companies who propose a Linux driver simply start by paying
a student during summer for porting their windows/sco/whatever
driver to linux. They think the job is done when he leaves.
Unfortunately, they receive complaints 3 months later from users
because the driver is broken and does not build. They don't have
the resources to keep a permanent developer on it, and they
quickly understand that Linux is just a "geek OS" and that it's
the last time they release any driver.
Of course, you'll tell me that they can write the driver for
the major stable distros (RHEL, SLES, ...). But when they
don't really understand what Linux is, do you believe it's the
student who will tell them "I should write it for RHEL" ? No.
The student will decide "I will write it for vanilla kernel
and test it on my Debian because I hate proprietary systems".
Anyway, those who write drivers for RHEL have no problem
keeping them closed because their users generally don't
expect to read the sources.
> thanks,
>
> greg k-h
>
> [1] My usual response is, "If we are so dumb, why are you using the kernel
> made by us?", which usually stops the conversation right there.
I've already heard a funny response to this : "Usually I use *BSD, but
right now for an unknown reason, it does not install on this strange
machine, so I was FORCED to install Linux, but I will remove it once
I can fix my BSD" :-) It's the same as people who complain about windows
all the day and use it all the day.
Regards,
Willy
On Monday 05 December 2005 11:29, Jan-Benedict Glaw wrote:
> On Mon, 2005-12-05 12:18:34 -0500, Jeff Garzik <[email protected]> wrote:
> > Arjan van de Ven wrote:
> > >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 :-)
Fabrice Bellard beat you to it, QEMU, and yes it's GPL.
Trying to bolt it to the kernel would deeply suck.
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
On Tuesday December 6, [email protected] wrote:
> On Mon, Dec 05, 2005 at 08:08:20PM -0800, Greg KH wrote:
>
> > For people to think that the kernel developers are just "too dumb" to
> > make a stable kernel api (and yes, I've had people accuse me of this
> > many times to my face[1]) shows a total lack of understanding as to
> > _why_ we change the in-kernel api all the time. Please see
> > Documentation/stable_api_nonsense.txt for details on this.
>
> It's not about being dumb, but this problem is -I think- what prevents
> some companies from releasing drivers for their hardware (when they
> don't consider that opening it will give their IP away). I've played
> several times with opensource drivers for ADSL modems, LCD modules,
> watchdogs, ethernet adapters, IDE drivers, etc... and their problem
> was that what worked well in 2.4.21 did not even build in 2.4.22
> and became difficult to fix starting with 2.4.23. Most of those
> small companies who propose a Linux driver simply start by paying
> a student during summer for porting their windows/sco/whatever
> driver to linux. They think the job is done when he leaves.
> Unfortunately, they receive complaints 3 months later from users
> because the driver is broken and does not build. They don't have
> the resources to keep a permanent developer on it, and they
> quickly understand that Linux is just a "geek OS" and that it's
> the last time they release any driver.
>
> Of course, you'll tell me that they can write the driver for
> the major stable distros (RHEL, SLES, ...).
I won't tell you that.
I'd say that with a linux driver, the job isn't done it "works", but
rather the job is done when it "is merged".
Once it is merged, it will mostly be updated along with the rest of
the kernel, and if it breaks silently, there is probably someone
available who can fix it.
I think we should frown on out-of-tree drivers nearly as much as
closed-source drivers.
NeilBrown
2005/12/6, Greg KH <[email protected]>:
> On Mon, Dec 05, 2005 at 04:23:57PM -0800, Tim Bird wrote:
> > Dave Airlie wrote:
> > >>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??
> >
> > I meant "handled in the worst possible way by
> > the kernel developers". It *is* possible to define
> > stable APIs and have them used successfully.
> >
> > POSIX is not the greatest example, but it seems
> > to work OK. I realize that drivers are more
> > tightly bound to the kernel than are libraries
> > or applications, but sheesh, this is not rocket
> > science.
>
> For people to think that the kernel developers are just "too dumb" to
> make a stable kernel api (and yes, I've had people accuse me of this
> many times to my face[1]) shows a total lack of understanding as to
> _why_ we change the in-kernel api all the time. Please see
> Documentation/stable_api_nonsense.txt for details on this.
>
> thanks,
>
> greg k-h
>
> [1] My usual response is, "If we are so dumb, why are you using the kernel
> made by us?", which usually stops the conversation right there.
Your response is nonsense. It has the same logic as saying "If
proprietary software is wrong, why are you using it?".
Everybody are using proprietary software, aren't they?
If the pattern goes in A->B .... ->A, then the developers are really dumb.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
On Tue, 2005-12-06 at 07:07 +0100, Willy Tarreau wrote:
> Most of those small companies who propose a Linux driver simply start
> by paying a student during summer for porting their
> windows/sco/whatever driver to linux. They think the job is done when
> he leaves. Unfortunately, they receive complaints 3 months later from
> users because the driver is broken and does not build. They don't have
> the resources to keep a permanent developer on it, and they quickly
> understand that Linux is just a "geek OS" and that it's the last time
> they release any driver.
If they hired someone who did a _proper_ job -- writing a fully portable
and maintainable driver which got merged into Linus' kernel, then this
scenario doesn't make much sense. In-kernel code does generally get
maintained as interfaces change.
Of course, maintaining a driver _outside_ the kernel tree is a
never-ending task -- but why would anybody ever want to do that?
--
dwmw2
On Tue, 2005-12-06 at 02:18 +0100, Andrea Arcangeli wrote:
> On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
> > 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.
>
> I agree about the erosion.
>
> I am convinced that the only way to stop the erosion is to totally stop
> buying hardware that has only binary only drivers (unless you buy it to
> create an open source driver or to reverse engineer the binary only
> driver of course! ;).
this only works if more people than "just Andrea and Arjan" do it
though.
>
> For example if a laptop has an embedded wirless or 3d card not supported by
> open source drivers, buy a laptop without any wireless card or without
> 3d, instead of buying one with the not-supported hardware without using
> it (I can guarantee there are still laptops that requires no 3d
> binary only drivers and no wirless cards drivers, even for the winmodems
> you can choose the ones supported by alsa). We literally have to refuse
> buying those cards with binary only kernel drivers.
I fully agree; I bought a centrino based laptop recently (from Dell),
because Intel did a most excellent job of getting all the parts I use
supported fully. That was actually my primary purchase criterium.
Several other vendors didn't get my sale because they had no decent
supported laptop. (eg ati or nvidia video or some at-the-time driverless
wireless)
> The fact Arjan got the "nvidia fanboy" complaining, is the sign that
> some people just don't care. This understandable for a 3d kind of
> product which is 90% for entertainment (nobody loses money when it
> crashes), and we generally can't expect everyone to care about the long
> term kernel development.
lately a trend started where linux users consider it normal to use
binary drivers. Not only for 3D, but for everything. To the point where
in discussions about the gpl bcm43xx driver in development they feel
it's useful to chime in by saying "just use ndiswrapper instead", in
fact that's the standard answer on mailinglist on ANY wireless issue
nowadays it seems. There is an atmosphere that it's the duty of the
kernel developers to keep nvidia and ndiswrapper and all other binary
drivers working, anyone who even suggests different is a fundamentalist
GPL terrorist. (if you think that I'm overreacting, just for fun read
the forum on heise.de about this mail/article; this article apparently
is very fundamentalist). Nowadays people get upset and start calling
names if you point then at the nvidia forums instead of given them the
exact answer they want on $whatevermailinglist.
So while I fully agree with your "we shouldn't buy the unsupported
hardware" I fear that that no longer is happening in practice, not even
on the server side anymore, where some of the linux-friendly hardware
vendors now sell machines which require binary only modules to run and
call it fully linux certified and don't even mention anywhere that it
needs such modules, or that those modules are only available for RHEL or
SLES.
Greetings,
Arjan van de Ven
On Tue, 2005-12-06 at 08:13 +0000, David Woodhouse wrote:
> On Tue, 2005-12-06 at 07:07 +0100, Willy Tarreau wrote:
> > Most of those small companies who propose a Linux driver simply start
> > by paying a student during summer for porting their
> > windows/sco/whatever driver to linux. They think the job is done when
> > he leaves. Unfortunately, they receive complaints 3 months later from
> > users because the driver is broken and does not build. They don't have
> > the resources to keep a permanent developer on it, and they quickly
> > understand that Linux is just a "geek OS" and that it's the last time
> > they release any driver.
>
> If they hired someone who did a _proper_ job -- writing a fully portable
> and maintainable driver which got merged into Linus' kernel, then this
Then you have to motivate the management that it the initial development
cost is (roughly) doubled because of the process to get it accepted into
the kernel (instead of having a bloated converted driver from $OTHER_OS
which works just now somehow). And they didn't realize that bitrotting
is much faster in the free world then in the old-economy (i.e. Win*).
> scenario doesn't make much sense. In-kernel code does generally get
> maintained as interfaces change.
Yes, most of them (until the maintainer vanishes and after a year of
not-compiling-since-no-one-apparently-cares a patch to delete it is
submitted).
> Of course, maintaining a driver _outside_ the kernel tree is a
> never-ending task -- but why would anybody ever want to do that?
-) Because it was never accepted (yes, there are lots of reasons here -
some are more valid, some are less valid as seen by the
company/management financinf this)?
-) Because the have drivers + user-space libs for several OSes and want
to keep them as similar and working together as possible?
-) __________________
And probably a few more (sane reasons, not insane reasons).
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Tue, 2005-12-06 at 02:20, Tim Bird wrote:
> > The _GPL tag is useful as an hint to binary only vendors as as such it
> > makes perfect sense.
> Well, if it makes sense to have developers giving out legal
> advice, then I guess so.
You seem to imply that kernel developers have no legitimity to give a
hint on how to use what *they* created.
Brian Gerst <bgerst <at> didntduck.org> writes:
> The problem with this statement is that Linux users are a drop in the
> bucket of sales for this hardware. Boycotting doesn't cost the vendors
> enough to make them care. And this does nothing for people who are
> converting over to Linux, and didn't buy hardware with that
> consideration in mind.
>
> The only way to break the stalemate is to reverse engineer drivers.
> Turning the screws tighter isn't going to make open drivers magically
> appear. More likely, the vendors will abandon Linux as being too
> hostile and/or too costly to support, leaving everybody back at square one.
>
> --
> Brian Gerst
>
I see binary drivers as a problem, too.
How does a customer find out, if a piece of Hardware works in the free software
world? Yes there are a few places, where you find a hardware compatibility list,
but these are scattered and often incomplete. And they only include hardware
that someone thinks is working, added a couple of month after sales launch.
The only solution is to create pressure on these companies, as suggested.
Ideally, there should be a label "designed for Linux" (or "designed for free
software" (maybe getting the bsd people on board as well?)) straight on the box.
So customers that start to care about linux, can see this right away and make
the right choice, when buying hardware.
And because the driver is already included/licensed before the product makes it
into the shelves, its a plug and play scenario for the customer. They don't need
to worry about drivers at all. Stick it in and it just works(tm).
This would be a real value added in favor of linux for the customer and could
create some real pressure on companies with binary only drivers.
Which Authority would be best to release such a Label?
Regards,
Dirk
Arjan van de Ven wrote:
> On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
>
>>On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
>>
>>>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.
I guess that such people also use drivers without Microsoft's digital
signature in Windows and don't understand where their bluescreens come
from. So talking to them is a wasted effort.
--
Alexander E. Patrakov
On Mon, 2005-12-05 at 17:20 -0800, Tim Bird wrote:
> Andrea Arcangeli wrote:
> >[...]
> > The _GPL tag is useful as an hint to binary only vendors as as such it
> > makes perfect sense.
> Well, if it makes sense to have developers giving out legal
> advice, then I guess so.
Lots of patent attorneys and average law persons gives advices on
technical stuff (where they effectively have no idea what's really going
on) so it *must* be legitimate the other way 'round.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Tue, 2005-12-06 at 10:26 +0100, Bernd Petrovitsch wrote:
> Lots of patent attorneys and average law persons gives advices on
> technical stuff (where they effectively have no idea what's really
> going on) so it *must* be legitimate the other way 'round.
I think Tim's right to suggest that we shouldn't be giving that kind of
advice. Especially when we are so inconsistent about it, and when our
opinion is irrelevant.
If your lawyers advise you that using a given symbol from your
binary-only module was OK when it was exported with EXPORT_SYMBOL, then
that situation _cannot_ change when we switch it to EXPORT_SYMBOL_GPL;
we're simply not _allowed_ to impose additional restrictions. The only
thing that changes is the _amount_ of trouble you are in if the court
disagrees with your lawyers, because now you've actively circumvented a
technical protection measure in order to violate our copyright.
That protection is the only real difference between EXPORT_SYMBOL() and
EXPORT_SYMBOL_GPL(), once you realise that it can't change the legal
status of the export in question, and you discount the 'advice' which we
shouldn't be giving anyway.
Since the protection of EXPORT_SYMBOL_GPL() is only relevant if you are
actually found to be in violation of the licence, we might as well be
using it for all symbols. If you fervently believe that binary-only
modules are legal, you can still go ahead and use them. It's just that
you'd better be _very_ sure of yourself before you do so, because if you
_do_ lose in court you'll be getting more than a slap on the wrist.
By switching in the opposite direction, Linus is actively weakening our
position, and I object very strongly to that.
--
dwmw2
David Woodhouse wrote:
> Since the protection of EXPORT_SYMBOL_GPL() is only relevant if you are
> actually found to be in violation of the licence, we might as well be
> using it for all symbols. If you fervently believe that binary-only
> modules are legal, you can still go ahead and use them. It's just that
> you'd better be _very_ sure of yourself before you do so, because if you
> _do_ lose in court you'll be getting more than a slap on the wrist.
>
> By switching in the opposite direction, Linus is actively weakening our
> position, and I object very strongly to that.
Linus made a pragmatic technical decision for the benefit of a bunch of
Linux users, a decision I support despite the fact that NVIDIA are a
bunch of sillyheads.
Realistically, no position was weakened, nothing new happened.
In the context of the larger thread, the doomsday scenario is highly
unlikely because of positive engineering attributes of open source.
Smart companies want open source drivers not because people snipe at
them verbally and legally, but because the process produces superior
engineering in the end.
Jeff
Andrea Arcangeli wrote (ao):
> Let's not forget they make money selling the hardware, the binary only
> driver is free.
The driver is not free. You paid for it when you bought the card. The
driver is just as free as the tires on the car you just bought.
--
Humilis IT Services and Solutions
http://www.humilis.net
Dirk Steuwer wrote (ao):
> The only solution is to create pressure on these companies, as suggested.
> Ideally, there should be a label "designed for Linux" (or "designed for free
> software" (maybe getting the bsd people on board as well?)) straight on the box.
> So customers that start to care about linux, can see this right away and make
> the right choice, when buying hardware.
Quite a few companies state on their site that their hardware is
supported in Linux if it is.
And I've never bought any computer equipment in a shop. Always online,
where there is no such thing as a box anyway :-)
--
Humilis IT Services and Solutions
http://www.humilis.net
On Monday 05 December 2005 18:44, Alistair John Strachan wrote:
> 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.
That just moves the problem. Now, there is yet even more concern that they
should release source for the firmware.
--
Luke-Jr
Developer, Utopios
http://utopios.org/
Gene Heskett a ?crit :
> Which is the best reason in the world to buy and use, the open source
> video card now under development, and I hear its less than 3-4 months
> from production status now, and at a competitive, sub $150 USD price.
Can you post a link about this open source video card ? I strongly wants
to support this kind of project. It's clear for me: this is the only way
to solve the problem in the long term.
Thanks,
--
Jean-Christian de Rivaz
On Tue, 2005-12-06 at 12:07 +0100, M. wrote:
>
>
> On 12/6/05, Andrea Arcangeli <[email protected]> wrote:
> On Mon, Dec 05, 2005 at 09:31:30AM -0500, Brian Gerst wrote:
> > The problem with this statement is that Linux users are a
> drop in the
> > bucket of sales for this hardware. Boycotting doesn't cost
> the vendors
> > enough to make them care. And this does nothing for people
> who are
> > converting over to Linux, and didn't buy hardware with that
> > consideration in mind.
>
> Effectively this is why 3d drivers are the only thing we
> litearlly lost
> control of. But my email was general. I wasn't only speaking
> of 3d
> hardware.
>
> For 3d you're very well right, but once linux becomes
> mainstream in the
> desktop, things could change.
>
> Without proper hardware support linux is not going to become
> mainstream in the desktop area. In fact It's adopted in offices, by
> governments and schools for security, reliability and openoffirce.org
> (low $$).
but... "proper hardware support" can be open source, that's the whole
point! Everyone considering binary only support "full" causes the entire
problem of not being able to run without binary modules anymore, which
in turn means you're either stuck with enterprise distro kernels, or
linux is stuck with a kernel that can't be developed on anymore in a 2.7
style series.
Nobody is arguing that hardware shouldn't be supported, to the contrary.
I and others are arguing that short term binary only "support" isn't
real support in the long term, and in both the long and short term leads
to a significant reduction in choice. Note: NVidia right now is nice
enough to do the blob+glue layer thing. Many others don't, they only
provide modules for certain enterprise distros. Now those schools and
governments of course run those enterprise distros... but what does that
gain in the end? Security? It doesn't; several of these binary modules
actually introduce security holes (the most famous one is an old 3D
driver of a company I won't name that had a "make me root" ioctl).
Price? Well those enterprise distribution companies need to make money
somehow... so while the price may be lower... you're stuck to them
again..
> So , without some sort of effort from kernel developers, things
> arent going to change.
I would turn this around; without some sort of effort from the USERS,
things aren't going to change. As long as USERS don't use their purchase
power to urge vendors that linux and open source are important, nothing
is going to improve. Going binary is not a long term improvement! It's
more like a quick shot of heroin that makes you feel better today,
rather than going to a psychiatrist who helps you out of your depression
for the rest of your life.
> There could be, for example, a limited but stable API for
> external/binary stuff. This could force hardware vendors to lately use
> the current API for better performance and thus releasing drivers with
> an open layer a la NVIDA & c. or even opensource.
doesn't work; such a limited api wouldn't be used by the majority of
those modules, simply because most of them want to touch internals for
some reason (probably lack of judgement and just because they can, but
still)
On Tue, 2005-12-06 at 13:04 +0100, Felipe Alfaro Solana wrote:
> > I would turn this around; without some sort of effort from the USERS,
> > things aren't going to change. As long as USERS don't use their
> > purchase power to urge vendors that linux and open source are
> > important, nothing is going to improve.
>
> I do always choose Linux-compatible hardware for my boxes. However, we
> are still a small community, so I see it complicated using our power
> to change vendor's minds.
it worked in the past.. and the linux community got bigger. lots bigger.
Now the hard part is getting the "newcomers" care about this and also
help to convince the vendors, rather than blindly accepting that
ndiswrapper and nvidia blobs are the right way.
On Tuesday 06 December 2005 03:18, Andrea Arcangeli wrote:
> On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
> > 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.
>
> I agree about the erosion.
>
> I am convinced that the only way to stop the erosion is to totally stop
> buying hardware that has only binary only drivers (unless you buy it to
> create an open source driver or to reverse engineer the binary only
> driver of course! ;).
I'm afraid there is not enough Linux users in desktop/laptop market
for vendors to notice.
How about refusing binary-only modules instead? I mean, maybe
if Linux will stop being lax about GPL requirements on modules.
--
vda
On Tue, Dec 06, 2005 at 10:51:39AM +0000, Luke-Jr wrote:
> On Monday 05 December 2005 18:44, Alistair John Strachan wrote:
> > 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.
>
> That just moves the problem. Now, there is yet even more concern that they
> should release source for the firmware.
ACPI is a demonstration why firmware is not the answer.
Ralf
I believe the only real thing to do is release all new kernels under a
new license called GPL_HARD - with a clause that would make all
linking to the kernel illegal if not in open source. Any vendor who
doesnt comply could be arrested and flown off to a detention camp on
some remote island without the right to legal council. We could borrow
some old planes from the US postal service..
These vendors could be interrogated until they reveil their
specifications for their hardware.
I vote for hard interrogation - if they wont tell they could be forced
to wear tux-outfits and listen to badly ripped mp3?s until they talk.
These vendors constitutes an axes of evil and are a real threat to the
security on a lot of machines.
To all vendors - you are either with us or against us!
--
Rudolf Randal - H?ssleholmsgatan 3B lgh 503 - 214 43 Malm? - Sweden -
Phone: +46 (0)76 234 05 77
On Tue, Dec 06, 2005 at 12:24:42AM +0100, Matthieu CASTET wrote:
> > What if.. what if the linux kernel developers tomorrow accept that
> > binary modules are OK and are essential for the progress of linux.
> >
> [...]
> > 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.
> And some embedded companies provide the minimal source code to put
> in arch and everything else (ethernet, adsl, wifi, ...) is binaries
> modules.
Provide a one time source drop to show what good GPL citizen they are,
then let it rot away making sure the average user will have to pay their
bill ...
Ralf
Arjan van de Ven wrote:
> On Tue, 2005-12-06 at 12:07 +0100, M. wrote:
>>
>> On 12/6/05, Andrea Arcangeli <[email protected]> wrote:
>> On Mon, Dec 05, 2005 at 09:31:30AM -0500, Brian Gerst wrote:
>> > The problem with this statement is that Linux users are a
>> drop in the
>> > bucket of sales for this hardware. Boycotting doesn't cost
>> the vendors
>> > enough to make them care. And this does nothing for people
>> who are
>> > converting over to Linux, and didn't buy hardware with that
>> > consideration in mind.
>>
>> Effectively this is why 3d drivers are the only thing we
>> litearlly lost
>> control of. But my email was general. I wasn't only speaking
>> of 3d
>> hardware.
>>
>> For 3d you're very well right, but once linux becomes
>> mainstream in the
>> desktop, things could change.
>>
>> Without proper hardware support linux is not going to become
>> mainstream in the desktop area. In fact It's adopted in offices, by
>> governments and schools for security, reliability and openoffirce.org
>> (low $$).
>
> but... "proper hardware support" can be open source, that's the whole
> point! Everyone considering binary only support "full" causes the entire
> problem of not being able to run without binary modules anymore, which
> in turn means you're either stuck with enterprise distro kernels, or
> linux is stuck with a kernel that can't be developed on anymore in a 2.7
> style series.
>
> Nobody is arguing that hardware shouldn't be supported, to the contrary.
> I and others are arguing that short term binary only "support" isn't
> real support in the long term, and in both the long and short term leads
> to a significant reduction in choice. Note: NVidia right now is nice
> enough to do the blob+glue layer thing. Many others don't, they only
> provide modules for certain enterprise distros. Now those schools and
> governments of course run those enterprise distros... but what does that
> gain in the end? Security? It doesn't; several of these binary modules
> actually introduce security holes (the most famous one is an old 3D
> driver of a company I won't name that had a "make me root" ioctl).
> Price? Well those enterprise distribution companies need to make money
> somehow... so while the price may be lower... you're stuck to them
> again..
>
>> So , without some sort of effort from kernel developers, things
>> arent going to change.
>
> I would turn this around; without some sort of effort from the USERS,
> things aren't going to change. As long as USERS don't use their purchase
> power to urge vendors that linux and open source are important, nothing
> is going to improve. Going binary is not a long term improvement! It's
> more like a quick shot of heroin that makes you feel better today,
> rather than going to a psychiatrist who helps you out of your depression
> for the rest of your life.
Once again I'd like to point out that user's purchase power means jack
when they only have two choices for video: ATI and Nvidia. You can't
walk into a computer store and find anything else (I don't count
integrated video on the motherboard as a solution, since only Intel
boards have it, sorry AMD users). Even over the web it's hard to find
anything else. I'm not trying to defend closed source here, but you
people just have to face the reality that trying to use the market to
get our way is just not going to work with video. The only way forward
is reverse engineering. We aren't going to get help from the vendors so
we have to help ourselves.
--
Brian Gerst
On Mon, 5 Dec 2005, Brian Gerst wrote:
> Arjan van de Ven wrote:
>> On Tue, 2005-12-06 at 12:07 +0100, M. wrote:
>>>
>>> On 12/6/05, Andrea Arcangeli <[email protected]> wrote:
>>> On Mon, Dec 05, 2005 at 09:31:30AM -0500, Brian Gerst wrote:
>>> > The problem with this statement is that Linux users are a
>>> drop in the
>>> > bucket of sales for this hardware. Boycotting doesn't cost
>>> the vendors
>>> > enough to make them care. And this does nothing for people
>>> who are
>>> > converting over to Linux, and didn't buy hardware with that
>>> > consideration in mind.
>>>
>>> Effectively this is why 3d drivers are the only thing we
>>> litearlly lost
>>> control of. But my email was general. I wasn't only speaking
>>> of 3d
>>> hardware.
>>>
>>> For 3d you're very well right, but once linux becomes
>>> mainstream in the
>>> desktop, things could change.
>>>
>>> Without proper hardware support linux is not going to become
>>> mainstream in the desktop area. In fact It's adopted in offices, by
>>> governments and schools for security, reliability and openoffirce.org
>>> (low $$).
>>
>> but... "proper hardware support" can be open source, that's the whole
>> point! Everyone considering binary only support "full" causes the entire
>> problem of not being able to run without binary modules anymore, which
>> in turn means you're either stuck with enterprise distro kernels, or
>> linux is stuck with a kernel that can't be developed on anymore in a 2.7
>> style series.
>>
>> Nobody is arguing that hardware shouldn't be supported, to the contrary.
>> I and others are arguing that short term binary only "support" isn't
>> real support in the long term, and in both the long and short term leads
>> to a significant reduction in choice. Note: NVidia right now is nice
>> enough to do the blob+glue layer thing. Many others don't, they only
>> provide modules for certain enterprise distros. Now those schools and
>> governments of course run those enterprise distros... but what does that
>> gain in the end? Security? It doesn't; several of these binary modules
>> actually introduce security holes (the most famous one is an old 3D
>> driver of a company I won't name that had a "make me root" ioctl).
>> Price? Well those enterprise distribution companies need to make money
>> somehow... so while the price may be lower... you're stuck to them
>> again..
>>
>>> So , without some sort of effort from kernel developers, things
>>> arent going to change.
>>
>> I would turn this around; without some sort of effort from the USERS,
>> things aren't going to change. As long as USERS don't use their purchase
>> power to urge vendors that linux and open source are important, nothing
>> is going to improve. Going binary is not a long term improvement! It's
>> more like a quick shot of heroin that makes you feel better today,
>> rather than going to a psychiatrist who helps you out of your depression
>> for the rest of your life.
>
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users). Even over the web it's hard to find
> anything else. I'm not trying to defend closed source here, but you
> people just have to face the reality that trying to use the market to
> get our way is just not going to work with video. The only way forward
> is reverse engineering. We aren't going to get help from the vendors so
> we have to help ourselves.
>
> --
> Brian Gerst
When the linux-BIOS group started, few knew where to start. Then,
mysteriously, there was a complete directory tree of a well-known
BIOS that appeared on the web. That was a start.
Want video drivers? I would suggest starting a Linux-video group.
Start with a few hacks of some reverse-engineered stuff then I
guess some help will mysteriously appear, especially if the
blob/glue stuff is done in that group, too. A video board company
doesn't care about operating systems! They care about selling
boards. The easier it is to relate to their video hardware, the
more likely help will be forthcoming.
Also, you are still likely to have a blob/glue system because
the blob is the stuff that needs to be uploaded to the FPGA upon
startup! Although serial eproms are cheap, few PC/Board vendors
will spend the money to put the blob on the board where it belongs.
So, usually it needs to be bit-banged into the device upon startup.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.44 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On 12/6/05, Brian Gerst <[email protected]> wrote:
> Arjan van de Ven wrote:
> > On Tue, 2005-12-06 at 12:07 +0100, M. wrote:
> >>
> >> On 12/6/05, Andrea Arcangeli <[email protected]> wrote:
> >> On Mon, Dec 05, 2005 at 09:31:30AM -0500, Brian Gerst wrote:
> >> > The problem with this statement is that Linux users are a
> >> drop in the
> >> > bucket of sales for this hardware. Boycotting doesn't cost
> >> the vendors
> >> > enough to make them care. And this does nothing for people
> >> who are
> >> > converting over to Linux, and didn't buy hardware with that
> >> > consideration in mind.
> >>
> >> Effectively this is why 3d drivers are the only thing we
> >> litearlly lost
> >> control of. But my email was general. I wasn't only speaking
> >> of 3d
> >> hardware.
> >>
> >> For 3d you're very well right, but once linux becomes
> >> mainstream in the
> >> desktop, things could change.
> >>
> >> Without proper hardware support linux is not going to become
> >> mainstream in the desktop area. In fact It's adopted in offices, by
> >> governments and schools for security, reliability and openoffirce.org
> >> (low $$).
> >
> > but... "proper hardware support" can be open source, that's the whole
> > point! Everyone considering binary only support "full" causes the entire
> > problem of not being able to run without binary modules anymore, which
> > in turn means you're either stuck with enterprise distro kernels, or
> > linux is stuck with a kernel that can't be developed on anymore in a 2.7
> > style series.
> >
> > Nobody is arguing that hardware shouldn't be supported, to the contrary.
> > I and others are arguing that short term binary only "support" isn't
> > real support in the long term, and in both the long and short term leads
> > to a significant reduction in choice. Note: NVidia right now is nice
> > enough to do the blob+glue layer thing. Many others don't, they only
> > provide modules for certain enterprise distros. Now those schools and
> > governments of course run those enterprise distros... but what does that
> > gain in the end? Security? It doesn't; several of these binary modules
> > actually introduce security holes (the most famous one is an old 3D
> > driver of a company I won't name that had a "make me root" ioctl).
> > Price? Well those enterprise distribution companies need to make money
> > somehow... so while the price may be lower... you're stuck to them
> > again..
> >
> >> So , without some sort of effort from kernel developers, things
> >> arent going to change.
> >
> > I would turn this around; without some sort of effort from the USERS,
> > things aren't going to change. As long as USERS don't use their purchase
> > power to urge vendors that linux and open source are important, nothing
> > is going to improve. Going binary is not a long term improvement! It's
> > more like a quick shot of heroin that makes you feel better today,
> > rather than going to a psychiatrist who helps you out of your depression
> > for the rest of your life.
>
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users). Even over the web it's hard to find
> anything else. I'm not trying to defend closed source here, but you
> people just have to face the reality that trying to use the market to
> get our way is just not going to work with video. The only way forward
> is reverse engineering. We aren't going to get help from the vendors so
> we have to help ourselves.
>
Well - reverse engineering isnt gonna get any easier over time .. as
hardware gets more complex and bus speed increases it will become more
and more impossible to do any probing?. There also isnt any way to
ensure that vendors wont go down the m$ way as on the xbox or xbox360
and encrypt data between chips to protect their IP.
Most likely that will prevent the reversely engineered driver from
getting out in time before the next generation of hardware arrives ?
--
Rudolf Randal - H?ssleholmsgatan 3B lgh 503 - 214 43 Malm? - Sweden -
Phone: +46 (0)76 234 05 77
>greg k-h
>
>[1] My usual response is, "If we are so dumb, why are you using the kernel
> made by us?", which usually stops the conversation right there.
This is indeed a very good question. Maybe Greg is right and we really
should not be using
their kernel. There are alternatives that are open source and equally good
if not better (BSD, Solaris).
Linux is made for the members of the Linux community (family) who understand
how important it is to get all the hardware details and other trade secrets
made available public domain. This is a live and death issue to the
community because it lmakes it possible to hackers to continue to hack.
Binary (only) drivers are considered evil because then may cause the
hardware information flow to hackers to stop forever. Linux should be made
the dominating desktop OS so that stupid hardware companies will be forced
to realize that resistence is futile.
But what do the desktop customers (the ones who should start using Linux)
expect? We would expect that Linux works with the hardware we have or
whatever we decide to buy. And more important we expect that the
applications we need are available for Linux. Do we care about hackers'
right to free hardware information? No. This means that we users are
complete morons and we should be brainwashed to realize how cool thing Linux
is.
So the conclusion is that we (potential) customers should grow up to the
level where we can fully understand the importance of the Linux movement.
The kernel community in turn does the right thing in trying to enforce pure
GPL even if it causes some unavoidable damage to usability of Linux. Linux
will sooner or later dominate the desktop. Until that happens we we users
should support the effort of the development community and happily suffer
from hardware compatibility problems (or user some less state-of-the-art
hardware). Or should we?
As I said maybe Greg's opinion is correct. We stupid morons should let the
kernel guys to play with their nice sandbox in whatever way they like. We
don't contribute anything to the kernel so we definitely don't have any vote
on what they do or don't do. We should stop raising idiotic issues like
unbanning binary only drivers. Instead by moving to some other open source
kernel we can improve the S/N ratio of this mailing list. This gives the
kernel community good working peace to build as pure GPL kernel as they
like.
Regards,
Aimo
_________________________________________________________________
Nopea ja hauska tapa l?hett?? viestej? reaaliaikaisesti - MSN Messenger.
http://messenger.msn.fi
> And more important we expect that the
> applications we need are available for Linux. Do we care about hackers'
> right to free hardware information? No.
In my article I tried to explain to you why you SHOULD care. If you can
get your drivers ONLY for the SLES/RHEL distros... would you be happy
with that? Are you currently running RHEL or SLES? If not, why not? If
you have a reason for that... then maybe you shouldn't be happy about
the direction things are going either!
Open drivers are NOT just for hackers. GET THAT? They are there for YOU
as well. So that YOU can run whatever linux you want, not just today but
also tomorrow and next month and later. Maybe you don't want to read the
source code, maybe you're no programmer at all and don't know how to
read it. Yet even if you use nvidia and ndiswrapper you depend on the
rest of the kernel drivers to be open to run the distribution you want,
and not RHEL or SLES.
Maybe saying this makes me a fundamentalist GPL terrorist (as some have
called me as reaction to the article I wrote). To some degree I don't
care, I've been called worse.
But I am hoping that people like you (and I don't mean that in any
negative way) start to realize why you can run the linux you want today,
and that embracing binary drivers as a good thing will threaten that
ability in the future.
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users). Even over the web it's hard to find
> anything else.
(resending this since it seems the other mail didn't get anywhere)
Sure. But that doesn't mean there is no purchase power. HP, Dell and IBM
and co DO have purchasing power over NVidia and ATI. If they tell ATI or
NVidia to either go open source (unlikely) or rearchitect their drivers
to do the "hot IP" in userspace, it will happen. And YOU can influence
Dell and HP and IBM again. By complaining to their sales people. By
letting them know binary modules aren't going to cut it. Not just for
video, but for EVERYTHING. Once the Dell/HP/IBM sales people hear enough
of "binary isn't good enough", the message will get through, and those
vendors in turn will crank up the pressure.
And enough people have influence when at work a linux desktop is
purchased (assumption I make here is that that's not going to be used
for 3D games), at such occasions you CAN influence the vendors and let
them know that the "binary" cards aren't an option.
There are lots of opportunities to put pressure on vendors, either
direct or indirect. Nvidia has a support department. If they get enough
calls / letters about their solution not being good enough, they're more
likely to consider the rearchtect solution.
On the other hand, if everyone just accepts it and praises them for
being a good citizen.. things will never change, and wireless is next.
Then audio. Then SATA. Then USB sticks. Then Networking.
On Tue, Dec 06, 2005 at 09:56:43AM +0000, David Woodhouse wrote:
> [..] we might as well be
> using it for all symbols [..]
Cool, so if we use it for all symbols it will add zero information to
the kernel. Which means it's exactly the same as if we nuke _GPL tag
completely and we remove it from all symbols.
I always thought the _GPL tag isn't needed and can be removed, your
suggestion to add it to all symbols confirms it. Furthermore its
existence is a sort of proof that you can legally link the kernel with
non-GPL modules (which Greg disagrees with, I don't have an opinion, I
only know Linus said binary only drivers are ok as long as they don't
create a derivative of the kernel).
I don't think the GPL tag can make somebody more or less illegal, it's
just irrelevant. This is just a favour we make to those companies, and
that they may also not trust in the first place because we're not
lawyers in the first place.
> By switching in the opposite direction, Linus is actively weakening our
> position, and I object very strongly to that.
I think Linus is doing the right thing here, and he is avoiding what I
described in the previous email: that is breaking drivers gratuitously
is what could make linux hostile and too costly to support IMHO. We want
to be parnters with all hardware companies, but we want them to support
linux properly (not with binary only drivers), in a way that we can fix
it, port it to other archs, and so that we don't lose support for the
hardware while improving internal APIs.
Also note, that if we lose control on the development (the doomsday
scenario) everybody else loses control too, it's not like somebody can
bank on it and steal the control and profit from it and pay lots of
taxes to the US governament. Everybody will lose and wealth will be
destroyed globally and less taxes will be paid in all countries
worldwide. All those hardware companies compete against each other, so
each one will have control on a little tiny piece of the OS, so when a
bug triggers in the doomsday secnario, the thing will become
undebuggable for everyone (at best everyone can blame on each other when
there's random memory corruption). That again may be acceptable for a
desktop, but I doubt it's acceptable for servers.
Rudolf Randal wrote:
> I believe the only real thing to do is release all new kernels under a
> new license called GPL_HARD - with a clause that would make all
Nice theory, but thank (insert favourite deity here) that the GPL
protects us from this ever happening!
On Tue, Dec 06, 2005 at 01:04:59PM +0100, Felipe Alfaro Solana wrote:
> are still a small community, so I see it complicated using our power
> to change vendor's minds.
Why not using the vendor that ships hardware that requires no binary
only driver?
I know there is the option to remove the embedded wireless card ;).
Better not to have it than to pay for it without using it. A bluetooth
usb dongle costs only a dozen dollars anyway.
On Mon, Dec 05, 2005 at 08:43:03PM -0500, Brian Gerst wrote:
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
The single fact you looked to see if there was something else is a very
good thing. As wrote in the other email, with their binary only drivers
those companies are increasing their risk of introducing more
competition into the 3d space, they open up a niche. I know I wouldn't
take this risk if I was in them.
Hi!
> >Every time we buy a piece of hardware with binary only drivers we admit
> >that the binary only driver vendors are doing the right choice for their
> >stockholders. Only when we refuse to buy it, we can make a slight
> >difference.
> >When we don't buy hardware without open source drivers, we send the
> >message to the shareholders that the management is causing them a loss.
>
> The problem with this statement is that Linux users are a drop in the
> bucket of sales for this hardware. Boycotting doesn't cost the vendors
> enough to make them care. And this does nothing for people who are
Actually, yes it does cost them. If you refuse to buy $2000 notebook,
because its 3D graphics card ($100) is not supported properly... well
notebook vendor is going to put pressure on graphics card vendor.
And you don't have to be Linux user to refuse closed hardware. Having
option in future is always good.x
Pavel
--
Thanks, Sharp!
On Tue, 2005-12-06 at 15:50 +0100, Andrea Arcangeli wrote:
> On Tue, Dec 06, 2005 at 09:56:43AM +0000, David Woodhouse wrote:
> > [..] we might as well be using it for all symbols [..]
>
> Cool, so if we use it for all symbols it will add zero information to
> the kernel. Which means it's exactly the same as if we nuke _GPL tag
> completely and we remove it from all symbols.
>
> I always thought the _GPL tag isn't needed and can be removed, your
> suggestion to add it to all symbols confirms it.
In terms of information, you're right -- there's no point in having both
of them.
However, the _GPL tag does mean that someone who wants to violate the
licence has to deliberately circumvent the protection, and cannot plead
ignorance. That does have an effect in court, albeit after the basic
question of guilt or innocence has been decided.
> Furthermore its existence is a sort of proof that you can legally link
> the kernel with non-GPL modules (which Greg disagrees with, I don't
> have an opinion, I only know Linus said binary only drivers are ok as
> long as they don't create a derivative of the kernel).
I happen to agree with Greg's opinion, and not with Linus'. But
obviously there is no 'right' answer until/unless it comes to court.
But yes -- its existence is indeed a 'sort of proof' that non-GPL
modules are at least _considered_ to be OK in some situations. I wish
we'd never invented EXPORT_SYMBOL_GPL() in the first place -- it appears
to legitimise something which was never really OK in the first place,
and weakens our position when we take it to court.
> I don't think the GPL tag can make somebody more or less illegal, it's
> just irrelevant. This is just a favour we make to those companies, and
> that they may also not trust in the first place because we're not
> lawyers in the first place.
True -- that's what I've said many times. The point, however, is that
the GPL tag provides a measure of protection which the violator would
have to _deliberately_ circumvent. That doesn't directly affect the
licensing question, but it does change the _penalties_ which a court
would impose if a vendor of non-GPL'd modules who is found to be
violating the GPL.
Maybe a vendor will have deep pockets and a penchant for risk, and will
still be happy to bypass the protection afforded by EXPORT_SYMBOL_GPL --
maybe with MODULE_LICENSE("GPL\0not really") or by other means. But the
_default_ would be that non-GPL modules would not work, and having to
circumvent the protection would make them stop and think _very_ hard
before doing it.
> > By switching in the opposite direction, Linus is actively weakening our
> > position, and I object very strongly to that.
>
> I think Linus is doing the right thing here, and he is avoiding what I
> described in the previous email:
He's also doing what you described in the email to which I'm reply --
reinforcing a 'sort of proof' that what they're doing is OK, by going
out of his way to accommodate them.
> that is breaking drivers gratuitously is what could make linux
> hostile and too costly to support IMHO.
Supporting Linux with binary-only drivers _is_ hostile and costly.
And it wouldn't be _broken_ -- they could still rebuild the kernel
without the checks, or make their module pretend to be licensed under
the GPL to bypass the EXPORT_SYMBOL_GPL() protection. Of course, they'd
have to be _very_ sure of their lawyers' interpretation of the GPL if
they were going to do that.
By switching to EXPORT_SYMBOL_GPL for everything, we put the onus upon
the vendors of such modules to be _very_ sure of themselves and the risk
they're taking before continuing to release such modules. I don't think
that's a bad thing.
> We want to be parnters with all hardware companies, but we want them
> to support linux properly (not with binary only drivers), in a way
> that we can fix it, port it to other archs, and so that we don't lose
> support for the hardware while improving internal APIs.
Allowing binary-only drivers only harms that goal, in the long term.
> Also note, that if we lose control on the development (the doomsday
> scenario) everybody else loses control too, it's not like somebody can
> bank on it and steal the control and profit from it and pay lots of
> taxes to the US governament. Everybody will lose and wealth will be
> destroyed globally and less taxes will be paid in all countries
> worldwide. All those hardware companies compete against each other, so
> each one will have control on a little tiny piece of the OS, so when a
> bug triggers in the doomsday secnario, the thing will become
> undebuggable for everyone (at best everyone can blame on each other when
> there's random memory corruption). That again may be acceptable for a
> desktop, but I doubt it's acceptable for servers.
I think we're digressing somewhat, but you seem to be agreeing that
binary-only modules are generally a bad thing. We have a tool available
to us to discourage their proliferation -- the licence under which the
kernel is released. That's the whole _point_ of the GPL, in fact.
So what's wrong with the suggestion that we make _use_ of that rather
than continuing to not only tolerate violations, but go out of our way
to aid and abet the violators?
--
dwmw2
* Brian Gerst:
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users). Even over the web it's hard to find
> anything else.
What about Matrox cards? Are there open drivers for accelerated 2D
operation?
Hi,
On 12/6/05, Aimo Asiakas <[email protected]> wrote:
> But what do the desktop customers (the ones who should start using Linux)
> expect? We would expect that Linux works with the hardware we have or
> whatever we decide to buy. And more important we expect that the
> applications we need are available for Linux. Do we care about hackers'
> right to free hardware information? No. This means that we users are
> complete morons and we should be brainwashed to realize how cool thing Linux
> is.
As Arjan said, this is not about the developers, it is about all of
us. While you're not interested in the availability of hardware
documentation, surely you do care if you can still run free software
on your machine in two years from now? Closed hardware documentation
means that you have to rely on your vendor to update the driver which
is not in their interest if they have a new product out which they
want you to buy. Nor will the driver be updated if the vendor has gone
out of business.
See, if you want to be able to walk in the store and buy whatever you
want and have it work on Linux (or any other open source kernel for
that matter), you're absolutely in favor of open hardware
documentation. You just haven't realized it yet.
Pekka
On Tue, 6 Dec 2005, Denis Vlasenko wrote:
> How about refusing binary-only modules instead? I mean, maybe
> if Linux will stop being lax about GPL requirements on modules.
Or why not to include an embedded version of gcc/binutils in the kernel
LKM interface. In this way all drivers can only be distributed in source
code which effectively makes all forms of binary only drivers impossible.
After that all the EXPORT_SYMBOL_GPL nonsense can be removed and a proper
DDI layer can be implemented for Linux. This makes it possible to ship
"outside the kernel build" drivers without a risk of major
incompatibility problems in the next kernel version. No, I'm not 100%
serious but just 50%.
Best regards,
Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
Dnia wtorek, 6 grudnia 2005 16:30, Florian Weimer napisał:
> * Brian Gerst:
> > Once again I'd like to point out that user's purchase power means jack
> > when they only have two choices for video: ATI and Nvidia. You can't
> > walk into a computer store and find anything else (I don't count
> > integrated video on the motherboard as a solution, since only Intel
> > boards have it, sorry AMD users). Even over the web it's hard to find
> > anything else.
>
> What about Matrox cards? Are there open drivers for accelerated 2D
> operation?
Open 2D is nothing new. The OpenGL is a major part.
Matrox and XGI (e.g. Volari V3 based cards) have openGL parts closed.
--
to_be || !to_be == 1, to_be | ~to_be == -1
On Tue, Dec 06, 2005 at 03:58:46PM +0800, Coywolf Qi Hunt wrote:
> > [1] My usual response is, "If we are so dumb, why are you using the kernel
> > made by us?", which usually stops the conversation right there.
>
> Your response is nonsense. It has the same logic as saying "If
> proprietary software is wrong, why are you using it?".
> Everybody are using proprietary software, aren't they?
Um, no, not at all. The logic is, "you trust these developers enough to
want to run their code, controlling the most basic and secure portions
of your machines, yet you think they are incapable programmers?"
And no kernel developers are forcing anyone to use Linux. If they don't
like it for whatever reasons, there are other alternatives...
thanks,
greg k-h
On 12/5/05, Arjan van de Ven <[email protected]> wrote:
> Linux in a binary world
Why not start our own Linux doomsday? Give the closed source vendors
exactly what they fear the most, a patent lawsuit. Whining will get us
nowhere, hitting the vendor's revenue stream will get you anything you
want.
US patent infringement provides the giant sledgehammer of having a
court issue an injunction stopping the shipment of product that is in
litigation over patent infringement. Note that it does not have to be
proven that the the patents are valid. RIM is very close to having an
injunction issued against it even though it is likely that the patents
they are accused of violating will be found invalid.
The game plan is simple. IBM and Intel hold enough hardware patents to
take down any hardware company these choose. Donate one or two key
patents to the FSF with a rule that they can't be used against the
company that donated them. The FSF then moves for a patent
infringement injunction against ATI, NVidia or other closed source
vendor.
The target company gets a choice:
1) open source the drivers and hardware. As a sweetener contribute a
patent to the pool and aim the FSF at the next domino. In exchange the
suit will be dropped.
2) Endure the lawsuit and hope the FSF doesn't get a $450M settlement
like NTP is getting from RIM. Meanwhile watch your stock price tumble
since the injunction prevents you from shipping product.
http://www.latimes.com/news/opinion/editorials/la-ed-ebay4dec04,0,6943666.story?coll=la-news-comment-editorials
--
Jon Smirl
[email protected]
Arjan van de Ven wrote:
> On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
>
>>On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
>>
>>>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.
>
>
I suppose this is as good as any point in the thread to add my 2
eurocents...
I use nvidia cards, mostly because they work better than an alternative
for now, but every time I need a card I look for stuff that is more
open, because I hate to have to use the non-free closed stuff to do
graphics. (Having no real choice in this is really annoying to me!)
I believe the kernel community has a great leverage point on these
proprietary vendors (although I don't know how far this goes), by
changing the ABI/API fairly often, they will have to adjust their driver
building tools as well. This will become annoying to them and may cause
them to free some more parts of their code. This is not a full solution,
but at least it will cause them to rethink their policies more often.
Alternatively, I'd be willing to pay some more money than for an
equivalent closed source driver card, to get good hardware with a GPL
driver. I may not be part of the majority of PC equipment buyers though ;-)
Cheers
Simon
* Jon Smirl:
> 2) Endure the lawsuit and hope the FSF doesn't get a $450M settlement
> like NTP is getting from RIM. Meanwhile watch your stock price tumble
> since the injunction prevents you from shipping product.
Unlike NTP[1], the FSF distributes real products and is vulnerable to
counterclaims.
[1] http://www.ntp.com/ belongs to a different company, AFAIK.
Sander <sander <at> humilis.net> writes:
>
> Quite a few companies state on their site that their hardware is
> supported in Linux if it is.
>
> And I've never bought any computer equipment in a shop. Always online,
> where there is no such thing as a box anyway
>
Yes, but there isn't and won't be much recognition - every company does its own
thing. And how many people buy online all the time? But even then, a genery
"runs with Linux" Logo would be great. If a company's product is not certified,
its not considered by Linux customers.
Also you could hold up figures from certified hardware to impress and argue
against companies that think there is no real market for Linux.
There needs to be a way to breack out of the chicken and egg problem - no linux
market, no linux hardware.
Corporate Customers can afford to do research, expert staff does the buying. But
the average homeuser? He needs a generic sign, as simple as that.
Dirk
On 12/5/05, Pekka Enberg <[email protected]> wrote:
> 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...
I remember calling up ATI and speaking to the CEO's secretary back in
the late 1990s. They'd just started to help out the GATOS guys a
little back then and I decided that they cared more than Nvidia do
about Linux so I would continue to buy only ATI cards. The ATI/Nvidia
thing even determined which model of Powerbook I would buy (since the
12" model had an Nvidia chipset).
Now I'm just disgusted with them. I understand exactly why they've
done what they have, but it's very uncool. People should call them up
and ask them to reconsider their actions. Question: who can I pay
money to for graphics cards that don't have hobbled drivers?
Jon.
P.S. I'm not just being anti-ATI. There are many others who are far
far worse - but we need good vendor support for graphics now more than
we ever did if more people are going to enjoy a good desktop
experience when using Linux.
On Tue, Dec 06, 2005 at 07:07:34AM +0100, Willy Tarreau wrote:
> It's not about being dumb, but this problem is -I think- what prevents
> some companies from releasing drivers for their hardware (when they
> don't consider that opening it will give their IP away). I've played
> several times with opensource drivers for ADSL modems, LCD modules,
> watchdogs, ethernet adapters, IDE drivers, etc... and their problem
> was that what worked well in 2.4.21 did not even build in 2.4.22
> and became difficult to fix starting with 2.4.23. Most of those
> small companies who propose a Linux driver simply start by paying
> a student during summer for porting their windows/sco/whatever
> driver to linux. They think the job is done when he leaves.
> Unfortunately, they receive complaints 3 months later from users
> because the driver is broken and does not build. They don't have
> the resources to keep a permanent developer on it, and they
> quickly understand that Linux is just a "geek OS" and that it's
> the last time they release any driver.
That's why Documentation/HOWTO was written, to help those people realize
what needs to be done in order to do it properly.
thanks,
greg k-h
On 12/6/05, Andrea Arcangeli <[email protected]> wrote:
> I am convinced that the only way to stop the erosion is to totally stop
> buying hardware that has only binary only drivers (unless you buy it to
> create an open source driver or to reverse engineer the binary only
> driver of course! ;).
That's not enough people to make a big enough difference - but I agree
with the logic and do my part.
One idea for dealing with this is to have the kernel complain more
loudly about binary only drivers - instead of using terms like "taint"
which Sysadmins might casually ignore it might be better to have a
couple of lines of warning message in their syslog explaining what it
means in more graphic terms. Granted that average users won't see this
but it would certainly help to convey the impression that binary only
is "wrong" (it's not putting policy in the kernel, it's embedded
politics in the kernel :P).
> I think messages like the one from Arjan are very positive to let
> people understand the long term effect of binary only drivers
I wrote a couple of articles this month which explain to the average
reader what is wrong with this and how it can be addressed. I used
Greg's mail as an example but will followup with a reference to this
thread - we need to encourage more people to talk about this.
> Perhaps we should add a printk that points to an url on kernel.org
> including Arjan's message every time a non-gpl module gets loaded by the
> kernel. I think it's a matter of educating the customer too or they can
> do mistakes, creating a blacklist would help too.
I like the idea of being far more graphic (no pun intended there) by
describing what this means in everyday language - "using binary only
drivers causes your machine to explode! (may not actually cause
machine to explode)" type stuff.
Jon.
On Mon, Dec 05, 2005 at 11:18:15PM -0500, Michael Poole wrote:
> Besides, if the act of linking is what makes the derivative work,
> there is no problem: The GPL allows a user to make any modifications
> or combinations or derivatives whatsoever, and only imposes
> requirements when the result is distributed. The linking of the two
> works occurs only on the end user's machine.
But if it's a module, it's probably been compiled against kernel headers.
Last time I checked, header files were covered by the GPL unless explicitly
placed under a more permissive license. How do you use something like
spinlocks without compiling in GPL code to a module?
-ben
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <[email protected]>.
On 12/6/05, Zwane Mwaikambo <[email protected]> wrote:
> On Mon, 5 Dec 2005, Gene Heskett wrote:
>
> > Which is the best reason in the world to buy and use, the open source
> > video card now under development, and I hear its less than 3-4 months
> > from production status now, and at a competitive, sub $150 USD price.
> >
> > If 50% of nvidia's currant linux market share were to dissappear a month
> > after this card becomes available for purchase by those whom one might
> > categorize as believers, I'd think that would send a message loud enough
> > to be heard.
> >
> > Particularly if windows drivers are available, open sourced, and
> > installable on a winderz box using the normal install wizard, and
> > promoted as such to the joe six-packs of the world. At the right price,
> > that would send an even louder message to both nvidia and ati
>
> Do you think this opensource hardware could keep up with nvidia and ati
> hardware development? Joe sixpack is all about the fastest hardware.
Well, they are not aiming at creating a high end gaming card.
Here are some quotes from various documents at http://www.opengraphics.org/ :
"
Requirements
In order to be interesting to the open source community and OEM
vendors such a card should at a minimum meet the following
requirements:
* Programming interface must be fully documented
* No IP encumberment for implementing drivers
* Very good 2d graphics performance
* Full OpenGL implementation with as much hardware acceleration as possible
* Good support for xv (yuv->rgb, scaling) for video playback
* Reasonable price!
"
"
Due to market size it will not be possible to compete on 3d
performance with market leaders such as ATI and NVIDIA. This is not an
immediate problem because gaming is not what this card is aimed at,
but performance should be good enough for scientific simulations and
similar.
"
"
1. *Will I be able to play Doom 3 with this hardware?*
Nope, but at the time of this writing, there is no graphics card on
the market on which you can play Doom 3 well while using open source
drivers. Less demanding games are likely to work however.
"
"
With about 6.4 gigabytes/second memory bandwidth, the video
performance should be comparable to current midrange graphic-cards
like the ATI Radeon 9600 which can e.g. play Battlefield 2.
"
Their featurelist also has more details:
http://wiki.duskglow.com/tiki-index.php?page=FeatureList
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Mon, 2005-12-05 at 11:23 -0500, Brian Gerst wrote:
> Intel? That's all nice and dandy if and only if you have an Intel
> CPU. Not an option for AMD users, for obvious reasons.
Actually even the Intel support isn't particularly good. We don't have
proper mode setup code -- we have to invoke the BIOS to do mode setup,
and we can't set specific modelines (like PAL-compatible modes); we're
limited to what the BIOS knows about -- it's like vesafb with
acceleration.
There's some work on reverse-engineering the BIOS so that you can
hackishly poke 'new' modes into its tables, but it's still not a very
good option.
--
dwmw2
On Tuesday 06 December 2005 16:27, Simon Oosthoek wrote:
> Arjan van de Ven wrote:
> > On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
> >>On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
> >>>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.
>
> I use nvidia cards, mostly because they work better than an alternative
> for now, but every time I need a card I look for stuff that is more
> open, because I hate to have to use the non-free closed stuff to do
> graphics. (Having no real choice in this is really annoying to me!)
The ATi Radeon 9200 works fine...
--
Luke-Jr
Developer, Utopios
http://utopios.org/
On Tuesday 06 December 2005 07:58, Coywolf Qi Hunt wrote:
> Your response is nonsense. It has the same logic as saying "If
> proprietary software is wrong, why are you using it?".
> Everybody are using proprietary software, aren't they?
No proprietary software here, excluding things such as firmware/BIOS where
there is no choice.
--
Luke-Jr
Developer, Utopios
http://utopios.org/
On Tue, 2005-12-06 at 17:36 +0200, Hannu Savolainen wrote:
> On Tue, 6 Dec 2005, Denis Vlasenko wrote:
>
> > How about refusing binary-only modules instead? I mean, maybe
> > if Linux will stop being lax about GPL requirements on modules.
> Or why not to include an embedded version of gcc/binutils in the kernel
> LKM interface. In this way all drivers can only be distributed in source
> code which effectively makes all forms of binary only drivers impossible.
Are you saying you'd open source all those binary only OSS drivers if
this were to happen?
Lee
On Tue, 2005-12-06 at 16:41 +0000, Dirk Steuwer wrote:
> Sander <sander <at> humilis.net> writes:
> >
> > Quite a few companies state on their site that their hardware is
> > supported in Linux if it is.
> >
> > And I've never bought any computer equipment in a shop. Always online,
> > where there is no such thing as a box anyway
> >
>
>
> Yes, but there isn't and won't be much recognition - every company does its own
> thing. And how many people buy online all the time? But even then, a genery
> "runs with Linux" Logo would be great. If a company's product is not certified,
> its not considered by Linux customers.
The vendors will just lie like they do now. For example M-Audio claims
all its products are supported under Linux but leave out the fact that
half of it had to be reverse engineered, lots of it still doesn't work
right for lack of docs, and whenever someone asks them about Linux
support they just punt to the ALSA mailing lists.
Lee
On Tue, Dec 06, 2005 at 04:49:14PM +0100, Pawe? Sikora wrote:
> Dnia wtorek, 6 grudnia 2005 16:30, Florian Weimer napisa?:
> > * Brian Gerst:
> > > Once again I'd like to point out that user's purchase power means jack
> > > when they only have two choices for video: ATI and Nvidia. You can't
> > > walk into a computer store and find anything else (I don't count
> > > integrated video on the motherboard as a solution, since only Intel
> > > boards have it, sorry AMD users). Even over the web it's hard to find
> > > anything else.
> >
> > What about Matrox cards? Are there open drivers for accelerated 2D
> > operation?
>
> Open 2D is nothing new. The OpenGL is a major part.
> Matrox and XGI (e.g. Volari V3 based cards) have openGL parts closed.
Interesting remark, but false. Xorg ships open source driver with full
3D acceleration suport forMatrox.
--
Tomasz Torcz "Never underestimate the bandwidth of a station
[email protected] wagon filled with backup tapes." -- Jim Gray
On Tue, 6 Dec 2005, Jesper Juhl wrote:
> On 12/6/05, Zwane Mwaikambo <[email protected]> wrote:
> > On Mon, 5 Dec 2005, Gene Heskett wrote:
> >
> > > Particularly if windows drivers are available, open sourced, and
> > > installable on a winderz box using the normal install wizard, and
> > > promoted as such to the joe six-packs of the world. At the right price,
> > > that would send an even louder message to both nvidia and ati
> >
> > Do you think this opensource hardware could keep up with nvidia and ati
> > hardware development? Joe sixpack is all about the fastest hardware.
>
> Well, they are not aiming at creating a high end gaming card.
>
> Here are some quotes from various documents at http://www.opengraphics.org/ :
My reply was to his email and not in reference to opengraphics.org
On 12/6/05, Jean-Christian de Rivaz <[email protected]> wrote:
> Gene Heskett a ?crit :
>
> > Which is the best reason in the world to buy and use, the open source
> > video card now under development, and I hear its less than 3-4 months
> > from production status now, and at a competitive, sub $150 USD price.
>
> Can you post a link about this open source video card ? I strongly wants
http://www.opengraphics.org/
> to support this kind of project. It's clear for me: this is the only way
> to solve the problem in the long term.
>
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Dnia wtorek, 6 grudnia 2005 20:00, Tomasz Torcz napisał:
> On Tue, Dec 06, 2005 at 04:49:14PM +0100, Paweł Sikora wrote:
> > Dnia wtorek, 6 grudnia 2005 16:30, Florian Weimer napisał:
> > > * Brian Gerst:
> > > > Once again I'd like to point out that user's purchase power means
> > > > jack when they only have two choices for video: ATI and Nvidia. You
> > > > can't walk into a computer store and find anything else (I don't
> > > > count integrated video on the motherboard as a solution, since only
> > > > Intel boards have it, sorry AMD users). Even over the web it's hard
> > > > to find anything else.
> > >
> > > What about Matrox cards? Are there open drivers for accelerated 2D
> > > operation?
> >
> > Open 2D is nothing new. The OpenGL is a major part.
> > Matrox and XGI (e.g. Volari V3 based cards) have openGL parts closed.
>
> Interesting remark, but false.
I investigated only mtx driver from theirs website.
> Xorg ships open source driver with full 3D acceleration suport forMatrox.
For which card?
--
to_be || !to_be == 1, to_be | ~to_be == -1
Brian Gerst wrote:
> Once again I'd like to point out that user's purchase power means jack
> when they only have two choices for video: ATI and Nvidia. You can't
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users). Even over the web it's hard to find
> anything else. I'm not trying to defend closed source here, but you
> people just have to face the reality that trying to use the market to
> get our way is just not going to work with video. The only way forward
> is reverse engineering. We aren't going to get help from the vendors so
> we have to help ourselves.
It sure looks that way.
Let's hope the rev-eng people do it the right way, by having one team
write a document, and a totally separate team write the driver from that
document.
Jeff
On 12/6/05, Zwane Mwaikambo <[email protected]> wrote:
> On Tue, 6 Dec 2005, Jesper Juhl wrote:
>
> > On 12/6/05, Zwane Mwaikambo <[email protected]> wrote:
> > > On Mon, 5 Dec 2005, Gene Heskett wrote:
> > >
> > > > Particularly if windows drivers are available, open sourced, and
> > > > installable on a winderz box using the normal install wizard, and
> > > > promoted as such to the joe six-packs of the world. At the right price,
> > > > that would send an even louder message to both nvidia and ati
> > >
> > > Do you think this opensource hardware could keep up with nvidia and ati
> > > hardware development? Joe sixpack is all about the fastest hardware.
> >
> > Well, they are not aiming at creating a high end gaming card.
> >
> > Here are some quotes from various documents at http://www.opengraphics.org/ :
>
> My reply was to his email and not in reference to opengraphics.org
>
Ok, then I misunderstood your mail.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Mon, Dec 05, 2005 at 08:12:16PM -0800, Greg KH wrote:
> On Mon, Dec 05, 2005 at 03:56:06PM -0800, Tim Bird wrote:
> > 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. ;-)
>
> Why do people bring up the "derivative works" issue all the time. Are
> they so blind to the very simple "linking" issue that all kernel modules
> do when they are loaded into the kernel?
The linked kernel+module combination is pretty clearly a derived work
(but I am not a lawyer). However, that never gets *distributed* and
the GPL only covers distribution rights.
The question of whether or not something which *could* be linked into
the kernel is a derived work is a very different question, and if
taken too far, an advocate of this interpretation starts advocating
something very close to interface copyrights --- something which I
will note the FSF is passionately against when they called a boycott
on companies such as Lotus many years ago.
But this is very much off-topic for this list. I suggest that folks
talk to Larry Rosen for his view on this issue, if they want a
balanced counterpoint to that pushed by the FSF.
- Ted
Andrea Arcangeli wrote:
> I think Linus is doing the right thing here, and he is avoiding what I
> described in the previous email: that is breaking drivers gratuitously
> is what could make linux hostile and too costly to support IMHO. We want
> to be parnters with all hardware companies, but we want them to support
> linux properly (not with binary only drivers), in a way that we can fix
> it, port it to other archs, and so that we don't lose support for the
> hardware while improving internal APIs.
Agreed.
Jeff
On Maw, 2005-12-06 at 18:42 +0000, David Woodhouse wrote:
> There's some work on reverse-engineering the BIOS so that you can
> hackishly poke 'new' modes into its tables, but it's still not a very
> good option.
Especially as the BIOS interface at the low level for the analogue end
and the logic driving it is board specific. Intel have been fairly clear
why they use the BIOS interface.
On Maw, 2005-12-06 at 13:19 -0500, Theodore Ts'o wrote:
> The question of whether or not something which *could* be linked into
> the kernel is a derived work is a very different question
Its also a question that falls into the area of conspiracy to commit an
offence in some legal domains rather than being about 'interface
copyright'.
Alan
On Tue, Dec 06, 2005 at 08:11:55PM +0100, Pawe? Sikora wrote:
> Dnia wtorek, 6 grudnia 2005 20:00, Tomasz Torcz napisa?:
> > On Tue, Dec 06, 2005 at 04:49:14PM +0100, Pawe? Sikora wrote:
> > > Dnia wtorek, 6 grudnia 2005 16:30, Florian Weimer napisa?:
> > > > * Brian Gerst:
> > > > > Once again I'd like to point out that user's purchase power means
> > > > > jack when they only have two choices for video: ATI and Nvidia. You
> > > > > can't walk into a computer store and find anything else (I don't
> > > > > count integrated video on the motherboard as a solution, since only
> > > > > Intel boards have it, sorry AMD users). Even over the web it's hard
> > > > > to find anything else.
> > > >
> > > > What about Matrox cards? Are there open drivers for accelerated 2D
> > > > operation?
> > >
> > > Open 2D is nothing new. The OpenGL is a major part.
> > > Matrox and XGI (e.g. Volari V3 based cards) have openGL parts closed.
> >
> > Interesting remark, but false.
>
> I investigated only mtx driver from theirs website.
Binary driver from matrox website caontains, IIRC, only some interface
to access matrox card in dual-monitor modes. It's irrelevant for OpenGL.
> > Xorg ships open source driver with full 3D acceleration suport forMatrox.
>
> For which card?
For my Matrox G550 and earlier models.
--
Tomasz Torcz "Never underestimate the bandwidth of a station
[email protected] wagon filled with backup tapes." -- Jim Gray
On Tue, 2005-12-06 at 14:13 -0500, Jeff Garzik wrote:
> Let's hope the rev-eng people do it the right way, by having one team
> write a document, and a totally separate team write the driver from
> that document.
>
Isn't it also legal for a single person or team to capture all IO
to/from the device with a bus analyzer or kernel debugger and write a
driver from that, as long as you don't disassemble the original driver?
Lee
On Tue, Dec 06, 2005 at 07:27:42PM +0000, Alan Cox wrote:
> On Maw, 2005-12-06 at 13:19 -0500, Theodore Ts'o wrote:
> > The question of whether or not something which *could* be linked into
> > the kernel is a derived work is a very different question
>
> Its also a question that falls into the area of conspiracy to commit an
> offence in some legal domains rather than being about 'interface
> copyright'.
Conspiracy to commit what offence? There's nothing wrong with linking
GPL'ed code with propietary code, in the privacy of your own home (or
server). The offence only happens when you distribute the resulting
derived work....
- Ted
Lee Revell wrote:
> On Tue, 2005-12-06 at 14:13 -0500, Jeff Garzik wrote:
>>Let's hope the rev-eng people do it the right way, by having one team
>>write a document, and a totally separate team write the driver from
>>that document.
> Isn't it also legal for a single person or team to capture all IO
> to/from the device with a bus analyzer or kernel debugger and write a
> driver from that, as long as you don't disassemble the original driver?
It's still legally shaky. The "Chinese wall" approach I described above
is beyond reproach, and that's where Linux needs to be.
Jeff
On Tue, 2005-12-06 at 14:41 -0500, Jeff Garzik wrote:
> Lee Revell wrote:
> > On Tue, 2005-12-06 at 14:13 -0500, Jeff Garzik wrote:
> >>Let's hope the rev-eng people do it the right way, by having one team
> >>write a document, and a totally separate team write the driver from
> >>that document.
>
> > Isn't it also legal for a single person or team to capture all IO
> > to/from the device with a bus analyzer or kernel debugger and write a
> > driver from that, as long as you don't disassemble the original driver?
>
> It's still legally shaky. The "Chinese wall" approach I described above
> is beyond reproach, and that's where Linux needs to be.
I know you are not a lawyer but do you have a pointer or two? As long
as we are REing for interoperability I've never read anything to
indicate the approach I described could be a problem even in the US.
Lee
On Maw, 2005-12-06 at 15:25 +0000, David Woodhouse wrote:
> But yes -- its existence is indeed a 'sort of proof' that non-GPL
> modules are at least _considered_ to be OK in some situations. I wish
> we'd never invented EXPORT_SYMBOL_GPL() in the first place -- it appears
> to legitimise something which was never really OK in the first place,
> and weakens our position when we take it to court.
<Legalese see below for interesting content>
On the contrary. I can demonstrate I've repeatedly stated that I
consider almost all modules invalid, that I contributed code before
Linus ever made any comments about non-GPL modules and that he
incorporated code from bodies strongly of that view who granted no non
GPL usage without asking them for any exception (notably from the FSF)
(and Linus is added to this for legal reasons alone)
</End of legalese>
I think however you also have to work *with* rather than against a lot
of the vendors who are trying to manage awkward problems (even if
generally of their own historical making). There are plenty of people
who do need a good kicking and ship binary only Linux systems that need
dealing with well before you want to worry about the less clear cases.
People like Nvidia who have made business decisions based on the
licensing problems they face and looked at the question aren't the folks
to go chasing with large hammers even if its annoying. Start with the
folks who really genuinely don't care. A look at gpl-violations.org will
show the scale of that problem.
Some of the other suggestions people have made don't work either. The
limit of power in a copyright license is constrained by law. The
drafters of copyright laws chose for good and sound reasons to say that
you can't use copyright agreements to interfere with non-derivative
works. They did this for a lot of good reasons.
EXPORT_SYMBOL_GPL also started with an intent to indicate internal
interfaces (ie those that are clearly derivative). If you want to split
the technology come legal issues and the politics rename it to
EXPORT_SYMBOL_INTERNAL. The only case for _GPL then would be to
specifically mark code that implements or derives from a work
implementing GPL patent licensed code. In those cases the derivative
work question is irrelevant as patents are not bounded in the same way.
That keeps the intent clear "this is an internal symbol", doesn't really
change the effect of any legal derivate works decision that I can see
(and its hard to see as caselaw for such cases is quite limited).
The enforcement side is also worth keeping because while we don't have
caselaw on the "lying about being GPL" case we do have some good
evidence in ongoing situations that corporate lawyers are very concerned
to discover they are shipping a lying module. Sorry no details on the
case in question can be public atm.
As to moving a function from _GPL, as I understand the legal situation
its up to the copyright holders to make a licensing change _if_ it is
one. If it isn't then it doesn't matter. If it is well Linus is probably
now personally liable (or OSDL) instead of Nvidia, his problem, his
choice. Is the new insert_page internal, that in itself isn't clear
Alan
On Maw, 2005-12-06 at 14:38 -0500, Theodore Ts'o wrote:
> Conspiracy to commit what offence? There's nothing wrong with linking
> GPL'ed code with propietary code, in the privacy of your own home (or
> server). The offence only happens when you distribute the resulting
> derived work....
In many countries moving the data from hard disk to memory is copying,
ditto to cache, and that is established caselaw.
Alan
On Tue, 6 Dec 2005, Lee Revell wrote:
> Are you saying you'd open source all those binary only OSS drivers if
> this were to happen?
I don't promise anything but we have been working on an open source
release of OSS (OpenOSS) at least for OpenSolaris during next
spring/summer. Linux port is also possible at the same time or bit later.
Sorry but I can't give any more details at this moment.
For various reasons this stuff will be released outside the kernel build.
For this reason I'm more or less worried about the difficulties
related with compiling driver code separately from the kernel image.
Best regards,
Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
On Maw, 2005-12-06 at 14:55 -0500, Lee Revell wrote:
> > It's still legally shaky. The "Chinese wall" approach I described above
> > is beyond reproach, and that's where Linux needs to be.
>
> I know you are not a lawyer but do you have a pointer or two? As long
> as we are REing for interoperability I've never read anything to
> indicate the approach I described could be a problem even in the US.
It isnt a problem providing you don't copy anything. The chinese wall
approach is used to avoid the risk that what happens is not
"Oh so register foo bit 4 controls the backlight"
but
"this sequence of instructions turns on the backlight"
The risk is that by reading the disassembled binary and rewriting it a
programming might actually be deemed to have copied code if they
accidentally just reproduce the original implementation.
Often of course disassembly is the hard way to solve the problem. Firing
up the driver with analyser tools and studying how it works can be far
more informative. With the ATI R3xx work asking the binary driver to
draw a wide range of triangles and monitoring the command queue output
for each request provides very good info, while attempting to deciphers
megabytes of windows 3D driver code, which is likely to contain self
modifying or JIT generated pipelines, is going to be extremely hard
work.
On Tue, Dec 06, 2005 at 08:11:55PM +0100, Paweł Sikora wrote:
> Dnia wtorek, 6 grudnia 2005 20:00, Tomasz Torcz napisał:
> > On Tue, Dec 06, 2005 at 04:49:14PM +0100, Paweł Sikora wrote:
> > > Dnia wtorek, 6 grudnia 2005 16:30, Florian Weimer napisał:
> > > > * Brian Gerst:
> > > > > Once again I'd like to point out that user's purchase power means
> > > > > jack when they only have two choices for video: ATI and Nvidia. You
> > > > > can't walk into a computer store and find anything else (I don't
> > > > > count integrated video on the motherboard as a solution, since only
> > > > > Intel boards have it, sorry AMD users). Even over the web it's hard
> > > > > to find anything else.
> > > >
> > > > What about Matrox cards? Are there open drivers for accelerated 2D
> > > > operation?
> > >
> > > Open 2D is nothing new. The OpenGL is a major part.
> > > Matrox and XGI (e.g. Volari V3 based cards) have openGL parts closed.
> >
> > Interesting remark, but false.
>
> I investigated only mtx driver from theirs website.
Indeed, anything newer than a G550 is binary only as far as 3D is concerned.
Sad, as Matrox used to be a really good recommendation for an
opensource friendly graphic card vendor.
It's not as if their newer cards are even that fast, so my only
guess is that they've gone the binary blob route purely for
paranoia reasons.
That said, they had a binary blob for some of the special
features of their cards for a long time, but most users would
never need it.
Dave
On Tue, Dec 06, 2005 at 08:18:27PM +0000, Alan Cox wrote:
> On Maw, 2005-12-06 at 14:38 -0500, Theodore Ts'o wrote:
> > Conspiracy to commit what offence? There's nothing wrong with linking
> > GPL'ed code with propietary code, in the privacy of your own home (or
> > server). The offence only happens when you distribute the resulting
> > derived work....
>
> In many countries moving the data from hard disk to memory is copying,
> ditto to cache, and that is established caselaw.
Ah, but the GPL hangs its requirements off of "distribution", not
copying per se. Also note the following statement from the GPL:
"The act of running the Program is not restricted"
But this is not legal advice, and I am not a lawyer; anyone who is
wants to figure out what they can or can't do shouldn't be talking to
either Alan or me; they should be talking to a real, live lawyer.
- Ted
Brian Gerst <[email protected]> :
[...]
> walk into a computer store and find anything else (I don't count
> integrated video on the motherboard as a solution, since only Intel
> boards have it, sorry AMD users).
Some SiS based motherboards offer both an integrated video and AMD
processor support.
--
Ueimor
On 12/6/05, Jesper Juhl <[email protected]> wrote:
> On 12/6/05, Jean-Christian de Rivaz <[email protected]> wrote:
> > Gene Heskett a ?crit :
> > Can you post a link about this open source video card ? I strongly wants
Merci monsieur de votre question.
> http://www.opengraphics.org/
I'll take a look at this - and I'd appreciate as much spam as possible
on this so I can turn it into some interesting articles on the topic.
Looks like I'll need to buy one of these :-)
Jon.
Alan Cox wrote:
> On Maw, 2005-12-06 at 18:42 +0000, David Woodhouse wrote:
>
>>There's some work on reverse-engineering the BIOS so that you can
>>hackishly poke 'new' modes into its tables, but it's still not a very
>>good option.
>
>
> Especially as the BIOS interface at the low level for the analogue end
> and the logic driving it is board specific. Intel have been fairly clear
> why they use the BIOS interface.
[utter, complete, abrupt tangent]
Since people are talking about BIOS, that made me remember that I wanted
to mention something of minor significance:
Marvell GPL'd their storage BIOS that ships with their 50xx and 60xx
cards. x86 code, not OF.
FWIW.
Now you may return to your regularly scheduled flamewar...
Jeff
On Tuesday 06 December 2005 18:48, you wrote:
> On Tue, 2005-12-06 at 16:41 +0000, Dirk Steuwer wrote:
> > Sander <sander <at> humilis.net> writes:
> > > Quite a few companies state on their site that their hardware is
> > > supported in Linux if it is.
> > >
> > > And I've never bought any computer equipment in a shop. Always
> > > online, where there is no such thing as a box anyway
> >
> > Yes, but there isn't and won't be much recognition - every company
> > does its own thing. And how many people buy online all the time? But
> > even then, a genery "runs with Linux" Logo would be great. If a
> > company's product is not certified, its not considered by Linux
> > customers.
>
> The vendors will just lie like they do now. For example M-Audio claims
> all its products are supported under Linux but leave out the fact that
> half of it had to be reverse engineered, lots of it still doesn't work
> right for lack of docs, and whenever someone asks them about Linux
> support they just punt to the ALSA mailing lists.
Then how about a "formal" linux certified logo? IOW a logo that can *only*
be used if the hardware has drivers that were written using an officially
supplied set of specifications and if said drivers are available under an
OSI certified licence. Any use of the logo on a piece of hardware that is
not certified would be liable to legal action.
Admittedly this would require a fair amount of effort to set up and uphold
but if it helped make it easier to choose compatible hardware it could be
worth it.
>
> Lee
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Lee Revell wrote:
> On Tue, 2005-12-06 at 14:41 -0500, Jeff Garzik wrote:
>
>>Lee Revell wrote:
>>
>>>On Tue, 2005-12-06 at 14:13 -0500, Jeff Garzik wrote:
>>>
>>>>Let's hope the rev-eng people do it the right way, by having one team
>>>>write a document, and a totally separate team write the driver from
>>>>that document.
>>
>>>Isn't it also legal for a single person or team to capture all IO
>>>to/from the device with a bus analyzer or kernel debugger and write a
>>>driver from that, as long as you don't disassemble the original driver?
>>
>>It's still legally shaky. The "Chinese wall" approach I described above
>>is beyond reproach, and that's where Linux needs to be.
>
>
> I know you are not a lawyer but do you have a pointer or two? As long
> as we are REing for interoperability I've never read anything to
> indicate the approach I described could be a problem even in the US.
The _potential_ for problems is very high:
1) [ref Alan's email] copying programming sequences
2) Lack of Chinese wall requires TRUST and EVIDENCE that you did the
rev-eng without "source code that fell off the back of a truck" [i.e.
illegally obtained] or "docs that fell off the back of a truck."
3) Lack of Chinese wall increases the likelihood that a SCOX or other
entity could use that as a legal weapon against Linux.
In Linux, I really have no way of knowing how questionable a driver
submission is, if it did not arrive from the Chinese wall approach, or a
known hacker with a valid path to hardware docs/engineers/code. Past
experience shows that Mr. Unknown Hacker is likely to take legal
shortcuts when writing the driver.
If I accept code of highly questionable origin, then I put Linux in
jeopardy.
Jeff
>
> The risk is that by reading the disassembled binary and rewriting it a
> programming might actually be deemed to have copied code if they
> accidentally just reproduce the original implementation.
>
>
> Often of course disassembly is the hard way to solve the problem. Firing
> up the driver with analyser tools and studying how it works can be far
> more informative. With the ATI R3xx work asking the binary driver to
> draw a wide range of triangles and monitoring the command queue output
> for each request provides very good info, while attempting to deciphers
> megabytes of windows 3D driver code, which is likely to contain self
> modifying or JIT generated pipelines, is going to be extremely hard
> work.
>
I can pretty much guarantee nobody is stupid enough to even think
about attaching a debugger or disassembler to fglrx, doing black-box
reverse engineering is sufficent for everything, and as the r300 is
derived in many respects from the r200, we have a lot of info from
it..
Dave.
Arjan van de Ven <arjan <at> infradead.org> writes:
> There are lots of opportunities to put pressure on vendors, either
> direct or indirect. Nvidia has a support department. If they get enough
> calls / letters about their solution not being good enough, they're more
> likely to consider the rearchtect solution.
Indeed a single centralized complete online hardware database (with hardware
rated according to driver support level) would go a long way to put real
pressure on vendors. We know how to set up one for gnome/kde themes surely it'd
be possible to create one for hardware ? (not the current nebulae of
semi-complete overlapping projects, menuconfig entries, blog notes, linux-kernel
notifications)
But this requires _kernel_ _people_ cooperation. You're the ones who know what
works and what doesn't. You're the ones who know which corporations are helpful.
You're the first people users contact when they have new hardware they'd like to
make work. You're the ones who know which drivers you're currently working on.
The PCI ID database can be maintained without kernel people intervention. A
"linux-friendly hardware" database can not.
Right now getting hardware advice is a long and painful process. Hardware that
works is only semi-documented. Hardware which doesn't isn't at all. Users have
to comb numerous on-line databases and mail archives (full of obsolete/wrong
info) to spec a single linux-friendly system. Few people bother to answer
hardware advice requests on mailing lists.
Linux users could reward friendly hardware makers if only you bothered to point
them the right way. That is :
- list publicly working hardware as soon as the kernel driver is ready
- list publicly non-working hardware as soon as someone enquires for a reference
which does not work.
There's no magic.
Hardware makers do all kinds of stupid stuff to please review sites. Review
sites are influential because lots of people buy stuff based on their advice.
Lots of people follow review site advice because review sites centralize info
about all kinds of hardware, so you don't have to comb the web to find it.
As Groklaw has shown - if you manage to do complete coverage of a subject, even
an obscure subject like IP laws or Linux drivers, you suddenly get quoted
everywhere. But to reach that stage you mustn't go halfways but record
meticulously info about all the hardware you know of.
--
Nicolas Mailhot
Jeff Garzik wrote:
> Lee Revell wrote:
>
>> On Tue, 2005-12-06 at 14:41 -0500, Jeff Garzik wrote:
>>
>>> Lee Revell wrote:
>>>
>>>> On Tue, 2005-12-06 at 14:13 -0500, Jeff Garzik wrote:
>>>>
>>>>> Let's hope the rev-eng people do it the right way, by having one
>>>>> team write a document, and a totally separate team write the
>>>>> driver from
>>>>> that document.
>>>>
>>>
>>>> Isn't it also legal for a single person or team to capture all IO
>>>> to/from the device with a bus analyzer or kernel debugger and write a
>>>> driver from that, as long as you don't disassemble the original
>>>> driver?
>>>
>>>
>>> It's still legally shaky. The "Chinese wall" approach I described
>>> above is beyond reproach, and that's where Linux needs to be.
>>
>>
>>
>> I know you are not a lawyer but do you have a pointer or two? As long
>> as we are REing for interoperability I've never read anything to
>> indicate the approach I described could be a problem even in the US.
>
>
> The _potential_ for problems is very high:
>
> 1) [ref Alan's email] copying programming sequences
>
> 2) Lack of Chinese wall requires TRUST and EVIDENCE that you did the
> rev-eng without "source code that fell off the back of a truck" [i.e.
> illegally obtained] or "docs that fell off the back of a truck."
>
> 3) Lack of Chinese wall increases the likelihood that a SCOX or other
> entity could use that as a legal weapon against Linux.
Guys, get real. SCO is out of money and just took 10 million in float
capital to keep the doors open. They are after IBM, not Linux. WAKE UP!!!
Jeff
>
> In Linux, I really have no way of knowing how questionable a driver
> submission is, if it did not arrive from the Chinese wall approach, or
> a known hacker with a valid path to hardware docs/engineers/code.
> Past experience shows that Mr. Unknown Hacker is likely to take legal
> shortcuts when writing the driver.
>
> If I accept code of highly questionable origin, then I put Linux in
> jeopardy.
>
> Jeff
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 2005-12-06 at 16:49 -0500, Jeff Garzik wrote:
> Lee Revell wrote:
> > On Tue, 2005-12-06 at 14:41 -0500, Jeff Garzik wrote:
> >
> >>Lee Revell wrote:
> >>
> >>>On Tue, 2005-12-06 at 14:13 -0500, Jeff Garzik wrote:
> >>>
> >>>>Let's hope the rev-eng people do it the right way, by having one team
> >>>>write a document, and a totally separate team write the driver from
> >>>>that document.
> >>
> >>>Isn't it also legal for a single person or team to capture all IO
> >>>to/from the device with a bus analyzer or kernel debugger and write a
> >>>driver from that, as long as you don't disassemble the original driver?
> >>
> >>It's still legally shaky. The "Chinese wall" approach I described above
> >>is beyond reproach, and that's where Linux needs to be.
> >
> >
> > I know you are not a lawyer but do you have a pointer or two? As long
> > as we are REing for interoperability I've never read anything to
> > indicate the approach I described could be a problem even in the US.
>
> The _potential_ for problems is very high:
>
> 1) [ref Alan's email] copying programming sequences
>
> 2) Lack of Chinese wall requires TRUST and EVIDENCE that you did the
> rev-eng without "source code that fell off the back of a truck" [i.e.
> illegally obtained] or "docs that fell off the back of a truck."
>
> 3) Lack of Chinese wall increases the likelihood that a SCOX or other
> entity could use that as a legal weapon against Linux.
>
> In Linux, I really have no way of knowing how questionable a driver
> submission is, if it did not arrive from the Chinese wall approach, or a
> known hacker with a valid path to hardware docs/engineers/code. Past
> experience shows that Mr. Unknown Hacker is likely to take legal
> shortcuts when writing the driver.
>
> If I accept code of highly questionable origin, then I put Linux in
> jeopardy.
Should this high barrier to entry for reverse engineered drivers be
documented anywhere? I would have expected black box reverse
engineering to be OK for Linux driver development.
Lee
On Tue, 2005-12-06 at 19:23 +0000, Alan Cox wrote:
> On Maw, 2005-12-06 at 18:42 +0000, David Woodhouse wrote:
> > There's some work on reverse-engineering the BIOS so that you can
> > hackishly poke 'new' modes into its tables, but it's still not a very
> > good option.
>
> Especially as the BIOS interface at the low level for the analogue end
> and the logic driving it is board specific. Intel have been fairly clear
> why they use the BIOS interface.
Have they? I haven't seen the excuse.
I assume it's similar to the excuse for ACPI -- "although we _could_
document the chips and allow board manufacturers to include simple
tables which describe the way they're wired together (in which they have
relatively little leeway), we'd rather hide it all behind some opaque
blob and have you trust HardwareVendorCode to drive it instead of being
able to write your own and debug it as you can with Free Software"?
Trusting the BIOS for this kind of thing isn't really much better than
trusting any other binary-only piece of code, from a technical point of
view. (Ignoring the licensing issues; we have indeed digressed). In
fact, given the traditional quality of BIOS implementations, trusting
the BIOS is far _worse_ than trusting any other piece of binary code.
--
dwmw2
* Lee Revell:
> I know you are not a lawyer but do you have a pointer or two? As long
> as we are REing for interoperability I've never read anything to
> indicate the approach I described could be a problem even in the US.
Are we still reverse-engineering for interoperability when we
essentially want to duplicate a piece of software with identical
purpose? 8-)
On Maw, 2005-12-06 at 22:25 +0000, David Woodhouse wrote:
> Have they? I haven't seen the excuse.
The video 'solution' is a combination of digital and analog components.
Intel defined one end only. Its a bit like AC97 audio only as I
understand it rather less structured.
Note that most of the BIOS fixes don't replace the BIOS code, they
provide extra mode table entries to it.
Alan
On Tue, Dec 06, 2005 at 11:44:43PM +0100, Florian Weimer wrote:
> Are we still reverse-engineering for interoperability when we
> essentially want to duplicate a piece of software with identical
> purpose? 8-)
There's not just x86* and ia64 out there, interoperability with
different archs isn't possible today.
On Tue, 2005-12-06 at 22:49 +0000, Alan Cox wrote:
> The video 'solution' is a combination of digital and analog
> components. Intel defined one end only. Its a bit like AC97 audio only
> as I understand it rather less structured.
>
> Note that most of the BIOS fixes don't replace the BIOS code, they
> provide extra mode table entries to it.
AIUI we can't even add 'extra' mode table entries -- we can only modify
existing entries, and we can't even set the full modeline information on
some systems because we haven't reverse-engineered the tables
completely.
It's done by copying the video BIOS into shadow RAM and modifying the
table in RAM. This isn't really much of an improvement over binary-only
drivers.
--
dwmw2
On Tue, 2005-12-06 at 23:44 +0100, Florian Weimer wrote:
> * Lee Revell:
>
> > I know you are not a lawyer but do you have a pointer or two? As long
> > as we are REing for interoperability I've never read anything to
> > indicate the approach I described could be a problem even in the US.
>
> Are we still reverse-engineering for interoperability when we
> essentially want to duplicate a piece of software with identical
> purpose? 8-)
>
I would think that any reverse engineering to make a Linux driver falls
under interoperability because it's the only way to make the hardware
work with my OS.
Lee
On Tue, 2005-12-06 at 13:54 -0700, Jeff V. Merkey wrote:
[...]
> Guys, get real. SCO is out of money and just took 10 million in float
> capital to keep the doors open. They are after IBM, not Linux. WAKE UP!!!
Yes, this was obvious since the first accusation. But "they"
-) didn't formulate it that way but came down with completely false (if
not intentionally lied *from the very first day of the public
campaign*).
-) used the Linux kernel as a - innocent - vehicle for their great
campaign to get bought by IBM (which - for God's sake - didn't work
out) *without* any serious and real background, evidence or anything
else.
So it's completely up to these folks to make up for the damage they
evoked.
And yes, I can understand that "they" want to make money and get rich
(who doesn't want this?). And no, this doesn't imply any tolerance or
even understanding of the used means, the lying all the way, spreading
FUD, and all other less then serious accusations and the media show.
Berndm, shutting now up about SCO since they are apparently dead
PS: I don't understand for what reason any (and which) entity should
give them money (and if it's only 1$).
--
"Mozart hätte Stehgeiger werden müssen, wenn Haydn ein Patent auf
Symphonien bekommen hätte" - http://www.luga.at/swpat/
"Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und
das nennen sie ihren Standpunkt." - A. Einstein
On Wed, 2005-12-07 at 00:13 +0100, Bernd Petrovitsch wrote:
> On Tue, 2005-12-06 at 13:54 -0700, Jeff V. Merkey wrote:
> [...]
> > Guys, get real. SCO is out of money and just took 10 million in float
> > capital to keep the doors open. They are after IBM, not Linux. WAKE UP!!!
>
> Yes, this was obvious since the first accusation. But "they"
> -) didn't formulate it that way but came down with completely false (if
> not intentionally lied *from the very first day of the public
> campaign*).
> -) used the Linux kernel as a - innocent - vehicle for their great
> campaign to get bought by IBM (which - for God's sake - didn't work
> out) *without* any serious and real background, evidence or anything
> else.
>
> So it's completely up to these folks to make up for the damage they
> evoked.
Please don't feed the trolls, this thread was bad enough already.
Lee
On 12/6/05, David Woodhouse <[email protected]> wrote:
> On Tue, 2005-12-06 at 19:23 +0000, Alan Cox wrote:
> > On Maw, 2005-12-06 at 18:42 +0000, David Woodhouse wrote:
> > > There's some work on reverse-engineering the BIOS so that you can
> > > hackishly poke 'new' modes into its tables, but it's still not a very
> > > good option.
> >
> > Especially as the BIOS interface at the low level for the analogue end
> > and the logic driving it is board specific. Intel have been fairly clear
> > why they use the BIOS interface.
>
> Have they? I haven't seen the excuse.
>
> I assume it's similar to the excuse for ACPI -- "although we _could_
> document the chips and allow board manufacturers to include simple
> tables which describe the way they're wired together (in which they have
> relatively little leeway), we'd rather hide it all behind some opaque
> blob and have you trust HardwareVendorCode to drive it instead of being
> able to write your own and debug it as you can with Free Software"?
Where possible ACPI does still use tables. For more complicated
configuration, ACPI uses easily-decompiled bytecodes. I think if the
graphics bios provided arch-neutral AML for doing all this
mode-setting stuff we'd be better off. Better than interpreting x86
real-mode BIOS code!
> Trusting the BIOS for this kind of thing isn't really much better than
> trusting any other binary-only piece of code, from a technical point of
> view. (Ignoring the licensing issues; we have indeed digressed). In
> fact, given the traditional quality of BIOS implementations, trusting
> the BIOS is far _worse_ than trusting any other piece of binary code.
You have to get a priori information about the system somewhere. With
ACPI at least it's not a complete mystery what the BIOS is doing,
unlike these video BIOSes.
-- Andy
On Tue, 2005-12-06 at 15:29 -0500, Dave Jones wrote:
[...]
> Indeed, anything newer than a G550 is binary only as far as 3D is concerned.
> Sad, as Matrox used to be a really good recommendation for an
> opensource friendly graphic card vendor.
>
> It's not as if their newer cards are even that fast, so my only
> guess is that they've gone the binary blob route purely for
> paranoia reasons.
Yes, the "software as such patent" and/or "trivial patent" disease
spreaded the last decades - not only in USPTO-land (and identically in
JPO-land) but also basically illegally in EPO-land.
And it is probably much simpler to "prove" (in the law sense, not
technically/mathematically) a patent infringement if you have C source
of the driver instead of some undocumented blob of object code.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Lee Revell wrote:
> Should this high barrier to entry for reverse engineered drivers be
> documented anywhere? I would have expected black box reverse
> engineering to be OK for Linux driver development.
As I said, the potential for problems is very high. I did not say it
was unacceptable. The barrier for entry is higher, though, yes.
The current case in point is several reverse-engineered wireless
drivers. I am not inclined to merge a few of the questionable projects,
but the Broadcom wireless project seems to have been done right, so it
will likely get merged quickly (once it passes quality/code reviews, etc.)
Jeff
On 12/5/05, William Lee Irwin III <[email protected]> wrote:
>>> 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.
On Mon, Dec 05, 2005 at 06:44:56PM +0000, Alistair John Strachan wrote:
> 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.
Linux has exempted itself from IP regulations of various countries by
a form of jurisdictional arbitrage, especially in the realms of reverse
engineering and cryptography. These sorts of IP regulations have strong
support from entrenched hardware, software, and entertainment interests,
and as the establishment of international/supranational regulatory
agencies proceeds and as regulatory "harmonizations" advance, this
jurisdictional arbitrage will become progressively more difficult to
continue. In particular, the "intellectual property" lobbyists, unless
challenged on a scale heretofore unseen, are likely to attempt to
convince individual governments to implement similar regulations one by
one as well as use such international/supranational affairs as the WTO,
EUCD, et al to impose such on countries otherwise disinclined to do so.
In particular, there is word of an initiative in France that threatens
to ban Linux and possibly all open-source software outright as
containing insufficient protections against the illegal dissemination
of copyrighted works, and/or as presenting some sort of threat to
royalty-based software, and/or (if I understand the notion properly) an
"illegal subsidy" to competitors of for-profit software firms, as
public utilities and other nonprofit and/or governmentally-erected
infrastructure have been ruled to be in various other instances. In
essence, a counterpart of the DMCA which declares open source software
and/or Linux a technology that can circumvent copyright protection, if
the DMCA doesn't do so itself.
Also, IP issues related to hardware are unlikely to stand still. As
observed earlier, several hardware vendors are looking to close their
driver source or to only offer binary drivers in the future. The
jurisdictional arbitrage under which the reverse engineering so common
for the implementation of open source drivers takes place is also
rather likely to be thwarted by similar attempts to promote legislation
to the above entertainment-related efforts.
So, as seen above, the "IP issues," if they're getting resolved at all,
don't appear to be getting resolved in Linux' favor. To all
appearances, there is literally an effort to legislate Linux out of
existence. One might call this "lawfare" (warfare through legislation)
against Linux.
-- wli
On Tue, 2005-12-06 at 15:25 -0800, Andrew Grover wrote:
> Where possible ACPI does still use tables. For more complicated
> configuration, ACPI uses easily-decompiled bytecodes. I think if the
> graphics bios provided arch-neutral AML for doing all this
> mode-setting stuff we'd be better off. Better than interpreting x86
> real-mode BIOS code!
This is true. Real drivers with only _tables_ to describe the hardware
would be best, but AML would be at least be better than i386 code, if we
have to settle for something less.
> You have to get a priori information about the system somewhere. With
> ACPI at least it's not a complete mystery what the BIOS is doing,
> unlike these video BIOSes.
Actually, the one time I tried to decompile a DSDT it was a Dell
Inspiron which did _everything_ through SMM traps. It was more opaque
even than a binary-only driver (or BIOS). At least with i386-code I have
_some_ hope of tracing it, if I have enough time and patience.
--
dwmw2
2005/12/7, Greg KH <[email protected]>:
> On Tue, Dec 06, 2005 at 03:58:46PM +0800, Coywolf Qi Hunt wrote:
> > > [1] My usual response is, "If we are so dumb, why are you using the kernel
> > > made by us?", which usually stops the conversation right there.
> >
> > Your response is nonsense. It has the same logic as saying "If
> > proprietary software is wrong, why are you using it?".
> > Everybody are using proprietary software, aren't they?
>
> Um, no, not at all. The logic is, "you trust these developers enough to
> want to run their code, controlling the most basic and secure portions
> of your machines, yet you think they are incapable programmers?"
One bought a PC, that doesn't mean he trust the BIOS, the firmware, etc...
He run windows on the box, that doesn't mean he trust windows either.
>
> And no kernel developers are forcing anyone to use Linux. If they don't
> like it for whatever reasons, there are other alternatives...
AFAIK, no proprietary software vendors are forcing any1 to buy their
proprietary software. Still you are speaking in a monopoly tone!
(cc: rms)
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
2005/12/7, Luke-Jr <[email protected]>:
> On Tuesday 06 December 2005 07:58, Coywolf Qi Hunt wrote:
> > Your response is nonsense. It has the same logic as saying "If
> > proprietary software is wrong, why are you using it?".
> > Everybody are using proprietary software, aren't they?
>
> No proprietary software here, excluding things such as firmware/BIOS where
> there is no choice.
Why 'excluding'? You can't deny you are using proprietary software.
Neither do us.
(cc: rms)
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
El Wed, 7 Dec 2005 09:42:22 +0800,
Coywolf Qi Hunt <[email protected]> escribi?:
> 2005/12/7, Luke-Jr <[email protected]>:
> > No proprietary software here, excluding things such as firmware/BIOS where
> > there is no choice.
>
> Why 'excluding'? You can't deny you are using proprietary software.
> Neither do us.
BIOS'es and firmware are not drivers or normal "processes". Firmware
doesn't deal with the internal kernel's locking for example- is a very
different thing. bios and firmware is pretty much part of the hardware,
pretty much like the chips' internal design: it just "does its work".
There's no of point on having open source bioses/firmware if you don't
have the design docs and all the related hardware info aswell.
(IOW: Saying that you'are using "propietary software" because you're
using a propietary BIOS is wrong, IMO - it's pretty much "propietary
hardware" even if its software)
On Wed, Dec 07, 2005 at 09:38:30AM +0800, Coywolf Qi Hunt wrote:
> 2005/12/7, Greg KH <[email protected]>:
> > And no kernel developers are forcing anyone to use Linux. If they don't
> > like it for whatever reasons, there are other alternatives...
>
> AFAIK, no proprietary software vendors are forcing any1 to buy their
> proprietary software. Still you are speaking in a monopoly tone!
How is the statement, "If you don't trust the intelligence of the Linux
kernel developers, then don't use the Linux kernel." a monopolistic
tone?
I'm serious, I never want to force anyone to use Linux. I want to make
Linux be so good that everyone wants to use it, out of their own free
will. And if they disagree with the way Linux is developed, or the
license terms, or the way it works, it will not bother me at all if they
choose to use something else.
I hear OpenSolaris is looking for users :)
thanks,
greg k-h
2005/12/7, Greg KH <[email protected]>:
> On Wed, Dec 07, 2005 at 09:38:30AM +0800, Coywolf Qi Hunt wrote:
> > 2005/12/7, Greg KH <[email protected]>:
> > > And no kernel developers are forcing anyone to use Linux. If they don't
> > > like it for whatever reasons, there are other alternatives...
> >
> > AFAIK, no proprietary software vendors are forcing any1 to buy their
> > proprietary software. Still you are speaking in a monopoly tone!
>
> How is the statement, "If you don't trust the intelligence of the Linux
> kernel developers, then don't use the Linux kernel." a monopolistic
> tone?
The fact is Linux supports more hardware now. Some *BSD users turn to
Linux in order to drive their hardware for the _same_ reason as users
turn to windows. That is really a monopolistic position.
>
> I'm serious, I never want to force anyone to use Linux. I want to make
> Linux be so good that everyone wants to use it, out of their own free
> will. And if they disagree with the way Linux is developed, or the
> license terms, or the way it works, it will not bother me at all if they
> choose to use something else.
Never doubt.
>
> I hear OpenSolaris is looking for users :)
Clever response. Add it to your usual response. ;)
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
On Wed, Dec 07, 2005 at 11:23:37AM +0800, Coywolf Qi Hunt wrote:
> 2005/12/7, Greg KH <[email protected]>:
> > On Wed, Dec 07, 2005 at 09:38:30AM +0800, Coywolf Qi Hunt wrote:
> > > 2005/12/7, Greg KH <[email protected]>:
> > > > And no kernel developers are forcing anyone to use Linux. If they don't
> > > > like it for whatever reasons, there are other alternatives...
> > >
> > > AFAIK, no proprietary software vendors are forcing any1 to buy their
> > > proprietary software. Still you are speaking in a monopoly tone!
> >
> > How is the statement, "If you don't trust the intelligence of the Linux
> > kernel developers, then don't use the Linux kernel." a monopolistic
> > tone?
>
> The fact is Linux supports more hardware now. Some *BSD users turn to
> Linux in order to drive their hardware for the _same_ reason as users
> turn to windows. That is really a monopolistic position.
No, not at all:
mo·nop·o·ly
Function: noun
1 : exclusive control of a particular market that is marked by
the power to control prices and exclude competition and that
esp. is developed willfully rather than as the result of
superior products or skill.
2 : one that has a monopoly
Source: Merriam-Webster's Dictionary of Law, © 1996 Merriam-Webster, Inc.
I think our "superior product and skill" is what makes us not a
monopoly :)
Besides, the *BSD developers routinely use our code to write their own
drivers (looking at how things are done) so in the end, having Linux
support a device helps them out too. So the "exclude competition"
portion of the above definition is also false...
thanks,
greg k-h
Wed, 7 Dec 2005 03:06:35 +0100 wrote:
> different thing. bios and firmware is pretty much part of the hardware,
> pretty much like the chips' internal design: it just "does its work".
> There's no of point on having open source bioses/firmware if you don't
> have the design docs and all the related hardware info aswell.
True for firmware, false for BIOS.
Jeff
On Tuesday 06 December 2005 14:49, Arjan van de Ven wrote:
> Sure. But that doesn't mean there is no purchase power. HP, Dell and IBM
> and co DO have purchasing power over NVidia and ATI. If they tell ATI or
> NVidia to either go open source (unlikely) or rearchitect their drivers
> to do the "hot IP" in userspace, it will happen.
Proprietary code in userspace is not much better.
> And YOU can influence Dell and HP and IBM again. By complaining to their
> sales people. By letting them know binary modules aren't going to cut it.
Neither is binary-only userland stuff.
Moving the problem doesn't solve it.
--
Luke-Jr
Developer, Utopios
http://utopios.org/
On Wed, 2005-12-07 at 07:02 +0000, Luke-Jr wrote:
> On Tuesday 06 December 2005 14:49, Arjan van de Ven wrote:
> > Sure. But that doesn't mean there is no purchase power. HP, Dell and IBM
> > and co DO have purchasing power over NVidia and ATI. If they tell ATI or
> > NVidia to either go open source (unlikely) or rearchitect their drivers
> > to do the "hot IP" in userspace, it will happen.
>
> Proprietary code in userspace is not much better.
Actually yes it is a lot better. Maybe it's not perfect, especially when
it talks to hardware, but in general userland code won't be able to
crash the machine, and is far less sensitive to internal changes to the
kernel. Userland applications are also independent works and are
isolated from eachother when they run. As long as you don't need them
for your system to boot.. Needing a userspace "driver" for 3D stuff is
a bit less optimal than the regular userland application, because it
voids some of the advantages I listed above, but it still is a heck of a
lot better than doing it in kernel land....
Grahame White <grahame <at> regress.homelinux.org> writes:
> Then how about a "formal" linux certified logo? IOW a logo that can *only*
> be used if the hardware has drivers that were written using an officially
> supplied set of specifications and if said drivers are available under an
> OSI certified licence. Any use of the logo on a piece of hardware that is
> not certified would be liable to legal action.
>
> Admittedly this would require a fair amount of effort to set up and uphold
> but if it helped make it easier to choose compatible hardware it could be
> worth it.
Yes, precisely what i was talking about.
Something really simple joe average can
follow.
It has to be validated from a license point of view,
but also from a technical side.
Otherwise, hardware folks license a piece of hardware and
then change something along the way, which doesn't work with the driver.
So ideally you have
the according linux kernel hacker acknowledging this as well was
OSI or someone else.
This would be a fantastic central database to look up for linux hardware
compatibility.
With clever Marketing, this in itself could be turn up quite some
revenue.
Part of the money could be returned to kernel bounty payment....
And this would put tremendous pressure on hardware folk to get in there
- job done.
I think this is feasable and if it chucks out some money, i can be done.
regards,
Dirk
Benjamin LaHaise wrote:
>On Mon, Dec 05, 2005 at 11:18:15PM -0500, Michael Poole wrote:
>
>
>>Besides, if the act of linking is what makes the derivative work,
>>there is no problem: The GPL allows a user to make any modifications
>>or combinations or derivatives whatsoever, and only imposes
>>requirements when the result is distributed. The linking of the two
>>works occurs only on the end user's machine.
>>
>>
>
>But if it's a module, it's probably been compiled against kernel headers.
>Last time I checked, header files were covered by the GPL unless explicitly
>placed under a more permissive license. How do you use something like
>spinlocks without compiling in GPL code to a module?
>
>
They can always claim that reverse engineering works both ways.
Linux spinlocks can be reverse engineered, or they can search
the mailing list archives for detailed explanations. :-/
Helge Hafting
Dirk Steuwer <[email protected]> wrote:
[...]
> Yes, but there isn't and won't be much recognition - every company does
> its own thing. And how many people buy online all the time? But even
> then, a genery "runs with Linux" Logo would be great.
Problem is that there are certain monopolists who would like everybody to
think there is nothing else around... besides, "works with Linux" (or BSD,
or whatever) doesn't say anything if it is "includes a driver for Red Hat's
2.2.x-y". "Works with Windows" doesn't say anything either (even if MSFT
themselves certifies games for running on Win98 and later it doesn't mean
they will run on WinNT)
> If a company's
> product is not certified, its not considered by Linux customers.
Doesn't work, as almost nothing is "Linux certified" today.
> Also you
> could hold up figures from certified hardware to impress and argue
> against companies that think there is no real market for Linux.
We here having any credible figures will happen /long/ after the affected
company has smelled the coffee and taken appropiate steps. They /do/ care
about who buys their stuff. It just is too little for now to make any big
difference. Having the figures here won't do any difference.
> There
> needs to be a way to breack out of the chicken and egg problem - no linux
> market, no linux hardware.
There is hardware that works well enough with Linux, thank you so much.
Some is broken, some doesn't work at all.
> Corporate Customers can afford to do research, expert staff does the
> buying. But the average homeuser? He needs a generic sign, as simple as
> that.
It would be very nice, true. But just isn't here yet.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Florian Weimer wrote:
>* Jon Smirl:
>
>
>
>>2) Endure the lawsuit and hope the FSF doesn't get a $450M settlement
>>like NTP is getting from RIM. Meanwhile watch your stock price tumble
>>since the injunction prevents you from shipping product.
>>
>>
>
>Unlike NTP[1], the FSF distributes real products and is vulnerable to
>counterclaims.
>
>
But they can fix that in a trivial way by setting up a separate company,
"FSF patent management" or some such?
Helge Hafting
On Wed, Dec 07, 2005 at 01:39:48PM +0100, Helge Hafting wrote:
> They can always claim that reverse engineering works both ways.
> Linux spinlocks can be reverse engineered, or they can search
> the mailing list archives for detailed explanations. :-/
Sure they can do that. But the point is they don't. Every propritary driver
so far uses the linux spinlock inline routines directly, may it be in the
object or in the glue code they ship.
On Mer, 2005-12-07 at 13:44 +0100, Helge Hafting wrote:
> But they can fix that in a trivial way by setting up a separate company,
> "FSF patent management" or some such?
You sell the patent and all rights to an offshore company that does no
other work. They then sue you for violating the patent because you
"accidentally" forgot to keep your own rights, you settle and pay them
back the same amount of money they paid you, you claim tax breaks on the
resulting loss.
Just spinning off a company in the modern day world is so tax
inefficient.
Alan
- -
The fundamental problem with western capitalist states is the peculiar
way they differentiate between "bribes" and "lobbying"
On Tue, Dec 06, 2005 at 04:41:44PM +0000, Dirk Steuwer wrote:
> Yes, but there isn't and won't be much recognition - every company does
> its own thing. And how many people buy online all the time? But even then,
> a genery "runs with Linux" Logo would be great. If a company's product
> is not certified, its not considered by Linux customers.
This is something I've wanted to see for years now. Linux distributions
do not have the motivation to work out the hardware certification issues
on the community level, as it interferes with their value add of branding.
I have always wished that when I see hardware advertising Linux support
that it has a meaning: open source, supportable drivers. Maybe it's time
to get such a project moving.
-ben
On Mon, 5 Dec 2005, Michael Poole wrote:
> Most likely people bring up the "derivative works" issue because
> that's what the GPL says it affects. The FSF contends that linking
> creates a derivative work, but is curiously quiet when people ask for
> statutory or case law to support that claim.
For statically linked programs this is quite easy to find.
--
All Rights Reversed
On Mon, 5 Dec 2005, Tim Bird wrote:
> 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?
>From my point of view, supporting binary drivers IS
the worst possible thing we could do.
It is all too common that a user ends up with two
binary drivers in his kernel, and both of the binary
driver vendors tell the user "try without the other
vendor's driver, otherwise we will not support you".
In the mean time, the user and the distro are caught
in-between two finger pointing binary driver vendors,
with no possibility of fixing the problem the user has.
3rd party binary drivers are such a support nightmare
that I wouldn't wish them on anyone. Especially not
on end users...
--
All Rights Reversed
On Wed, 7 Dec 2005, Benjamin LaHaise wrote:
> On Tue, Dec 06, 2005 at 04:41:44PM +0000, Dirk Steuwer wrote:
>> Yes, but there isn't and won't be much recognition - every company does
>> its own thing. And how many people buy online all the time? But even then,
>> a genery "runs with Linux" Logo would be great. If a company's product
>> is not certified, its not considered by Linux customers.
>
> This is something I've wanted to see for years now. Linux distributions
> do not have the motivation to work out the hardware certification issues
> on the community level, as it interferes with their value add of branding.
> I have always wished that when I see hardware advertising Linux support
> that it has a meaning: open source, supportable drivers. Maybe it's time
> to get such a project moving.
>
> -ben
If you have one of those junk PCs that the major companies keep
buying, look at the label; "Designed for Microsoft Windows".
This should tell you how little bluff-factor the "Linux fringe"
can pull.
In spite of the imminent destruction of major companies IP by
the incredibly stupid Windows OS, they still use it. Like lemmings
being led to the sea, most companies can't accept that M$ is
a defective, bug-ridden, and security-holed system. Instead they
think that M$ couldn't possibly be as bad as has been proven and
documented.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Mon, 5 Dec 2005, Brian Gerst wrote:
> The problem with this statement is that Linux users are a drop in the
> bucket of sales for this hardware. Boycotting doesn't cost the vendors
> enough to make them care.
Profit margins in the hardware world are small enough that
1% of the users can have a significant influence...
> And this does nothing for people who are converting over to
> Linux, and didn't buy hardware with that consideration in mind.
Not in the short term, no. But in the long term it may
make a difference.
--
All Rights Reversed
Hannu Savolainen wrote:
>
>Or why not to include an embedded version of gcc/binutils in the kernel
>LKM interface. In this way all drivers can only be distributed in source
>code which effectively makes all forms of binary only drivers impossible.
>After that all the EXPORT_SYMBOL_GPL nonsense can be removed and a proper
>DDI layer can be implemented for Linux. This makes it possible to ship
>"outside the kernel build" drivers without a risk of major
>incompatibility problems in the next kernel version. No, I'm not 100%
>serious but just 50%.
>
>
>
char mydriver[] = { 0x90, 0xf3, 0xa4, ... };
struct { unsigned long offset; void* symbol; } fixups[] = { { 79,
schedule }, ... };
module_init() { link(mydriver, fixups); ((void (*)())mydriver)(); }
:)
--
error compiling committee.c: too many arguments to function
Rik van Riel writes:
> On Mon, 5 Dec 2005, Michael Poole wrote:
>
> > Most likely people bring up the "derivative works" issue because
> > that's what the GPL says it affects. The FSF contends that linking
> > creates a derivative work, but is curiously quiet when people ask for
> > statutory or case law to support that claim.
>
> For statically linked programs this is quite easy to find.
Then please actually do this (rather than just waving your hands).
Michael Poole
On 12/7/05, Helge Hafting <[email protected]> wrote:
> Florian Weimer wrote:
>
> >* Jon Smirl:
> >
> >
> >
> >>2) Endure the lawsuit and hope the FSF doesn't get a $450M settlement
> >>like NTP is getting from RIM. Meanwhile watch your stock price tumble
> >>since the injunction prevents you from shipping product.
> >>
> >>
> >
> >Unlike NTP[1], the FSF distributes real products and is vulnerable to
> >counterclaims.
> >
> >
> But they can fix that in a trivial way by setting up a separate company,
> "FSF patent management" or some such?
Yes, even better set it up as a newly created charitable foundation.
Then donations to it are tax deductible and the headline with read:
"Patent crook steals from charity".
This doesn't have to be done in the US, but the laws in the US are
very favorable to do it.
>
> Helge Hafting
>
--
Jon Smirl
[email protected]
On 2005-12-06T17:32:14, Florian Weimer <[email protected]> wrote:
> > 2) Endure the lawsuit and hope the FSF doesn't get a $450M settlement
> > like NTP is getting from RIM. Meanwhile watch your stock price tumble
> > since the injunction prevents you from shipping product.
> Unlike NTP[1], the FSF distributes real products and is vulnerable to
> counterclaims.
We have organizations which could do this, but their sponsors wouldn't
like it.
Sincerely,
Lars Marowsky-Br?e
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"
On 2005-12-07T08:09:09, Dirk Steuwer <[email protected]> wrote:
> Yes, precisely what i was talking about.
> Something really simple joe average can
> follow.
> It has to be validated from a license point of view,
> but also from a technical side.
Be careful here. You're talking about something OSDL could actually be
useful for. This means there's some serious dragons here.
Sincerely,
Lars Marowsky-Br?e
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"
On Wed, 7 Dec 2005, Benjamin LaHaise wrote:
> On Tue, Dec 06, 2005 at 04:41:44PM +0000, Dirk Steuwer wrote:
> > Yes, but there isn't and won't be much recognition - every company does
> > its own thing. And how many people buy online all the time? But even then,
> > a genery "runs with Linux" Logo would be great. If a company's product
> > is not certified, its not considered by Linux customers.
>
> This is something I've wanted to see for years now. Linux distributions
> do not have the motivation to work out the hardware certification issues
> on the community level, as it interferes with their value add of branding.
> I have always wished that when I see hardware advertising Linux support
> that it has a meaning: open source, supportable drivers. Maybe it's time
> to get such a project moving.
Yes, the problem afaict is the "works with Linux(notm)" crowd,
e.g., those companies who see ndiswrapper as a way to say
"works with Linux." I don't see how the Runs with Linux(tm)
org can keep them from saying "works with Linux" and confusing
uses with that, but IANAL. Maybe "Linux native support" or
some such words could be used to mean your "open source,
supportable drivers."
--
~Randy
On Wednesday, December 7, 2005 10:13 am, Randy.Dunlap wrote:
> > This is something I've wanted to see for years now. Linux
> > distributions do not have the motivation to work out the hardware
> > certification issues on the community level, as it interferes with
> > their value add of branding. I have always wished that when I see
> > hardware advertising Linux support that it has a meaning: open
> > source, supportable drivers. Maybe it's time to get such a project
> > moving.
>
> Yes, the problem afaict is the "works with Linux(notm)" crowd,
> e.g., those companies who see ndiswrapper as a way to say
> "works with Linux." I don't see how the Runs with Linux(tm)
> org can keep them from saying "works with Linux" and confusing
> uses with that, but IANAL. Maybe "Linux native support" or
> some such words could be used to mean your "open source,
> supportable drivers."
I think it's pretty clear that the brand would have to entail a very
specific meaning, like "drivers for this device are open source and in
the upstream kernel" or somesuch. Anything else would dilute the
meaning of a penguin sticker (or whatever it is) so much as to be
useless I think, as you point out.
Now, who's in a position to make this happen? Maybe Linux International?
(I think Maddog mentioned something like this at a Kernel Summit a few
years ago.)
Jesse
On Tue, 6 Dec 2005, Arjan van de Ven wrote:
> On Tue, 2005-12-06 at 02:18 +0100, Andrea Arcangeli wrote:
> > I am convinced that the only way to stop the erosion is to totally stop
> > buying hardware that has only binary only drivers
> this only works if more people than "just Andrea and Arjan" do it
> though.
This worked very well in the late 1990's, when various
sites had Linux hardware compatibility lists.
Does anybody still maintain a list like that today (with
components, not just whole certified systems) ?
--
All Rights Reversed
On Wed, 7 Dec 2005, Rik van Riel wrote:
> On Tue, 6 Dec 2005, Arjan van de Ven wrote:
> > On Tue, 2005-12-06 at 02:18 +0100, Andrea Arcangeli wrote:
>
> > > I am convinced that the only way to stop the erosion is to totally stop
> > > buying hardware that has only binary only drivers
>
> > this only works if more people than "just Andrea and Arjan" do it
> > though.
>
> This worked very well in the late 1990's, when various
> sites had Linux hardware compatibility lists.
>
> Does anybody still maintain a list like that today (with
> components, not just whole certified systems) ?
There are lists for USB and for IEEE1394 (Firewire).
I'm not aware of others, but then I haven't searched for others.
Such lists could tell us not only which devices work (are
supported with open source drivers) but also which devices
are not supported and hence may need attention.
There has been some discussion about OSDL attempting to do this.
--
~Randy
> Such lists could tell us not only which devices work (are
> supported with open source drivers) but also which devices
> are not supported and hence may need attention.
>
> There has been some discussion about OSDL attempting to do this.
the biggest pitfal by having this done by a commercial entity or an
entity with commercial funding is that there is a LOT of pressure to
call things with binary drivers also certified/working.
It has to be an entity that can resist that pressure; if OSDL can,
great. But their funding is partially from sources that will try to put
that pressure on I suspect...
So I would almost rather have a separate "kicked off and supported by
OSDL" organisation with its own charter than have OSDL do it itself. I
can imagine OSDL feeling the same as well ...
Coywolf Qi Hunt <[email protected]> wrote:
> 2005/12/7, Greg KH <[email protected]>:
> > On Wed, Dec 07, 2005 at 09:38:30AM +0800, Coywolf Qi Hunt wrote:
> > > 2005/12/7, Greg KH <[email protected]>:
> > > > And no kernel developers are forcing anyone to use Linux. If they
> > > > don't like it for whatever reasons, there are other alternatives...
> > > AFAIK, no proprietary software vendors are forcing any1 to buy their
> > > proprietary software. Still you are speaking in a monopoly tone!
> > How is the statement, "If you don't trust the intelligence of the Linux
> > kernel developers, then don't use the Linux kernel." a monopolistic
> > tone?
> The fact is Linux supports more hardware now. Some *BSD users turn to
> Linux in order to drive their hardware for the _same_ reason as users
> turn to windows.
So? Nobody is forcing them. Nobody is squeezing them for money (or anything
else) in exchange. If they want, they can take it, use it, modify it to
their heart's content. Modulo GPL restrictions, obviously.
> That is really a monopolistic position.
Perhaps /position/, but not /taking advantage of it/. The second part is
where trouble brews.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Wed, 2005-12-07 at 09:17 -0500, Benjamin LaHaise wrote:
> On Tue, Dec 06, 2005 at 04:41:44PM +0000, Dirk Steuwer wrote:
> > Yes, but there isn't and won't be much recognition - every company does
> > its own thing. And how many people buy online all the time? But even then,
> > a genery "runs with Linux" Logo would be great. If a company's product
> > is not certified, its not considered by Linux customers.
>
> This is something I've wanted to see for years now. Linux distributions
> do not have the motivation to work out the hardware certification issues
> on the community level, as it interferes with their value add of branding.
> I have always wished that when I see hardware advertising Linux support
> that it has a meaning: open source, supportable drivers. Maybe it's time
> to get such a project moving.
If even some "Linux-friendly" hardware manufacturers barely cooperate
with the Linux comminuty now what makes you think this would work?
Christ, some vendors don't bother to get their Windows drivers
certified.
Lee
On Wed, 2005-12-07 at 10:44 -0800, Randy.Dunlap wrote:
> On Wed, 7 Dec 2005, Rik van Riel wrote:
>
> > On Tue, 6 Dec 2005, Arjan van de Ven wrote:
> > > On Tue, 2005-12-06 at 02:18 +0100, Andrea Arcangeli wrote:
> >
> > > > I am convinced that the only way to stop the erosion is to totally stop
> > > > buying hardware that has only binary only drivers
> >
> > > this only works if more people than "just Andrea and Arjan" do it
> > > though.
> >
> > This worked very well in the late 1990's, when various
> > sites had Linux hardware compatibility lists.
> >
> > Does anybody still maintain a list like that today (with
> > components, not just whole certified systems) ?
>
> There are lists for USB and for IEEE1394 (Firewire).
> I'm not aware of others, but then I haven't searched for others.
>
http://www.alsa-project.org/alsa-doc/index.php?vendor=All#matrix
It's a LOT of work to keep up to date...
Lee
On Wed, Dec 07, 2005 at 02:12:20PM -0500, Lee Revell wrote:
> If even some "Linux-friendly" hardware manufacturers barely cooperate
> with the Linux comminuty now what makes you think this would work?
Nothing in life is guaranteed. But at the very least, I think it would
be a good step towards improving the Linux end user experience. Instead
of the unclear mess we have now (Is it supported? Check with your
vendor!), we would be able to say "Look for the Linux Certified logo".
Combine that with a standard format for source code driver disks, and
it would be a good step in the right direction.
> Christ, some vendors don't bother to get their Windows drivers
> certified.
Maybe our lower cost will make it easier to entice hardware vendors. As
far as I know, the requirements for Windows driver certification are
pretty heft as vendors have to pay for the cost of future driver
maintenence. In the Linux case we'll make it easier on the vendors as
our maintenence component comes from having the source code and many
hands amongst the community.
-ben
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <[email protected]>.
On Wed, 7 Dec 2005, Arjan van de Ven wrote:
> > Such lists could tell us not only which devices work (are
> > supported with open source drivers) but also which devices
> > are not supported and hence may need attention.
> >
> > There has been some discussion about OSDL attempting to do this.
>
> the biggest pitfal by having this done by a commercial entity or an
> entity with commercial funding is that there is a LOT of pressure to
> call things with binary drivers also certified/working.
> It has to be an entity that can resist that pressure; if OSDL can,
> great. But their funding is partially from sources that will try to put
> that pressure on I suspect...
> So I would almost rather have a separate "kicked off and supported by
> OSDL" organisation with its own charter than have OSDL do it itself. I
> can imagine OSDL feeling the same as well ...
What about linux/Documentation/, which is maintained by us (as in `the
community', not by `commercial entity that can be pressured')?
At least for a `positive' lists it's not that difficult: if the driver is in
the tree, just add the supported hardware to the list in linux/Documentation/.
Whether we want to put a `negative' list there as well is another question.
Perhaps some form of `to do' or `drivers wanted' list?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, 6 Dec 2005, Denis Vlasenko wrote:
> On Tuesday 06 December 2005 03:18, Andrea Arcangeli wrote:
> > On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
> > > 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.
> >
> > I agree about the erosion.
> >
> > I am convinced that the only way to stop the erosion is to totally stop
> > buying hardware that has only binary only drivers (unless you buy it to
> > create an open source driver or to reverse engineer the binary only
> > driver of course! ;).
>
> I'm afraid there is not enough Linux users in desktop/laptop market
> for vendors to notice.
>
> How about refusing binary-only modules instead? I mean, maybe
You mean, call panic() if module license not acceptable? Nice!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Dec 07, 2005 at 07:55:08PM +0100, Arjan van de Ven wrote:
> the biggest pitfal by having this done by a commercial entity or an
> entity with commercial funding is that there is a LOT of pressure to
> call things with binary drivers also certified/working.
> It has to be an entity that can resist that pressure; if OSDL can,
> great. But their funding is partially from sources that will try to put
> that pressure on I suspect...
> So I would almost rather have a separate "kicked off and supported by
> OSDL" organisation with its own charter than have OSDL do it itself. I
> can imagine OSDL feeling the same as well ...
I don't like to see an entity doing this: if an organization (no matter
if for-profit or no-profit) will do it, they may ask vendors to pay to
be added to the "certified list".
Nobody should be required to pay to be added in the list. Furthermroe I
would suggest to use the kernel.org website, to leave it neutral.
A moinmoin wiki.kernel.org should work fine and it takes 10 minutes to
set it up. Let's use the community to build this list. Perhaps
wiki.kernel.org could also be used to document some kernel stuff later
on.
On Wed, 2005-12-07 at 21:16 +0100, Andrea Arcangeli wrote:
> On Wed, Dec 07, 2005 at 07:55:08PM +0100, Arjan van de Ven wrote:
> > the biggest pitfal by having this done by a commercial entity or an
> > entity with commercial funding is that there is a LOT of pressure to
> > call things with binary drivers also certified/working.
> > It has to be an entity that can resist that pressure; if OSDL can,
> > great. But their funding is partially from sources that will try to put
> > that pressure on I suspect...
> > So I would almost rather have a separate "kicked off and supported by
> > OSDL" organisation with its own charter than have OSDL do it itself. I
> > can imagine OSDL feeling the same as well ...
>
> I don't like to see an entity doing this: if an organization (no matter
> if for-profit or no-profit) will do it, they may ask vendors to pay to
> be added to the "certified list".
yeah I agree that would be not good. providing a good open driver should
be reward already, not be a reason to be asked for more money
> A moinmoin wiki.kernel.org should work fine and it takes 10 minutes to
> set it up. Let's use the community to build this list. Perhaps
> wiki.kernel.org could also be used to document some kernel stuff later
> on.
the problem with this is that with wiki's you get a sliding scope wrt
criteria; I mean, many people will say nvidia graphics work great with
linux... and the wiki will represent that ;(
On Wed, 07 Dec 2005 20:53:03 +0100, Geert Uytterhoeven wrote:
> On Wed, 7 Dec 2005, Arjan van de Ven wrote:
> > > Such lists could tell us not only which devices work (are
> > > supported with open source drivers) but also which devices
> > > are not supported and hence may need attention.
> > >
> > > There has been some discussion about OSDL attempting to do this.
> >
> > the biggest pitfal by having this done by a commercial entity or an
> > entity with commercial funding is that there is a LOT of pressure to
> > call things with binary drivers also certified/working.
> > It has to be an entity that can resist that pressure; if OSDL can,
> > great. But their funding is partially from sources that will try to put
> > that pressure on I suspect...
> > So I would almost rather have a separate "kicked off and supported by
> > OSDL" organisation with its own charter than have OSDL do it itself. I
> > can imagine OSDL feeling the same as well ...
>
> What about linux/Documentation/, which is maintained by us (as in `the
> community', not by `commercial entity that can be pressured')?
>
> At least for a `positive' lists it's not that difficult: if the driver is in
> the tree, just add the supported hardware to the list in linux/Documentation/.
>
> Whether we want to put a `negative' list there as well is another question.
> Perhaps some form of `to do' or `drivers wanted' list?
I'm a little less worried about OSDL advocating binary drivers. I
*am* more worried about how the message goes out, how the information
becomes visible to the right people, etc. I think OSDL can help there;
the project managers, product marking people, senior manager's etc. at
these various companies have business models that assume Linux is
"just like everything else" and these people don't go rooting around
in linux/Documentation looking for the answers to their business model.
OSDL can help here since more business folks talk to OSDL.
And, by calling attention to those items which do and do not have source
drivers available along with the education on business reasons for
avoiding binary drivers might help get the message through to more of
the right people.
Ideally, any OSDL effort would also be reviewed and contributed to by
the development community to keep it focused in the right directions.
gerrit
> I'm a little less worried about OSDL advocating binary drivers.
fair enough; in my experience this kind of thing comes down to defining
a good enough charter/rulebook to begin with, and then just sticking to
that. The rules can just be public and part of the communication of what
the lists are etc. If OSDL can buy into a good set of rules I see no
problems with them doing it; I do hope that it can be "for no fee"
service. Or at worst, have an option for the manufacturer to put in a
link or two on the product page for a fee to cover the costs of the lot.
> I
> *am* more worried about how the message goes out, how the information
> becomes visible to the right people, etc. I think OSDL can help there;
to be honest I liked the kernel.org idea... there probably can be other
means too, but a good decent website (eg nice categories, search option
etc) goes a really long way esp if it's 'official' like kernel.org is.
the hair part may be an option for users to add links to pages with
extra info for a certain piece of hardware, that needs manual review
On Wed, Dec 07, 2005 at 09:19:02PM +0100, Arjan van de Ven wrote:
> the problem with this is that with wiki's you get a sliding scope wrt
> criteria; I mean, many people will say nvidia graphics work great with
> linux... and the wiki will represent that ;(
then the wiki will be closed. But it worth a try. Of course the topic
will explain it's a list of hardware supported by open source (GPL
compatible) drivers.
Like wiki.kernel.org/OpenSourceKernelDrivers
On Wed, 7 Dec 2005, Andrea Arcangeli wrote:
> A moinmoin wiki.kernel.org should work fine and it takes 10 minutes to
> set it up. Let's use the community to build this list.
MoinMoin needs a navigation structure though. This has
been on my TODO list (http://linux-mm.org/RikvanRiel) for
months now, but I haven't gotten around to it yet ;(
Maybe I should try making this during the christmas
holidays. Or, better yet, convince somebody else to do
it with this shameless email ;)
> Perhaps wiki.kernel.org could also be used to document some kernel stuff
> later on.
This is already done in a few places:
http://linux-net.osdl.org/
http://linux-mm.org/
http://wiki.kernelnewbies.org/
--
All Rights Reversed
On Wed, Dec 07, 2005 at 09:30:13PM +0100, Arjan van de Ven wrote:
> to be honest I liked the kernel.org idea... there probably can be other
> means too, but a good decent website (eg nice categories, search option
> etc) goes a really long way esp if it's 'official' like kernel.org is.
To categorize with wiki, hierarchy can be used. Like
OpenSourceKernelDrivers/{Storage,Video,Audio} etc... Search is
automatic. However for audio one may as well just use #redirect
www.alsasomehwere inside the Audio page.
On Wed, Dec 07, 2005 at 12:22:24PM -0800, Gerrit Huizenga wrote:
> I'm a little less worried about OSDL advocating binary drivers.
Really ? That's a worst case scenario as far as I can see.
Dave
Andrea Arcangeli writes:
> Furthermroe I would suggest to use the kernel.org website, to leave it
neutral.
Don't you mean 'leaving it political', kernel.org is hardly neutral.
Neutrality is usually handled by a single trusted entity such as a Judge
;-/ and not by a committee or a democracy.
This issue is hardly black-and-white. The Hardware Vendors are hardly
monolithic. Markets are not always just horizontal, or just vertical.
For instance, there are reasons, somewhat outside the control of the
Hardware Vendor, for binary drivers. Often, in the hopes of achieving
standards compliance, Hardware vendors are cornered by legalities over
the copyright associated with those standards that ties their hands
either from releasing interface documentation or from releasing source
code. Yet all these vendors would be overjoyed to have Linux drivers for
their Hardware in order to increase the sales of their products.
The users are overjoyed when they have a wide variety of useful hardware
products to select. The market is overjoyed when there is competition.
Linux gains popularity when the users are placated, increasing the
interest in funding projects, engineers and organizations associated
with Linux. Call this trickle down economics if you want.
Locking out the Hardware is counterproductive for all to varying degrees
(I agree that locking out the details is also counterproductive, do not
misconstrue my argument). The current state of affairs where binary-only
drivers are grudgingly handled and politically sensitive offers the
balance that urges these Hardware Vendors to pursue open source variants
or to move initial binary-only offerings eventually in the future
towards an open-source solution when conditions change to permit it.
Thus without hurting the OS, the users or the Hardware vendors; with the
timely delivery of advanced hardware. Without an open door, that piece
of hardware, or the market window, will pass Linux by. Despise the
results, by all means. Plan to protect copyrights that binaries may
violate, that is a noble duty. Remain forever vigilant against
encroachment. But please stop planning a revolt, locking the door,
constructing conspiracy theories or creating scenarios of utter
destruction and mayhem.
Sleep with the enemy when you have mutual gain (keep a loaded gun under
the pillow to keep him honest ;-> ).
Sincerely -- Mark Salyzyn
Death of the net predicted, news at 11
On Wed, 07 Dec 2005 16:02:46 EST, Dave Jones wrote:
> On Wed, Dec 07, 2005 at 12:22:24PM -0800, Gerrit Huizenga wrote:
>
> > I'm a little less worried about OSDL advocating binary drivers.
>
> Really ? That's a worst case scenario as far as I can see.
So, OSDL is an organization, sometimes referred to as "osdl.org"
and OSDL has members which are listed on the members page.
OSDL.org has no desire to advocate binary drivers in any way and I
don't expect that they will do anything to educate or influence their
members or the global vendor/IHV/developer communities to use binary
drivers. Further, I expect they will do exactly the opposite, in
particular, educate members, developers, IHV's on how to deploy
open source drivers and the benefits of doing so.
There are *members* of OSDL who continue to have binary drivers as
part of their product line, in part because of IHV business choices,
and some of those *members* (e.g. IBM) are working to reduce the
number of binary drivers while at the same time not impacting revenue.
The goal is to remove all need for binary drivers as quickly as we can.
Business realities are keeping this from happening "immediately" but most
of the member companies that I know of are working in a similar direction.
OSDL.org has also offered to help by creating a mailing list for open source
drivers with a focus on educating and supporting IHV's (see
[email protected]) and a new documentation site (brand new!!!)
http://developer.osdl.org/dev/opendrivers/documentation/ which will
evolve into a Wiki over time. That Wiki will hopefully help out
IHV developers but ALSO will focus on program managers, product
managers, executives, etc.
Resolving the customer issues related to device drivers has been rated
as the #1 problem impeding customer adoption of Linux today. That has
been raised by several vendors as well as by the OSDL Board of directors
as the #1 problem to solve.
There is a contingent of us working to ensure that the future solution
to this problem is aligned with the community guidelines of open source,
mainline accepted drivers over time, as well as with the distro needs
as we understand them. There is a lot of material that we've generated
with a goal of educating the IHV's; we continue to work with them over
time at all levels within our own companies and the various IHV's. This
is not an easy battle - MS still owns a large share of the IHV's business
and it is ultimately business reasons that are most compelling to
them over time.
But, net summary, I trust that OSDL would do the right thing in hosting
and editing a repository of information related to helping companies
move towards open source drivers over time.
gerrit
From: Gerrit Huizenga <[email protected]>
Date: Wed, 07 Dec 2005 13:30:18 -0800
> OSDL.org has no desire to advocate binary drivers in any way and I
> don't expect that they will do anything to educate or influence their
> members or the global vendor/IHV/developer communities to use binary
> drivers. Further, I expect they will do exactly the opposite, in
> particular, educate members, developers, IHV's on how to deploy
> open source drivers and the benefits of doing so.
You might want to read the following before stating such
things:
http://www.kroah.com/log/2005/11/03/#osdl_gkai
Thanks.
On Tue, 6 Dec 2005, Jon Smirl wrote:
> On 12/5/05, Arjan van de Ven <[email protected]> wrote:
>> Linux in a binary world
>
> Why not start our own Linux doomsday? Give the closed source vendors
> exactly what they fear the most, a patent lawsuit. Whining will get us
> nowhere, hitting the vendor's revenue stream will get you anything you
> want.
I like this idea a lot.
> US patent infringement provides the giant sledgehammer of having a
> court issue an injunction stopping the shipment of product that is in
> litigation over patent infringement. Note that it does not have to be
> proven that the the patents are valid. RIM is very close to having an
> injunction issued against it even though it is likely that the patents
> they are accused of violating will be found invalid.
>
The other thing to keep in mind in the specific case of ATI and NVIDIA is
that their competition is feirce and expensive. They somewhat depend
on consumers being willing to purchase a new graphics card every half
year to two years. The fact that they have both 'held the throne'
so to speak in terms of performance and might demonstrate that a
costly patent lawsuit would be a good thing for them to avoid -
because their competitor is literally breathing down their neck,
they could very much do without the distraction or the loss of funds.
> The game plan is simple. IBM and Intel hold
> enough hardware patents to
> take down any hardware company these choose. Donate one or two key
> patents to the FSF with a rule that they can't be used against the
> company that donated them. The FSF then moves for a patent
> infringement injunction against ATI, NVidia or other closed source
> vendor.
>
> The target company gets a choice:
>
> 1) open source the drivers and hardware. As a sweetener contribute a
> patent to the pool and aim the FSF at the next domino. In exchange the
> suit will be dropped.
>
Perhaps the way to go about this is to put a lot of applicable patents
in a pool. Join us and our patents will defend your newly opened
drivers from your competition's lawsuits. Oppose us, and we will make
things very bad for you, giving your competition an opportunity to take
the lead again, and if they know what's good for them, beat you to
the punch with open drivers.
The key then is target one company at a time, because the time
and money they would waste defending themselves would likely do very
bad things to allowing their competitor to take a *big* lead. Hell,
wasn't 3dfx's fall from power partially related to IP suits? Or
did I just hear that somewhere? I don't recall.
> 2) Endure the lawsuit and
> hope the FSF doesn't get a $450M settlement
> like NTP is getting from RIM. Meanwhile watch your stock price tumble
> since the injunction prevents you from shipping product.
>
> http://www.latimes.com/news/opinion/editorials/la-ed-ebay4dec04,0,6943666.story?coll=la-news-comment-editorials
>
> --
> Jon Smirl
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Ah, what it's like to dream. :)
On Wednesday 07 December 2005 21:38, David S. Miller wrote:
>
> You might want to read the following before stating such
> things:
>
> http://www.kroah.com/log/2005/11/03/#osdl_gkai
>
Ouch!
On Wed, 07 Dec 2005 13:38:20 PST, "David S. Miller" wrote:
> From: Gerrit Huizenga <[email protected]>
> Date: Wed, 07 Dec 2005 13:30:18 -0800
>
> > OSDL.org has no desire to advocate binary drivers in any way and I
> > don't expect that they will do anything to educate or influence their
> > members or the global vendor/IHV/developer communities to use binary
> > drivers. Further, I expect they will do exactly the opposite, in
> > particular, educate members, developers, IHV's on how to deploy
> > open source drivers and the benefits of doing so.
>
> You might want to read the following before stating such
> things:
>
> http://www.kroah.com/log/2005/11/03/#osdl_gkai
>
> Thanks.
I have read that and in fact I was at that meeting. That was a case
where we had spent some time trying to convince member companies that
a stable kernel API was not going to happen. They did not believe it.
Greg and others came in and expressed directly to those people their
viewpoints. That has helped and the companies in question are still
thinking about their future strategy. Greg had an impact where OSDL
members (myself included) were simply viewed as expressing a radical
opinion which reality would change.
This whole concept of drivers being broken has been painful for everyone
and people are still trying to apply traditional solutions. The kernel
communities solution solves a piece of the problem (not the distro portion
of the problem) but the continuing education on a pardaigm shift seems
to be unending. I've been working on this for over a year and I still
run into people every day that just don't see the value of the paradigm
change and don't even realize that there *is* a paradigm change.
Wishing the problem away hasn't helped. People need education and all
kinds of levels and unfortunately LKML doesn't reach most of the people
that actually need the education. :(
gerrit
Benjamin LaHaise wrote:
>On Wed, Dec 07, 2005 at 02:12:20PM -0500, Lee Revell wrote:
>
>
>>If even some "Linux-friendly" hardware manufacturers barely cooperate
>>with the Linux comminuty now what makes you think this would work?
>>
>>
>
>Nothing in life is guaranteed. But at the very least, I think it would
>be a good step towards improving the Linux end user experience. Instead
>of the unclear mess we have now (Is it supported? Check with your
>vendor!), we would be able to say "Look for the Linux Certified logo".
>Combine that with a standard format for source code driver disks, and
>it would be a good step in the right direction.
>
>
>
The problem as I see it:
A hardware vendor hires someone to write a driver. The driver is
completed and submitted and finally makes it into the kernel. It's
fully GPL and everyone is happy. The hardware gets a "Native Linux
Support" logo. The card goes out of favor and no one is interested in
maintaining the driver, it is marked obsolete and finally removed from
the kernel. ...the logo still suggests the hardware will work.
Possible fix:
It might be possible to add a serial number to the logo, and keep a
database that maintains a current status of the device in the Linux kernel.
Does this make sense?
--
Jeffrey Hundstad
PS. warning "not politically correct": When I heard "Native Linux
Support" I immediately thought of Tux with a full Native American Indian
headdress
Jeffrey Hundstad writes:
> It might be possible to add a serial number to the logo, and keep a
> database that maintains a current status of the device in the Linux
> kernel.
>
> Does this make sense?
Not especially. To be accurate, it would have to be bumped every time
a driver is removed from the kernel -- or, more accurately, every time
the in-kernel API changes. To be useful, such an increment would have
to only happen once a year or so, or else updating the packaging is
too much work. Currently, the in-kernel API changes every month or
two, which means a driver compatibility serial number would be
inaccurate, futile, or both.
Michael Poole
On Wed, Dec 07, 2005 at 04:23:59PM -0600, Jeffrey Hundstad wrote:
> The problem as I see it:
>
> A hardware vendor hires someone to write a driver. The driver is
> completed and submitted and finally makes it into the kernel. It's
> fully GPL and everyone is happy. The hardware gets a "Native Linux
> Support" logo. The card goes out of favor and no one is interested in
> maintaining the driver, it is marked obsolete and finally removed from
> the kernel. ...the logo still suggests the hardware will work.
Your assumptions are pretty wild: drivers which are accepted into the
mainline kernel, we *rarely* drop. Only recently have some of the more
impossible to find ISA drivers started being dropped.
> It might be possible to add a serial number to the logo, and keep a
> database that maintains a current status of the device in the Linux kernel.
Note as you're thinking. It makes more sense to say that the driver
works with version x.y.z of the kernel and later.
-ben
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <[email protected]>.
On Mer, 2005-12-07 at 15:46 -0600, Chase Venters wrote:
> bad things to allowing their competitor to take a *big* lead. Hell,
> wasn't 3dfx's fall from power partially related to IP suits? Or
> did I just hear that somewhere? I don't recall.
If my memory still works correctly 3Dfx sued Nvidia and in the end
Nvidia had to buy them to solve it. Patents are a big issue in the 3D
graphics space and the 'what they can't see' approach to minimising
lawsuits has its obvious appeal.
One of the problems in this area is the big fight going on and the fact
it is not commodity. Ten random developers are not going to produce a
driver comparable to Nvidia's libGL in the same way that ten random
developers can produce as good an ATA or SCSI adapter as anyone else
On 12/7/05, Alan Cox <[email protected]> wrote:
> On Mer, 2005-12-07 at 15:46 -0600, Chase Venters wrote:
> > bad things to allowing their competitor to take a *big* lead. Hell,
> > wasn't 3dfx's fall from power partially related to IP suits? Or
> > did I just hear that somewhere? I don't recall.
>
> If my memory still works correctly 3Dfx sued Nvidia and in the end
> Nvidia had to buy them to solve it. Patents are a big issue in the 3D
> graphics space and the 'what they can't see' approach to minimising
> lawsuits has its obvious appeal.
>
> One of the problems in this area is the big fight going on and the fact
> it is not commodity. Ten random developers are not going to produce a
> driver comparable to Nvidia's libGL in the same way that ten random
> developers can produce as good an ATA or SCSI adapter as anyone else
I do believe that patent lawsuits can be used to force hardware specs
out of everyone; all we need is for someone to donate a good patent to
get the ball rolling. Being on the receiving end of a suit like this
will suck big time. There is no good solution for the company being
attacked, cough up your hardware specs or risk an injunction that may
kill your company.
But to play fair the settlement should only ask for the specs needed
to program the hardware. It wouldn't be right to use these tactics to
force Nvidia's libGL source out of them if they didn't want to
contribute it.
Can the Linux community justify using ruthless means to force
documentation out of vendors? Asking politely doesn't seem to be
working - I suspect it may take something of this magnitude to force
a change out of NVidia/ATI.
--
Jon Smirl
[email protected]
On Wednesday 07 December 2005 05:41 pm, Jon Smirl wrote:
> Can the Linux community justify using ruthless means to force
> documentation out of vendors? Asking politely doesn't seem to be
> working - I suspect it may take something of this magnitude to force
> a change out of NVidia/ATI.
Is this a vote? Cause you have mine. :)
Seriously, there is a danger in the move being seen by the press as too
adversarial, but with everything I've been reading and seeing lately, I'm
starting to think that the NVidia/ATI situation may be the single largest
danger to Linux.
I'm sorry to have not followed the entire "Small PCI Core Patch" thread and
reference it anyway, but would any device class in Linux be in *near* as much
danger as the video drivers if Greg's patch was a reality? I seem to have the
impression that there would be alternative wireless drivers, SCSI drivers,
etc...
I think you'd want to try to be more political, naturally. It could start by
gently suggesting to NVIDIA or ATI that they join a patent commons project
(where these offensive patents will also reside). They open their driver and
agree to allow the open source driver to use their patents, then in return
the commons agrees to defend them from backlash.
But that might not work - things might just heat up. Who would you go after
first - NVIDIA or ATI? The underdog or the current leader? A threat of losing
your market leadership, or of being seriously beaten while you are already
down?
If we got an open graphics driver from one of these two (or, hell, even the
ability to make one), I would hope that would give us the boost we need to,
after a short while, finish kicking binary drivers out for good.
But perhaps I'm still dreaming.
- Chase
On Tue, 2005-12-06 at 21:39 +0000, Nicolas Mailhot wrote:
> Arjan van de Ven <arjan <at> infradead.org> writes:
>
> > There are lots of opportunities to put pressure on vendors, either
> > direct or indirect. Nvidia has a support department. If they get enough
> > calls / letters about their solution not being good enough, they're more
> > likely to consider the rearchtect solution.
>
> Indeed a single centralized complete online hardware database (with hardware
> rated according to driver support level) would go a long way to put real
> pressure on vendors. We know how to set up one for gnome/kde themes surely it'd
> be possible to create one for hardware ? (not the current nebulae of
> semi-complete overlapping projects, menuconfig entries, blog notes, linux-kernel
> notifications)
>
> But this requires _kernel_ _people_ cooperation. You're the ones who know what
> works and what doesn't. You're the ones who know which corporations are helpful.
> You're the first people users contact when they have new hardware they'd like to
> make work. You're the ones who know which drivers you're currently working on.
>
> The PCI ID database can be maintained without kernel people intervention. A
> "linux-friendly hardware" database can not.
>
> Right now getting hardware advice is a long and painful process. Hardware that
> works is only semi-documented. Hardware which doesn't isn't at all. Users have
> to comb numerous on-line databases and mail archives (full of obsolete/wrong
> info) to spec a single linux-friendly system. Few people bother to answer
> hardware advice requests on mailing lists.
i disagree, you make it sound like it takes weeks of effort to find out
which stuff works on linux, and that basically you have to be lucky to
find it at all...
basically the only thing that doesent work (i dont count binary-only
solutions working) is nvidia and ati.
other mainstream stuff just works.. i never have to look for hardware
when i buy, it simply works (whereas the few times i have put together a
system that should run windows hardware has often not worked very well..
if at all)
i have also converted a fair share of windows users to linux, where they
have simply gone to the store and bought their pc, and it has never
given problems (granted, there i have installed nvidia driver even
though its closed source stuff.)
as it is today, the end user doesent really have much of a problem.
>
> Linux users could reward friendly hardware makers if only you bothered to point
> them the right way. That is :
> - list publicly working hardware as soon as the kernel driver is ready
> - list publicly non-working hardware as soon as someone enquires for a reference
> which does not work.
i agree, stupid vendors which ignores linux drivers should be pointed
out, and vendors which either give specs, develop drivers or help doing
so should also be pointed out.
>
> There's no magic.
>
> Hardware makers do all kinds of stupid stuff to please review sites. Review
> sites are influential because lots of people buy stuff based on their advice.
> Lots of people follow review site advice because review sites centralize info
> about all kinds of hardware, so you don't have to comb the web to find it.
>
> As Groklaw has shown - if you manage to do complete coverage of a subject, even
> an obscure subject like IP laws or Linux drivers, you suddenly get quoted
> everywhere. But to reach that stage you mustn't go halfways but record
> meticulously info about all the hardware you know of.
>
On Tue, 2005-12-06 at 22:00 +0100, Francois Romieu wrote:
> Brian Gerst <[email protected]> :
> [...]
> > walk into a computer store and find anything else (I don't count
> > integrated video on the motherboard as a solution, since only Intel
> > boards have it, sorry AMD users).
>
> Some SiS based motherboards offer both an integrated video and AMD
> processor support.
>
unfortunately that sis chip has a hardware bug (or so the xorg module
tells me) which makes dri impossible, and video overlay extremely bad..
> --
> Ueimor
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Benjamin LaHaise wrote:
>On Tue, Dec 06, 2005 at 04:41:44PM +0000, Dirk Steuwer wrote:
>
>
>>Yes, but there isn't and won't be much recognition - every company does
>>its own thing. And how many people buy online all the time? But even then,
>>a genery "runs with Linux" Logo would be great. If a company's product
>>is not certified, its not considered by Linux customers.
>>
>>
>
>This is something I've wanted to see for years now. Linux distributions
>do not have the motivation to work out the hardware certification issues
>on the community level, as it interferes with their value add of branding.
>I have always wished that when I see hardware advertising Linux support
>that it has a meaning: open source, supportable drivers. Maybe it's time
>to get such a project moving.
>
> -ben
>-
>
>
Hi
I understand this as a logical answer to "Designed for Windows", but is
it really what we want?
After all, "Runs with Linux" (or such) does not, by it self, speak about
closed drivers. Also, it will only attract Linux-users toward a goal
everyone would gain from: maintainable drivers after "expiration" date.
Why not something more of "Runs on Open Drivers", which also gives us a
chance to "teach" people why to use an open OS without the replies:
"Windows is pretty" (actually, it was a guy who told me that)
"It is difficult (to learn new stuff)"
etc..
Even in the short run (we _will_ have world-domination someday ;) ) I
think such an approach is more beneficial because we can gather force
from *BSD, Solaris and (even) Windows-users as well.
Well, just an idea...
/Richard Knutsson
El Thu, 08 Dec 2005 01:58:56 +0100,
Kasper Sandberg <[email protected]> escribi?:
> i disagree, you make it sound like it takes weeks of effort to find out
> which stuff works on linux, and that basically you have to be lucky to
> find it at all...
>
> basically the only thing that doesent work (i dont count binary-only
> solutions working) is nvidia and ati.
Agreed - I know several people who has bought "exotic" laptops and
everything (sound, usb, irda, firewire, ethernet, pcmcia slots) except
video cards worked out-of-the box using distros like ubuntu
Many times Windows XP requires inserting the CDs with 3rd party drivers.
IMO the way linux is doing things is the Right Way: Hardware should
work out of the box, and things like the windows' panel control driver
dialogs are a failure because users should't care about low-level
things like installing drivers. The "works under linux logo" is
misleading because a given device may not have such logo and
it may have been supported by a recent kernel version or it may
work only with a distro or things like that.
Companies like adaptec are collaborating in creating open source
drivers since linux became relevant in servers because companies
understood that their devices need to support linux properly
if they want to get money. IMO it will happen the same with desktops
once linux gets a decent part of the market share if people keeps the
same pressure on them.
The main problem right now are graphic chips, but IMHO that's because
right now there's a "revolution" in the graphics market: programmable
GPUs, 3d-hardware-accelerated desktops and all that, but i think
it'd be reasonable to expect that it'll settle down after a few years
and it will be easier to write drivers for them (today you can
reverse engineer a device but ati will release a new and revamped
chip in six months etc.)
On Thu, Dec 08, 2005 at 03:07:37AM +0100, Richard Knutsson wrote:
> Why not something more of "Runs on Open Drivers", which also gives us a
> chance to "teach" people why to use an open OS without the replies:
> "Windows is pretty" (actually, it was a guy who told me that)
What does something like that say about the state of the drivers? If one
of the open OSes doesn't merge the driver, do they get to use the logo?
The more you dilute something, the harder the whole process becomes.
-ben
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <[email protected]>.
On 12/8/05, Jeffrey Hundstad <[email protected]> wrote:
> Benjamin LaHaise wrote:
>
> >On Wed, Dec 07, 2005 at 02:12:20PM -0500, Lee Revell wrote:
> >
> >
> >>If even some "Linux-friendly" hardware manufacturers barely cooperate
> >>with the Linux comminuty now what makes you think this would work?
> >>
> >>
> >
> >Nothing in life is guaranteed. But at the very least, I think it would
> >be a good step towards improving the Linux end user experience. Instead
> >of the unclear mess we have now (Is it supported? Check with your
> >vendor!), we would be able to say "Look for the Linux Certified logo".
> >Combine that with a standard format for source code driver disks, and
> >it would be a good step in the right direction.
> >
> >
> >
> The problem as I see it:
>
> A hardware vendor hires someone to write a driver. The driver is
> completed and submitted and finally makes it into the kernel. It's
> fully GPL and everyone is happy. The hardware gets a "Native Linux
> Support" logo. The card goes out of favor and no one is interested in
> maintaining the driver, it is marked obsolete and finally removed from
> the kernel. ...the logo still suggests the hardware will work.
I think "Designed for Windows" has the same problem. I know some
hardware that works well with Win98 but no driver exist for XP.
Fortunately that hardware works with Linux...
I would say the fix is "Runs with Linux(tm) 2005-2006" and the
hardware vendor finances maintainance during the specified period.
/ magnus
Benjamin LaHaise wrote:
>On Thu, Dec 08, 2005 at 03:07:37AM +0100, Richard Knutsson wrote:
>
>
>>Why not something more of "Runs on Open Drivers", which also gives us a
>>chance to "teach" people why to use an open OS without the replies:
>>"Windows is pretty" (actually, it was a guy who told me that)
>>
>>
>
>What does something like that say about the state of the drivers? If one
>of the open OSes doesn't merge the driver, do they get to use the logo?
>
>
Good point, the questions already for the "Runs on Linux" (have not seen
any answers to them yet):
* is all drivers going to be runnable for all series and if not, how is
that going to show?
* do the logo mean "only guarantied with the latest version (in the
serie)"? some sort of time stamp on the logo?
The reason for my "suggestion" is:
* is there no risk to scare off people not interested in Linux?
* more likely it would get help from other OS-users too.
* is this about open drivers or the OS? (possible idea is to not
verbally say Linux but having Tux on the logo) (think there is to much
focus on the OS, ex: have seen "run on all Windows versions" for
IDE->SATA-converters).
>The more you dilute something, the harder the whole process becomes.
>
>
True! I hope I did not do so by suggesting/writing this.
> -ben
>
>
Thank you, for answering.
/Richard
PS
Don't get me wrong! If I see a "Runs on Linux"-logo in the future, I
will be thrilled. No doubt about that!
DS
On Thu, 8 Dec 2005, Diego Calleja wrote:
> El Thu, 08 Dec 2005 01:58:56 +0100,
> Kasper Sandberg <[email protected]> escribi?:
>
> Many times Windows XP requires inserting the CDs with 3rd party drivers.
>
> IMO the way linux is doing things is the Right Way: Hardware should
> work out of the box, and things like the windows' panel control driver
> dialogs are a failure because users should't care about low-level
> things like installing drivers. The "works under linux logo" is
Lets be objective at least, Windows XP was released in 2002, have you
tried Linux distros from 2002 on said laptops?
On 6/12/2005, at 3:31 AM, Brian Gerst wrote:
> Andrea Arcangeli wrote:
>>
>> When we don't buy hardware without open source drivers, we send the
>> message to the shareholders that the management is causing them a
>> loss.
>
> The problem with this statement is that Linux users are a drop in
> the bucket of sales for this hardware. Boycotting doesn't cost the
> vendors enough to make them care. And this does nothing for people
> who are converting over to Linux, and didn't buy hardware with that
> consideration in mind.
I happen to know of an orphaned wireless chip that might be revived
if we can orchestrate orders for a few thousand cards. It has a nice
Linux driver that could be open sourced very easily, as so far as I
can tell it doesn't derive from anything that wasn't BSD licensed in
the first place... and the hardware performance is exemplary. Anyone
with significant purchasing capacity reading this?
Andrew
Michael Poole wrote:
>Jeffrey Hundstad writes:
>
>
>
>>It might be possible to add a serial number to the logo, and keep a
>>database that maintains a current status of the device in the Linux
>>kernel.
>>
>>Does this make sense?
>>
>>
>
>Not especially. To be accurate, it would have to be bumped every time
>a driver is removed from the kernel -- or, more accurately, every time
>the in-kernel API changes. To be useful, such an increment would have
>to only happen once a year or so, or else updating the packaging is
>too much work. Currently, the in-kernel API changes every month or
>two, which means a driver compatibility serial number would be
>inaccurate, futile, or both.
>
>
Well, a driver that gets _into_ the tree will get a lot of maintenance
for free. Basically, someone wanting to change an internal interface
normally takes care of all internal users of that interface. (And yes,
there are some exceptions but this is the rule.)
Still, to prevent everlasting "runs with linux" stickers, give them one-year
stickers only. Get a GPL driver into the kernel tree in 2005, and you
get the "runs with linux 2005" sticker. To get a sticker for 2006,
there have
to be an active maintainer. This could be the company doing maintenance. Or,
in case of really popular hardware, it could be the kernel regulars doing
it voluntarily. In the latter case, the company would only need to ask
for the 2006 sticker.
Once a driver gets no maintenance, neither from the company nor the
community,
no more stickers is handed out for it.
And of course it shouldn't be stickers only, but also logos they can put on
their websites. Linux people usually look up such things on the web
when planning purchases. Also, a company that _wants_ to support linux can
show that they still support the previous generation of products.
They have no use for physical stickers for a product that doesn't sell much,
but having a logo is advertising, they show that their products have
long-time viability for linux users.
Helge Hafting
Luke-Jr wrote:
>On Tuesday 06 December 2005 16:27, Simon Oosthoek wrote:
>
>
>>Arjan van de Ven wrote:
>>
>>
>>>On Mon, 2005-12-05 at 18:26 +0000, Andrew Walrond wrote:
>>>
>>>
>>>>On Monday 05 December 2005 10:52, Arjan van de Ven wrote:
>>>>
>>>>
>>>>>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.
>>>
>>>
>>I use nvidia cards, mostly because they work better than an alternative
>>for now, but every time I need a card I look for stuff that is more
>>open, because I hate to have to use the non-free closed stuff to do
>>graphics. (Having no real choice in this is really annoying to me!)
>>
>>
>
>The ATi Radeon 9200 works fine...
>
>
Lucky you. Mine doesn't. Using 3D on it makes the machine unstable,
and the performance is apalling too. So I'm looking for something
else - a radeon 7000 is cheap . . .
And don't say that a crash during a 3D game isn't important - it is
a two-user machine and the other user is not amused when this happens.
Helge Hafting
Chase Venters wrote:
>On Wednesday 07 December 2005 05:41 pm, Jon Smirl wrote:
>
>
>>Can the Linux community justify using ruthless means to force
>>documentation out of vendors? Asking politely doesn't seem to be
>>working - I suspect it may take something of this magnitude to force
>>a change out of NVidia/ATI.
>>
>>
>
>Is this a vote? Cause you have mine. :)
>
>Seriously, there is a danger in the move being seen by the press as too
>adversarial, but with everything I've been reading and seeing lately, I'm
>starting to think that the NVidia/ATI situation may be the single largest
>danger to Linux.
>
This is a win-win situation. for us, it is NOT a problem if the press
see the move as too adversarial. In fact - that would be the best
outcome of all because then we have the press and general opinion
against dumb patents.
Putting an end to stupid patents in general (and software patents
specifically) is even better than bogging a difficult hw company
down with lawsuits.
If they think the move is too nasty - then it must be because the
move itself is a bad thing - an opportunity that shouldn't exist, right?
Helge Hafting
On 12/7/05, Benjamin LaHaise <[email protected]> wrote:
> On Tue, Dec 06, 2005 at 04:41:44PM +0000, Dirk Steuwer wrote:
> > Yes, but there isn't and won't be much recognition - every company does
> > its own thing. And how many people buy online all the time? But even then,
> > a genery "runs with Linux" Logo would be great. If a company's product
> > is not certified, its not considered by Linux customers.
>
> This is something I've wanted to see for years now. Linux distributions
> do not have the motivation to work out the hardware certification issues
> on the community level, as it interferes with their value add of branding.
> I have always wished that when I see hardware advertising Linux support
> that it has a meaning: open source, supportable drivers. Maybe it's time
> to get such a project moving.
I've read that thread with interest and would like to share some of my thoughts.
What are the issues with a "run with Linux" sticker?
- supported by who? kernel.org? a distribution? the vendor?
- accredited by who? the entity that supports? an external entity?
- support which features? If the in-kernel driver contains the bare
minimum number of features, but no support for the advanced features,
what does the support claim mean? E.g. with all the OSS/ALSA, APM/ACPI
debates, I wonder what happens whenever a hardware is 'half'
supported.
- which Linux version? Some people mention restricting support to a
particular linux version or time periods. I find this not very
practical. How can you guarantee that in the next 2 years (or even 6
months)? With non stable API/ABI, how do you want to sell the idea of
unknown unforecastable development costs to the hardware maker?
- I still see people saying supported on "Linux 9.1" (aka Red Hat/Suse
or whatever)...
- it requires the manufacturer to care about putting the sticker in
place. If they start to advertise support, they will have more costs,
even if the support is handled by an external entity.
- what happens when a different revision of the 'same' hardware is not
supported anymore? It happened with one my webcam.
- how does that work when online? You will have a particular hardware
saying "Runs With Linux" and another one fully supported by the maker,
or fully unsupported use-ndiswrapper-like saying "Runs On Linux" or
"Works on Linux". How does the sticker help me to decide?
Because of all these reasons, I don't think we will ever have half of
the really supported hardware even display the sticker. What does that
mean for me as a user? I will still need to search for information
about the other part.
How to identify the other part?
I'd rather want to know this information from the community. The
community, in help with the distribution vendors, should come up with
a big database that contains all this information. I don't want to go
on the ALSA web site to check if my sound card is supported, then on
the SATA one for my disk controller, then on linux-usb etc...
I want tools to help us feed that database, like the Ubuntu Device
Database client. But I want that at the Linux scale not the
distribution one.
* The client software would be used to report functional state of
hardware elements or access information about a particular hardware
present on the machine.
* There should be an easy way to have a Live distro with the latest
kernel that contains the minimal set of programs required to run this
Hardware Database client.
Cheers,
Jerome
On Jeu 8 décembre 2005 01:58, Kasper Sandberg wrote:
> On Tue, 2005-12-06 at 21:39 +0000, Nicolas Mailhot wrote:
>> Arjan van de Ven <arjan <at> infradead.org> writes:
>>
>> > There are lots of opportunities to put pressure on vendors, either
>> > direct or indirect. Nvidia has a support department. If they get
>> enough
>> > calls / letters about their solution not being good enough, they're
>> more
>> > likely to consider the rearchtect solution.
>> Right now getting hardware advice is a long and painful process.
>> Hardware that
>> works is only semi-documented. Hardware which doesn't isn't at all.
>> Users have
>> to comb numerous on-line databases and mail archives (full of
>> obsolete/wrong
>> info) to spec a single linux-friendly system. Few people bother to
>> answer
>> hardware advice requests on mailing lists.
> i disagree, you make it sound like it takes we
eks of effort to find out
> which stuff works on linux, and that basically you have to be lucky to
> find it at all...
>
> basically the only thing that doesent work (i dont count binary-only
> solutions working) is nvidia and ati.
I agree you can get most systems working. If you don't care about advanced
features (PM management, hardware-specific optimizations...), the means
(nsdiswrapper, specific kernel version...) and limit yourself to very
mainstream hardware (ie two-years-old perf when windows users get the
latest enhancements).
But that's exactly the point Arjan made. Because we do not discriminate
based on support quality, whole classes of devices are choosing minimalist
support (-> erosion). Graphic cards and wireless cards are only those who
pushed this logic to its extreme.
If you trust blind luck and good enough, you don't have any purchasing
influence, and things will degenerate as they are doing now.
This is BTW why the logo idea is stupid. Logo is a boolean stuff. Either
you only give it to perfectly friendly hardware, and almost no one will
get it, or you accept all sorts of compromises, and harware makers will
only aim for the minimal requirements needed for the logo and nothing
else.
Much better a notation on a web site, showing in real time how individual
hardware/hardware makers are progressing from red to green (with shades of
orange between) or the other way.
This is what linuxprinting does, what alsa tries to (and fails somewhat,
sorry Lee) etc, etc. If a single system was used and more effort expanded
to have exhaustive hardware lists I assure you its effects would be felt
by hardware makers. Every single hardware review site could complete its
coverage for free by linking the official linux kernel hardware assessment
to its review. Right now they have no idea if a piece of hardware works
well or not, and because it's a lot of work to get the info they don't
bother. Which means kernel people opinion is worth next to nothing (as
Arjan complains).
Some people have proposed a wiki. A wiki is good but that's an
half-measure. Do it the full way - choose one of the FOSS ecommerce
stacks, replace the its comparison parameters by things we care about,
feed the underlying DB and just watch as people buy based on your
notation.
People do not follow the recommendations of every review web site because
they trust them. They follow the recommendations because it's the ones
easiest to get, and they don't want to bother with official (but difficult
to reach) sources.
Regards,
--
Nicolas Mailhot
Randy.Dunlap wrote (ao):
> On Wed, 7 Dec 2005, Rik van Riel wrote:
> > This worked very well in the late 1990's, when various
> > sites had Linux hardware compatibility lists.
> >
> > Does anybody still maintain a list like that today (with
> > components, not just whole certified systems) ?
>
> There are lists for USB and for IEEE1394 (Firewire).
> I'm not aware of others, but then I haven't searched for others.
There is a great list for SATA too, by Jeff Garzik:
http://linux.yyz.us/sata/
--
Humilis IT Services and Solutions
http://www.humilis.net
On 8 Dec 2005, at 09:42, jerome lacoste wrote:
>
> I've read that thread with interest and would like to share some of
> my thoughts.
>
> What are the issues with a "run with Linux" sticker?
>
> - supported by who? kernel.org? a distribution? the vendor?
>
Supported financially by:
OSDL? A generous donor? IBM? Distros?
> - accredited by who? the entity that supports? an external entity?
>
The technical accreditation would have to be based on the existing
expertise of the kernel maintainers.
Administration handled by a new Independent not-for-profit body with
initial funding from the bodies mentioned above.
On going funding provided by revenue from anyone who wants to use the
logo without having provided an open-source driver in 'payment'.
> - support which features? If the in-kernel driver contains the bare
> minimum number of features, but no support for the advanced features,
> what does the support claim mean? E.g. with all the OSS/ALSA, APM/ACPI
> debates, I wonder what happens whenever a hardware is 'half'
> supported.
>
The accreditation, by kernel maintainers, would be based on the fact
that the driver provides full support for the features of the hardware.
> - which Linux version? Some people mention restricting support to a
> particular linux version or time periods. I find this not very
> practical. How can you guarantee that in the next 2 years (or even 6
> months)? With non stable API/ABI, how do you want to sell the idea of
> unknown unforecastable development costs to the hardware maker?
>
> - I still see people saying supported on "Linux 9.1" (aka Red Hat/Suse
> or whatever)...
>
Maybe the OEM cannot get accreditation for a new device if they have
any accredited devices which are 'broken'
> - it requires the manufacturer to care about putting the sticker in
> place. If they start to advertise support, they will have more costs,
> even if the support is handled by an external entity.
>
The purpose of the logo is to build customer demand for hardware
which is accredited and therefore has the benefits of open source
drivers which will be maintained.
Once the logo gains mind share there will be a competitive advantage
for the OEMs who use it.
Therefore they will be willing to bear some costs.
> - what happens when a different revision of the 'same' hardware is not
> supported anymore? It happened with one my webcam.
>
As above.
(Maybe the OEM cannot get accreditation for a new device if they have
any accredited devices which are 'broken')
> - how does that work when online? You will have a particular hardware
> saying "Runs With Linux" and another one fully supported by the maker,
> or fully unsupported use-ndiswrapper-like saying "Runs On Linux" or
> "Works on Linux". How does the sticker help me to decide?
>
The primary requiremnet to gain the logo is that there is an open
source driver (merged in the kernel tree).
The logo allows people to tell the difference between OEMs who claim
compatibility because they use ndiswrapper and those who actually
have a proper kernel driver.
>
> Because of all these reasons, I don't think we will ever have half of
> the really supported hardware even display the sticker. What does that
> mean for me as a user? I will still need to search for information
> about the other part.
>
> How to identify the other part?
>
The solution depends on build the logo 'brand' so that different
players in the linux world want to use it .
This will happen in the following manner:
(as described in this thread http://lkml.org/lkml/2005/12/7/391)
>
>> Why will this work? Here is how I see it developing in the server
>> market:
>>
>> 1. The logo will be launched along with a campaign to explain to
>> technical users that (a) open source drivers are better quality,
>> (b) that binary drivers threaten the future of the Linux ecosystem.
>>
>> 2. Any company which manufactures equipment with open source
>> drivers already available will have the logo granted for their
>> current equipment.
>> This means that right from the outset it will be possible to
>> put together a system which is wholly conformant, i.e. the entire
>> PC is eligible to carry the logo.
>> 3. Certain small system builders will get on board.
>> 4. Obviously, everyone on LKML will only buy/recommend hardware
>> which carries "the mark of the penguin". As will geeks the world
>> over.
>> 5. One of the distros will decide that their "Supported Hardware"
>> list will only feature items with the logo.
>> 6. Medium sized system builders, maybe "partners" of the distro
>> will begin to ship systems that fully conform.
>> 7. All the supporters above will be using the the new Open Source
>> Graphics hardware from http://www.opengraphics.org. (Important later)
>> 8. Corporate or government buyers will by now become aware of the
>> value of buying certified equipment.
> I'd rather want to know this information from the community. The
> community, in help with the distribution vendors, should come up with
> a big database that contains all this information. I don't want to go
> on the ALSA web site to check if my sound card is supported, then on
> the SATA one for my disk controller, then on linux-usb etc...
>
> I want tools to help us feed that database, like the Ubuntu Device
> Database client. But I want that at the Linux scale not the
> distribution one.
> * The client software would be used to report functional state of
> hardware elements or access information about a particular hardware
> present on the machine.
> * There should be an easy way to have a Live distro with the latest
> kernel that contains the minimal set of programs required to run this
> Hardware Database client.
With a logo a PC vendor such as Dell can stick the logo on their PCs
if and only if every component in the machine is certified.
(Including motherboard, on-board graphics, on-boad-sound, on-board
raid etc. etc.)
This means you or I don't have to try to find out the exact machine
specification from Dell and then individually check each part against
the hardware database.
regards,
Felix
On Thursday 08 December 2005 08:14, you wrote:
> Luke-Jr wrote:
> >The ATi Radeon 9200 works fine...
>
> Lucky you. Mine doesn't. Using 3D on it makes the machine unstable,
> and the performance is apalling too.
Hm, well I don't have DRI enabled on my primary desktop... just on a second
one dedicated to gaming. Not sure if that makes any difference...
> So I'm looking for something else - a radeon 7000 is cheap . . .
That'll outperform a 9200? ;)
> And don't say that a crash during a 3D game isn't important -
A system crash? Worst I've ever seen was a X crash, back before I got my X
configs good. If you mean a game crash, I wouldn't know... half the time it'd
probably be my fault. ;)
> it is a two-user machine and the other user is not amused when this happens.
Maybe he would be if it showed a BSOD? :p
--
Luke-Jr
Developer, Utopios
http://utopios.org/
[...]
> With a logo a PC vendor such as Dell can stick the logo on their PCs
> if and only if every component in the machine is certified.
> (Including motherboard, on-board graphics, on-boad-sound, on-board
> raid etc. etc.)
>
> This means you or I don't have to try to find out the exact machine
> specification from Dell and then individually check each part against
> the hardware database.
I completely agree with all your arguments. My point is that your
solution is a long term one. It depends on demand being there, on
hardware vendors to be educated/lobbied/pressured, on both part
vendors and part assemblers to use the logos (as a good side effect
creating the logo might enforce the existance of Linux/Free OS
specialized hardware companies).
This is a good but long term shot. It will take years before such a
framework becomes effective for the user.
For example. If I have to buy a laptop today, I will have a hard time
finding a computer fully supported under Linux using Free drivers.
Let's say that the laptop of my dreams contains a non supported wifi
driver. I already have a supported exteranl Wifi card. In that case,
I'd rather pick the tool almost good for the job that shows me as
profficient under Linux (non certified), than a fully certified laptop
but that doesn't make me as effective.
We probably need both the logo/certification and the centralized
hardware database, but the later might be effective sooner.
Jerome
On Wed, 7 Dec 2005, Michele wrote:
> On 12/7/05, Geert Uytterhoeven <[email protected]> wrote:
> > On Tue, 6 Dec 2005, Denis Vlasenko wrote:
> > > On Tuesday 06 December 2005 03:18, Andrea Arcangeli wrote:
> > > > On Mon, Dec 05, 2005 at 04:18:51AM -0800, William Lee Irwin III wrote:
> > > > > 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.
> > > >
> > > > I agree about the erosion.
> > > >
> > > > I am convinced that the only way to stop the erosion is to totally
> > stop
> > > > buying hardware that has only binary only drivers (unless you buy it
> > to
> > > > create an open source driver or to reverse engineer the binary only
> > > > driver of course! ;).
> > >
> > > I'm afraid there is not enough Linux users in desktop/laptop market
> > > for vendors to notice.
> > >
> > > How about refusing binary-only modules instead? I mean, maybe
> >
> > You mean, call panic() if module license not acceptable? Nice!
>
> This can only be defined a GPL-integralist approach. You are ignoring closed
> SDK used by almost every one who uses linux on embedded platforms...from
> Linksys routers and access points to media stations to STB with hardware a/v
> decoders. You cant really think linux could influence nearly the whole IT
> market, especially if they make money selling closed source SDK.
If you post in HTML, you're message will never make it to the list.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 8 Dec 2005, at 11:48, jerome lacoste wrote:
> [...]
>> With a logo a PC vendor such as Dell can stick the logo on their PCs
>> if and only if every component in the machine is certified.
>> (Including motherboard, on-board graphics, on-boad-sound, on-board
>> raid etc. etc.)
>>
>> This means you or I don't have to try to find out the exact machine
>> specification from Dell and then individually check each part against
>> the hardware database.
>
> I completely agree with all your arguments. My point is that your
> solution is a long term one. It depends on demand being there, on
> hardware vendors to be educated/lobbied/pressured, on both part
> vendors and part assemblers to use the logos (as a good side effect
> creating the logo might enforce the existance of Linux/Free OS
> specialized hardware companies).
>
> This is a good but long term shot. It will take years before such a
> framework becomes effective for the user.
>
I am not trying to address the immediate problem.
This is a strategy to prevent the "Doomsday Scenario" outlined by
Arjan which ends up with most drivers being closed source.
I said in my other thread (http://lkml.org/lkml/2005/12/7/391):
>> The primary motivation for this is that it leverages the
>> individual power of each purchaser (of a system or individual
>> piece of hardware) be they a consumer, SME, system builder, tier 1
>> or 2 PC manufacturer, government dept., or Linux distro company,
>> into a single point of pressure that can be applied to OEMs to
>> ensure that they provide open source drivers.
regards,
Felix
El Wed, 7 Dec 2005 22:21:31 -0800 (PST),
Zwane Mwaikambo <[email protected]> escribi?:
> Lets be objective at least, Windows XP was released in 2002, have you
> tried Linux distros from 2002 on said laptops?
Indeed windows xp was released in 2002, but Microsoft don't seem
to add new drivers in the service packs (which is something they
could do).
On Thu, 2005-12-08 at 13:31 +0100, Diego Calleja wrote:
> El Wed, 7 Dec 2005 22:21:31 -0800 (PST),
> Zwane Mwaikambo <[email protected]> escribió:
>
> > Lets be objective at least, Windows XP was released in 2002, have you
> > tried Linux distros from 2002 on said laptops?
>
> Indeed windows xp was released in 2002, but Microsoft don't seem
> to add new drivers in the service packs (which is something they
> could do).
in the OEM editions they sure do.
Arjan van de Ven wrote:
> in the OEM editions they sure do.
You mean, for the specific OEM hardware involved? I don't think MS does that,
its probably the OEM...
Putting drivers into Windows installation CDs is easier then it seems at first.
I have made a few to ease installation on new computers, though I usually use
Ghost to achieve the same goal.
Which is actually what some OEMs do instead of giving you a real Windows
installation CD (With the image residing on a hidden partition).
--
[Name ] :: [Matan I. Peled ]
[Location ] :: [Israel ]
[Public Key] :: [0xD6F42CA5 ]
[Keyserver ] :: [keyserver.kjsl.com]
encrypted/signed plain text preferred
Andrea Arcangeli <andrea <at> cpushare.com> writes:
>
> On Wed, Dec 07, 2005 at 09:19:02PM +0100, Arjan van de Ven wrote:
> > the problem with this is that with wiki's you get a sliding scope wrt
> > criteria; I mean, many people will say nvidia graphics work great with
> > linux... and the wiki will represent that ;(
>
> then the wiki will be closed. But it worth a try. Of course the topic
> will explain it's a list of hardware supported by open source (GPL
> compatible) drivers.
>
> Like wiki.kernel.org/OpenSourceKernelDrivers
>
I think this could be of value, although i have my problems with a wiki solution.
As pointed out, there is no structure in the wiki itself, the advantages are
just that quick'n'easy editing is possible and everyone can start topics.
For a hardwaredatabase i like to see a structure. Kernel developers are
required to enter the support into the database, when submitting the driver.
Ongoing status will be logged there as well. Status and devices can only be
entered by kernel developers.
The interface could have a mixed structure - fixed fields in the header
(device ID, status, kernel version,..)
and a wiki style body for free editing of additional info.
Below each device there could be a open comment forum, allowing user/tester
to leave info.
this whole thing could then serve as a starting point for this diskussion:
http://thread.gmane.org/gmane.linux.kernel/355950
Where an logo is awarded for full device support with free driver, which
hardware vendors can stick on their boxes. Customers therefore know that
this device is "Plug and Play" :-) no driver installation hassle.
This is what linux should be known for, not like the current situation..
regards,
Dirk
On 8 Dec 2005, Helge Hafting said:
> Lucky you. Mine doesn't. Using 3D on it makes the machine unstable,
> and the performance is apalling too. So I'm looking for something
> else - a radeon 7000 is cheap . . .
Backtraces? X version? X config?
(FWIW, my AGP Radeon 9250 works flawlessly as of X.org 6.8.99.901.
6.8.2 and earlier were wobbly.)
Whether performance is appalling I don't know because I don't have any
standards to measure it by, but I get 2000fps or thereabouts out of
glxgears. That's a hell of a lot better than the 64fps I got out of
my earlier mach64 :)
> And don't say that a crash during a 3D game isn't important - it is
> a two-user machine and the other user is not amused when this happens.
Agreed. If you can handle a brief possibility of deadlocking then you
can get a backtrace when X dies, which is very useful:
<http://xorg.freedesktop.org/wiki/DebuggingTheXserver>.
--
`Don't confuse the shark with the remoras.' --- Rob Landley
El Thu, 8 Dec 2005 13:23:11 +0000 (UTC),
Dirk Steuwer <[email protected]> escribi?:
> For a hardwaredatabase i like to see a structure. Kernel developers are
> required to enter the support into the database, when submitting the driver.
> Ongoing status will be logged there as well. Status and devices can only be
> entered by kernel developers.
[Please don't remove the CC list]
This sounds like the typical nightmare that never is 100% accurate and
needs lots of mainteinance (developers not updating the wiki, etc) as
Lee Revell pointed out.
IMO the one way of creating such database is automating it. If you
could get a list of the device IDs supported by drivers you
could (?) use the pciid/usbid/whatever list to build a user-readable
database of the devices supported by the linux tree. Maybe it won't
100% perfect but...
Dave Airlie <[email protected]> writes:
> 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).
Maybe one day they might see that having an open source driver, or
even just releasing the hardware interface specifications so that
drivers can be written, will give them an advantage over those who
only have closed source drivers. After all, these companies are in the
business of designing and selling hardware and knowing the interface
specifications (ie the registers and the commands which have to be
sent to them etc) should not give away the layout of the silicon (ie
does not give competitors information about how the commands are
translated to actual operations on the screen). So publishing the
interface should not violate the IP of the silicon design owners.
On Thu, 2005-12-08 at 13:31 +0100, Diego Calleja wrote:
> El Wed, 7 Dec 2005 22:21:31 -0800 (PST),
> Zwane Mwaikambo <[email protected]> escribi?:
>
> > Lets be objective at least, Windows XP was released in 2002, have you
> > tried Linux distros from 2002 on said laptops?
well true, but really there are no newer windows release available to
buy, so this must be what they want us to use! (xp with sp2 embedded
still have problems with alot stuff)
>
> Indeed windows xp was released in 2002, but Microsoft don't seem
> to add new drivers in the service packs (which is something they
> could do).
>
On Thu, 2005-12-08 at 10:39 +0200, Meelis Roos wrote:
> >> Some SiS based motherboards offer both an integrated video and AMD
> >> processor support.
> >>
> KS> unfortunately that sis chip has a hardware bug (or so the xorg module
> KS> tells me) which makes dri impossible, and video overlay extremely bad..
>
> Care to tell some more? I'm just considering purchasing a SiS or ULi
> based mainboard for AMD64 and would like to get the details about this
> SiS problem.
>
this is my experience with my brothers laptop, its an asus, i cant
remember model off hand, it has a sempron 3000+ cpu, and some sis
chipset.
i installed linux on it due to him having excessive windows problems..
the xorg log told me i couldnt get dri, because of some hardware
problem, then it gave me a link, which i cant remember either, which
explained much more in detail about this.. and the thing about the video
overlay i do remember, it was something about some shared memory it uses
for the card which made the video overlay not work good, in both windows
and linux as far as i remember.. and it was true, video did sometimes
stutter and such.. and there is no dri..
i will contact my brother to get some more info..
On 12/7/05, Arjan van de Ven <[email protected]> wrote:
>
> > A moinmoin wiki.kernel.org should work fine and it takes 10 minutes to
> > set it up. Let's use the community to build this list. Perhaps
> > wiki.kernel.org could also be used to document some kernel stuff later
> > on.
>
> the problem with this is that with wiki's you get a sliding scope wrt
> criteria; I mean, many people will say nvidia graphics work great with
> linux... and the wiki will represent that ;(
>
Well, if the USB developers are already keeping a list of "known
good/known bad" devices, and the IEEE 1394 people are maintaining such
a list, and the ALSA people are maintaining a list, wouldn't it make
sense to just have some sort of agregation method to present a
centralized front end to the information? A distributed hardware
matrix as it were?
Seems wise, in order to avoid the problem that Arjan mentioned, to
have developers closest to the drivers to be the primary maintainers
of the info. Users are obviously going to be an important source of
information, but having random users editing a wiki page with "works
great for me," "doesn't work at all for me"-style comments appears
less helpful than a matrix maintained w/ input from users (where input
from users is primarily though the bug reporting process or something
else a little more disciplined than unqualified affirmative or
negative blurbs).
Dave
Kasper Sandberg <[email protected]> wrote:
[...]
> i disagree, you make it sound like it takes weeks of effort to find out
> which stuff works on linux, and that basically you have to be lucky to
> find it at all...
> basically the only thing that doesent work (i dont count binary-only
> solutions working) is nvidia and ati.
Count several WiFi cards into it too. Perhaps very-high-end stuff.
And what doesn't work well on Linux in "normal PCs" (rock-bottom priced
stuff, mostly) doesn't work well at all, period.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Randy.Dunlap <[email protected]> wrote:
> On Wed, 7 Dec 2005, Rik van Riel wrote:
[...]
> > Does anybody still maintain a list like that today (with
> > components, not just whole certified systems) ?
>
> There are lists for USB and for IEEE1394 (Firewire).
> I'm not aware of others, but then I haven't searched for others.
<http://www.linuxprinting.org> has comprehensive coverage of printers.
Yes, I know it is not exactly what has been asked here, but still.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Diego Calleja <[email protected]> wrote:
[...]
> I think that the infrastructure for building such database automatically
> is already there: In the same way MODULE_DEVICE_TABLE is used by hotplug
> & friends to load the right module you can use MODULE_DEVICE_TABLE to
> build a database of the devices supported by a kernel compiled with
> "make allmodconfig", parse it and put it in a web page.
What use is it to me when I'm going to buy ShinyCard-9900, and the database
tells me that RandomChip 2530a is supported? The packages rarely tell you
what chips are in the cards, moreover there have been cases of /very
similar/ card versions (i.e., SomeThing-990 and SomeThing-990+, or
Card-897a and Card-897b) being /totally/ different inside). The only
reliable way to find out if it works is a test drive. Distributions like
Ubuntu are invaluable here.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Thu, 8 Dec 2005, Horst von Brand wrote:
> Kasper Sandberg <[email protected]> wrote:
>
> [...]
>
>> i disagree, you make it sound like it takes weeks of effort to find out
>> which stuff works on linux, and that basically you have to be lucky to
>> find it at all...
>
>> basically the only thing that doesent work (i dont count binary-only
>> solutions working) is nvidia and ati.
>
> Count several WiFi cards into it too. Perhaps very-high-end stuff.
>
> And what doesn't work well on Linux in "normal PCs" (rock-bottom priced
> stuff, mostly) doesn't work well at all, period.
> --
> Dr. Horst H. von Brand User #22616 counter.li.org
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Talk about rock-bottom stuff, does anybody know if I can build
a file-system on a CompactFlash card that plugs into a USB adapter
from Linux (like those marketed by Kodak) ??
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Dirk Steuwer <[email protected]> writes:
> Ideally, there should be a label "designed for Linux" (or "designed for
> free software" (maybe getting the bsd people on board as well?))
> straight on the box. So customers that start to care about linux, can
> see this right away and make the right choice, when buying hardware.
The last bit of hardware I bought, a super-cheapo NIC (for use with an
ADSL modem), prominently stated it was "linux compatible". Morever, all
the other brands of super-cheapo NIC alongside it on the shelf did the
same thing; they all used the defacto linux logo -- the chubby penguin --
on the front of the box to indicate this, next to the windows logo to.
The fine print on the side of the box said something to the effect of
"linux driver is included with OS, not in box" (whereas a floppy with
windows driver was in the box).
I dunno, maybe there's something weird about NICs or something...
I suppose for them it's a no-brainer, since they generally know their
stuff will just work in linux, and the only cost to them is someone to
insert the logo in the box art. Also, since competition among low-end
brands like that is probably ferocious, even a little marketing advantage
is probably worth persuing.
[But in my experience, it's certainly not _unusual_ to see "linux
compatible" on random consumer hardware boxes these days (I live in Tokyo
though; maybe the market's a bit different here than where you live).]
-Miles
--
Quidquid latine dictum sit, altum viditur.
linux-os (Dick Johnson) wrote:
> Talk about rock-bottom stuff, does anybody know if I can build
> a file-system on a CompactFlash card that plugs into a USB adapter
> from Linux (like those marketed by Kodak) ??
If you're talking about one of those 15-in-one card readers...
Yes..it shows up like a normal USB storage block device. I use one of
those things to copy 512MB CF disks using 'dd' often...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
With Mr. Hemminger's permission, I've started a Hardware WIKI catagory on
the linux-net wiki: http://linux-net.osdl.org/index.php/Main_Page (bottom of first column)
I plan to add my notes on NICs and motherboards (that I use primarily for
network traffic applications) to this page. I don't plan to try to make
it exhaustive (though others can contribute, of course). I do plan to
add notes and work-arounds as I find them...and I seem to have some luck
finding issues since I often stretch the networking side of the hardware...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 9 Dec 2005, at 05:49, Miles Bader wrote:
>
> The last bit of hardware I bought, a super-cheapo NIC (for use with an
> ADSL modem), prominently stated it was "linux compatible".
> Morever, all
> the other brands of super-cheapo NIC alongside it on the shelf did the
> same thing; they all used the defacto linux logo -- the chubby
> penguin --
> on the front of the box to indicate this, next to the windows logo to.
>
> The fine print on the side of the box said something to the effect of
> "linux driver is included with OS, not in box" (whereas a floppy with
> windows driver was in the box).
>
> I dunno, maybe there's something weird about NICs or something...
> I suppose for them it's a no-brainer, since they generally know their
> stuff will just work in linux, and the only cost to them is someone to
> insert the logo in the box art. Also, since competition among low-end
> brands like that is probably ferocious, even a little marketing
> advantage
> is probably worth persuing.
>
> [But in my experience, it's certainly not _unusual_ to see "linux
> compatible" on random consumer hardware boxes these days (I live in
> Tokyo
> though; maybe the market's a bit different here than where you live).]
Two advantages to a certified logo program:
1. To ensure that the driver actually works, continues to work and
fully supports the features of the hardware.
2. To enable PC manufactures to badge their entire systems (e.g. a
Dell with a Linux Compatible sticker on the box).
The long term objective being to put those manufacturers who don't
supply open source drivers at a disadvantage.
regards,
Felix
On Fri, 2005-12-09 at 09:49 +0000, Felix Oxley wrote:
[...]
> Two advantages to a certified logo program:
[...]
> 2. To enable PC manufactures to badge their entire systems (e.g. a
> Dell with a Linux Compatible sticker on the box).
Actually it would probably some pressure on Dell to actually admit the
(some) Linux runs on their hardware. In the marketing folders, they
recommend software from the evil empire.
And I saw last week an add from Lenovo where they also recommend the
monopoly software. This raises - at least for me - the question how
serious IBM was and is with their support and commitment Linux ....
> The long term objective being to put those manufacturers who don't
> supply open source drivers at a disadvantage.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
> Some people have proposed a wiki. A wiki is good but that's an
> half-measure. Do it the full way - choose one of the FOSS ecommerce
> stacks, replace the its comparison parameters by things we care about,
> feed the underlying DB and just watch as people buy based on your
> notation.
>
> People do not follow the recommendations of every review web site because
> they trust them. They follow the recommendations because it's the ones
> easiest to get, and they don't want to bother with official (but difficult
> to reach) sources.
>
> Regards,
>
And for feeding the DB, could this be an extended KLive approach which gathers
device ID, querys the database for ho many versions there really are
under this id :-) and asks some questions:
* are you happy with performance of 1234:5678 Graphics Adapter xyz?
* is said adapter of type OEM, Original, ...
* is feature f working?
* how about feature l?
* kernel version
* an so on
How about getting hardware review people on board?
They do good testing and recieve a link back to their site?
Dirk
On Monday 05 December 2005 21:56, Zwane Mwaikambo wrote:
> Do you think this opensource hardware could keep up with nvidia and ati
> hardware development? Joe sixpack is all about the fastest hardware.
Not really. The early adopters and cutting edge gamers are, sure. For
everybody else its price/performance and "good enough to run my games". The
playstation 2 is how many years old now? But it's still selling fresh
copies, and will until the PS3 comes out. (And even then, people will still
play PS2 games.)
Like everything else, this is application driven. If it runs World of
Warcraft and City of Heroes, there's a market for it. May be a cheap market,
but it's there. Especially if it fits nicely in laptops, has low power
consumption, doesn't need a cooling fan...
(Also, keep in mind that half of graphics performance is how much texture
memory the sucker has and how fast the ram it talks to is.)
(I remember the days when games had a selection menu so you could tell it what
kind of sound card you had. 3D video cards are still there. Won't last
forever.)
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
On Thu, 2005-12-08 at 15:49 -0600, Rob Landley wrote:
> I remember the days when games had a selection menu so you could tell
> it what kind of sound card you had.
Don't they still do that, for EAX, A3D, etc?
Lee
> No proprietary software here, excluding things such as firmware/BIOS where
> there is no choice.
Why 'excluding'? You can't deny you are using proprietary software.
Neither do us.
The FSF chose, for its newest server, a machine that supports a
free BIOS. You can make such choices too.
We are also trying to help the work to support free BIOS on a laptop
so that my next laptop can run a free BIOS. There are surely ways you
can help, too, if you want to be constructive.
Non-free device firmware is also a problem, when it has to be
installed from outside the device. The OpenBSD developers have done a
lot of work to arrange to avoid non-free device firmware. The FSF
tries to help too; we maintain some lists of hardware which works
without non-free firmware. We need more of these lists; if you are an
expert on some category of hardware, and you would like to help,
please write to me.
AFAIK, no proprietary software vendors are forcing any1 to buy their
proprietary software. Still you are speaking in a monopoly tone!
Strictly speaking, they do not _force_ members of the public to use
their software. But they do create situations that put strong
pressure on people to use certain proprietary software. While this is
not literally "forcing" people, it is close enough to deserve similar
criticism.
Meanwhile, in France, the media companies have proposed an amendment
to the French DMCA which would make it more like the former proposed
US CBDTPA (Consume But Don't Try Programming Act). It would forbid
the distribution of programs that allow copying of copyrighted works
and do not enforce DRM.
Various programs in GNU/Linux systems, including Apache, ftpd, Emacs,
and Linux, could fall under this prohibition. It is impossible to see
where the line would be drawn, because the text of the law is not
clear.
On Tuesday 06 December 2005 03:56, Zwane Mwaikambo wrote:
> Do you think this opensource hardware could keep up with nvidia and ati
> hardware development? Joe sixpack is all about the fastest hardware.
Personally, I'm hoping that it will get some standard interfaces to video
cards and possibly lay out a VESA-for-OpenGL or such that is later adopted by
all other cards...
--
Luke-Jr
Developer, Utopios
http://utopios.org/
Richard M. Stallman wrote:
> > No proprietary software here, excluding things such as firmware/BIOS where
> > there is no choice.
>
> Why 'excluding'? You can't deny you are using proprietary software.
> Neither do us.
>
>The FSF chose, for its newest server, a machine that supports a
>free BIOS. You can make such choices too.
>
>We are also trying to help the work to support free BIOS on a laptop
>so that my next laptop can run a free BIOS. There are surely ways you
>can help, too, if you want to be constructive.
>
>
"constructive" is a for profit model that sustains the hi tech
industry. The current
models have created a conduit for socialist disintegration of the
american hi tech
markets, loss of jobs, and have funnelled technology out of the
country. Legal
defense funds should be the biggest red flags of all. If this system
you devised really
works, why all the litigation? Why all the need for legal defense funds
and patent
infringement insurance? I've watched the entire market slowly collapse
over the years
as the result of the affect of the GPL on America's hi tech markets.
It isn't working, and it isn't sustainable. non-profit and "temples" of
GPL "religion"
have evolved, with the leaders living in orgnaizations that subsist from
handouts and
donations. This movement has spawned a global attitude that has no
respect
for IP rights, and it's extended itself to no respect for human rights,
or any other rights
of the indivdual. That's the legacy this has left and the ultimate
conclusion.
My 2 cents.
J
On Sat, Dec 10, 2005 at 12:06:54AM -0700, Jeff V. Merkey wrote:
> Richard M. Stallman wrote:
>
> > > No proprietary software here, excluding things such as firmware/BIOS
> > where
> > > there is no choice.
> >
> > Why 'excluding'? You can't deny you are using proprietary software.
> > Neither do us.
> >
> >The FSF chose, for its newest server, a machine that supports a
> >free BIOS. You can make such choices too.
> >
> >We are also trying to help the work to support free BIOS on a laptop
> >so that my next laptop can run a free BIOS. There are surely ways you
> >can help, too, if you want to be constructive.
> >
> >
> "constructive" is a for profit model that sustains the hi tech
> industry. The current
> models have created a conduit for socialist disintegration of the
> american hi tech
> markets, loss of jobs, and have funnelled technology out of the
> country. Legal
The hi-tech industry can sustain itself just fine selling _hardware_.
Wether it does so from America or elsewhere isn't all that interesting,
although it may be an indication of wich countries that have
competitive advantages - and which have disadvantages. Open source
software is not a problem here, it certainly takes a bite out of
_software_ markets but the effect is the same on every country.
It is generally a good thing, not having to pay for software
means more money for hardware (or non-computer stuff.) The money
is still spent though - so no ill effects for the economy. But
a nice effect for users - who gets more "other stuff" without
loosing software.
> defense funds should be the biggest red flags of all. If this system
> you devised really
> works, why all the litigation? Why all the need for legal defense funds
> and patent
> infringement insurance?
Isn't that something that you have to have in american business today,
wether you run the FSF or some more ordinary company?
> I've watched the entire market slowly collapse
> over the years
> as the result of the affect of the GPL on America's hi tech markets.
>
Really? 90% still uses windows, it is not as if paid software
dwindled much yet . . .
> It isn't working, and it isn't sustainable. non-profit and "temples" of
Certainly sustainable. You can usually not make a living programming free
sw _only_, but there is support, there is hw sales, there is working
with something different having free sw as a hobby only.
> GPL "religion"
> have evolved, with the leaders living in orgnaizations that subsist from
> handouts and
> donations. This movement has spawned a global attitude that has no
> respect
> for IP rights, and it's extended itself to no respect for human rights,
> or any other rights
> of the indivdual. That's the legacy this has left and the ultimate
> conclusion.
Less respect for IP rights - possibly. Perhaps that's a good thing though,
some of us thinks such rights are a bit overrated.
Helge Hafting
On Sat, 2005-12-10 17:43:20 +0100, Helge Hafting <[email protected]> wrote:
> > GPL "religion"
> > have evolved, with the leaders living in orgnaizations that subsist from
> > handouts and
> > donations. This movement has spawned a global attitude that has no
> > respect
> > for IP rights, and it's extended itself to no respect for human rights,
> > or any other rights
> > of the indivdual. That's the legacy this has left and the ultimate
> > conclusion.
>
> Less respect for IP rights - possibly. Perhaps that's a good thing though,
> some of us thinks such rights are a bit overrated.
_Less_ respect? I'm sorry, no. Once I started working on free
software, I really started having raising respect for what you call
Intellectual Property. ...and also recognizing some special words:
"patented" -- product will be extraordinary expensive and probably not
any longer actively developed (like it would be if
there was real competition).
"special" -- product will use parts and materials that are hard to
obtain, hard to repair and probably expensive, too.
"Intellectual Property" means to not do the very best for the
customers, but for the company. So if somebody fights for their IP to
be kept secret, that's just as good as writing "I'm selfish and only
want to get your money."
Thanks.
I try to share my IP to teaching people using free software, but also
doing some limited hardware soldering etc. Lots of fun, won't create
secret IP and will actually educate people to be creative instead of
consuming television...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +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));
Jan-Benedict Glaw wrote:
>On Sat, 2005-12-10 17:43:20 +0100, Helge Hafting <[email protected]> wrote:
>
>
>>>GPL "religion"
>>>have evolved, with the leaders living in orgnaizations that subsist from
>>>handouts and
>>>donations. This movement has spawned a global attitude that has no
>>>respect
>>>for IP rights, and it's extended itself to no respect for human rights,
>>>or any other rights
>>>of the indivdual. That's the legacy this has left and the ultimate
>>>conclusion.
>>>
>>>
>>Less respect for IP rights - possibly. Perhaps that's a good thing though,
>>some of us thinks such rights are a bit overrated.
>>
>>
>
>_Less_ respect? I'm sorry, no. Once I started working on free
>software, I really started having raising respect for what you call
>Intellectual Property. ...and also recognizing some special words:
>
>"patented" -- product will be extraordinary expensive and probably not
> any longer actively developed (like it would be if
> there was real competition).
>"special" -- product will use parts and materials that are hard to
> obtain, hard to repair and probably expensive, too.
>
>"Intellectual Property" means to not do the very best for the
>customers, but for the company. So if somebody fights for their IP to
>be kept secret, that's just as good as writing "I'm selfish and only
>want to get your money."
>
>Thanks.
>
>I try to share my IP to teaching people using free software, but also
>doing some limited hardware soldering etc. Lots of fun, won't create
>secret IP and will actually educate people to be creative instead of
>consuming television...
>
>MfG, JBG
>
>
>
Two responses from people who live in socialist countries. Sure you
agree, it's just status quo from your perspectives.
Jeff
On Sat, 2005-12-10 11:44:37 -0700, Jeff V. Merkey <[email protected]> wrote:
> Two responses from people who live in socialist countries. Sure you
> agree, it's just status quo from your perspectives.
Jeff, I'm not sure if we both think about the same things when we talk
about "socialist", but I guess you may want to have a look at
Germany's history, as well as the whole newer history (like 50 years)
of Old Europe...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +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));
On Sat, December 10, 2005 2:06 am, Jeff V. Merkey said:
> "constructive" is a for profit model that sustains the hi tech industry.
> The current
There are for-profit models of selling GPL software. Anyway, billions of
dollars are still spent every year on software.
> models have created a conduit for socialist disintegration of the
> american hi tech markets, loss of jobs, and have funnelled technology out
You should look at the dwindling manufacturing sector in America and
notice that the same thing is happening there without any GPL to blame.
> of the country. Legal defense funds should be the biggest red flags of
> all. If this system you devised really works, why all the litigation?
> Why all the need for legal defense funds and patent infringement
This is just utter nonsense; most litigation in the software industry
occurs between closed source vendors.
> insurance? I've watched the entire market slowly collapse over the
> years as the result of the affect of the GPL on America's hi tech
> markets.
By which measure has the market collapsed? Whatever you mean, my guess is
that you're overestimating the role of the GPL. More likely, you're just
misinterpreting globalization and the natural transition of the sector
into more of a commodity market.
> It isn't working, and it isn't sustainable. non-profit and "temples" of
> GPL "religion" have evolved, with the leaders living in orgnaizations
Hah! By your definition of the word, American capitalism is just another
"religion".
> that subsist from handouts and donations. This movement has spawned a
> global attitude that has no respect for IP rights, and it's extended
This movement has spawned a global attitude supporting greater consumer
rights. Overall, its been a very positive and healthy force.
> itself to no respect for human rights, or any other rights of the
> indivdual. That's the legacy this has left and the ultimate
> conclusion.
Oh please, how exactly does GPL software undermine human rights?
Cheers,
Sean
Jan-Benedict Glaw wrote:
>On Sat, 2005-12-10 11:44:37 -0700, Jeff V. Merkey <[email protected]> wrote:
>
>
>>Two responses from people who live in socialist countries. Sure you
>>agree, it's just status quo from your perspectives.
>>
>>
>
>Jeff, I'm not sure if we both think about the same things when we talk
>about "socialist", but I guess you may want to have a look at
>Germany's history, as well as the whole newer history (like 50 years)
>of Old Europe...
>
>MfG, JBG
>
>
>
I'm married to a German citizen and I visit Germany for 3-4 week stints
once a year. Last year I went to Aachen and Amsterdam on vacation.
Every computer store I visited sold pirated copies of Windows XP and
Microsoft Office and in Amsterdam people were selling copies on the
street corners in the Artis District.
The entire culture has absolutely no concept of IP rights and I was
amazed at how open folks are there about piracy. If someone did that in
the US, they'd
be in jail. I have lived in Germany, Italy, France, Spain, Crete, and
I spent about 2 years in the UK when I was a younger man, and I have a
really
good handle on the culture over there. Even the republic countries
which have democratic governments are very much socialist in terms of the
lifestyle and the governments, and the way people live, so it's no
surprise the whole concept of free software and the GPL are so natural
to the
culture of Europe in general.
I have been very dismayed at how FOSS has been used as a vehicle to
promote anti-american attitudes into our own culture. It's sad. I have
lived in
all these places and the only place where people have guaranteed rights
as individuals and true freedom is America. I was in Germany in the late
1970's and earlt 1980's when the Bater-Meinhoffs were killing Americans
in the streets and the Grune-Gehfahr (Green Party) was having
demonstrations burning effigies of Uncle Sam in the Hauptewache District
in Frankfurt. This younger generation has no concept of what they are
supporting or how bad things can get. It is the doom of men that they
forget.
At any rate, I do understand, and I have a son-in-law in Germany and
grandchildren who speak German and not English (I know what Oh-pa means
and I can always tell them "Ich Habe Dich Leib"), so I do agree the
bonds between countries are becoming more and more blurred. I remember an
older German man in Aachen in a Luftwaffe Uniform watching me with my
grandson in Starbucks try to talk to each other and him smiling at the
thought an American man has grandkids who are totally immersed in the
German culture. At any rate, Stallman needs to in the next GPL incorporate
capitalist provisions which will allow FOSS to become a self sustaining
model. The US markets are abandoning Linux as a commerical offering
and Windows is continuing to get stronger and stronger. It's tough to
embrace technology when people cannot see a future in it. Hardware
purchases aside.
Jeff
Jeff
On Sat, 2005-12-10 13:44:38 -0700, Jeff V. Merkey <[email protected]> wrote:
> Jan-Benedict Glaw wrote:
> >On Sat, 2005-12-10 11:44:37 -0700, Jeff V. Merkey
> ><[email protected]> wrote:
> >>Two responses from people who live in socialist countries. Sure you
> >>agree, it's just status quo from your perspectives.
> >Jeff, I'm not sure if we both think about the same things when we talk
> >about "socialist", but I guess you may want to have a look at
> >Germany's history, as well as the whole newer history (like 50 years)
> >of Old Europe...
> I'm married to a German citizen and I visit Germany for 3-4 week stints
> once a year. Last year I went to Aachen and Amsterdam on vacation.
> Every computer store I visited sold pirated copies of Windows XP and
> Microsoft Office and in Amsterdam people were selling copies on the
> street corners in the Artis District.
Well, so what's your point? Germans and Netherlands tend to steal
software? Be it, but thses countries aren't socialistic at all...
> The entire culture has absolutely no concept of IP rights and I was
> amazed at how open folks are there about piracy. If someone did that in
> the US, they'd
> be in jail. I have lived in Germany, Italy, France, Spain, Crete, and
> I spent about 2 years in the UK when I was a younger man, and I have a
> really
> good handle on the culture over there. Even the republic countries
> which have democratic governments are very much socialist in terms of the
> lifestyle and the governments, and the way people live, so it's no
> surprise the whole concept of free software and the GPL are so natural
> to the
> culture of Europe in general.
What *may* be true is that possibly European mentality towards
"Intellectual Property" is somewhat different to the US. I've learned
to gain strength by sharing something (esp. knowledge) in a community
and not to basically try to de-share knowledge, making it a rare good.
Give a man a fish, he'll have food for the day. Teach a man fishing
and he'll have food for all his life. You probably know that
sentence. You seem to not distinguish between enforced sharing and
willfull sharing. That's where the problems arise.
> I have been very dismayed at how FOSS has been used as a vehicle to
> promote anti-american attitudes into our own culture. It's sad. I have
> lived in
> all these places and the only place where people have guaranteed rights
> as individuals and true freedom is America. I was in Germany in the late
> 1970's and earlt 1980's when the Bater-Meinhoffs were killing Americans
> in the streets and the Grune-Gehfahr (Green Party) was having
> demonstrations burning effigies of Uncle Sam in the Hauptewache District
> in Frankfurt. This younger generation has no concept of what they are
> supporting or how bad things can get. It is the doom of men that they
> forget.
Really? People, esp. the younger ones, really tend to get quite a lot
of political input. Just look at hot political topics that are
discussed in the media as well as at the school like the way the US
government (as well as some European governments) try to do their nice
war against terror and where it affects our daily life.
> At any rate, I do understand, and I have a son-in-law in Germany and
> grandchildren who speak German and not English (I know what Oh-pa means
> and I can always tell them "Ich Habe Dich Leib"), so I do agree the
> bonds between countries are becoming more and more blurred. I remember an
> older German man in Aachen in a Luftwaffe Uniform watching me with my
> grandson in Starbucks try to talk to each other and him smiling at the
> thought an American man has grandkids who are totally immersed in the
> German culture. At any rate, Stallman needs to in the next GPL incorporate
> capitalist provisions which will allow FOSS to become a self sustaining
> model. The US markets are abandoning Linux as a commerical offering
> and Windows is continuing to get stronger and stronger. It's tough to
> embrace technology when people cannot see a future in it. Hardware
> purchases aside.
I think you totally over-estimate the goal of GPL and/or FOSS. This is
what it's *not*:
- Kill commercial markets. (Though it'll bring PITA to some
commercial vendors that will need to compete with FOSS.)
- World domination. (There's always some granny loving Win3.1 so
there's always at least one {BSD,Linux,...} compatible computer
not running it. Also, would you as a FOSS programmer like to
support all these John McDummy users that cannot handle a
computer at all?)
Though, it is (besides other things):
- A lot of *personal* fun for some single, technically-skilled
programmers that like to hack software and present their work.
- A way to earn money (I've worked at a company using Linux and the
whole GNU stack of software for several years).
So not the whole worls spins around earning money. A lot of motivation
(especially speaking for myself) is just about programming,
self-teaching as well as teaching others and allowing others to use my
work (for money or not for money), as long as they use my rules (which
basically is: use it if you want, don't hide the details and give
something back, please.)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +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));
Sorry to continue this OT thread.
Jeff V. Merkey wrote:
>>
> "constructive" is a for profit model that sustains the hi tech
> industry. The current
> models have created a conduit for socialist disintegration of the
> american hi tech
> markets, loss of jobs, and have funnelled technology out of the
> country. Legal
> defense funds should be the biggest red flags of all. If this system
> you devised really
> works, why all the litigation? Why all the need for legal defense funds
> and patent
> infringement insurance? I've watched the entire market slowly collapse
> over the years
> as the result of the affect of the GPL on America's hi tech markets.
> It isn't working, and it isn't sustainable. non-profit and "temples" of
> GPL "religion"
> have evolved, with the leaders living in orgnaizations that subsist from
> handouts and
> donations. This movement has spawned a global attitude that has no
> respect
> for IP rights, and it's extended itself to no respect for human rights,
> or any other rights
> of the indivdual. That's the legacy this has left and the ultimate
> conclusion.
If you are totally against "socialist" licenses and the OSS movement,
what are you doing on this mailing list? I rather doubt many people here
share your views, and I seriously doubt that you are going to convince
anyone to change their viewpoints.
I suspect you are simply trolling, and I suppose I am taking the bait.
On Sat, 2005-12-10 at 17:43 +0100, Helge Hafting wrote:
> On Sat, Dec 10, 2005 at 12:06:54AM -0700, Jeff V. Merkey wrote:
[....]
> > donations. This movement has spawned a global attitude that has no
> > respect
> > for IP rights, and it's extended itself to no respect for human rights,
> > or any other rights
> > of the indivdual. That's the legacy this has left and the ultimate
> > conclusion.
>
> Less respect for IP rights - possibly. Perhaps that's a good thing though,
Not at all - *much* more respect for IP rights then ever before.
The problem is the raised awareness yields problems for old economy
corporations which rely on segmented markets with a relatively small
number of competitors (so that you can actually handle all the patent
and license issue[0]) and the rest are private folks which can't afford
going to court after $CORPORATION took some piece of "work" (i.e.
usually software) and sells it as part of a e.g. WLAN access point
without paying for it a cent.
> some of us thinks such rights are a bit overrated.
Bernd
[0]: And we all know the licenses and patent "fees" are not more than an
insurance for not getting sued by the issuer of the license.
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Sat, 2005-12-10 at 13:44 -0700, Jeff V. Merkey wrote:
[....]
> I'm married to a German citizen and I visit Germany for 3-4 week stints
Then you should know more about Europena culture than stated below:
> once a year. Last year I went to Aachen and Amsterdam on vacation.
> Every computer store I visited sold pirated copies of Windows XP and
> Microsoft Office and in Amsterdam people were selling copies on the
> street corners in the Artis District.
a) Tell MSFT about it, not us.
b) How many stores did you visit (in Amsterdam and in Aachen) and how
many of them are there?
c) I don't believe that the average store in .at, .de or .nl sells
pirated copies - this is as illegal here as in the US.
> The entire culture has absolutely no concept of IP rights and I was
> amazed at how open folks are there about piracy. If someone did that in
You should then learn more about the difference (both factual now and
historical) between authors rights as in .at now (in .de years ago) vs
copyright in GB/US.
> the US, they'd
> be in jail. I have lived in Germany, Italy, France, Spain, Crete, and
The question of jailing is "illegal vs illegal" - not a moral question.
> I spent about 2 years in the UK when I was a younger man, and I have a
> really
> good handle on the culture over there. Even the republic countries
> which have democratic governments are very much socialist in terms of the
> lifestyle and the governments, and the way people live, so it's no
"Socialist" or "communist"? These are in Europe two totally different
things (though they usually share the same political color).
And it is probably better than the alternatives.
> surprise the whole concept of free software and the GPL are so natural
> to the culture of Europe in general.
Which leads to the immediate question why the concept and license was
born in the US?
> I have been very dismayed at how FOSS has been used as a vehicle to
> promote anti-american attitudes into our own culture. It's sad. I have
Who uses it this way?
> lived in
> all these places and the only place where people have guaranteed rights
> as individuals and true freedom is America. I was in Germany in the late
"freedom" as "anarchy light"?
> 1970's and earlt 1980's when the Bater-Meinhoffs were killing Americans
The Bader-Meinhoff-Gang was a very extreme left wing terrorist group
which also killed e.g. German minister. Putting this as example for
Germany is like stating that Timothy McVeigh is an average US citizen.
> in the streets and the Grune-Gehfahr (Green Party) was having
Yes, the Green parties (at least in .at and AFAICT in .de) where a
"threat" to the old established parties since a new competitor came up
the horizon. And the tries several things (which you didn't mention) to
"fight" the new competition (without much success BTW).
> demonstrations burning effigies of Uncle Sam in the Hauptewache District
> in Frankfurt. This younger generation has no concept of what they are
Sorry, no details out of my head.
But apparently some radicals where there. If they were "invited" by the
demo organisers or even organised the demo themselves, is another
question which you should answer if you bring this as an example (or
should we hunt for similar events in the US and present them as
example?).
Or did they just came to make the action and get filmed by journalists
since a peaceful demonstration for cili rights and similar doesn't get
the headlines (and Pulitzer price?) - only the action.
> supporting or how bad things can get. It is the doom of men that they
> forget.
Should we now start the "which country got the worst radicals in which
century" listing?
[....]
> German culture. At any rate, Stallman needs to in the next GPL incorporate
> capitalist provisions which will allow FOSS to become a self sustaining
> model. The US markets are abandoning Linux as a commerical offering
You measure FOSS only on old models (and do not question these models).
Successful companies adapt to new models and who cares about the
remaining - and thus - unsuccessful ones?
Can it be more "capitalistic" (the word has probably at least as much
negative as positive meaning - and leftists probably don't agree even to
that).
> and Windows is continuing to get stronger and stronger. It's tough
Yes, MSFTs propaganda is apparently working in the US.
And it is a pity that no one is questioning the commercial methods and
strategy of such copmpanies (and no, the point is not about "Win*
software is better or worse than free software", we are here at a much
higher layer then technical facts since technical facts are completely
irrelevant regarding these commercial methods).
Bernd, shutting up again
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Sat, 2005-12-10 at 13:44 -0700, Jeff V. Merkey wrote:
> I'm married to a German citizen and I visit Germany for 3-4 week stints
> once a year. Last year I went to Aachen and Amsterdam on vacation.
> Every computer store I visited sold pirated copies of Windows XP and
> Microsoft Office and in Amsterdam people were selling copies on the
> street corners in the Artis District.
Did you find those people selling pirated windows copies on the street
before or after you visited a coffeeshop ?
> Jeff
- Erwin (who is Dutch and finds this story highly unlikely, unless there
is another Amsterdam in Asia somewhere).
* Jeff V. Merkey:
> I'm married to a German citizen and I visit Germany for 3-4 week stints
> once a year. Last year I went to Aachen and Amsterdam on vacation.
> Every computer store I visited sold pirated copies of Windows XP and
> Microsoft Office
Usually, they sell unlicensed OEM versions, which is fine because you
don't need a license to sell CDs once they've legally entered the EU.
If Microsoft itself distributed them to
Theoretically, the situation is the same in the U.S., but maybe
Microsoft has just better means to enforce the OEM/end user price
discrimination.
> Even the republic countries which have democratic governments are
> very much socialist in terms of the lifestyle and the governments,
> and the way people live, so it's no surprise the whole concept of
> free software and the GPL are so natural to the culture of Europe in
> general.
Maybe we are all socialist bastards (I doubt it, some of us are too
good at playing capitalist), but it's not our respect or disrespect of
IP laws that makes a difference. It's things like social security,
mandatory health insurance, etc., which are backed by actual law, not
very limited private-sector initiatives promoting copyleft schemes.
> I have been very dismayed at how FOSS has been used as a vehicle to
> promote anti-american attitudes into our own culture.
I don't see what's anti-American about free software. I assume that
being an American encompasses more than promoting a certain, very
narrowly scoped IP-related agenda. On the contrary, putting free
speech over IP protection is a very American thing, and most Europeans
do not value freedom of speech that high.
> It's sad. I have lived in all these places and the only place where
> people have guaranteed rights as individuals and true freedom is
> America.
I'm not sure if Mr Padilla agrees.
> I was in Germany in the late 1970's and earlt 1980's when the
> Bater-Meinhoffs were killing Americans in the streets and the
> Grune-Gehfahr (Green Party) was having demonstrations burning
> effigies of Uncle Sam in the Hauptewache District in Frankfurt.
> This younger generation has no concept of what they are supporting
> or how bad things can get. It is the doom of men that they forget.
*shrug* You have your own troubles with militias on the far right
(ignoring this WOT thing, which is beyond rational debate anyway).
> At any rate, Stallman needs to in the next GPL incorporate
> capitalist provisions which will allow FOSS to become a self
> sustaining model. The US markets are abandoning Linux as a
> commerical offering and Windows is continuing to get stronger and
> stronger.
So what? The Microsoft monopoly is only a temporary thing. Breaking
it shouldn't be the highest-ranked item on the FSF's agenda.
Eventually, Microsoft will commit a fatal mistake (or a series of
minor ones) which will seal its fate. Free software matters in the
long run, and short-term considerations shouldn't alter our course too
much.
* Erwin Rol:
> - Erwin (who is Dutch and finds this story highly unlikely, unless there
> is another Amsterdam in Asia somewhere).
IP enforcements varies quite a lot across Europe. I'm being told that
in the UK, the DVD situation is as worse as in some Asian countries
(i.e. you can buy illegal copies of current movies on flea markets).
I'm not aware of such a level of open unlicensed for-profit copying in
Germany (beyond the OEM debate). We have a long history of test
buyers at flea markets, and our culture is generally know for its
tendency to denounce. 8-)
The things we have is (a) professional software counterfeiting, (b)
small-scale movie swapping in firmly established rings for no
commercial gain (c) unlicensed movie distribution at professional
scale, and (d) P2P swapping. (a) and (d) are world-wide problems, and
(b) and (c) do not happen openly.
On Sat, Dec 10, 2005 at 01:44:38PM -0700, Jeff V. Merkey wrote:
[...]
> The entire culture has absolutely no concept of IP rights and I was
> amazed at how open folks are there about piracy. If someone did that in
> the US, they'd
> be in jail. I have lived in Germany, Italy, France, Spain, Crete, and
> I spent about 2 years in the UK when I was a younger man, and I have a
> really
> good handle on the culture over there. Even the republic countries
> which have democratic governments are very much socialist in terms of the
> lifestyle and the governments, and the way people live, so it's no
> surprise the whole concept of free software and the GPL are so natural
> to the
> culture of Europe in general.
>
Free sw and GPL is not about disrespect for intellectual property. We
want the GPL to be respected - as well as *enforced* when need be.
Free sw people tend to respect IP laws *more* than others - simply because
it is easier for us. We don't need to choose between piracy
or paying through the nose for an os or an office productivity suite,
whe have all of this and more for free - legally. Some of us take
pride in not pirating anything.
> I have been very dismayed at how FOSS has been used as a vehicle to
> promote anti-american attitudes into our own culture. It's sad. I have
> lived in
> all these places and the only place where people have guaranteed rights
> as individuals and true freedom is America.
"The only place!" Are you just trying to provoke? Or can you tell me
what freedoms and rights I lack? I live in a democracy, I vote, I
have freedom of speech and press, I can leave if I'm not satisified anyway.
I also have the freedom of going wherever I want, any time of day, without risk.
If you wonder why some people have an anti-american attitude, try listening to
what they say. It is usually about foreign policies, environmental problems,
or the actions of large America-based multinational corporations.
> I was in Germany in the late
> 1970's and earlt 1980's when the Bater-Meinhoffs were killing Americans
Criminals, which were eventually caught. Seems to me America has enough
of their own criminals killing americans?
> in the streets and the Grune-Gehfahr (Green Party) was having
> demonstrations burning effigies of Uncle Sam in the Hauptewache District
Excercising their freedom of speech? It'd be sad if they couldn't.
If you love freedom of speech, then you have to put up with people
saying all sorts of things. Even things you don't like.
Helge Hafting
At any rate, Stallman needs to in the next GPL incorporate
capitalist provisions which will allow FOSS to become a self sustaining
model.
The GNU General Public License was developed in the US, and follows
the principles that the US proclaims, which include doing business.
That is how I came to the conclusion that selling copies is one of the
things that free software must permit for every user.
However, freedom and community are more fundamental than economics.
The primary goal of the GNU GPL is to defend the freedom of all users,
particularly the freedom to cooperate. Business questions are
secondary.
Fortunately, we need not to do anything to enable free software to
"become self-sustaining", because it is already sustaining itself just
fine. If and when we see real problems, rather than speculation
about problems, we might have a reason to try to solve them.
But we could not make radical changes in the GNU GPL, even if we
wanted to. It would violate the commitment stated in section 9 of the
Luke-Jr wrote:
>On Thursday 08 December 2005 08:14, you wrote:
>
>
>>Luke-Jr wrote:
>>
>>
>>>The ATi Radeon 9200 works fine...
>>>
>>>
>>Lucky you. Mine doesn't. Using 3D on it makes the machine unstable,
>>and the performance is apalling too.
>>
>>
>
>Hm, well I don't have DRI enabled on my primary desktop... just on a second
>one dedicated to gaming. Not sure if that makes any difference...
>
>
>
>>So I'm looking for something else - a radeon 7000 is cheap . . .
>>
>>
>
>That'll outperform a 9200? ;)
>
>
Actually yes, because something is clearly wrong.
The pci 9200 SE can run tuxracer at 640x480 - not smooth
but playable until it locks the machine after a few minutes.
The AGP matrox G550 is better, it runs 1280x1024 tuxracer
with a unknown but noticeable higher framerate. According to
people I talked to before, the 9200SE is supposed to outperform
this, even with a pci bus. But it is not even close and I don't
bother running 3D on it any more due to the hanging.
>
>
>>And don't say that a crash during a 3D game isn't important -
>>
>>
>
>A system crash? Worst I've ever seen was a X crash, back before I got my X
>configs good. If you mean a game crash, I wouldn't know... half the time it'd
>probably be my fault. ;)
>
>
I don't mind a game crash - I can always find another game. But it will
at least screw up that card so bad that I need a reboot to get
a working xserver running on that display. Typically, the
crash ends with a 99% cpu loop in the kernel, a blocked display,
and perhaps the other xserver gets in trouble too.
>
>
>>it is a two-user machine and the other user is not amused when this happens.
>>
>>
>
>Maybe he would be if it showed a BSOD? :p
>
>
Nope. A windows crash isn't any "better", and they are used to
the linux-level of stability anyway.
Helge Hafting
Nix wrote:
>On 8 Dec 2005, Helge Hafting said:
>
>
>>Lucky you. Mine doesn't. Using 3D on it makes the machine unstable,
>>and the performance is apalling too. So I'm looking for something
>>else - a radeon 7000 is cheap . . .
>>
>>
>
>Backtraces? X version? X config?
>
>
6.8.2 from debian testing
>(FWIW, my AGP Radeon 9250 works flawlessly as of X.org 6.8.99.901.
>6.8.2 and earlier were wobbly.)
>
>
Time to try again then, I guess. Nice to know that something
is happening with the newer servers.
>Whether performance is appalling I don't know because I don't have any
>standards to measure it by, but I get 2000fps or thereabouts out of
>glxgears. That's a hell of a lot better than the 64fps I got out of
>my earlier mach64 :)
>
>
I have never seen glxgears go into the thousands. The card is
obviously not supposed to be like this - either card or driver is
faulty. Most people don't seem to have performance problems,
with their radeons, so perhaps my card is a bit different and
don't fit the driver.
Helge Hafting
On Mon, 2005-12-12 at 00:19 +0100, Helge Hafting wrote:
> On Sat, Dec 10, 2005 at 01:44:38PM -0700, Jeff V. Merkey wrote:
[...]
> > I have been very dismayed at how FOSS has been used as a vehicle to
> > promote anti-american attitudes into our own culture. It's sad. I have
> > lived in
> > all these places and the only place where people have guaranteed rights
> > as individuals and true freedom is America.
>
> "The only place!" Are you just trying to provoke? Or can you tell me
Obviously.
> what freedoms and rights I lack? I live in a democracy, I vote, I
> have freedom of speech and press, I can leave if I'm not satisified anyway.
> I also have the freedom of going wherever I want, any time of day, without risk.
The last sentence needs to be stressed.
> If you wonder why some people have an anti-american attitude, try listening to
> what they say. It is usually about foreign policies, environmental problems,
> or the actions of large America-based multinational corporations.
Or the arrogance to even only think that the whole world must act as the
US administration wishes.
> > I was in Germany in the late
> > 1970's and earlt 1980's when the Bater-Meinhoffs were killing Americans
>
> Criminals, which were eventually caught. Seems to me America has enough
> of their own criminals killing americans?
Remember the last 3-5 years IIRC about typical tourist robberies in
Florida?
Probably the US don't want any visitors from Europe anymore (and with
the current list of to-be-delivered data before one may enter the so
called "land of the free" I certainly wait for that period to get over).
> > in the streets and the Grune-Gehfahr (Green Party) was having
> > demonstrations burning effigies of Uncle Sam in the Hauptewache District
>
> Excercising their freedom of speech? It'd be sad if they couldn't.
> If you love freedom of speech, then you have to put up with people
> saying all sorts of things. Even things you don't like.
The so called "freedom of speech" in the so called "land of the free"
can be seen if agents of 3-letter agencies walk into universities to
"avoid" talks on certain topics.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Wed, Dec 07, 2005 at 04:06:44PM -0500, Salyzyn, Mark wrote:
> Don't you mean 'leaving it political', kernel.org is hardly neutral.
> Neutrality is usually handled by a single trusted entity such as a Judge
> ;-/ and not by a committee or a democracy.
;)
kernel.org is better than a dot com website, that's what I meant by
neutral.
> This issue is hardly black-and-white. The Hardware Vendors are hardly
> monolithic. Markets are not always just horizontal, or just vertical.
>
> For instance, there are reasons, somewhat outside the control of the
> Hardware Vendor, for binary drivers. Often, in the hopes of achieving
> standards compliance, Hardware vendors are cornered by legalities over
> the copyright associated with those standards that ties their hands
> either from releasing interface documentation or from releasing source
> code. Yet all these vendors would be overjoyed to have Linux drivers for
> their Hardware in order to increase the sales of their products.
A standard that ties the hands and requires not releasing the source
should be obsoleted by a new one that is based on open information and
open source.
I understand the tainting problem, but for the future you really should
create a new standard whose objective is "interoperability" and not
to tie hands.
Note that even as programmers it's very easy to be tainted, and it
requires skills to avoid it. Companies have the same problem, if they
accept the tainting they may have to pay for the conseguences eventually
(i.e. presumably lower sale of their products).
So if something this should be a lesson to remind.
Binary only drivers in such a tainting legal condition sounds reasonable
for the current generation of hardware (accepting the perhaps
unavoidable lower sales), but for new hardware you must find a way out
of it. Found a new standard body, ask your competitors to join it and
see what is their reaction, create sane legalities (like NDA with
expiration after which GPL source can be released) or similar better
choices.
If you did a mistake it's not me who has the duty to help resolving it.
I can only suggest you not to do the same mistake again and again, while
the "standard that ties the hands" is banking on it.
> The users are overjoyed when they have a wide variety of useful hardware
> products to select. The market is overjoyed when there is competition.
>
> Linux gains popularity when the users are placated, increasing the
> interest in funding projects, engineers and organizations associated
> with Linux. Call this trickle down economics if you want.
Sure.
> Locking out the Hardware is counterproductive for all to varying degrees
> (I agree that locking out the details is also counterproductive, do not
> misconstrue my argument). The current state of affairs where binary-only
> drivers are grudgingly handled and politically sensitive offers the
> balance that urges these Hardware Vendors to pursue open source variants
> or to move initial binary-only offerings eventually in the future
> towards an open-source solution when conditions change to permit it.
> Thus without hurting the OS, the users or the Hardware vendors; with the
> timely delivery of advanced hardware. Without an open door, that piece
> of hardware, or the market window, will pass Linux by. Despise the
> results, by all means. Plan to protect copyrights that binaries may
> violate, that is a noble duty. Remain forever vigilant against
> encroachment. But please stop planning a revolt, locking the door,
> constructing conspiracy theories or creating scenarios of utter
> destruction and mayhem.
Even today you can check when a driver has an open source driver. I do,
it takes time, sometime I have to annoy to the developers to be sure I
read the pciids correctly. If there was a way to find it more easily it
would be helpful and hopefully it will allow more people to choose
hardware with open source drivers.
I don't agree with the revolt of breaking all drivers and I think
reversing that patch was the right thing to do (because doing so all
users would suffer), I only want your revenue to shrink over time
in order to give a business reason to care about open source drivers.
Technical reasons are always secondary to business reasons.
> Sleep with the enemy when you have mutual gain (keep a loaded gun under
> the pillow to keep him honest ;-> ).
;)
On Mon, 2005-12-12 at 14:45 +0100, Bernd Petrovitsch wrote:
> > If you wonder why some people have an anti-american attitude, try
> listening to
> > what they say. It is usually about foreign policies, environmental
> problems,
> > or the actions of large America-based multinational corporations.
>
> Or the arrogance to even only think that the whole world must act as
> the
> US administration wishes.
>
Almost as bad as the Jeff Merkeys and George W Bushes of the US, are
Europeans who assume all or even most Americans are a Merkey or a GWB.
Lee
On Mon, 2005-12-12 at 10:34 -0500, Lee Revell wrote:
> On Mon, 2005-12-12 at 14:45 +0100, Bernd Petrovitsch wrote:
> > > If you wonder why some people have an anti-american attitude, try
> > listening to
> > > what they say. It is usually about foreign policies, environmental
> > problems,
> > > or the actions of large America-based multinational corporations.
> >
> > Or the arrogance to even only think that the whole world must act as
> > the
> > US administration wishes.
>
> Almost as bad as the Jeff Merkeys and George W Bushes of the US, are
> Europeans who assume all or even most Americans are a Merkey or a GWB.
ACK.
I didn't want to (or actually did[0]) say that all or most or many are
that way.
But at least a few do nevertheless - and if it's only a clique in
Washington with a few people in Brussels.
Bernd
[0]: or wanted to. Sorry, if you or anyone had the wrong impression.
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Sul, 2005-12-11 at 17:38 +0100, Florian Weimer wrote:
> IP enforcements varies quite a lot across Europe. I'm being told that
> in the UK, the DVD situation is as worse as in some Asian countries
> (i.e. you can buy illegal copies of current movies on flea markets).
It isnt quite as bad. However there is a lack of interest in enforcement
from local government who have better things to spend their money on,
and also because the IP rules have been abused so much in the UK
including to charge rip off prices that local goverment serves voters
who are likely to vote against not for any local government
representative who decides to go on an anti-piracy crusade. I've heard
people in the trading standards area (which tackles counterfeiting)
who've been told by their elected "masters" to concentrate solely on the
other areas of their duties like product safety if they want to have an
operating budget next year.
Unfortuantely the bad behaviour of the big media companies that
triggered much of this gets reflected back at everything even
disinterest in GPL violation enforcment or large scale violations by big
business.
Alan
David S. Miller wrote:
>From: Gerrit Huizenga <[email protected]>
>Date: Wed, 07 Dec 2005 13:30:18 -0800
>
>
>
>>OSDL.org has no desire to advocate binary drivers in any way and I
>>don't expect that they will do anything to educate or influence their
>>members or the global vendor/IHV/developer communities to use binary
>>drivers. Further, I expect they will do exactly the opposite, in
>>particular, educate members, developers, IHV's on how to deploy
>>open source drivers and the benefits of doing so.
>>
>>
>
>You might want to read the following before stating such
>things:
>
> http://www.kroah.com/log/2005/11/03/#osdl_gkai
>
>Thanks.
>
>
Did you also read Greg's follow up posting:
http://www.kroah.com/log/2005/11/07#osdl_gkai2
where he says that he was wrong about OSDL pushing for binary drivers?
(Not that the update was a glowing review of OSDL in general ;-))
I agree with Gerrit - from where I sit on OSDL's DCL tech forum, I have
not seen any push for binary drivers and have seen consistent pressure
pushing towards GPL'ed only drivers.
That position is strongly spelled out in the OSDL sponsored open drivers
page as well.
Regards,
ric
On Mon, 12 Dec 2005, Helge Hafting said:
> Nix wrote:
>>(FWIW, my AGP Radeon 9250 works flawlessly as of X.org 6.8.99.901.
>>6.8.2 and earlier were wobbly.)
>>
>>
> Time to try again then, I guess. Nice to know that something
> is happening with the newer servers.
Yep :) modular X is on its way...
>>Whether performance is appalling I don't know because I don't have any
>>standards to measure it by, but I get 2000fps or thereabouts out of
>>glxgears. That's a hell of a lot better than the 64fps I got out of
>>my earlier mach64 :)
Hm, retrying I see 500fps. I wonder what I was doing differently
earlier... :/
> I have never seen glxgears go into the thousands. The card is
> obviously not supposed to be like this - either card or driver is
> faulty.
FWIW when glxgears is running, X consumes about 2% more CPU time
than normal: it's almost impossible to detect.
It sounds to me almost like direct rendering is disabled, which will of
course have catastropic effects on performance. What does glxinfo say?
FWIW, on my box it says
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier,
GLX_SGIX_fbconfig
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 20041207 AGP 4x x86/MMX+/3DNow!+/SSE TCL
OpenGL version string: 1.3 Mesa 6.4
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture,
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram,
GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color,
GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos,
GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle,
GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix,
GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x23 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x24 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x25 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x26 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x27 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x28 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x29 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x2a 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x2b 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x2c 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x2d 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x2e 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
0x2f 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x30 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x31 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x32 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
> Most people don't seem to have performance problems,
> with their radeons, so perhaps my card is a bit different and
> don't fit the driver.
The X startup log can also be useful here. I've noticed that if you
get the AGPMode wrong in either direction, the results can be
catastrophic: if it's too low the card is terribly slow and if it's
too high you soon get the X server hanging as it waits forever for
the card to respond to something it hasn't had time to receive (or
something like that, anyway).
--
`Don't confuse the shark with the remoras.' --- Rob Landley
On Wed, 7 Dec 2005, Jesse Barnes wrote:
> Now, who's in a position to make this happen? Maybe Linux International?
> (I think Maddog mentioned something like this at a Kernel Summit a few
> years ago.)
I don't remember tha name of the orginization, but the group that Linus
setup to enforce the trademark would be perfect for this. licensing a
'runs with linux' sticker would be exactly the type of thing the trademark
is designed to protect.
I think it's obvious that anything with in-kernel drivers would qualify
(new versions of hardware may need driver updates before they could use
the sticker) and if Linus could define a suitable level of documentation
of the hardware I think that that should very quickly lead to an in-kernel
driver (and given hardware lead time it may be reasonable to allow the
sticker based on the release of documentation)
I would not like to see it for external drivers, especially ones that work
only with specific kernels from specific distros. even if the source is
available, unless it can be merged into the kernel it's going to be a
ongoing problem (although the open-source-but-external driver code could
end up being deemed 'sufficiant documentation')
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
On Mon, 12 Dec 2005, David Lang wrote:
> On Wed, 7 Dec 2005, Jesse Barnes wrote:
>
> > Now, who's in a position to make this happen? Maybe Linux International?
> > (I think Maddog mentioned something like this at a Kernel Summit a few
> > years ago.)
>
> I don't remember tha name of the orginization, but the group that Linus
> setup to enforce the trademark would be perfect for this. licensing a
> 'runs with linux' sticker would be exactly the type of thing the trademark
> is designed to protect.
That's the Linux Mark Institute:
http://www.linuxmark.org/
> I think it's obvious that anything with in-kernel drivers would qualify
> (new versions of hardware may need driver updates before they could use
> the sticker) and if Linus could define a suitable level of documentation
> of the hardware I think that that should very quickly lead to an in-kernel
> driver (and given hardware lead time it may be reasonable to allow the
> sticker based on the release of documentation)
>
> I would not like to see it for external drivers, especially ones that work
> only with specific kernels from specific distros. even if the source is
> available, unless it can be merged into the kernel it's going to be a
> ongoing problem (although the open-source-but-external driver code could
> end up being deemed 'sufficiant documentation')
>
> David Lang
--
~Randy
On Tuesday 06 December 2005 09:17, Pavel Machek wrote:
> Actually, yes it does cost them. If you refuse to buy $2000 notebook,
> because its 3D graphics card ($100) is not supported properly... well
> notebook vendor is going to put pressure on graphics card vendor.
One thing about understanding large companies: if they can't measure it, it
doesn't exist.
And yes, this sometimes leads to really stupid behavior. I remember an old
businessweek article from 1998 about how Pizza Hut responded to the
encroachment of Papa Johns by measuring salami slices with a micrometer and
timing how long it took the sauce to flow down an incline. The fundamental
problem was, a large chunk of their customer base preferred the other guy's
pizza, but they couldn't _measure_ that. Responding to concerns about
aesthetics and usability by focusing on "six nines" of reliability is a
common mistake. Because it's easy to _measure_. The squeaky wheel, and all
that...
So if they don't know _why_ you refused to buy the $2000 notebook (and telling
a salesbeing with no way to propogate it up the chain of command doesn't
help), then it doesn't mean anything to them. For all they know you didn't
like the color, the CPU fan was too loud, the battery didn't last long
enough, the touchpad was uncomfortable...
Yes, you can write letters to them to inform them of your concerns. But what
they care about is money, and correlating your concerns to aggregate sales
figures is hand waving at best.
> And you don't have to be Linux user to refuse closed hardware. Having
> option in future is always good.x
If Linux desktop users are less than 5% of the laptop buying population, a
more effective technique would be to focus purchases on small companies that
_do_ provide things we can use. Trimming $25 million off of a $1 billion
market niche is a lot less noticeable than creating and sustaining a new $25
million market niche. (That's something that's easy to measure. Here's $x
dollars that could go to us, but doesn't.)
Of course getting a $1 billion company excited over a $25 million niche...
You might want to read "the innovator's dilemma", by clayton christensen.
_Marvelous_ book...
> Pavel
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
> t best.
>
> > And you don't have to be Linux user to refuse closed hardware. Having
> > option in future is always good.x
>
> If Linux desktop users are less than 5% of the laptop buying population, a
> more effective technique would be to focus purchases on small companies that
> _do_ provide things we can use.
however, in areas where margins are really thin, like consumer PC
hardware, 5% of revenue is the difference between a loss and a profit.
And if we can have official 'works well' and 'don't buy' lists, the PR
around that can help make that impact, especially if people who don't
run linux yet but might in the future also start to pay attention to
this list.
Nix wrote:
[...]
>FWIW when glxgears is running, X consumes about 2% more CPU time
>than normal: it's almost impossible to detect.
>
>
Sure - the load is low - and so is performance. As if the machine
isn't really trying - perhaps the driver is waiting when there is
no need to wait.
>It sounds to me almost like direct rendering is disabled, which will of
>course have catastropic effects on performance. What does glxinfo say?
>
>
No. While it is bad, it is not as bad as sw rendering. Tuxracer
with sw rendering is unbearable - 2 seconds per frame or so!
>> Most people don't seem to have performance problems,
>>with their radeons, so perhaps my card is a bit different and
>>don't fit the driver.
>>
>>
>
>The X startup log can also be useful here. I've noticed that if you
>get the AGPMode wrong in either direction, the results can be
>catastrophic: if it's too low the card is terribly slow and if it's
>too high you soon get the X server hanging as it waits forever for
>the card to respond to something it hasn't had time to receive (or
>something like that, anyway).
>
>
Well, there is no AGPmode for a PCI card, is there?
Helge Hafting
On Monday 12 December 2005 17:52, Ric Wheeler wrote:
>
> Did you also read Greg's follow up posting:
>
> http://www.kroah.com/log/2005/11/07#osdl_gkai2
>
> where he says that he was wrong about OSDL pushing for binary drivers?
> (Not that the update was a glowing review of OSDL in general ;-))
>
> I agree with Gerrit - from where I sit on OSDL's DCL tech forum, I have
> not seen any push for binary drivers and have seen consistent pressure
> pushing towards GPL'ed only drivers.
>
> That position is strongly spelled out in the OSDL sponsored open drivers
> page as well.
>
Useful. Thanks for pointing it out.
Andrew Walrond
Salyzyn, Mark wrote:
>For instance, there are reasons, somewhat outside the control of the
>Hardware Vendor, for binary drivers. Often, in the hopes of achieving
>standards compliance, Hardware vendors are cornered by legalities over
>the copyright associated with those standards that ties their hands
>either from releasing interface documentation or from releasing source
>code. Yet all these vendors would be overjoyed to have Linux drivers for
>their Hardware in order to increase the sales of their products.
>
>
Uh, a copyrighted standard? They are trying to live up to a secret
standard, one they cannot publish?
Don't sound like a standard to me - a standard is something known,
that is the purpose of standardization.
This sounds like "we standardized the voltage for household lamps, but
we won't tell if it is 110V, 220V or something completely different."
I really hope I misunderstood this.
Standards compliance should never get in the way of open source.
Sure - if the owner modifies the source, then the thing may no longer
comply with the standard. In some cases even illegal or dangerous.
But in that case, it is the fault of the owner, not the vendor. The vendor
can simply say that anyone changing the (distributed) source should get
their own certification.
Helge Hafting
On Tuesday 13 December 2005 01:56, Arjan van de Ven wrote:
> > t best.
> >
> > > And you don't have to be Linux user to refuse closed hardware. Having
> > > option in future is always good.x
> >
> > If Linux desktop users are less than 5% of the laptop buying population,
> > a more effective technique would be to focus purchases on small companies
> > that _do_ provide things we can use.
>
> however, in areas where margins are really thin, like consumer PC
> hardware, 5% of revenue is the difference between a loss and a profit.
With thin margins, 5% of volume isn't the same thing as 5% revenue. It may be
5% of _profit_, but unless fixed costs being amortized are a dominant factor
the whole point of thin margins is that it costs you almost as much to
produce as you sell it for.
More importantly, if they can't trace the loss back to what made the
difference, then it doesn't matter. And very few things at this level have
only one cause. When less than 1% of the planet's population ever bought the
product in the first place, a few more not buying it really doesn't register
easily. Making a change may net you $5 million and cost you $10 million
elsewhere. (Hence boycotts either not being noticed or being attributed to
tidal forces and brownian motion. And most of them simply _aren't_ big
enough to make a difference. There are groups out that regularly claim
responsibility for the sun coming up. Decision makers learn to filter this
stuff out.)
Now large customers that purchase lots of stuff in blocks can easily get their
needs noticed at the negotiating table. "Not supporting X will cost your
company this $$$ million contract". They don't have to find this out via
data mining or surveys, there's a big check with explicit strings attached.
> And if we can have official 'works well' and 'don't buy' lists, the PR
> around that can help make that impact, especially if people who don't
> run linux yet but might in the future also start to pay attention to
> this list.
Bad publicity, and good publicity for competitors, is something that can get
noticed, yes. But being able to translate it into actual dollar values is
noticeably more effective. Showing an $x dollar market that wouldn't exist
without Linux-motivated purchases is one way to do that.
Expecting windows users to make purchasing decisions based on a Linux
compatability list goes a bit beyond wishful thinking, though.
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
On Tue, 2005-12-13 at 09:25 +0100, Helge Hafting wrote:
> Salyzyn, Mark wrote:
[...]
> >For instance, there are reasons, somewhat outside the control of the
> >Hardware Vendor, for binary drivers. Often, in the hopes of achieving
Even if this is the case it is the decision of the hardware vendor to go
that way. The underlying organzation may be equally guilty but that
doens't make the hardware vendor innocent - simply he plays the same
game just with an excuse.
> >standards compliance, Hardware vendors are cornered by legalities over
> >the copyright associated with those standards that ties their hands
> >either from releasing interface documentation or from releasing source
> >code. Yet all these vendors would be overjoyed to have Linux drivers for
> >their Hardware in order to increase the sales of their products.
Then it is up to them to do something.
> Uh, a copyrighted standard? They are trying to live up to a secret
> standard, one they cannot publish?
> Don't sound like a standard to me - a standard is something known,
> that is the purpose of standardization.
> This sounds like "we standardized the voltage for household lamps, but
> we won't tell if it is 110V, 220V or something completely different."
> I really hope I misunderstood this.
s/copyright/patent/ then you will get it probably more right.
Given (beautiful and readable) source code, a patent infringement is
probably much easier to proove than with disassembled output of gcc-4.x.
> Standards compliance should never get in the way of open source.
> Sure - if the owner modifies the source, then the thing may no longer
> comply with the standard. In some cases even illegal or dangerous.
Propriatory vendors (the larger they are, the more it makes sense) do
that all the time without telling their customers/users (usually
somewhere hidden within some tools which produce not compliant garbage)
and the strategy is called "customer lockin".
> But in that case, it is the fault of the owner, not the vendor. The vendor
> can simply say that anyone changing the (distributed) source should get
> their own certification.
At least for (certified) ISDN stacks any change on the source (including
trivial bug fixes) invalidates any official certification AFAIK.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On 13 Dec 2005, at 09:07, Rob Landley wrote:
> On Tuesday 13 December 2005 01:56, Arjan van de Ven wrote:
>>> t best.
>>>
>>>> And you don't have to be Linux user to refuse closed hardware.
>>>> Having
>>>> option in future is always good.x
>>>
>>> If Linux desktop users are less than 5% of the laptop buying
>>> population,
>>> a more effective technique would be to focus purchases on small
>>> companies
>>> that _do_ provide things we can use.
>>
>> however, in areas where margins are really thin, like consumer PC
>> hardware, 5% of revenue is the difference between a loss and a
>> profit.
>
> With thin margins, 5% of volume isn't the same thing as 5%
> revenue. It may be
> 5% of _profit_, but unless fixed costs being amortized are a
> dominant factor
> the whole point of thin margins is that it costs you almost as much to
> produce as you sell it for.
>
> More importantly, if they can't trace the loss back to what made the
> difference, then it doesn't matter. And very few things at this
> level have
> only one cause. When less than 1% of the planet's population ever
> bought the
> product in the first place, a few more not buying it really doesn't
> register
> easily. Making a change may net you $5 million and cost you $10
> million
> elsewhere. (Hence boycotts either not being noticed or being
> attributed to
> tidal forces and brownian motion. And most of them simply _aren't_
> big
> enough to make a difference. There are groups out that regularly
> claim
> responsibility for the sun coming up. Decision makers learn to
> filter this
> stuff out.)
>
> Now large customers that purchase lots of stuff in blocks can
> easily get their
> needs noticed at the negotiating table. "Not supporting X will
> cost your
> company this $$$ million contract". They don't have to find this
> out via
> data mining or surveys, there's a big check with explicit strings
> attached.
>
>> And if we can have official 'works well' and 'don't buy' lists,
>> the PR
>> around that can help make that impact, especially if people who don't
>> run linux yet but might in the future also start to pay attention to
>> this list.
>
> Bad publicity, and good publicity for competitors, is something
> that can get
> noticed, yes. But being able to translate it into actual dollar
> values is
> noticeably more effective. Showing an $x dollar market that
> wouldn't exist
> without Linux-motivated purchases is one way to do that.
Hence the justification for a Linux logo. As I said in another thread
"Linux Hardware Quality Labs":
"The primary motivation for this is that it leverages the individual
power of each purchaser (of a system or individual piece of hardware)
be they a consumer, SME, system builder, tier 1 or 2 PC manufacturer,
government dept., or Linux distro company, into a single point of
pressure that can be applied to OEMs to ensure that they provide open
source drivers."
regards,
Felix
On Maw, 2005-12-13 at 10:44 +0100, Bernd Petrovitsch wrote:
> At least for (certified) ISDN stacks any change on the source (including
> trivial bug fixes) invalidates any official certification AFAIK
This was abolished in most of the countries that had such rules. Several
reasons including competition but above all the national security card.
If a bad software stack could take out the phone exchange so could
someone planning a bomb attack who wanted to kill phone service.
Except in .de it seems the telco's found it hard to justify after that
issue was raised
Alan
On Tuesday 13 December 2005 03:25, Helge Hafting wrote:
>Salyzyn, Mark wrote:
>>For instance, there are reasons, somewhat outside the control of the
>>Hardware Vendor, for binary drivers. Often, in the hopes of
>> achieving standards compliance, Hardware vendors are cornered by
>> legalities over the copyright associated with those standards that
>> ties their hands either from releasing interface documentation or
>> from releasing source code. Yet all these vendors would be
>> overjoyed to have Linux drivers for their Hardware in order to
>> increase the sales of their products.
>
>Uh, a copyrighted standard? They are trying to live up to a secret
>standard, one they cannot publish?
>Don't sound like a standard to me - a standard is something known,
>that is the purpose of standardization.
>This sounds like "we standardized the voltage for household lamps,
> but we won't tell if it is 110V, 220V or something completely
> different." I really hope I misunderstood this.
Standards bodies typically get their supporting income from the sale of
the standard specification in fancy printed pdf's. As its a small
market, the only way to survive is the highway robbery model where a
copy is maybe over $1000 USD. Its a bad model for the FOSS crowd as
they may not have the bucks to spend on a real copy. Generally, their
copyrights are VERY well enforced by their shysters which compounds
the issue.
All of our preaching is to the choir, as the standards bodies could
care less, if you want a copy, pony up. Thats life, unforch.
>Standards compliance should never get in the way of open source.
>Sure - if the owner modifies the source, then the thing may no longer
>comply with the standard. In some cases even illegal or dangerous.
>But in that case, it is the fault of the owner, not the vendor. The
> vendor can simply say that anyone changing the (distributed) source
> should get their own certification.
>
>Helge Hafting
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <[email protected]> which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
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.
Hi!
> >>If even some "Linux-friendly" hardware manufacturers barely cooperate
> >>with the Linux comminuty now what makes you think this would work?
> >>
> >>
> >
> >Nothing in life is guaranteed. But at the very least, I think it would
> >be a good step towards improving the Linux end user experience. Instead
> >of the unclear mess we have now (Is it supported? Check with your
> >vendor!), we would be able to say "Look for the Linux Certified logo".
> >Combine that with a standard format for source code driver disks, and
> >it would be a good step in the right direction.
> >
> >
> >
> The problem as I see it:
>
> A hardware vendor hires someone to write a driver. The driver is
> completed and submitted and finally makes it into the kernel. It's
> fully GPL and everyone is happy. The hardware gets a "Native Linux
> Support" logo. The card goes out of favor and no one is interested in
> maintaining the driver, it is marked obsolete and finally removed from
> the kernel. ...the logo still suggests the hardware will work.
And? There's no problem. You still have GPLed driver, that is
reasonably nice (it was in kernel at one point), so you just fix that.
Don't overcomplicate this.
Pavel
--
Thanks, Sharp!
On Tue, 13 Dec 2005, Helge Hafting mused:
> Nix wrote:
> [...]
>
>>FWIW when glxgears is running, X consumes about 2% more CPU time
>>than normal: it's almost impossible to detect.
>>
> Sure - the load is low - and so is performance. As if the machine
> isn't really trying - perhaps the driver is waiting when there is
> no need to wait.
If it gets it wrong X deadlocks, but yes, it does seem... odd.
>>It sounds to me almost like direct rendering is disabled, which will of
>>course have catastropic effects on performance. What does glxinfo say?
>>
> No. While it is bad, it is not as bad as sw rendering. Tuxracer
> with sw rendering is unbearable - 2 seconds per frame or so!
Ah, yes, tuxracer does have fairly high demands, doesn't it.
[delay]
I just installed the latest ppracer alpha (the closest out there to
tuxracer)
OK, I see 25-40fps with that, with DRI. If I turn on stencil buffering
it gets unbearable, but that's just asking too much of the card I think.
>>The X startup log can also be useful here. I've noticed that if you
>>get the AGPMode wrong in either direction, the results can be
>>catastrophic: if it's too low the card is terribly slow and if it's
>>too high you soon get the X server hanging as it waits forever for
>>the card to respond to something it hasn't had time to receive (or
>>something like that, anyway).
>>
> Well, there is no AGPmode for a PCI card, is there?
Ah, this is a pure-PCI 9250, is it? (I wasn't aware you could get hold
of those anymore... I think X supports them, but textured stuff is
necessarily going to be slower.)
--
`I must caution that dipping fingers into molten lead
presents several serious dangers.' --- Jearl Walker
There was a recent lawsuit, settled before judgement, in the USA over
the ownership of a GPL program that implemented a copyrighted standard.
The name of the case was Drew Technologies v. Society of Automotive
Engineers.
On Tue, 2005-12-13 at 17:59 -0500, [email protected] wrote:
> There was a recent lawsuit, settled before judgement, in the USA over
> the ownership of a GPL program that implemented a copyrighted standard.
The document (as such) containing the standard is copyrighted.
But this has nothing to do with: "I read the standard somewhere somehow
and implement it in some piece of GPLed software."
What do you exactly really mean?
> The name of the case was Drew Technologies v. Society of Automotive
> Engineers.
URL?
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Drew Technologies v. Society of Automotive Engineers
A GPL Win in Michigan - DrewTech v. SAE
http://www.groklaw.net/article.php?story=20050225223848129
xboom
Nix wrote:
>>No. While it is bad, it is not as bad as sw rendering. Tuxracer
>>with sw rendering is unbearable - 2 seconds per frame or so!
>>
>>
>
>Ah, yes, tuxracer does have fairly high demands, doesn't it.
>
>[delay]
>
>I just installed the latest ppracer alpha (the closest out there to
>tuxracer)
>
>OK, I see 25-40fps with that, with DRI. If I turn on stencil buffering
>it gets unbearable, but that's just asking too much of the card I think
>
At what resolution? 25fps is nice enough - as good as movies.
I no longer remember exactly, but I had to use 640x480 to get
anything close to playable - lucky to get 10 or so fps.
I have been in touch with DRI developers before - this card isn't
supposed to be "great", but it _is_ supposed to beat the
matrox G550 which it isn't even close to. The matrox has its
own problems - it sometimes looses the font in this game, and
the fps reporting is wrong. But the game is smooth at 1280x1024 . . .
>>Well, there is no AGPmode for a PCI card, is there?
>>
>>
>
>Ah, this is a pure-PCI 9250, is it? (I wasn't aware you could get hold
>of those anymore... I think X supports them, but textured stuff is
>necessarily going to be slower.)
>
>
Yes - it is a pure pci thing, because the AGP slot is taken by the matrox.
As for textured stuff being slower, I was under the impression that tuxracer
use something like a total of 3 different textures, that surely should fit
in the 64MB of onboard memory? Now ppracer have more textures, but
old tuxracer levels don't actually use them.
Getting drawing commands into the card will of course also be slower
with PCI, but 'I hope that is a small part of the work.
Helge Hafting
Gene Heskett wrote:
>On Tuesday 13 December 2005 03:25, Helge Hafting wrote:
>
>
>>Salyzyn, Mark wrote:
>>
>>
>>>For instance, there are reasons, somewhat outside the control of the
>>>Hardware Vendor, for binary drivers. Often, in the hopes of
>>>achieving standards compliance, Hardware vendors are cornered by
>>>legalities over the copyright associated with those standards that
>>>ties their hands either from releasing interface documentation or
>>>from releasing source code. Yet all these vendors would be
>>>overjoyed to have Linux drivers for their Hardware in order to
>>>increase the sales of their products.
>>>
>>>
>>Uh, a copyrighted standard? They are trying to live up to a secret
>>standard, one they cannot publish?
>>Don't sound like a standard to me - a standard is something known,
>>that is the purpose of standardization.
>>This sounds like "we standardized the voltage for household lamps,
>>but we won't tell if it is 110V, 220V or something completely
>>different." I really hope I misunderstood this.
>>
>>
>
>Standards bodies typically get their supporting income from the sale of
>the standard specification in fancy printed pdf's. As its a small
>market, the only way to survive is the highway robbery model where a
>copy is maybe over $1000 USD. Its a bad model for the FOSS crowd as
>they may not have the bucks to spend on a real copy. Generally, their
>copyrights are VERY well enforced by their shysters which compounds
>the issue.
>
>
This is not a problem. We ask for GPL source code, not
the fancy printed copyrighted pdf. Sure it'd be nice to have,
maintenance is harder without it, but the driver itself
should not cause copright problems with a standards
document. This because a copy of the document isn't
included in the driver source.
>All of our preaching is to the choir, as the standards bodies could
>care less, if you want a copy, pony up. Thats life, unforch.
>
>
Sure - if I want the standard document. No need if all I want is the
driver that was written with the aid of said standard document,
assuming the driver writer didn't include large passages from
the document in the comments.
Something like:
/* Implementation of the xyz algorithm, see std.document for
specification on how it is supposed to work. */
ought to be fine.
Helge Hafting
Bernd Petrovitsch wrote:
>On Tue, 2005-12-13 at 09:25 +0100, Helge Hafting wrote:
>
>
>>Salyzyn, Mark wrote:
>>
>>
>[...]
>
>
>>>For instance, there are reasons, somewhat outside the control of the
>>>Hardware Vendor, for binary drivers. Often, in the hopes of achieving
>>>
>>>
>
>Even if this is the case it is the decision of the hardware vendor to go
>that way. The underlying organzation may be equally guilty but that
>doens't make the hardware vendor innocent - simply he plays the same
>game just with an excuse.
>
>
>
>>>standards compliance, Hardware vendors are cornered by legalities over
>>>the copyright associated with those standards that ties their hands
>>>either from releasing interface documentation or from releasing source
>>>code. Yet all these vendors would be overjoyed to have Linux drivers for
>>>their Hardware in order to increase the sales of their products.
>>>
>>>
>
>Then it is up to them to do something.
>
>
>
>>Uh, a copyrighted standard? They are trying to live up to a secret
>>standard, one they cannot publish?
>>Don't sound like a standard to me - a standard is something known,
>>that is the purpose of standardization.
>>This sounds like "we standardized the voltage for household lamps, but
>>we won't tell if it is 110V, 220V or something completely different."
>>I really hope I misunderstood this.
>>
>>
>
>s/copyright/patent/ then you will get it probably more right.
>Given (beautiful and readable) source code, a patent infringement is
>probably much easier to proove than with disassembled output of gcc-4.x.
>
>
Oh. So they are infringing already, and just trying to hide it?
This is so common that it applies to most drivers? :-(
>
>
>>Standards compliance should never get in the way of open source.
>>Sure - if the owner modifies the source, then the thing may no longer
>>comply with the standard. In some cases even illegal or dangerous.
>>
>>
>
>Propriatory vendors (the larger they are, the more it makes sense) do
>that all the time without telling their customers/users (usually
>somewhere hidden within some tools which produce not compliant garbage)
>and the strategy is called "customer lockin".
>
>
Closed source may lock customers out, not in. I don't see how an
open source driver makes it easier for the customer to get away
from the product. If the proprietary nvidia driver went open source,
it still wouldn't work with competing cards - the hw is too different.
Copying the _hardware_ is still a copyright infringement, and possibly
also a patent issue.
>
>
>>But in that case, it is the fault of the owner, not the vendor. The vendor
>>can simply say that anyone changing the (distributed) source should get
>>their own certification.
>>
>>
>
>At least for (certified) ISDN stacks any change on the source (including
>trivial bug fixes) invalidates any official certification AFAIK.
>
>
And that does not in any way prevent open source. Sure - if you
_change_ that source you invalidate certification, but that is
your problem, not the vendors problem. It is not a reason to
keep the code secret. If anything goes wrong, they can simply
point the finger, the vendor driver is ok.
Helge Hafting
On Wed, 2005-12-14 at 09:59 +0100, Helge Hafting wrote:
> Bernd Petrovitsch wrote:
> >On Tue, 2005-12-13 at 09:25 +0100, Helge Hafting wrote:
> >
> >
> >>Salyzyn, Mark wrote:
[...]
> >>Uh, a copyrighted standard? They are trying to live up to a secret
> >>standard, one they cannot publish?
> >>Don't sound like a standard to me - a standard is something known,
> >>that is the purpose of standardization.
> >>This sounds like "we standardized the voltage for household lamps, but
> >>we won't tell if it is 110V, 220V or something completely different."
> >>I really hope I misunderstood this.
> >
> >s/copyright/patent/ then you will get it probably more right.
> >Given (beautiful and readable) source code, a patent infringement is
> >probably much easier to proove than with disassembled output of gcc-4.x.
> >
> Oh. So they are infringing already, and just trying to hide it?
ACK - there are so many patents out there (where many them are granted
for software as such, trivial, prior art and/or combinations of them)
> This is so common that it applies to most drivers? :-(
ACK. But this fact is probably not be present in the mind of the average
(none-techie) beancounter, manager or decider.
> >>Standards compliance should never get in the way of open source.
> >>Sure - if the owner modifies the source, then the thing may no longer
> >>comply with the standard. In some cases even illegal or dangerous.
> >
> >Propriatory vendors (the larger they are, the more it makes sense) do
> >that all the time without telling their customers/users (usually
> >somewhere hidden within some tools which produce not compliant garbage)
> >and the strategy is called "customer lockin".
> >
> Closed source may lock customers out, not in. I don't see how an
Yes, also. But I was here refering to software in general, e.g. the
excess of the browser war in creating new HTML entities which were
silently used by the own "WYSIWYG-HTML-Editor" (as if such could exist -
not even in theory).
> open source driver makes it easier for the customer to get away
> from the product. If the proprietary nvidia driver went open source,
> it still wouldn't work with competing cards - the hw is too different.
> Copying the _hardware_ is still a copyright infringement, and possibly
> also a patent issue.
Hardware-related, ACK.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
"linux-os \(Dick Johnson\)" <[email protected]> writes:
> When the linux-BIOS group started, few knew where to start. Then,
> mysteriously, there was a complete directory tree of a well-known
> BIOS that appeared on the web. That was a start.
Nope it wasn't. None of the developers even read the code.
We needed to keep our hands clean.
Eric
On Wed, 14 Dec 2005, Eric W. Biederman wrote:
> "linux-os \(Dick Johnson\)" <[email protected]> writes:
>
>> When the linux-BIOS group started, few knew where to start. Then,
>> mysteriously, there was a complete directory tree of a well-known
>> BIOS that appeared on the web. That was a start.
>
> Nope it wasn't. None of the developers even read the code.
> We needed to keep our hands clean.
>
> Eric
>
Standard disclaimer #123
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
"linux-os \(Dick Johnson\)" <[email protected]> writes:
> On Wed, 14 Dec 2005, Eric W. Biederman wrote:
>
>> "linux-os \(Dick Johnson\)" <[email protected]> writes:
>>
>>> When the linux-BIOS group started, few knew where to start. Then,
>>> mysteriously, there was a complete directory tree of a well-known
>>> BIOS that appeared on the web. That was a start.
>>
>> Nope it wasn't. None of the developers even read the code.
>> We needed to keep our hands clean.
>>
>> Eric
>>
>
> Standard disclaimer #123
And it is true.
It's not like a mess of 20 year old spaghetti assembly is a useful
starting point for anything.
I sat down and I read the relevant standards documents and what
chipset documentation there was and I manged to write code.
It's not like there is anything fundamentally hard about what bootstrap
firmware does.
Not to be insulting but disbelief here sounds a lot like SCO's assertion
that Linus couldn't written linux.
Eric
On Wed, 14 Dec 2005, Eric W. Biederman wrote:
> "linux-os \(Dick Johnson\)" <[email protected]> writes:
>
>> On Wed, 14 Dec 2005, Eric W. Biederman wrote:
>>
>>> "linux-os \(Dick Johnson\)" <[email protected]> writes:
>>>
>>>> When the linux-BIOS group started, few knew where to start. Then,
>>>> mysteriously, there was a complete directory tree of a well-known
>>>> BIOS that appeared on the web. That was a start.
>>>
>>> Nope it wasn't. None of the developers even read the code.
>>> We needed to keep our hands clean.
>>>
>>> Eric
>>>
>>
>> Standard disclaimer #123
>
> And it is true.
>
> It's not like a mess of 20 year old spaghetti assembly is a useful
> starting point for anything.
>
> I sat down and I read the relevant standards documents and what
> chipset documentation there was and I manged to write code.
>
> It's not like there is anything fundamentally hard about what bootstrap
> firmware does.
>
> Not to be insulting but disbelief here sounds a lot like SCO's assertion
> that Linus couldn't written linux.
No, no. If you know that there is information available that you
could read and use as a reference, then you would certainly read
that information, wouldn't you? There are many things about
the PC/AT architecture that could not possibly be known without
using some kind of reference because of "compatibility" issues.
For instance, how do you link the two interrupt controllers
together? You can't see it in the old PC/AT handbook schematics,
and its not in the documentation of the chips. Also, reading
a register won't give you the answer because the register values
are dynamic. So, you look to see what others have done. You
can start with the AT BIOS that's published, but it won't work
(I know because I have written two AT Class BIOS). You really
need to see what others have done in a few cases.
When we started to use the AMD SC520, we found out that the
BIOS vendor wanted to charge a large fee per "label".
So, I wrote a BIOS for it. Using all of the available
documentation for the SC520 plus the PC/AT would not result
in a few things working. So I had to peek. Just like
everybody else.
So, if you claim that you have written a PC/AT BIOS without
ever seeing how others have done it, you are in a world of
hurt, sort of beating yourself up for no good reason at all.
Also, since the basic architecture accesses things from software
interrupts, it's pretty easy to debug stuff. You just keep
substituting your code for the BIOS code. Eventually, you
have everything working except the raw initialization stuff
which can only be tested by throwing it off the cliff and
seeing if it will fly! That's when you find that the cascaded
interrupt controller doesn't work, BYW.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Greg KH wrote:
> For people to think that the kernel developers are just "too dumb" to
> make a stable kernel api (and yes, I've had people accuse me of this
> many times to my face[1]) shows a total lack of understanding as to
> _why_ we change the in-kernel api all the time. Please see
> Documentation/stable_api_nonsense.txt for details on this.
I read this doc, and it doesn't make your case any clearer, on the contrary!
But first, your work to the kernel represents a not so dumb contribution,
especially the replacement of devfs. Thanks!
Now, to call a stable api nonsense is nonsense. Really, only a _stable_ api
is worth to be considered an API. Think about it.
The only advantage of not offering a _stable_ api is to enforce some weird
kind of copy protection scheme, because let's face it:
An API would benefit everybody, even those that may take advantage of it.
So to limit the kernel by making it awkward to interact with it, because
somebody may take advantage, is a rather paranoid way of doing things.
Things are bad enough the kernel being monolithic, and then inhibiting a sane
API to develop may only serve to delay the competitiveness of the kernel.
Loose the paranoia and prove GNU/Linux can stand on its own.
Thanks!
--
Al
On Thu, 2005-12-15 at 00:13 +0300, Al Boldi wrote:
> Greg KH wrote:
> > For people to think that the kernel developers are just "too dumb" to
> > make a stable kernel api (and yes, I've had people accuse me of this
> > many times to my face[1]) shows a total lack of understanding as to
> > _why_ we change the in-kernel api all the time. Please see
> > Documentation/stable_api_nonsense.txt for details on this.
>
> I read this doc, and it doesn't make your case any clearer, on the contrary!
>
> But first, your work to the kernel represents a not so dumb contribution,
> especially the replacement of devfs. Thanks!
>
> Now, to call a stable api nonsense is nonsense. Really, only a _stable_ api
> is worth to be considered an API. Think about it.
a stable api/abi for the linux kernel would take at least 2 years to
develop. The current API is not designed for stable-ness, a stable API
needs stricter separation between the layers and more opaque pointers
etc etc.
There is a price you pay for having such a rigid scheme (it arguably has
advantages too, those are mostly relevant in a closed source system tho)
is that it's a lot harder to implement improvements. Linux isn't so much
designed as evolved, and in evolution, new dominant things emerge
regularly. A stable API would prevent those from even coming into
existing, let alone become dominant and implemented. The price linux
pays for this is that code needs changing all the time. On the other
hand.. the GPL gives you that code so that you can do that...
Arjan van de Ven wrote:
> On Thu, 2005-12-15 at 00:13 +0300, Al Boldi wrote:
> > Greg KH wrote:
> > > For people to think that the kernel developers are just "too dumb" to
> > > make a stable kernel api (and yes, I've had people accuse me of this
> > > many times to my face[1]) shows a total lack of understanding as to
> > > _why_ we change the in-kernel api all the time. Please see
> > > Documentation/stable_api_nonsense.txt for details on this.
> >
> > I read this doc, and it doesn't make your case any clearer, on the
> > contrary!
> >
> > But first, your work to the kernel represents a not so dumb
> > contribution, especially the replacement of devfs. Thanks!
> >
> > Now, to call a stable api nonsense is nonsense. Really, only a _stable_
> > api is worth to be considered an API. Think about it.
>
> a stable api/abi for the linux kernel would take at least 2 years to
> develop. The current API is not designed for stable-ness, a stable API
> needs stricter separation between the layers and more opaque pointers
> etc etc.
True. But it would be time well spent.
> There is a price you pay for having such a rigid scheme (it arguably has
> advantages too, those are mostly relevant in a closed source system tho)
> is that it's a lot harder to implement improvements.
This is a common misconception. What is true is that a closed system is
forced to implement a stable api by nature. In an OpenSource system you can
just hack around, which may seem to speed your development cycle when in
fact it inhibits it.
> Linux isn't so much designed as evolved, and in evolution, new dominant
> things emerge regularly. A stable API would prevent those from even coming
> into existing, let alone become dominant and implemented.
GNU/OpenSource is unguided by nature. A stable API contributes to a guided
development that is scalable. Scalability is what leads you to new heights,
or else could you imagine how ugly it would be to send this message using
asm?
Thanks!
--
Al
Al Boldi wrote:
> Arjan van de Ven wrote:
>
>>
>>a stable api/abi for the linux kernel would take at least 2 years to
>>develop. The current API is not designed for stable-ness, a stable API
>>needs stricter separation between the layers and more opaque pointers
>>etc etc.
>
>
> True. But it would be time well spent.
>
Who's time would be well spent?
Not mine because I don't want a stable API. Not mine because I
don't use binary drivers and I don't care to encourage them.
[that is, unless you manage to convince me below ;)]
Anyone else is free to fork the kernel and develop their own
stable API for it. I don't think I would go so far as to call
that time well spent, however.
>
>>There is a price you pay for having such a rigid scheme (it arguably has
>>advantages too, those are mostly relevant in a closed source system tho)
>>is that it's a lot harder to implement improvements.
>
>
> This is a common misconception. What is true is that a closed system is
> forced to implement a stable api by nature. In an OpenSource system you can
> just hack around, which may seem to speed your development cycle when in
> fact it inhibits it.
>
How? I'm quite willing to listen, but throwing around words like 'guided
development' and 'scalability' doesn't do anything. How does the lack of a
stable API inhibit my kernel development work, exactly?
>
>>Linux isn't so much designed as evolved, and in evolution, new dominant
>>things emerge regularly. A stable API would prevent those from even coming
>>into existing, let alone become dominant and implemented.
>
>
> GNU/OpenSource is unguided by nature.
I've got a fairly good idea of what work I'm doing, and what I'm planning
to do, long term goals, projects, etc. What would be the key differences
with "non-GNU/OpenSource" development that would make you say they are not
unguided by nature?
> A stable API contributes to a guided
> development that is scalable. Scalability is what leads you to new heights,
> or else could you imagine how ugly it would be to send this message using
> asm?
>
Let's not bother with bad analogies and stick to facts. Do you know how
many people work on the Linux kernel? And how rapidly the source tree
changes? Estimates of how many bugs we have? Comparitive numbers from
projects with stable APIs? That would be very interesting.
Thanks,
Nick
Send instant messages to your online friends http://au.messenger.yahoo.com
On Dec 14, 2005, at 23:49, Al Boldi wrote:
> Arjan van de Ven wrote:
>> There is a price you pay for having such a rigid scheme (it
>> arguably has advantages too, those are mostly relevant in a closed
>> source system though) is that it's a lot harder to implement
>> improvements.
>
> This is a common misconception. What is true is that a closed
> system is forced to implement a stable api by nature. In an
> OpenSource system you can just hack around, which may seem to speed
> your development cycle when in fact it inhibits it.
This is _not_ the way Linux works. We don't have a stable API
_precisely_ so we don't have to "hack around" our API. When the API
is broken, we fix the API, therefore it doesn't get "hacked around"
nearly as much as a so-called "Stable API" would be. The development
cycle is *accelerated* by the fact that an important API changes are
_OK_.
>> Linux isn't so much designed as evolved, and in evolution, new
>> dominant things emerge regularly. A stable API would prevent those
>> from even coming into existing, let alone become dominant and
>> implemented.
>
> GNU/OpenSource is unguided by nature. A stable API contributes to
> a guided development that is scalable.
Wrong again. "Guided" implies that some overall authority controls
everything that goes on, which is inherently unscalable. Look at how
inefficient all the governments are! Look at how inefficient Linux
kernel development was before BK and git! When Linus had to deal
with the thousands of patches individually, that was the development
bottleneck. As it is now, the merging work that Linus alone used to
do is now divided up across a combination of Andrew Morton, Greg KH,
and many valuable others (who can't all be listed without making this
message overflow the mailing list limits).
Linux development scales _now_ better than any other software (open
_OR_ closed) on the planet; recent patches from 2.6.X to 2.6.X+1-rc1
are 25MB in size and constantly growing. If you can come up with a
development model that works as well and prove it in production, then
good for you. I don't expect, however, to see any closed-source
project come close to the rate of production of Linux; even
_Microsoft_ couldn't afford as many man-hours on a single codebase
for long.
Cheers,
Kyle Moffett
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
-- Brian Kernighan
On Thu, 2005-12-15 at 07:49 +0300, Al Boldi wrote:
> Arjan van de Ven wrote:
> > On Thu, 2005-12-15 at 00:13 +0300, Al Boldi wrote:
> > > Greg KH wrote:
> > > > For people to think that the kernel developers are just "too dumb" to
> > > > make a stable kernel api (and yes, I've had people accuse me of this
> > > > many times to my face[1]) shows a total lack of understanding as to
> > > > _why_ we change the in-kernel api all the time. Please see
> > > > Documentation/stable_api_nonsense.txt for details on this.
> > >
> > > I read this doc, and it doesn't make your case any clearer, on the
> > > contrary!
> > >
> > > But first, your work to the kernel represents a not so dumb
> > > contribution, especially the replacement of devfs. Thanks!
> > >
> > > Now, to call a stable api nonsense is nonsense. Really, only a _stable_
> > > api is worth to be considered an API. Think about it.
> >
> > a stable api/abi for the linux kernel would take at least 2 years to
> > develop. The current API is not designed for stable-ness, a stable API
> > needs stricter separation between the layers and more opaque pointers
> > etc etc.
>
> True. But it would be time well spent.
feel free to spend your time on it, you seem to consider it well spent
time. A lot of us don't, so we're not going to spend our time on it....
> > There is a price you pay for having such a rigid scheme (it arguably has
> > advantages too, those are mostly relevant in a closed source system tho)
> > is that it's a lot harder to implement improvements.
>
> This is a common misconception.
a stable API is more rigid, that is not and can't be a misconception.
> What is true is that a closed system is
> forced to implement a stable api by nature. In an OpenSource system you can
> just hack around, which may seem to speed your development cycle when in
> fact it inhibits it.
in practice it doesn't. The kernel drivers are GPL, and API changes when
needed just happen, all callers are fixed. The alternative would be a
"crooked" API which needs workarounds on both sides. No thanks.
>
> > Linux isn't so much designed as evolved, and in evolution, new dominant
> > things emerge regularly. A stable API would prevent those from even coming
> > into existing, let alone become dominant and implemented.
>
> GNU/OpenSource is unguided by nature. A stable API contributes to a guided
> development that is scalable. Scalability is what leads you to new heights,
> or else could you imagine how ugly it would be to send this message using
> asm?
I think Linux proves you wrong (and a bit of a troll to be honest ;)
Anyway, it's an open system, if you think something should happen... you
can make it happen by contributing and then defending it. If it's the
right thing, it'll then happen.
Nick Piggin wrote:
> Al Boldi wrote:
> > Arjan van de Ven wrote:
> >>a stable api/abi for the linux kernel would take at least 2 years to
> >>develop. The current API is not designed for stable-ness, a stable API
> >>needs stricter separation between the layers and more opaque pointers
> >>etc etc.
> >
> > True. But it would be time well spent.
>
> Who's time would be well spent?
>
> Not mine because I don't want a stable API. Not mine because I
> don't use binary drivers and I don't care to encourage them.
> [that is, unless you manage to convince me below ;)]
The fact that somebody may take advantage of a stable API should not lead us
to reject the idea per se.
> Anyone else is free to fork the kernel and develop their own
> stable API for it.
That would be sad.
The objective of a stable API would be to aid the collective effort and not
to divide it.
> >>There is a price you pay for having such a rigid scheme (it arguably has
> >>advantages too, those are mostly relevant in a closed source system tho)
> >>is that it's a lot harder to implement improvements.
> >
> > This is a common misconception. What is true is that a closed system is
> > forced to implement a stable api by nature. In an OpenSource system you
> > can just hack around, which may seem to speed your development cycle
> > when in fact it inhibits it.
>
> How? I'm quite willing to listen, but throwing around words like 'guided
> development' and 'scalability' doesn't do anything. How does the lack of a
> stable API inhibit my kernel development work, exactly?
If you are working alone a stable API would be overkill. But GNU/Linux is a
collective effort, where stability is paramount to aid scalability.
I hope the concepts here are clear.
> >>Linux isn't so much designed as evolved, and in evolution, new dominant
> >>things emerge regularly. A stable API would prevent those from even
> >> coming into existing, let alone become dominant and implemented.
> >
> > GNU/OpenSource is unguided by nature.
>
> I've got a fairly good idea of what work I'm doing, and what I'm planning
> to do, long term goals, projects, etc. What would be the key differences
> with "non-GNU/OpenSource" development that would make you say they are not
> unguided by nature?
The same goes for OpenSource in general, but GNU/OpenSource has a larger
community and therefore is in greater need of a stable API.
> > A stable API contributes to a guided
> > development that is scalable. Scalability is what leads you to new
> > heights, or else could you imagine how ugly it would be to send this
> > message using asm?
>
> Let's not bother with bad analogies and stick to facts. Do you know how
> many people work on the Linux kernel? And how rapidly the source tree
> changes? Estimates of how many bugs we have? Comparitive numbers from
> projects with stable APIs? That would be very interesting.
You got me here! It's really common sense as in:
stability breeds scalability, and instability breeds chaos.
Arjan van de Ven wrote:
> I think Linux proves you wrong (and a bit of a troll to be honest ;)
No troll! Just being IMHO. I hope that's OK?
Of course, if your aim is not to be scalable then please ignore this message
as it will not have any meaning.
Thanks!
--
Al
> > Anyone else is free to fork the kernel and develop their own
> > stable API for it.
>
> That would be sad.
>
> The objective of a stable API would be to aid the collective effort and not
> to divide it.
I think you missed how linux development works. Things fork all the
time. The unsuccessful forks die. The successful ones join the "main
line" again. Darwinism at work.
You're free to put your coding where your mouth is and design and
implement a stable API. If it's a success.. it'll get there. If it's
not.. no harm done to the rest.
> If you are working alone a stable API would be overkill. But GNU/Linux is a
> collective effort, where stability is paramount to aid scalability.
>
> I hope the concepts here are clear.
I think I don't get how you come from "stable API" to "aid scalability"
in the light that the current non-API doesn't seem to prevent
scalability to the size linux development is today.
> > I've got a fairly good idea of what work I'm doing, and what I'm planning
> > to do, long term goals, projects, etc. What would be the key differences
> > with "non-GNU/OpenSource" development that would make you say they are not
> > unguided by nature?
>
> The same goes for OpenSource in general, but GNU/OpenSource has a larger
> community and therefore is in greater need of a stable API.
again you skip a step. I see how a "large community" leads to "needs a
visible API". The leap to "need stable API" I don't see in practice.
> Arjan van de Ven wrote:
> > I think Linux proves you wrong (and a bit of a troll to be honest ;)
>
> No troll! Just being IMHO. I hope that's OK?
I hope you're also willing to put your effort where your words are,
otherwise you are trolling to a large degree.
On Thu, 2005-12-15 at 00:13 +0300, Al Boldi wrote:
[....]
> Now, to call a stable api nonsense is nonsense. Really, only a _stable_ api
> is worth to be considered an API. Think about it.
You got it.
In old economy terms to keep it corporations-compatible (and if I
formulated it the other way around): Then there is no in-kernel API.
There are the syscalls you should use.
Have fun ....
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Al Boldi wrote:
> Nick Piggin wrote:
>
>>Al Boldi wrote:
>>
>>>
>>>True. But it would be time well spent.
>>
>>Who's time would be well spent?
>>
>>Not mine because I don't want a stable API. Not mine because I
>>don't use binary drivers and I don't care to encourage them.
>>[that is, unless you manage to convince me below ;)]
>
>
> The fact that somebody may take advantage of a stable API should not lead us
> to reject the idea per se.
>
Of course not, but the fact that they do nothing to help us means
that it doesn't carry a lot of weight (IMO, of course).
So: who's time well spent?
>
>>Anyone else is free to fork the kernel and develop their own
>>stable API for it.
>
>
> That would be sad.
>
> The objective of a stable API would be to aid the collective effort and not
> to divide it.
>
As Arjan said, this is how kernel development works. I was using it
to highlight the fact that nobody has done so yet, which gives some
indication that it is not time well spent.
>>>This is a common misconception. What is true is that a closed system is
>>>forced to implement a stable api by nature. In an OpenSource system you
>>>can just hack around, which may seem to speed your development cycle
>>>when in fact it inhibits it.
>>
>>How? I'm quite willing to listen, but throwing around words like 'guided
>>development' and 'scalability' doesn't do anything. How does the lack of a
>>stable API inhibit my kernel development work, exactly?
>
>
> If you are working alone a stable API would be overkill. But GNU/Linux is a
> collective effort, where stability is paramount to aid scalability.
>
> I hope the concepts here are clear.
>
No, they're not. I see no reason why your conjecture would be true and
you have failed to provide even any theories as to why it might be.
What's more, I'm not even clear what you mean by the scalability of a
development process. So, please elaborate -- this is not a rhetorical
question because I'm interested as to why you think this is the case, and
I have not had much experience with closed software development.
>>>GNU/OpenSource is unguided by nature.
>>
>>I've got a fairly good idea of what work I'm doing, and what I'm planning
>>to do, long term goals, projects, etc. What would be the key differences
>>with "non-GNU/OpenSource" development that would make you say they are not
>>unguided by nature?
>
>
> The same goes for OpenSource in general, but GNU/OpenSource has a larger
> community and therefore is in greater need of a stable API.
>
Yes, the same goes for OpenSource in general, fine. But what I'm asking
is: how is non-OpenSource different? What can we do better? How can we
learn from them?
>>Let's not bother with bad analogies and stick to facts. Do you know how
>>many people work on the Linux kernel? And how rapidly the source tree
>>changes? Estimates of how many bugs we have? Comparitive numbers from
>>projects with stable APIs? That would be very interesting.
>
>
> You got me here! It's really common sense as in:
> stability breeds scalability, and instability breeds chaos.
>
But you might not be far wrong in saying that Linux has one of the most
chaotic and scalable development processes in the world.
We have unstable APIs, but IMO we have a great and stable software.
> Arjan van de Ven wrote:
>
>>I think Linux proves you wrong (and a bit of a troll to be honest ;)
>
>
> No troll! Just being IMHO. I hope that's OK?
>
That's fine, but Linux and the development process is a personal
achievement and creation of many here, so you have to try to be
respectful :)
> Of course, if your aim is not to be scalable then please ignore this message
> as it will not have any meaning.
>
I think most believe what I do: that our development model is scalable
(scalability seems to be the least of its worries), and that unstable
APIs are not a bad thing.
Everybody is also open to try to improve, however "stability breeds
scalability, and instability breeds chaos" is simply not "common sense",
so please explain and justify it before going further.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
On Thu, 2005-12-15 at 11:31 +0300, Al Boldi wrote:
> The fact that somebody may take advantage of a stable API should not lead
> us to reject the idea per se.
True. But then nobody said the idea was rejected for that reason, just
that supporting binary drivers is not a compelling reason to embrace a
stable API. In other words, supporting binary drivers is not nearly as
important as other factors which would be harmed by a stable API.
> The objective of a stable API would be to aid the collective effort and
> not to divide it.
The collective effort seems to be doing just fine without it.
> If you are working alone a stable API would be overkill. But GNU/Linux
> is a collective effort, where stability is paramount to aid scalability.
>
> I hope the concepts here are clear.
No, it's not clear what you mean by scalability. What is it exactly that
you think would be more scalable? As has been mentioned already, there
is no better example today of scalable development than the Linux kernel.
So, I don't think you've laid out at all what it is you're talking about.
> No troll! Just being IMHO. I hope that's OK?
>
> Of course, if your aim is not to be scalable then please ignore this
> message as it will not have any meaning.
The linux kernel development model scales very well. Linux itself scales
from the smallest embedded processors to the largest parallel computing
farms today; all without a stable internal API. So you've failed to make
a case that there is a problem for which a stable API is the solution.
Cheers,
Sean
Al Boldi wrote:
>Nick Piggin wrote:
>
>
>>Al Boldi wrote:
>>
>>
>>>Arjan van de Ven wrote:
>>>
>>>
>>>>a stable api/abi for the linux kernel would take at least 2 years to
>>>>develop. The current API is not designed for stable-ness, a stable API
>>>>needs stricter separation between the layers and more opaque pointers
>>>>etc etc.
>>>>
>>>>
>>>True. But it would be time well spent.
>>>
>>>
>>Who's time would be well spent?
>>
>>Not mine because I don't want a stable API. Not mine because I
>>don't use binary drivers and I don't care to encourage them.
>>[that is, unless you manage to convince me below ;)]
>>
>>
>
>The fact that somebody may take advantage of a stable API should not lead us
>to reject the idea per se.
>
>
It is all about advantages and disadvantages.
Disadvantages of a stable API:
* It encourages binary-only drivers, while we prefer source drivers.
Changing the API often and without warning is one way of
hampering binary-only driver development without harming
open-source drivers.
* A stable API isn't really possible. There will be revisions due
to new compilers, new processors, new needs. So the only
question is how often do we change. Hanging onto an obsolete
API too long will hamper _kernel_ development and performance.
Example: smp changed a lot of things. The old idea
that cli/sti was a way of implementing a critical section had to go.
To argue for a stable API then, you need to come up
with advantages, and they have to outweigh the disadvantages too.
Do a stable API save us work? No, because whoever changes the API
also fixes all in-kernel users of said API. Some API changes, like
using more or less register parameters, don't even need to fix API users
as the compiler does it all.
Outside users we don't care about at all, because they are all welcome
to get their driver in. (Assuming it is useful and the code quality is
good...)
>>Anyone else is free to fork the kernel and develop their own
>>stable API for it.
>>
>>
>
>That would be sad.
>
>The objective of a stable API would be to aid the collective effort and not
>to divide it.
>
>
Forks are not a problem. Anything useful in a fork will usually
be merged back sooner or later. And think about the
"normal" development process: If I were to write a driver,
I would get the kernel source, make my driver, then submit it.
In the meantime, I effectively have my own short-lived fork.
>>>>There is a price you pay for having such a rigid scheme (it arguably has
>>>>advantages too, those are mostly relevant in a closed source system tho)
>>>>is that it's a lot harder to implement improvements.
>>>>
>>>>
>>>This is a common misconception. What is true is that a closed system is
>>>forced to implement a stable api by nature. In an OpenSource system you
>>>can just hack around, which may seem to speed your development cycle
>>>when in fact it inhibits it.
>>>
>>>
>>How? I'm quite willing to listen, but throwing around words like 'guided
>>development' and 'scalability' doesn't do anything. How does the lack of a
>>stable API inhibit my kernel development work, exactly?
>>
>>
>
>If you are working alone a stable API would be overkill. But GNU/Linux is a
>collective effort, where stability is paramount to aid scalability.
>
>
This doesn't actually hold when the source is available for all
to get and update. The source API doesn't change so often,
so it is time enough to develop a source driver without spending
all the time on adapting to the source API. Once you get the driver
in, you no longer have to keep up.
The binary api can change several times with every revision, with no
impact on open-source developers. So, no need to stabilize it.
Specs already says that a driver has to be compiled for the kernel
it is used with - a binary driver working with two releases (even
concecutive releases) are pure luck. So a binary vendor has to
at least compile for every release (and every supported platform).
If the source api changes too, then there is some programming
to do as well. Both of these have a price, and there is the hope
that more will see the light - that they can support linux fully without
these costs by going open source.
>>
>>I've got a fairly good idea of what work I'm doing, and what I'm planning
>>to do, long term goals, projects, etc. What would be the key differences
>>with "non-GNU/OpenSource" development that would make you say they are not
>>unguided by nature?
>>
>>
>
>The same goes for OpenSource in general, but GNU/OpenSource has a larger
>community and therefore is in greater need of a stable API.
>
>
A large community may find some kind of stability useful, the
line does not have to be drawn at the binary api level though.
The source API is much more stable than the binary API. And
source changes is usually only withing some subsytem.
I.e. a change in the pci driver API don't affect filesystem drivers
and so on.
>
>
>>> A stable API contributes to a guided
>>>development that is scalable. Scalability is what leads you to new
>>>heights, or else could you imagine how ugly it would be to send this
>>>message using asm?
>>>
>>>
>>Let's not bother with bad analogies and stick to facts. Do you know how
>>many people work on the Linux kernel? And how rapidly the source tree
>>changes? Estimates of how many bugs we have? Comparitive numbers from
>>projects with stable APIs? That would be very interesting.
>>
>>
>
>You got me here! It's really common sense as in:
>stability breeds scalability, and instability breeds chaos.
>
>
This saying doesn't necessarily apply to an API in a open-source
project. Especially not when talking about an internal API.
The kernel has an external binary API that is stable, it is
the syscall interface.
>Arjan van de Ven wrote:
>
>
>>I think Linux proves you wrong (and a bit of a troll to be honest ;)
>>
>>
>
>No troll! Just being IMHO. I hope that's OK?
>
>Of course, if your aim is not to be scalable then please ignore this message
>as it will not have any meaning.
>
>
Another option is that your assumption about "stability as a requirement
for scalability" is wrong at least in case of the kernel. The kernel
development scales very well so far. I can't see any delays caused by
developers trying to keep up with a change in binary APIs. Well,
except a handful of closed source vendors, but that is more or less
intentional. If they get tired, they can hand in their source.
Helge Hafting
> Disadvantages of a stable API:
> * It encourages binary-only drivers, while we prefer source drivers.
> Changing the API often and without warning is one way of
> hampering binary-only driver development without harming
> open-source drivers.
You are really shooting yourself in the foot here.
> Do a stable API save us work? No, because whoever changes the API
> also fixes all in-kernel users of said API.
That's very inefficient.
> how is non-OpenSource different? What can we do better? How can we
> learn from them?
Pretty much nothing, except for taking advantage of their precooked
interconnectivity api's, in which they excel in abstracting them pretty
well.
> > If you are working alone a stable API would be overkill. But GNU/Linux
> > is a collective effort, where stability is paramount to aid scalability.
> >
> > I hope the concepts here are clear.
>
> No, it's not clear what you mean by scalability. What is it exactly that
> you think would be more scalable? As has been mentioned already, there
> is no better example today of scalable development than the Linux kernel.
> So, I don't think you've laid out at all what it is you're talking about.
>
> I think I don't get how you come from "stable API" to "aid scalability"
> in the light that the current non-API doesn't seem to prevent
> scalability to the size linux development is today.
>
> The linux kernel development model scales very well. Linux itself scales
> from the smallest embedded processors to the largest parallel computing
> farms today; all without a stable internal API. So you've failed to make
> a case that there is a problem for which a stable API is the solution.
>
> Another option is that your assumption about "stability as a requirement
> for scalability" is wrong at least in case of the kernel. The kernel
> development scales very well so far. I can't see any delays caused by
> developers trying to keep up with a change in binary APIs. Well,
> except a handful of closed source vendors, but that is more or less
> intentional. If they get tired, they can hand in their source.
>
> I think most believe what I do: that our development model is scalable
> (scalability seems to be the least of its worries), and that unstable
> APIs are not a bad thing.
Don't mistake scalability for manageability/mantainability or flexibility.
Scalability is more, much more. It's about extendability and reusability
built on a solid foundation that may be stacked. Layers upon layers, the
sky is the limit. Stability is the key to unlock this scalability.
> > No troll! Just being IMHO. I hope that's OK?
>
> That's fine, but Linux and the development process is a personal
> achievement and creation of many here, so you have to try to be
> respectful :)
Sorry! Can you point out which part was offending?
Thanks!
--
Al
On 12/15/05, Al Boldi <[email protected]> wrote:
>
> Don't mistake scalability for manageability/mantainability or flexibility.
> Scalability is more, much more. It's about extendability and reusability
> built on a solid foundation that may be stacked. Layers upon layers, the
> sky is the limit. Stability is the key to unlock this scalability.
>
There is a game, called "bullsh*t bingo" where you have bunch of
buzzwords on you scorecard and you cross them out as you sneak them in
conversation. Well, I think you just have won a round.
--
Dmitry
On Thu, 2005-12-15 at 21:29 +0300, Al Boldi wrote:
> > how is non-OpenSource different? What can we do better? How can we
> > learn from them?
>
> Pretty much nothing, except for taking advantage of their precooked
> interconnectivity api's, in which they excel in abstracting them
> pretty
> well.
>
Sorry you are just WRONG here. If you wanted to do low latency audio on
Windows 4 years ago you were fucked because the kernel mixer adds 30ms
of latency and there's no API to bypass it! Haha, you lose.
Eventually Cakewalk figured out an undocumented unsupported method
called "Kernel Streaming" to bypass the kernel mixer. God knows how
many man hours were wasted on this problem.
Please drop your ridiculous assertion that stable APIs don't impede
progress. To create an stable API that would support new and innovative
future applications would require a LOT of foresight. It's MUCH easier
to just change the API when someone comes up with an application the old
one can't support.
Lee
On Thu, Dec 15, 2005 at 09:29:01PM +0300, Al Boldi wrote:
> Don't mistake scalability for manageability/mantainability or flexibility.
> Scalability is more, much more. It's about extendability and reusability
> built on a solid foundation that may be stacked. Layers upon layers, the
> sky is the limit. Stability is the key to unlock this scalability.
You know, Lehrer had done that one better (see, e.g.,
http://www.guntheranderson.com/v/data/whenyoua.htm)
Al Boldi wrote:
>>Disadvantages of a stable API:
>>* It encourages binary-only drivers, while we prefer source drivers.
>> Changing the API often and without warning is one way of
>> hampering binary-only driver development without harming
>> open-source drivers.
>
>
> You are really shooting yourself in the foot here.
>
Replying to different people in the same email gets confusing.
> Don't mistake scalability for manageability/mantainability or flexibility.
> Scalability is more, much more. It's about extendability and reusability
> built on a solid foundation that may be stacked. Layers upon layers, the
> sky is the limit. Stability is the key to unlock this scalability.
>
You're just completely making that all up with no reasons or basis.
What's more it doesn't even mean anything. It is quite obvious that
you have zero real arguments as to why a stable API is good. So let's
just leave it at that.
Nick
Send instant messages to your online friends http://au.messenger.yahoo.com
Al Boldi <[email protected]> wrote:
>> Disadvantages of a stable API:
>> * It encourages binary-only drivers, while we prefer source drivers.
>> Changing the API often and without warning is one way of
>> hampering binary-only driver development without harming
>> open-source drivers.
>
> You are really shooting yourself in the foot here.
If binary drivers were a nice idea, it would be so, but unfortunately they
aren't. E.g.:
Nvidia stuffes a userspace library into the kernel. BAD.
Ati can't work correctly if there are other graphic cards in the system,
because they include functions from a different layer in their driver,
which off cause can't interface correctly. The WXP divers are affected,
too. Doubleplusungood.
Both of these drivers are about 7 times larger than the whole kernel image.
Other binary drivers are similar. That's a waste of resources.
DOS didn't have an API for non-FAT filesystems. In order to support ISO9660,
the network support was abused instead of changing the internals. Obviously
this defeated reasonable caching, and the drivers needed to add their own
cache implementation, which had to be maintained seperately. Double work,
and a waste of resources.
(The DOS internals usurally can't be changed because they are stable. The
stable API was too cumbersome for the programmer's needs, so they started
using the internal structures directly. Therefore there was no way to
increase the max. path length beyond 64 bytes.)
>> Do a stable API save us work? No, because whoever changes the API
>> also fixes all in-kernel users of said API.
>
> That's very inefficient.
More inefficient than adding a compatibility layer?
If each change has to add another compatibility layer, the calls will have
to traverse several functions without doing anything usefull. Multiply this
with the number of users, and you'll see that one millisecond of CPU time
will accumulate to a quarter of an hour for each million users. Multiply
this with thousands of calls each user will do within each hour, and you'll
see that within each hour, you'd waste more than eleven days of CPU time.
Within one day and a half, you have wasted a whole year. Within that time,
you can easily change the API several times. That is, unless you hold
meetings about how it should look like.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
[My Radeon 9250-AGP is fine, Helge's 9250-PCI is dog slow]
On Wed, 14 Dec 2005, Helge Hafting wrote:
> Nix wrote:
>
>>OK, I see 25-40fps with that, with DRI. If I turn on stencil buffering
>>it gets unbearable, but that's just asking too much of the card I think
>>
> At what resolution? 25fps is nice enough - as good as movies.
> I no longer remember exactly, but I had to use 640x480 to get
> anything close to playable - lucky to get 10 or so fps.
1280x1024.
I think we can fairly say that there's a system config difference here
of some kind. :)
> I have been in touch with DRI developers before - this card isn't
> supposed to be "great", but it _is_ supposed to beat the
> matrox G550 which it isn't even close to. The matrox has its
> own problems - it sometimes looses the font in this game, and
> the fps reporting is wrong. But the game is smooth at 1280x1024 . . .
... as with my 9250.
>>Ah, this is a pure-PCI 9250, is it? (I wasn't aware you could get hold
>>of those anymore... I think X supports them, but textured stuff is
>>necessarily going to be slower.)
>>
> Yes - it is a pure pci thing, because the AGP slot is taken by the matrox.
> As for textured stuff being slower, I was under the impression that tuxracer
> use something like a total of 3 different textures, that surely should fit
> in the 64MB of onboard memory? Now ppracer have more textures, but
> old tuxracer levels don't actually use them.
True enough.
I'll admit I'm not sure why you're seeing such a speed difference if
hardware rendering is on; an order of magnitude seems a bit much just
for PCI versus AGP. Perhaps Dave knows?
--
`I must caution that dipping fingers into molten lead
presents several serious dangers.' --- Jearl Walker
Al Boldi wrote:
>>Disadvantages of a stable API:
>>* It encourages binary-only drivers, while we prefer source drivers.
>> Changing the API often and without warning is one way of
>> hampering binary-only driver development without harming
>> open-source drivers.
>>
>>
>
>You are really shooting yourself in the foot here.
>
>
Only if supporting binary-only drivers is somehow considered
important/useful.
I don't believe so - so I don't shoot my foot here. :-)
>>Do a stable API save us work? No, because whoever changes the API
>>also fixes all in-kernel users of said API.
>>
>>
>
>That's very inefficient.
>
>
Wrong. It means that whoever want to change an API don't do so too lightly,
because there certainly is some work involved. Even if it often only is
a big "grep" followed up by some trivial editing. So, API change only
when there is a win offsetting this work.
Such a process may seem inefficient if one were to schedule that work
among a limited workforce. They had better not waste their time as that
block further options for profit. But only _companies_ work that way.
The kernel is different. There are lots and lots of people, each working
on their favourite part. (Which is one reason why development scales so
well.)
If someone does a time-consuming api change, then they aren't free to
do other work. But if they don't do that api change - you can't schedule
other work for them anyway because they aren't employees. They are
volunteers, their work don't cost any but it is also only for themselves
to decide what they work on.
So the usual rules or common sense about work management
in a company do not apply. Each patch is a gift you can't trade
for something else.
>>how is non-OpenSource different? What can we do better? How can we
>>learn from them?
>>
>>
>
>Pretty much nothing, except for taking advantage of their precooked
>interconnectivity api's, in which they excel in abstracting them pretty
>well.
>
>
>
[...]
>Don't mistake scalability for manageability/mantainability or flexibility.
>
>
Well, if we have manageability, maintainability and flexibility
then we are very well off, even if it doesn't fit your definition
of scalability.
>Scalability is more, much more. It's about extendability and reusability
>built on a solid foundation that may be stacked.
>
Again: Code reuse is nice, or even necessary, with a limited and
expensive workforce. It is not a concern with an unlimited free
workforce though. If some volunteer makes an improvement by
doing a big rewrite - well, the job gets done and nobody have to
pay him. This works. And you can't
get they guy to do something you find more useful "instead". Maintainers
can refuse patches of course - this usually cause people to work less
on linux rather than working more efficiently on linux. So even
a "lot of work for only a little gain" type patch is taken, if it is
technically sound. Because the time couldn't be better spent anyway,
so it wasn't wasted.
>Layers upon layers, the
>sky is the limit. Stability is the key to unlock this scalability.
>
>
I consider too many stacked layers inefficient. Keep it simple . . .
Helge Hafting
Helge Hafting wrote:
> Al Boldi wrote:
> >Scalability is more, much more. It's about extendability and reusability
> >built on a solid foundation that may be stacked.
>
> Again: Code reuse is nice, or even necessary, with a limited and
> expensive workforce. It is not a concern with an unlimited free
> workforce though. If some volunteer makes an improvement by
> doing a big rewrite - well, the job gets done and nobody have to
> pay him. This works. And you can't
> get they guy to do something you find more useful "instead". Maintainers
> can refuse patches of course - this usually cause people to work less
> on linux rather than working more efficiently on linux. So even
> a "lot of work for only a little gain" type patch is taken, if it is
> technically sound. Because the time couldn't be better spent anyway,
> so it wasn't wasted.
>
> >Layers upon layers, the
> >sky is the limit. Stability is the key to unlock this scalability.
>
> I consider too many stacked layers inefficient. Keep it simple . . .
True. But they are necessary to reach higher grounds.
Think about it.
Thanks!
--
Al