Linux stifles innovation...

Linux stifles innovation...

[fsnchzjr]

Watch Microsoft's Jim Allchin go Linux-bashing!!!
Nice little article on how we're all going to die of herpes from our
repeated exposition to Linux...
http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
g=ltnc

Re: Linux stifles innovation...

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

* fsnchzjr (fsnchzjr@zxmail.com) wrote:
> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> Nice little article on how we're all going to die of herpes from our
> repeated exposition to Linux...
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?tag=ltnc

	Just remember, the tag is 'ltnc' --> 'long-time, no clue'.

		Stephen

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: Linux stifles innovation...

[Mark Haney]

>> repeated exposition to Linux...
Hey isn't that _exposure_ to Linux?  Or one of Dubya's words?  Like
strategery?

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of fsnchzjr
Sent: Thursday, February 15, 2001 12:49 PM
To: 'linux-kernel@vger.kernel.org'
Subject: Linux stifles innovation...


Watch Microsoft's Jim Allchin go Linux-bashing!!!
Nice little article on how we're all going to die of herpes from our
repeated exposition to Linux...
http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
g=ltnc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Linux stifles innovation...

[David D.W. Downey]

Seriously though folks, look at who's doing this!

They've already tried once to sue 'Linux', were told they couldn't because
Linux is a non-entity (or at least one that they can not effectively sue
due to the classification Linux holds), and now they can't use their
second favorite tactic for stifling NON-M$ product lines.

How? They can't BUY the linux code base OR any GPL's software to the point
that they can bury it by buying and freezing the code from public use.

We sort HAD to expect something like THIS to come. Though what DOES
concern me is how effective this current ploy may be if they get ANY sort
of backing from the government. (I doubt they will, but What If?)

Let's hope EFF and FSF stay on their toes for this one. M$ doesn't have to
win to really wipe our nose in stuff. They got the cash whereas we don't.
ALTHOUGH, spending money to fight an idea or concept has never proven
successful. And since the RESULTS of that idea or concept (in this case
source code) are not suable AFAIK. So we got the upper hand there.


-- 
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA

RE: Linux stifles innovation...

[Alan Olsen]

On Thu, 15 Feb 2001, David D.W. Downey wrote:

> Seriously though folks, look at who's doing this!
> 
> They've already tried once to sue 'Linux', were told they couldn't because
> Linux is a non-entity (or at least one that they can not effectively sue
> due to the classification Linux holds), and now they can't use their
> second favorite tactic for stifling NON-M$ product lines.
> 
> How? They can't BUY the linux code base OR any GPL's software to the point
> that they can bury it by buying and freezing the code from public use.
> 
> We sort HAD to expect something like THIS to come. Though what DOES
> concern me is how effective this current ploy may be if they get ANY sort
> of backing from the government. (I doubt they will, but What If?)

I expect the next thing that will happen is that they will get patents on
key portions of their protocols and then start enforcing them.

With the various IP laws that have been passed in the last few years in
the US (and through WIPO) they will have a large brick to try and hit us
with. (IMHO these laws pretty much allow large entities to buy their
markets and are the biggest threat to innovation out there.)

> Let's hope EFF and FSF stay on their toes for this one. M$ doesn't have to
> win to really wipe our nose in stuff. They got the cash whereas we don't.
> ALTHOUGH, spending money to fight an idea or concept has never proven
> successful. And since the RESULTS of that idea or concept (in this case
> source code) are not suable AFAIK. So we got the upper hand there.

Actually I am sending copies of his rant out to all of my friends who
still use Microsoft products.

If that is the attitude they have towards their customers and the
development community then it is time to get away while you still can.

Of course, the reason I moved over all my development to Linux in the
first place what that I did not have to worry about being screwed over by
a "corporate strategy" or have the license terms changed on the next
release or have to pay for something over and over again in the vain
attempt to get something to work.

With Linux I can read the source.  There are no hidden interfaces. No
mystical archane knowledge that you have to pay the company to learn get
the job done.  It is all there and it all works.  (Or if it does not, then
the tools exist to make it work.)

I wonder what kind of law they will try to push to outlaw Open Source?

If this is his idea of "The American Way" then he needs to take a basic
civics course.  He obviously slept through the last one.

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
    "In the future, everything will have its 15 minutes of blame."

RE: Linux stifles innovation...

[dave]

"I'm an American, I believe in the American Way, I worry if the 
government encourages open source, and I don't think we've done 
enough education of policy makers to understand the threat."


He believes in the "Golden Rule" too...

Can you say "NSA" or "Secure Linux"?

I believe they are truly worried.  It's all about money and control,
both of which they are leaking badly.

I have faith in the policy makers at large.  A certain judge
understood M$'s policy all to well.  A lot of parallels can be drawn
between this latest volley and their current legal predicament.

I'm rambling, but this has got me a bit upset.
-- 
Dave

---------------------------------------------------------------------------
Dave Helton, KD0YU    - dave@realworldcomputing.net  - http://www.kd0yu.com

RE: Linux stifles innovation...

[Richard B. Johnson]

On Thu, 15 Feb 2001 dave@kd0yu.com wrote:

> 
> "I'm an American, I believe in the American Way, I worry if the 
> government encourages open source, and I don't think we've done 
> enough education of policy makers to understand the threat."
> 

It is not American to steal. The first "Flight Simulator" was
published on the PROGRAM EXCHANGE BBS System in the '70s. I know,
with the help of some Turbo Pascal wizards for the graphics, and
my state-machine, written in assembly, I did it. The original idea
was started, and ran in text-mode under CP/M.

The first flight simulator was also very difficult to fly. This
is because I incorporated all the quirks of airplanes, spiral
instability, long-mode oscillations, adverse yaw, etc. I had just
gotten my Commercial Pilot's license at the time and joined AIAA.
Every quirk I could find was built into that simulator.

When M$ copied it, their first releases were also difficult to fly.
Eventually, they understood enough about the code so that they were
able to remove the instabilities and any kid could fly it. Their
introduction into "games" brought them enough money to do anything
they wanted, including continuing to steal.

Again, this is not "American". This is Microsoft.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

[OTP] RE: Linux stifles innovation...

[David D.W. Downey]

On Thu, 15 Feb 2001, Alan Olsen wrote:

> I expect the next thing that will happen is that they will get patents on
> key portions of their protocols and then start enforcing them.
>

They can only patent their own creations. I'd like to see them try to get
patents for their "extensions" to TCP or some other bastardization they've
made to the various standard protocols. They'd be isolating themselves out
of the market in a heartbeat. Who would be willing to pay for their
breaking of standards? Their existing user base perhaps but not many more
than that, save the few companies that decided it was in their best
interests to pay the fee. More than likely they'll kill their own market
they go that route.


> With the various IP laws that have been passed in the last few years in
> the US (and through WIPO) they will have a large brick to try and hit us
> with. (IMHO these laws pretty much allow large entities to buy their
> markets and are the biggest threat to innovation out there.)
>

OK, WIPO? Never heard of it. Got a URL?

> Actually I am sending copies of his rant out to all of my friends who
> still use Microsoft products.
>

hehe, already done that. Got some GOOD feedback off of that. So far 5 of
the 10 I've emailed have responded in rage. Don't know too many humans
that take kindly to being politely called an idiot in public, which is
basically what M$ has been saying. "You're an idiot if you use Linux
because Linux stifles inovation. Thus you are a pawn of the Linux movement
which makes you part of the threat to intellectual property (Read this as
you are a part of the threat to my bottom line.

 > If that is the attitude they have towards their customers and the
> development community then it is time to get away while you still can.
>

Microsoft relies rather heavily on the belief that their business model
has locked their client base in. What they don't understand is that, the
"movement" of Opensource as they so call it, will start to cost them even
MORE money than we do now. Why? because as more people get pissed off at
the mindframe of M$ and realize that there are comparable OpenSource
products out there, they'll be leaving M$. Admittedly this will start out
as a small trickle, taking place over the next say 2 years.

Microsoft needs to wake up to the understanding that the only way they
will survive if the "Linux movement" (their words not mine) gets ticked
off enough to truly start a concerted effort to make open source based
replacements for Microsoft products, is to play nice with Linux and
OpenSource products in general, they're dead in the water.

> Of course, the reason I moved over all my development to Linux in the
> first place what that I did not have to worry about being screwed over by
> a "corporate strategy" or have the license terms changed on the next
> release or have to pay for something over and over again in the vain
> attempt to get something to work.
>

I started with Linux in 94 because I thought it was a replacement for
Windows. Even back then, when Linux was still a dog of a kernel, it seemed
to exude power and inovation. (My personal belief so no one flame me for
that line.)

> With Linux I can read the source.  There are no hidden interfaces. No
> mystical archane knowledge that you have to pay the company to learn get
> the job done.  It is all there and it all works.  (Or if it does not, then
> the tools exist to make it work.)
>

Microsoft relies HEAVILY on the changes they've made in their product
lines to hide details from the consumer, some of whom NEED to know those
changes. This is just a case of a company that's chosen a business model
that can't compete with it's exact opposite. They know it, we know it, and
their advantage right now is that the general public DOESN'T know it.

I do feel kind of sorry for Microsoft. Their attornies and marketing force
must have tons of ulcers trying to figure out how to beat (not just
co-exist with) a product that has no clearly defined (read suable) human
owner, and that changes on an hourly basis like the sea changes the layout
of the sand on a beach. Severely tough to fight something like that.


> I wonder what kind of law they will try to push to outlaw Open Source? >
> If this is his idea of "The American Way" then he needs to take a basic
> civics course.  He obviously slept through the last one.
>

He wasn't sleeping. He was down the hall in Corporate Raiding 101.

David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA

Re: Linux stifles innovation...

[Bill Wendling]

Also sprach Alan Olsen:
} I expect the next thing that will happen is that they will get patents on
} key portions of their protocols and then start enforcing them.
} 
Which protocols would that be? TCP/IP wasn't invented by them.

} I wonder what kind of law they will try to push to outlaw Open Source?
} 
With the horrid (pro-Microsoft) Aschroft in office, who knows what MS can
get away with. Not to mention all of the pro-business, anti-human cronies
in Washington running the Presidency (cause \/\/ just can't do it).

-- 
|| Bill Wendling			wendling@ganymede.isdn.uiuc.edu

Re: Linux stifles innovation...

[William T Wilson]

On Thu, 15 Feb 2001, Bill Wendling wrote:

> With the horrid (pro-Microsoft) Aschroft in office, who knows what MS
> can get away with. Not to mention all of the pro-business, anti-human
> cronies in Washington running the Presidency (cause \/\/ just can't do
> it).

Most of the pro-business people in the Bush administration are also
anti-regulation.  I think the net effect on free software will be a
wash.  While there wouldn't be any Microsoft antitrust case, there
probably wouldn't be any WIPO, either...

RE: Linux stifles innovation...

[Rik van Riel]

On Thu, 15 Feb 2001, Alan Olsen wrote:

> I expect the next thing that will happen is that they will get
> patents on key portions of their protocols and then start
> enforcing them.

If Microsoft would start pissing off IBM and other major
companies which have big business interests in Linux by
invoking their patents, I can just imagine IBM coming down
on Microsoft with their own patents ...

"Hey you!  Stop flipping those bits!  Hold it right there!
 ... Don't you flip any more bits, read this patent first..."

(and I'm sure they must have patents on _setting_ bits as
well ;))

cheers,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

RE: Linux stifles innovation...

[James Sutherland]

On Fri, 16 Feb 2001, Rik van Riel wrote:

> On Thu, 15 Feb 2001, Alan Olsen wrote:
> 
> > I expect the next thing that will happen is that they will get
> > patents on key portions of their protocols and then start
> > enforcing them.
> 
> If Microsoft would start pissing off IBM and other major
> companies which have big business interests in Linux by
> invoking their patents, I can just imagine IBM coming down
> on Microsoft with their own patents ...
> 
> "Hey you!  Stop flipping those bits!  Hold it right there!
>  ... Don't you flip any more bits, read this patent first..."
> 
> (and I'm sure they must have patents on _setting_ bits as
> well ;))

Apparently they DO have a patent on the tab key - you thought Amazon's
"one click shopping" patent was bad?!


James.

RE: Linux stifles innovation...

[Mark Haney]

Okay, so if we are going to get real stupid about the whole thing, I wonder
if Microsloth is going to patent the patent?


-----Original Message-----
From: James Sutherland [mailto:jas88@hermes.cam.ac.uk]On Behalf Of James
Sutherland
Sent: Friday, February 16, 2001 10:11 AM
To: Rik van Riel
Cc: Alan Olsen; David D.W. Downey; Mark Haney;
linux-kernel@vger.kernel.org
Subject: RE: Linux stifles innovation...


On Fri, 16 Feb 2001, Rik van Riel wrote:

> On Thu, 15 Feb 2001, Alan Olsen wrote:
>
> > I expect the next thing that will happen is that they will get
> > patents on key portions of their protocols and then start
> > enforcing them.
>
> If Microsoft would start pissing off IBM and other major
> companies which have big business interests in Linux by
> invoking their patents, I can just imagine IBM coming down
> on Microsoft with their own patents ...
>
> "Hey you!  Stop flipping those bits!  Hold it right there!
>  ... Don't you flip any more bits, read this patent first..."
>
> (and I'm sure they must have patents on _setting_ bits as
> well ;))

Apparently they DO have a patent on the tab key - you thought Amazon's
"one click shopping" patent was bad?!


James.

Re: Linux stifles innovation...

[David Woodhouse]

mhaney@info4cars.com said:
> Okay, so if we are going to get real stupid about the whole thing, I
> wonder if Microsloth is going to patent the patent?

Filing nuisance patents for obvious stuff which shouldn't ever get granted
is a viable business method and as such is patentable in the US. 

After all, what patent officer is going to point out the prior art?

:)

--
dwmw2

RE: Linux stifles innovation...

[Mark Haney]

Oh God.  You're right.  But who's going to patent the patent on the patent?
*ad infinitum*


-----Original Message-----
From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
Woodhouse
Sent: Friday, February 16, 2001 11:26 AM
To: Mark Haney
Cc: James Sutherland; Rik van Riel; Alan Olsen; David D.W. Downey;
linux-kernel@vger.kernel.org
Subject: Re: Linux stifles innovation...



mhaney@info4cars.com said:
> Okay, so if we are going to get real stupid about the whole thing, I
> wonder if Microsloth is going to patent the patent?

Filing nuisance patents for obvious stuff which shouldn't ever get granted
is a viable business method and as such is patentable in the US.

After all, what patent officer is going to point out the prior art?

:)

--
dwmw2

RE: Linux stifles innovation...

[David D.W. Downey]

Would someone tell me where you get all this lovely information on
patents held by M$? I can't find anything.


On Fri, 16 Feb 2001, James Sutherland wrote:

> On Fri, 16 Feb 2001, Rik van Riel wrote:
>
> > On Thu, 15 Feb 2001, Alan Olsen wrote:
> >
> > > I expect the next thing that will happen is that they will get
> > > patents on key portions of their protocols and then start
> > > enforcing them.
> >
> > If Microsoft would start pissing off IBM and other major
> > companies which have big business interests in Linux by
> > invoking their patents, I can just imagine IBM coming down
> > on Microsoft with their own patents ...
> >
> > "Hey you!  Stop flipping those bits!  Hold it right there!
> >  ... Don't you flip any more bits, read this patent first..."
> >
> > (and I'm sure they must have patents on _setting_ bits as
> > well ;))
>
> Apparently they DO have a patent on the tab key - you thought Amazon's
> "one click shopping" patent was bad?!
>
>
> James.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA

RE: Linux stifles innovation...

[James Sutherland]

On Fri, 16 Feb 2001, David D.W. Downey wrote:

> Would someone tell me where you get all this lovely information on
> patents held by M$? I can't find anything.

Sorry, it's *IBM* who are said to hold a patent on the tab key.

Legend has it Microsoft once found a patent of theirs which IBM appeared
to have infringed, and were very excited at the possibility of something
to hold over IBM, so their lawyers met IBM's lawyers. The MS lawyers
beamed "look at our patent you've infringed!" IBM's lawyers replied "look
at this pile of our patents YOU'VE infringed... let's start with this
one. A Tab key." MS suddenly realised they were outlawyered...

No idea how accurate it is, but just the thought of MS's lawyers getting a
nasty shock like that has a certain appeal :-)


James.

Re: Linux stifles innovation...

[Carlos Fernandez Sanz]

I did some research on the patent database and found nothing regarding such
a patent. There's patent on word processors (not the concept but related to)
and uses tab on the description...and that patent is from 1980.

----- Original Message -----
From: "James Sutherland" <jas88@cam.ac.uk>
To: "David D.W. Downey" <pgpkeys@hislinuxbox.com>
Cc: "Rik van Riel" <riel@conectiva.com.br>; "Alan Olsen"
<alan@clueserver.org>; "Mark Haney" <mhaney@info4cars.com>;
<linux-kernel@vger.kernel.org>
Sent: Friday, February 16, 2001 15:18
Subject: RE: Linux stifles innovation...


> On Fri, 16 Feb 2001, David D.W. Downey wrote:
>
> > Would someone tell me where you get all this lovely information on
> > patents held by M$? I can't find anything.
>
> Sorry, it's *IBM* who are said to hold a patent on the tab key.
>
> Legend has it Microsoft once found a patent of theirs which IBM appeared
> to have infringed, and were very excited at the possibility of something
> to hold over IBM, so their lawyers met IBM's lawyers. The MS lawyers
> beamed "look at our patent you've infringed!" IBM's lawyers replied "look
> at this pile of our patents YOU'VE infringed... let's start with this
> one. A Tab key." MS suddenly realised they were outlawyered...
>
> No idea how accurate it is, but just the thought of MS's lawyers getting a
> nasty shock like that has a certain appeal :-)
>
>
> James.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Linux stifles innovation...

[Dan Hollis]

On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:
> I did some research on the patent database and found nothing regarding such
> a patent. There's patent on word processors (not the concept but related to)
> and uses tab on the description...and that patent is from 1980.

You know XOR is patented (yes, the logical bit operation XOR).

-Dan

Re: Linux stifles innovation...

[Michael H. Warfield]

On Fri, Feb 16, 2001 at 04:35:02PM -0800, Dan Hollis wrote:
> On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:
> > I did some research on the patent database and found nothing regarding such
> > a patent. There's patent on word processors (not the concept but related to)
> > and uses tab on the description...and that patent is from 1980.

> You know XOR is patented (yes, the logical bit operation XOR).

	But wasn't that Xerox that had that?  Yeah, the same ones that
screwed us over with the compression patent that shot .gif images out
of the sky.  There was inovation for you.

> -Dan

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: Linux stifles innovation...

[Dan Hollis]

On Fri, 16 Feb 2001, Michael H. Warfield wrote:
> > You know XOR is patented (yes, the logical bit operation XOR).
> 	But wasn't that Xerox that had that?

US Patent #4,197,590 held by NuGraphics, Inc.

> Yeah, the same ones that screwed us over with the compression patent
> that shot .gif images out of the sky.  There was inovation for you.

That wasn't Xerox. That was Unisys (due to LZW).

-Dan

re: XOR [ was: Linux stifles innovation... ]

[David Relson]

At 08:52 PM 2/16/01, you wrote:
 > On Fri, 16 Feb 2001, Michael H. Warfield wrote:
 > > > You know XOR is patented (yes, the logical bit operation XOR).
 > > 	But wasn't that Xerox that had that?
 >
 > US Patent #4,197,590 held by NuGraphics, Inc.

The patent was for using the technique of using XOR for dragging/moving 
parts of a graphics image without erasing other parts.  Also, since the 
patent was granted in 1980, the inventors have had their 17 years of patent 
protection, and we're all free to use the technique - legally!

David

P.S.  Given that XOR is a basic boolean operation, I don't think the USPTO 
would ever be so dumb as to grant a patent on it.  But, then the PTO has 
shown a creative ability to grant patents to questionable ideas, so who can 
say what they would/could/will do?

re: XOR [ was: Linux stifles innovation... ]

[Dan Hollis]

On Fri, 16 Feb 2001, David Relson wrote:
> At 08:52 PM 2/16/01, you wrote:
>  > On Fri, 16 Feb 2001, Michael H. Warfield wrote:
>  > > > You know XOR is patented (yes, the logical bit operation XOR).
>  > > 	But wasn't that Xerox that had that?
>  > US Patent #4,197,590 held by NuGraphics, Inc.
> The patent was for using the technique of using XOR for dragging/moving
> parts of a graphics image without erasing other parts.  Also, since the
> patent was granted in 1980, the inventors have had their 17 years of patent
> protection, and we're all free to use the technique - legally!

So you approve of 4,197,590 and think it was an innovative and non obvious
invention in 1980?

-Dan

re: XOR [ was: Linux stifles innovation... ]

[Jonathan Morton]

>>  > > > You know XOR is patented (yes, the logical bit operation XOR).

>>  > > 	But wasn't that Xerox that had that?

>>  > US Patent #4,197,590 held by NuGraphics, Inc.

>> The patent was for using the technique of using XOR for dragging/moving
>> parts of a graphics image without erasing other parts.  Also, since the
>> patent was granted in 1980, the inventors have had their 17 years of patent
>> protection, and we're all free to use the technique - legally!
>
>So you approve of 4,197,590 and think it was an innovative and non obvious
>invention in 1980?

Dunno about that, but I have heard of "clever techniques" using XOR in
graphic sprite manipulation being used in microcomputer games in the
early/mid 80's.  No mention of NuGraphics' patent was present - in fact
this code was available in an "Assembly for fun" type book which I still
have a copy of.

The computer on which these techniques was demonstrated was the BBC
Microcomputer, released in 1981 and based on a 2 MHz 6502.  Similar
techniques were doubtless used on games for the Apple ][ which was released
several years previously using a 1 MHz 6502.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----

re: XOR [ was: Linux stifles innovation... ]

[David Relson]

At 09:32 PM 2/16/01, Dan Hollis wrote:
>On Fri, 16 Feb 2001, David Relson wrote:
> > At 08:52 PM 2/16/01, you wrote:
> >  > On Fri, 16 Feb 2001, Michael H. Warfield wrote:
> >  > > > You know XOR is patented (yes, the logical bit operation XOR).
> >  > >  But wasn't that Xerox that had that?
> >  > US Patent #4,197,590 held by NuGraphics, Inc.
> > The patent was for using the technique of using XOR for dragging/moving
> > parts of a graphics image without erasing other parts.  Also, since the
> > patent was granted in 1980, the inventors have had their 17 years of patent
> > protection, and we're all free to use the technique - legally!
>
>So you approve of 4,197,590 and think it was an innovative and non obvious
>invention in 1980?
>
>-Dan


Dan,

No, I didn't say I approved of the patent.  I merely reported a bit of the 
when and what of the patent and said that that is no longer relevant, i.e. 
it's not a concern.

I don't approve of software patents.  I think the idea of granting software 
patents is a bad idea.  As programmers solving problems everyday, we are 
constantly developing techniques for dealing with new problems or finding 
new and better solutions for old problems.  This is a process of continuous 
invention carried out simultaneously and independently in many 
places.  Putting patent restrictions on this process is a bad idea.

David



--------------------------------------------------------
David Relson                   Osage Software Systems, Inc.
relson@osagesoftware.com       Ann Arbor, MI 48103
www.osagesoftware.com          tel:  734.821.8800

Re: XOR [ was: Linux stifles innovation... ]

[brian]

>  > On Fri, 16 Feb 2001, Michael H. Warfield wrote:
>  > > > You know XOR is patented (yes, the logical bit operation XOR).
>  > > 	But wasn't that Xerox that had that?

>  > US Patent #4,197,590 held by NuGraphics, Inc.

On Fri, Feb 16, 2001 at 09:20:34PM -0500, David Relson wrote:
> The patent was for using the technique of using XOR for dragging/moving 
> parts of a graphics image without erasing other parts.  Also, since the 
> patent was granted in 1980, the inventors have had their 17 years of patent 
> protection, and we're all free to use the technique - legally!

In 1984 I received a demand letter for $10,000 from the above
referenced company as a unlimited license for use of a that
patent and another patent.

At the time I ran a company that made graphics cards for IBM PCs.

-- 
Brian Litzinger <brian@worldcontrol.com>

    Copyright (c) 2000 By Brian Litzinger, All Rights Reserved

Re: XOR [ was: Linux stifles innovation... ]

[Dan Hollis]

On Sat, 17 Feb 2001 brian@worldcontrol.com wrote:
> In 1984 I received a demand letter for $10,000 from the above
> referenced company as a unlimited license for use of a that
> patent and another patent.
> At the time I ran a company that made graphics cards for IBM PCs.

Did you ignore it or did you pay up?

FWIW I recall there was prior art dating back to 1974 at the very least...

-Dan

Re: Linux stifles innovation...

[James Sutherland]

On Fri, 16 Feb 2001, Michael H. Warfield wrote:

> On Fri, Feb 16, 2001 at 04:35:02PM -0800, Dan Hollis wrote:
> > On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:
> > > I did some research on the patent database and found nothing regarding such
> > > a patent. There's patent on word processors (not the concept but related to)
> > > and uses tab on the description...and that patent is from 1980.
> 
> > You know XOR is patented (yes, the logical bit operation XOR).
> 
> 	But wasn't that Xerox that had that?  Yeah, the same ones that
> screwed us over with the compression patent that shot .gif images out
> of the sky.  There was inovation for you.

That was Unisys, and it is certainly more innovative than XOR. (Or even
FFT, which is also now patented in one form...)


James.

Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

mhw@wittsend.com (Michael H. Warfield) writes:

>	But wasn't that Xerox that had that?  Yeah, the same ones that
>screwed us over with the compression patent that shot .gif images out
>of the sky.  There was inovation for you.

Wrong company. You may want to check your facts before bashing.


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Linux stifles innovation...

[James Sutherland]

On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:

> I did some research on the patent database and found nothing regarding such
> a patent. There's patent on word processors (not the concept but related to)
> and uses tab on the description...and that patent is from 1980.

Perhaps that's it, then. Or maybe the story is a little distorted. No
doubt you've spotted that IBM does have quite a significant portfolio of
patents, though!


James.

Re: Linux stifles innovation...

[LA Walsh]

"David D.W. Downey" wrote:
> 
> Seriously though folks, look at who's doing this!
> 
> They've already tried once to sue 'Linux', were told they couldn't because
> Linux is a non-entity (or at least one that they can not effectively sue
> due to the classification Linux holds), ...
---
	Not having a long memory on these things, do you have an article
or reference on this -- I'd love to read about that one.  Sue Linux?  For
what?  Competing?  

	Perhaps by saying Open Source is a threat to the "American Way", they
mean they can't effectively 'sue', buy up or destroy it?  

-l

-- 
L A Walsh                        | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338

Re: Linux stifles innovation...

[Helge Hafting]

They are wrong about linux stifling innovation, there
is plenty of innovation in linux itself.

On the other hand:
''I can't imagine something that could be worse than this 
for the software business and the intellectual-property business.''

Sure.  Linux *is* bad for the IP business.  Open source outcompetes it!
I see no problem with that though.  And those who want to get
paid for computing work?  No problem.  There is always support.

Helge Hafting

Re: Linux stifles innovation...

[James Sutherland]

On Fri, 16 Feb 2001, Helge Hafting wrote:

> They are wrong about linux stifling innovation, there is plenty of
> innovation in linux itself.

Indeed. If Linux did nothing new, what do they have to fear?!

> On the other hand:
> ''I can't imagine something that could be worse than this 
> for the software business and the intellectual-property business.''

Linux IS (part of) the software business, though! That's like saying
Walmart is bad for shops - it is bad for OTHER, COMPETING shops.

> Sure.  Linux *is* bad for the IP business.  Open source outcompetes it!

Eh? Linux IS intellectual property! OK, those in the OSS community are
rather less litigious AFAICS, which is bad for IP *lawyers* - in much the
same way antibiotics are "bad" for diseases...

> I see no problem with that though.  And those who want to get
> paid for computing work?  No problem.  There is always support.

Hrm. Getting paid to write code is preferable, IMHO...


James.

Re: Linux stifles innovation...

[Helge Hafting]

James Sutherland wrote:

> > I see no problem with that though.  And those who want to get
> > paid for computing work?  No problem.  There is always support.
> 
> Hrm. Getting paid to write code is preferable, IMHO...

You can still get paid for writing something new.  I have heard about
businesses that write open source software on order.  I.e. customer
pay for customizing an open source package the company knows well,
then they release the extensions too.

Helge Hafting

Re: Linux stifles innovation...

[Joseph Pingenot]

>> On the other hand:
>> ''I can't imagine something that could be worse than this 
>> for the software business and the intellectual-property business.''
>Linux IS (part of) the software business, though! That's like saying
>Walmart is bad for shops - it is bad for OTHER, COMPETING shops.

Actually, I'd contend that it's more like Wal-Mart (oder Aldi) claiming that 
  the Mom-n-Pop store (Tante Emma Laden) down the street is ruining their
  business.  It's the big Goliath coming out once again.

[Unfortunately, I only know the German equivalents of the xlat'ed phrases]
-- 
Joseph==============================================jap3003@ksu.edu
"I felt a great disturbance in the force.  As if a significant plot
  line suddenly cried out in terror... and was suddenly silenced."
                        -Torg in "Sluggy Freelance" www.sluggy.com.

Re: Linux stifles innovation...

[Andrew Scott]

On 15 Feb 2001, at 9:49, fsnchzjr wrote: 

> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> Nice little article on how we're all going to die of herpes from our
> repeated exposition to Linux...
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> g=ltnc

That's about as self-serving a statement as I've ever seen. If this 
'Jim Alchin' actually believes what he's saying, he's got to be one 
of the worlds biggest fools, and if he doesn't believe what he's 
saying, well there aren't too many words that would accurately 
describe what he is. 

It's pretty funny in some ways, e.g. "We can build a better product 
than Linux...", which begs the question, "Well, why don't you?". 
Perhaps it costs too much? 





------------------Mailed via Pegasus 3.12c & Mercury 1.48---------------
A.J.Scott@casdn.neu.edu                    Fax (617)373-2942
Andrew Scott                               Tel (617)373-5278   _
Northeastern University--138 Meserve Hall                     / \   /
College of Arts & Sciences-Deans Office                      / \ \ /
Boston, Ma. 02115                                           /   \_/

Re: Linux stifles innovation...

[Jesse Pollard]

On Fri, 16 Feb 2001, Andrew Scott wrote:
>On 15 Feb 2001, at 9:49, fsnchzjr wrote: 
>
>> Watch Microsoft's Jim Allchin go Linux-bashing!!!
>> Nice little article on how we're all going to die of herpes from our
>> repeated exposition to Linux...
>> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
>> g=ltnc
>
>That's about as self-serving a statement as I've ever seen. If this 
>'Jim Alchin' actually believes what he's saying, he's got to be one 
>of the worlds biggest fools, and if he doesn't believe what he's 
>saying, well there aren't too many words that would accurately 
>describe what he is. 
>
>It's pretty funny in some ways, e.g. "We can build a better product 
>than Linux...", which begs the question, "Well, why don't you?". 
>Perhaps it costs too much? 

Actually, the question should be "Well, why didn't you?"
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

Re: Linux stifles innovation...

[Dennis]

At 02:48 PM 02/16/2001, Jesse Pollard wrote:
>On Fri, 16 Feb 2001, Andrew Scott wrote:
> >On 15 Feb 2001, at 9:49, fsnchzjr wrote:
> >
> >> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> >> Nice little article on how we're all going to die of herpes from our
> >> repeated exposition to Linux...
> >> 
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> >> g=ltnc
> >
> >That's about as self-serving a statement as I've ever seen. If this
> >'Jim Alchin' actually believes what he's saying, he's got to be one
> >of the worlds biggest fools, and if he doesn't believe what he's
> >saying, well there aren't too many words that would accurately
> >describe what he is.
> >
> >It's pretty funny in some ways, e.g. "We can build a better product
> >than Linux...", which begs the question, "Well, why don't you?".
> >Perhaps it costs too much?

objective, arent we?

There is much truth to the concept, although Microsoft should not be ones 
to comment on it as such.

For example, if there were six different companies that marketed ethernet 
drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
with different "features" that were of value to you. Instead, you have 
crappy GPL code that locks up under load, and its not worth spending 
corporate dollars to fix it because you have to give away your work for 
free under GPL. And since there is a "free" driver that most people can 
use, its not worth building a better mousetrap either because the market is 
too small. So, the handful of users with problems get to "fit it 
themselves", most of whom cant of course.

Theres also the propensity for mediocre stuff to get into the kernel 
because some half-baked programmer was willing to contribute some code. The 
50% of the kernel that remains "experimental" ad infinitum is evidence of that.

The biggest thing that the linux community does to stifle innovation is to 
bash commercial vendors trying to make a profit by whining endlessly about 
"sourceless" distributions and recommending "open-source" solutions even 
when they are wholly inferior. You're only hurting yourselves in the long 
run. In that respect MS is correct, because those with the dollars to 
innovate will stay away.

DB

Re: Linux stifles innovation...

[Alan Cox]

> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> with different "features" that were of value to you. Instead, you have 
> crappy GPL code that locks up under load, and its not worth spending 

Umm I find the driver very reliable. And actually I have choice of two
eepro100 drivers eepro100.c and e100.c so you cant even pick an example.

Of course your keenness to let people write alternative free drivers for
your etinc pci card is extremely well known. Fortunately despite your best
efforts there is now a choice in 2.4

[LONG RANT] Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

alan@lxorguk.ukuu.org.uk (Alan Cox) writes:

>> For example, if there were six different companies that marketed ethernet 
>> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
>> with different "features" that were of value to you. Instead, you have 
>> crappy GPL code that locks up under load, and its not worth spending 

>Umm I find the driver very reliable. And actually I have choice of two
>eepro100 drivers eepro100.c and e100.c so you cant even pick an example.

>Of course your keenness to let people write alternative free drivers for
>your etinc pci card is extremely well known. Fortunately despite your best
>efforts there is now a choice in 2.4

Alan,

the point was (IMHO): "I don't want to compile, check and test". And
yes, this is the point of most commercial companies who want to _use_
an OS and not to develop it. They want to _buy_ a distribution and use
it.  And if it does not work, they want support.

This is fully possible today. Companies that do this kind of business
are all around (Starting with RH, SuSE and Caldera, down to small,
vertical market consulting companies like mine. ;-) )

_BUT_ all these people that want to use Linux ask sometimes for help
outside their vendor contracts, they get told exactly this: "Go away
where. You're not using the "one true source from kernel.org". They're
more locked it with their "open software" than people that use
windows. Because if they ask for help in a M$ support forum, they get
help. Sometimes (most of the times) they have to pay for it but
they're willing to pay. That's the point. They're willing to pay for
help and they don't want to hear "fuck off and get xxx Linux instead
of yyy Linux". Or "fuck off and use zmailer, only idiots still use
sendmail". 

Or "Recompile your kernel. Check out kernel v2.3.99pre7-ac8 with the
latest patch from Andrea Arcangeli" (And most of the times they as
themselves, who is this Andrea-gal anyway? ;-) (SCNR))"

If someone comes to a "free software" group and is even proposing
<other unix> - Linux heterogenous environments or (gods beware)
Windows <-> Linux environments, they're flamed down with the wrath of
god by the self-appointed "Free Software Advocats" and part time
CS-hackers. "Use open source" may be even the most friendly answer
that you get. 

Look at the ECN discussion. Look at the NFS discussion. Look at the IP
fragmentation discussion. Most non-technical people don't want to hear
"you can't connect from your company proxy to hotmail because they're
braindead with their firewalls and don't wanna listen". They hear this
once, they hear this twice, they fire their consultant and get M$
Proxy Server. At least they can now _sometimes_ connect to Hotmail (if
the proxy is not down. ;-) )

I mean, look: This is a "community" where people fight over
distributions of _one_ operation system like over the way to
salvation.  Look at the "comments" about the RH shipped compiler or
the SuSE / RH patched kernels. I can quote you mails that I got about
"RedHat lusers" just because people use the shipped stuff. This is
"community"?

And what did we get? Face it:

The state of the drivers in the linux kernel is abysmal. How many of
the drivers are really vendor-supported? Some vendors got flamed for
giving parts of their code or even their whole driver code away
instead of being helped by the community (Intel, Lucent, to name a
few).

And if a company takes a bold step and releases the source to one of
their core products (Netscape), what happens? Open Source developers
run away once they realize, _how_ complex planned and engineered (and
unfortunately grown) multiplatform source really is. 

I would think, only a very small percentage of the so open source
developers has yet seen a product (Yes, a single system. Not a
collection of lots of small programs like a Linux distribution) with
more than 1 GByte Source code in four different languages (with by the
way controls real world hardware like nuclear power stations) and had
to maintain such code. How much source is the linux kernel if you
subtract the drivers and take only one architecture. 5 MBytes? 10?
We're talking an order of magnitudes bigger here.

Take printing and font rendering (which is one of my most favourite
pet peeves because here, Linux is _so far_ behind Windows that it
doesn't even start to see their tail lights in the distance):

The state of driver for printing or font rendering on the desktop is
terrible. You may rant about M$ all the time, but if I buy a new
printer, I get a driver which produces printouts like on my screen and
like my last printer. I get all the nifty features supported that this
printer has.

Why are there no driver for all this stuff for Linux? I'm sure,
companies would love to hire people to write these drivers. 

Answer (IMHO):

Programmer that can do so is tangled in the "it must be open, free,
GPL" idea. Company wants to make at least some bucks with their
products and the driver is part of the product. So they may want to
release a driver which is "closed source". Uh. I can see the flame
wars in the newsgroups "stay away from brand XX, they're publishing
evil closed source drivers". Better buy brand YY, they have no drivers
at all but you can use Ghostscript to get an inferior and worse
looking printout but have the warm feeling of "all open source".

You can be sure, that Company XX will not repeat their "drivers for
Linux" experiment with such media exposure.

The Linux community must grow. It must grow soon and it must grow
mature. People, even the most narrow minded open source advocates must
accept, that there are people out there, that happliy use
"proprietary", "closed source" and "open source" all along. Yes, you
have to obey the licenses. Yes, you have to point mistakes in
licensing and incompatible licensing out to companies, that make
mistakes. But at least I would be happy if there would be a printing
engine that is entirely open source and all the printer vendors can
write a small, closed source stub that drives their printer over
parallel port, ethernet or USB and give us all the features, that the
Linux _USERS_ (and these are the people that count) want. But even if
there is such an engine written for Gnome or KDE, some really
ingenious "free software advocate" will slap a "must not be used with
any kind of non-GPL driver" on it and all the printer vendors will
give you the finger.

And Billg is the one that wins.

The whole Linux community is using closed-source/open-source all along
for years: Netscape. Star Office. To name a few. Why is it so hard to
accept, that at least some people or companies are willing to offer
support for their products but not with their source? I charge these
companies for my support but I have no problem with their tools. I
even buy them (and get ripped off like with Cygnus Source Navigator :-( ).

And if you really read till here: No, I'm not an M$ advocate. I use M$
products for four things: Word, Excel, Powerpoint and my finance
software. I have to use M$ because there are no alternatives for Linux
that are acceptable in a professional, cross-company environment. If I
tell a customer "I can't open that document in Star Writer", they
start laughing.

But I spent some of my earlier years in a community which was soooo
much like the Linux community today: The Amiga environment. And it saw
it wither and die just because of this kind of in-fighting which
programming language to use to write the Word-Killer (C or Modula)
instead of _WRITING_ the Word-Killer.

I'm using Linux since seven years now. I don't want to lose it. But
then again, Linux must grow. I'm too old to switch to Windows now. ;-)

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [LONG RANT] Re: Linux stifles innovation...

[Russell King]

*** Please drop me from the CC: and To: lists before replying to this.
*** I do read linux-kernel, so there is no need to send me two copies
*** of your replies.

Henning P. Schmiedehausen writes:
> But at least I would be happy if there would be a printing
> engine that is entirely open source and all the printer vendors can
> write a small, closed source stub that drives their printer over
> parallel port, ethernet or USB and give us all the features, that the
> Linux _USERS_ (and these are the people that count) want.

Speaking as a Linux _USER_, if this happens, can I get said print
engine working on my ARM machines with these closed source drivers?
Can Alpha users get this print system working?  Can Sparc uses
get it working?  What?  I can't?  They can't?  Well, its no good to
me nor them.  You've just made the system x86 specific.  Well done,
thats a step backwards, not forwards.

Oh please nice big corporation, can you please build said closed
source stub for ARM?  No?  Why?  You don't see the point?

Ah, golly, I'll just have to throw my ARM machines away because
we have some critical parts of the system which are closed source.

> But even if there is such an engine written for Gnome or KDE, some
> really ingenious "free software advocate" will slap a "must not be
> used with any kind of non-GPL driver" on it...

Good.  I build the stuff to work on my ARM machines.

> The whole Linux community is using closed-source/open-source all along
> for years: Netscape. Star Office.

They don't work on ARM though, do they?  Gee, I guess ARM Ltd ought to
stop my contract because what use is an ARM kernel without everything
else to go with it?

For me, closed source is _REALLY_ bad news.  _EXTREMELY_ bad news.
It 100% prevents me from doing stuff.

Its really good that the Linux community is so open.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P . Schmiedehausen]

On Sat, Feb 17, 2001 at 01:37:58PM +0000, Russell King wrote:

> Henning P. Schmiedehausen writes:
> > But at least I would be happy if there would be a printing
> > engine that is entirely open source and all the printer vendors can
> > write a small, closed source stub that drives their printer over
> > parallel port, ethernet or USB and give us all the features, that the
> > Linux _USERS_ (and these are the people that count) want.
> 
> Speaking as a Linux _USER_, if this happens, can I get said print
> engine working on my ARM machines with these closed source drivers?
>
> Can Alpha users get this print system working?  Can Sparc uses
> get it working?  What?  I can't?  They can't?  Well, its no good to
> me nor them.  

Maybe not. But you can use this print engine API to pay anyone to
write a driver for you. What you just said, is exactly my point. You
said:

"If a company does not write a driver which works on all hardware
 platforms in all cases and gives us the source, then it is better,
 that the company writes no drivers at all."

"If I can't force a company to write a driver for everyone, then I
 don't want to write them any driver at all."

IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

> You've just made the system x86 specific.  Well done, thats a step
> backwards, not forwards.

No. Some Linux users got a driver that works as well as the drivers
for another OS. This is good for Linux. And all Linux users and
developers got an open, stable API, which is supported by big printer
vendors and enables everyone to write good drivers.

If you need a printer driver for the ARM, you're able to approach the
company XXX and either pay for an ARM specific driver (and they will
listen to you because they already have made a driver for another
Linux platform, learned that they can make money with Linux software
and have experience with driver(s) for Linux. And it will be just a
recompile most of the time).

> Ah, golly, I'll just have to throw my ARM machines away because
> we have some critical parts of the system which are closed source.

We're talking about a driver. If Company XX won't sell it to you for
your architecture, it's their right to do so. There is software that
I've written that you might want to have, too. If I chose not to sell
it to you, what do you do? You can say "company XX sucks" and buy an
equal product with an ARM driver from YY which listens to you. _THAT_
is IMHO open. Not forcing everyone to comply with your ideology.

> > But even if there is such an engine written for Gnome or KDE, some
> > really ingenious "free software advocate" will slap a "must not be
> > used with any kind of non-GPL driver" on it...
> 
> Good.  I build the stuff to work on my ARM machines.

Can you get a Legato Networker Client for Linux-ARM? Can you get one for
Linux-MIPS? Why? Because someone payed for the port.

> They don't work on ARM though, do they?  Gee, I guess ARM Ltd ought to
> stop my contract because what use is an ARM kernel without everything
> else to go with it?
> 
> For me, closed source is _REALLY_ bad news.  _EXTREMELY_ bad news.
> It 100% prevents me from doing stuff.

No. It means, that for some programs, in order to have them, you have
to pay. That is fine. There ain't no such thing as a free lunch. You
may, of course, chose not to pay, but then you may not be able to use
a certain program.

Look, I'm willing to pay money for the whole M$ Office Suite on
Linux. Yes.  I would give billg gladly a big chunk of my money to get
this application suite on Linux. Not a copy or a "just almost like M$
Office". But the real thing. The real "M$ Office 2k" suite for Linux.

Can I?  No. Because M$ chose not to offer its product for Linux. Bad
for me. It means, that I can not get parts of my work done on Linux.
Can I buy AutoCAD? Photoshop? Quicken? Outlook? Visio? Not look alikes
or clones or "almost as good as". But the real thing with the same
support as on Windows. I can for the Mac. Why can't I for Linux?

Because IMHO some companies shy away from the aggressive and sometime
openly hostile behaviour of the Open Source community ("If you don't
support your application on Linux/SPARC with an B/W framebuffer, you
suck. Go away") towards commercial companies.  ("If you don't support
Gnome 1.0 but just KDE 2.1, you suck. Go away"). And billg laughs and
just points the confused companies towards the "stable" and "easy to
use" M$ OS.

And the volatile APIs which are immature in some points (Font handling. 
Printer support. Color handling. Same things all the time. But displaying 
the results of your work and printing them onto paper is for many
people the most important thing. And frankly, Linux sucks here).

In your opinion, it is better, that I can't get some programs at all
than paying money for them.

In my opinion, I prefer to get it at least for i386/Linux than not to
get them at all. Because if I can't get them for i386/Linux, I must
get them for i386/Windows. Because I need a specific application. 
Not a specific OS architecture.

> Its really good that the Linux community is so open.

So tolerate the fact that some companies chose to release a program as
closed source for only one Linux platform. It is better than not
releasing at all.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [LONG RANT] Re: Linux stifles innovation...

[Felix von Leitner]

Thus spake Henning P . Schmiedehausen (hps@intermeta.de):
> "If a company does not write a driver which works on all hardware
>  platforms in all cases and gives us the source, then it is better,
>  that the company writes no drivers at all."

> "If I can't force a company to write a driver for everyone, then I
>  don't want to write them any driver at all."

> IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

Henning, what is the matter with you?

I bought the hardware.  Why should I pay for the driver?
Not even on Windows you pay extra for a driver!

Please state your intentions.  Why would you want to split the Linux
user base into people who pay companies to screw them (I get a driver
for hardware I already paid for, but the driver will work with exactly
one kernel version on one hardware) and people who think they deserve
support when they buy hardware?

Why do we even have to discuss drivers?
A company that actively hinders developing a good driver with patents,
NDAs or other legal crap does not deserve my money.  If you throw your
money at such people, you deserve everything you get.

Felix

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4902 bytes --]

leitner@convergence.de (Felix von Leitner) writes:

>Thus spake Henning P . Schmiedehausen (hps@intermeta.de):
>> "If a company does not write a driver which works on all hardware
>>  platforms in all cases and gives us the source, then it is better,
>>  that the company writes no drivers at all."

>> "If I can't force a company to write a driver for everyone, then I
>>  don't want to write them any driver at all."

>> IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

>Henning, what is the matter with you?

The matter with me is: "Vendors AAA ships its hardware product with a
driver for i386/Linux". The driver may be closed source, but at least
there _is_ a driver. Russell now says: "This is bad, because I can't use
the driver for my ARM box. So the vendor should ship no driver at
all. This is better than a i386-only driver". 

I say "I'm happy that there is _ANY_ driver at all. Because the vendor
has recognized the importance of Linux at least on i386. And if they
did this and they see, that they _can_ get market share, maybe they
will start thinking about releasing for other architectures, too. Or
even release the source to their driver".

And if someone wants a driver for the hardware of vendor AAA on ARM
and vendor AAA does decide _not_ to release the product for ARM, it is
their right to do so. 

And Russell may still approach AAA to release an ARM driver, too. Or
buy a product from BBB, which does support ARM with either a
vendor-supported close source driver or an open source driver.

Someone approached Legato to release a MIPS/Linux version of their
backup client. Maybe they even paid for the port. And now, everyone
can get this client from the Legato website. It is still closed
source, but still, everyone that has a MIPS/Linux box benefited from
this. 

>I bought the hardware.  Why should I pay for the driver?

If the hardware is "NOT SUPPORTED BESIDES LINUX/i386" and you have an
ARM, the solution is simple: DON'T BUY IT. VOTE WITH YOUR MONEY. If
Linux/ARM starts becoming a sigificant part of the market share,
vendor AAA will either lose to vendor BBB or release a driver for ARM.

>Please state your intentions.  Why would you want to split the Linux
>user base into people who pay companies to screw them (I get a driver
>for hardware I already paid for, but the driver will work with exactly
>one kernel version on one hardware) and people who think they deserve
>support when they buy hardware?

If you buy a hardware and on the box is stated "Supported on Windows,
MacOS and Linux/i386" and you have none of these platforms, why buy
it? If you buy it and then start complaining "it is not vendor-
supported on Linux/ARM", it is your fault and not the fault of the
vendor. If the vendor puts a second box next to the hardware box on
the shelves, which just contains a CD-ROM with a binary only driver
for Linux/ARM and sells this box for $99, it's their right to do
so. And Russell can buy a vendor supported driver for Linux/ARM.

>Why do we even have to discuss drivers?
>A company that actively hinders developing a good driver with patents,
>NDAs or other legal crap does not deserve my money.  If you throw your
>money at such people, you deserve everything you get.

That's exactly my point. Nice to see, that we agree. ;-) See
above. Vote with your money. But IMHO it's better to get
vendor-supported drivers for Linux/i386, than no driver at
all. Because if these drivers do not work, I _can_ call the company
and complain.

And I actively _DON'T_ want _YOU_ to decide what _I_ want. If I can
get a driver for the hardware XXX that I need for a project and vendor
AAA sells me a driver for this product on Linux only for a certain
platform, kernel version and distribution, it is _MY_ _PERSONAL_
_DECISION_ to still buy this driver or not. I don't want anyone to
tell me "you must not do this, because it's bad". If it's bad or not,
please let me decide. I'm old enough to decide for myself.

I WANT THE CHOICE. If I have no choice, I buy the product on another
platform.

And you can be sure, I will not come running to LKM to complain and
demand support.

And you can even sue if you're in Germany and the driver does not work
as stated on the box("Erfüllung zugesicherter Eigenschaften, Nach-
besserung oder Wandlung").

	Regards
		Henning

P.S.: I consider "configuring a mailer so that it does not accept mail
from a sender" neither good style nor "das letzte Wort" in a discussion. 
It is IMHO a sign of weakness and inability to discuss on an objective
base. It is more like "I don't like your opinion, so I censor you".
Discussion, Microsoft-style.

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

I wrote:

>The matter with me is: "Vendors AAA ships its hardware product with a
>driver for i386/Linux". The driver may be closed source, but at least
>there _is_ a driver. Russell now says: "This is bad, because I can't use
>the driver for my ARM box. So the vendor should ship no driver at
>all. This is better than a i386-only driver". 

Russell told me, that this is not what he said. I seem to have
over-interpreted his statements. I apologize for that.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [LONG RANT] Re: Linux stifles innovation...

[Russell King]

Henning P. Schmiedehausen writes:
> The matter with me is: "Vendors AAA ships its hardware product with a
> driver for i386/Linux". The driver may be closed source, but at least
> there _is_ a driver. Russell now says: "This is bad, because I can't use
> the driver for my ARM box. So the vendor should ship no driver at
> all. This is better than a i386-only driver". 

I thank you again to NOT put words in my mouth that I didn't say.

> If the hardware is "NOT SUPPORTED BESIDES LINUX/i386" and you have an
> ARM, the solution is simple: DON'T BUY IT. VOTE WITH YOUR MONEY. If
> Linux/ARM starts becoming a sigificant part of the market share,
> vendor AAA will either lose to vendor BBB or release a driver for ARM.

When there is no vendor BBB to supply such a driver?  This is my point.

> And Russell can buy a vendor supported driver for Linux/ARM.

Not possible.  There are none at the present time, and have been none
over the past 8 years for ARM Linux.  Only recently, because of the hard
work put into ARM Linux by the ARM community as a whole have the ARM
vendors started to take Linux seriously.  There are now around 50 or
so different ARM machines that can run Linux, but most of them are not
of a PC form factor.  All of them are committed to open source.  None
of them write printer drivers.  In fact, for a vast majority of them
a printer driver would not make sense.

> And I actively _DON'T_ want _YOU_ to decide what _I_ want.

I don't want to tell you want you want either.  Neither do I want
you putting words into my mouth that I did not say.  IMHO if you
carry on in this light, and you have been shouted down for doing
so, I am in full support of those who shouted you down, whether they
be in the open source, closed source or whatever arena you care to
think of.

As a mark of good nature, I will dismiss all of your mistakes thus far.
However, if you carry on mis-representing and mis-quoting me in this way,
then I shall have to demand a full public appology, and demand that you
decist in doing so.

> I WANT THE CHOICE. If I have no choice, I buy the product on another
> platform.

That is your right.  No one is taking that away from you.  However, I
want the choice to develop what I want, how I want, and allow other
people to contribute to this development.

If you would like to carry this discussion on in private, then I'm quite
willing to accept.  However, it is off-topic for the Linux-Kernel mailing
list.  If you wish to keep this public, then as before, please don't
reply directly to me or CC: me.  Thanks.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [LONG RANT] Re: Linux stifles innovation...

[Russell King]

*** Please don't reply directly to me, either via CC: or To:.
*** I'll pick up any replies via linux-kernel.  Thanks.

Henning P . Schmiedehausen writes:
> Maybe not. But you can use this print engine API to pay anyone to
> write a driver for you. What you just said, is exactly my point. You
> said:
> 
> "If a company does not write a driver which works on all hardware
>  platforms in all cases and gives us the source, then it is better,
>  that the company writes no drivers at all."

That is not what I said.  I said the opposite - "If I company writes a
closed source driver, it will be x86 specific and will ignore the rest
of the Linux community.  However, that company is free to write such
a driver; I won't stop them because I can't stop them."

> "If I can't force a company to write a driver for everyone, then I
>  don't want to write them any driver at all."

Please restate - this sentence does not make sense at all.  No one is
forcing anyone to write drivers.

> IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

Please, don't decend into flame wars.

> If you need a printer driver for the ARM, you're able to approach the
> company XXX and either pay for an ARM specific driver (and they will
> listen to you because they already have made a driver for another
> Linux platform, learned that they can make money with Linux software
> and have experience with driver(s) for Linux. And it will be just a
> recompile most of the time).

Oh, and how many users can afford to pay $10000s for a company to develop
such a driver?  Yes, the driver will cost lots of money because the
company has to put effort into it, and they believe that they won't
see a reasonable return on it.  Also, since the company has its name
to think about, it will want to test it to some degree (I'll mention
here that some drivers seem on MS Windows seem to be untested), which
again adds to the cost.  What you end up with is a price structure
such as:

1. Cost of driver for x86 platform for device x = $50
2. Cost of driver for other platforms for same device x = $10000

Now, can you see an individual person finding $10000 to pay some company
to get the driver?  If you try to, then you're stark raving mad, and
they'll tell you to go away.

Getting closed source software ported by companies is an extremely
expensive business which no user can afford.

There are things that I would really like to say about closed source
software at this point, which will come as no surprise to anyone, but
unfortunately I would get sued to buggery for doing so.  Note however
that they don't relate to the "open source" argument, but to personal
experience of a sector of the software industry.

> We're talking about a driver. If Company XX won't sell it to you for
> your architecture, it's their right to do so. There is software that
> I've written that you might want to have, too. If I chose not to sell
> it to you, what do you do? You can say "company XX sucks" and buy an
> equal product with an ARM driver from YY which listens to you. _THAT_
> is IMHO open. Not forcing everyone to comply with your ideology.

I'm sorry, I think you misinterpreted what I said.  First point - agreed.
Second point - if you choose not to sell it to me, and I have your
hardware product, I will attempt to find out how to make this hardware
product work on ARM, and open source the driver that I come up with.
If I do not have your hardware product, and there are alternatives that
do have usable drivers, then I'll buy theirs instead.

Once the open source driver is out there, then it is a fact of human
nature that people will go for the open source driver.  If the open
source driver is crap, then they have a few choices:

1. berate me and my driver, just like people berate companies
2. improve on the open source driver to make it better
3. buy your driver because its soo much better

Note that at no point have I forced you to write open source drivers here.

> Can you get a Legato Networker Client for Linux-ARM? Can you get one for
> Linux-MIPS? Why? Because someone payed for the port.

Not AFAIK.

> Because IMHO some companies shy away from the aggressive and sometime
> openly hostile behaviour of the Open Source community ("If you don't
> support your application on Linux/SPARC with an B/W framebuffer, you
> suck. Go away") towards commercial companies.  ("If you don't support
> Gnome 1.0 but just KDE 2.1, you suck. Go away"). And billg laughs and
> just points the confused companies towards the "stable" and "easy to
> use" M$ OS.

I'm sorry, I've never approached a company, not even Netscape and said
"you don't support ARM, you suck, go away".  About the only question
that would get asked is "Can you supply a port to ARM", and the answer
will be either "what's ARM?" or "No".  There won't even be a price tag
fixed on it.

> In your opinion, it is better, that I can't get some programs at all
> than paying money for them.

What you're saying here isn't clear.  Can you please restate this bit?

> So tolerate the fact that some companies chose to release a program as
> closed source for only one Linux platform. It is better than not
> releasing at all.

And then we'll be dead in the water.  Thanks, but no thanks.

One of the major points that you're missing is that the people who start
open source projects do not start out with the idea that all commercial
companies have to be flattened and pulverised until they give in.  They
start the project because they think it is a good idea, and they think
that they can do a better job at it.  It is their choice to do that.

After a while, if a company comes along and attempts to get support for
a version of the project that is one, or even two years old, the response
will be "Please upgrade to the latest version".  That is very reasonable,
and even people like M$ will give you that response, so long as you've
paid their support costs.

That response is certainly my response for questions about Linux kernel
2.4.0-test1.  Why?

1. I can't remember, and I don't keep a log of the problems with
   2.4.0-test1.  2.4.0-test1 is a version I choose not to support because
   it is not an officially released stable version.
2. We've fix a lot of problems that were in 2.4.0-test1, and chances are
   that the problem is already fixed.
3. The company is not offering any money for 2.4.0-test1 to be supported.

Now, I'd suggest that if companies that wanted support for old versions
of open-source software were to offer money to the people they were trying
to get support from, the response would not be your suggested "you suck,
go away" but "we'd be pleased to help you.  We'll look into your problem."

Anyway, this is a more or less pointless discussion.  You've got your
ideas and ideals set in your mind, I've got mine.

Thank you for sharing your mind with us.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [LONG RANT] Re: Linux stifles innovation...

[Jacob Luna Lundberg]

> Speaking as a Linux _USER_, if this happens, can I get said print
> engine working on my ARM machines with these closed source drivers?
> Can Alpha users get this print system working?  Can Sparc uses
> get it working?  What?  I can't?  They can't?  Well, its no good to
> me nor them.  You've just made the system x86 specific.  Well done,
> thats a step backwards, not forwards.

Just out of curiosity, why can't the specification be along the lines of a
vendor data file saying ``if you want the printer to do x then say y'' and
``if the printer says x then it means y''.  That ought to add a lot of
functionality right there.  Sure there are evil winprinters that this
wouldn't be enough for but it would be hardware independant, yes?

Or alternatively what about getting vendors to release their source to a
middleman as a trade secret?  The middleman could then release binaries
for the various arches...  Distasteful, but I'd love to be able to use
*all* the features of my Lexmark OptraColor 45...  ;)

-Jacob

Re: [LONG RANT] Re: Linux stifles innovation...

[Peter Samuelson]

[Jacob Luna Lundberg]
> Just out of curiosity, why can't the specification be along the lines
> of a vendor data file saying ``if you want the printer to do x then
> say y'' and ``if the printer says x then it means y''.  That ought to
> add a lot of functionality right there.

Think about it.  A spec based on what you say would be quite easy to
reverse-compile, no?  In which case, obviously the company's IP, such
as it is, is not protected.  In which case, why not just do an open
source driver and be done with it?

The concept of architecture-independent device drivers goes back to
Open Firmware.  But in that case, there is a practical consideration:
the drivers couldn't be compiled down to machine language since they
had to be accessible as-is at boot time.

Peter

Re: [LONG RANT] Re: Linux stifles innovation...

[Ben Ford]

Jacob Luna Lundberg wrote:

>> Speaking as a Linux _USER_, if this happens, can I get said print
>> engine working on my ARM machines with these closed source drivers?
>> Can Alpha users get this print system working?  Can Sparc uses
>> get it working?  What?  I can't?  They can't?  Well, its no good to
>> me nor them.  You've just made the system x86 specific.  Well done,
>> thats a step backwards, not forwards.
> 
> 
> Just out of curiosity, why can't the specification be along the lines of a
> vendor data file saying ``if you want the printer to do x then say y'' and
> ``if the printer says x then it means y''.  That ought to add a lot of
> functionality right there.  Sure there are evil winprinters that this
> wouldn't be enough for but it would be hardware independant, yes?

isn't that what windows *.INF files do?
(don't flame me  I'm not sure about it)

-b

Re: [LONG RANT] Re: Linux stifles innovation...

[Jonathan Morton]

>Henning P. Schmiedehausen writes:
>> But at least I would be happy if there would be a printing
>> engine that is entirely open source and all the printer vendors can
>> write a small, closed source stub that drives their printer over
>> parallel port, ethernet or USB and give us all the features, that the
>> Linux _USERS_ (and these are the people that count) want.
>
>Speaking as a Linux _USER_, if this happens, can I get said print
>engine working on my ARM machines with these closed source drivers?
>Can Alpha users get this print system working?  Can Sparc uses
>get it working?  What?  I can't?  They can't?  Well, its no good to
>me nor them.  You've just made the system x86 specific.  Well done,
>thats a step backwards, not forwards.
>
>Oh please nice big corporation, can you please build said closed
>source stub for ARM?  No?  Why?  You don't see the point?
>
>Ah, golly, I'll just have to throw my ARM machines away because
>we have some critical parts of the system which are closed source.

<SNIP>

I have similar, though less acute, problems with PowerPC.  Because it's
seen as a "smaller market", less work is done on it and less closed-source
software makes it's way onto it.  Try to download a PowerPC version of
Netscape (4.x, not 6) - all you'll find are the MacOS versions, nothing for
Linux.  Fortunately, distro makers manage to have extracted one for
themselves.

As for 680x0...  well I'd love to have been able to use my old Quadra 840av
as a router/firewall/server, but nobody knows how the *hardware* works well
enough to get either Linux or NetBSD working properly on it.  So I wind up
using it as an IRC bot and scanner station, using the old, now unsupported
MacOS 8.1, which will never have it's bugs fixed because Apple considers
ancient hardware not worth it's while.  Fortunately it works well enough
for the job, and I don't have to complain too loudly about it, which is
more than I could say about any (especially recent) Micro$oft product.

Even on x86 I have problems.  I just bought ATI's flashiest new graphics
card - the All-in-Wonder Radeon - and installed it into my "workstation"
PC, which just happens to also have a Win95 partition.  With a little
fiddling, I get the 2D and 3D output features running smoothly, if not yet
optimally, under the latest version of XFree86 and the Linux kernel.  Much
the same goes for the Windows drivers.

Then I start looking for the software to drive the "extra" features, such
as the TV/video input/capture stuff, which is what distinguishes the
All-in-Wonder from the regular Radeon (and which makes it cost 2x as much).
I'll probably eventually find the right drivers for Linux - I know they
exist, if in uncompleted form - but so far I have not found them on the ATI
CDs bundled with the card!  There's a video-editing package bundled, but it
can't do anything without the right driver.

Then I try to run the Video CDs - supposedly in DVD format - and I get
errors about "wrong region code" with no way of changing the region code or
working out which region code I even need, and then the "DVD Player"
crashes Windows solid.  So much for the RIAA and closed source...

So, I have 9 computers in my bedroom.  The Macs (mostly) run MacOS.  The
PCs (mostly) run Linux.  Strange that one of the Linux machines (the most
underpowered and overworked one) has an uptime exceeding 100 days, whereas
I've never had even 4 weeks out of any of the Macs despite the "higher
quality hardware" argument.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----

Re: [LONG RANT] Re: Linux stifles innovation...

[Helge Hafting]

"Henning P. Schmiedehausen" wrote:

> 
> _BUT_ all these people that want to use Linux ask sometimes for help
> outside their vendor contracts, they get told exactly this: "Go away
> where. You're not using the "one true source from kernel.org". They're
> more locked it with their "open software" than people that use
> windows. Because if they ask for help in a M$ support forum, they get
> help. Sometimes (most of the times) they have to pay for it but
> they're willing to pay. That's the point. They're willing to pay for
> help and they don't want to hear "fuck off and get xxx Linux instead
> of yyy Linux". Or "fuck off and use zmailer, only idiots still use
> sendmail".

Microsoft is no better.  MS don't provide all the software that
runs on windows.  Get some product (say, a word processor) that
competes with with MS office.  Then go try getting help when
that word processor have trouble with your new printer.
MS: "Get word instead, only idiots use that word processor.  Or
 try a different printer.  Maybe the vendor has a newer driver."
Printer vendor: "must be a sw problem, it works fine with office"
Word processor vendor: "It works fine with hundreds of printers,
 use something other than that screwball printer of yours."
Been there, done that.

 > Or "Recompile your kernel. Check out kernel v2.3.99pre7-ac8 with the
> latest patch from Andrea Arcangeli" (And most of the times they as
> themselves, who is this Andrea-gal anyway? ;-) (SCNR))"
Nothing wrong with this advice.  Of course the company that prefer
paying for support will simply not see it, the guy they pay for
support will be the one who collect such advice and implement it.

> Look at the ECN discussion. Look at the NFS discussion. Look at the IP
> fragmentation discussion. Most non-technical people don't want to hear
> "you can't connect from your company proxy to hotmail because they're
> braindead with their firewalls and don't wanna listen". They hear this
But you can connect.  Your support guy simply have to turn off ECN.
Distributors don't ship ECN kernels anyway, they aren't stupid.  It is
a default only for those who compile their own kernel.

> The state of driver for printing or font rendering on the desktop is
> terrible. You may rant about M$ all the time, but if I buy a new
> printer, I get a driver which produces printouts like on my screen and
> like my last printer. I get all the nifty features supported that this
> printer has.
Linux surely don't support all the printers out there.  
This fact is no more problem than the fact that "windows don't
run on ARM, 68040, S/390, and a lot of other platforms linux runs on"

A company buy intel compatible machines for running windows.  And they
buy one of the well-supported printers if they want a linux
print server.  Go for a postscript printer, or one of those with
good ghostscript support.  Not a problem at all.

Helge Hafting

Re: [LONG RANT] Re: Linux stifles innovation...

[Werner Almesberger]

Henning P. Schmiedehausen wrote:
> Company wants to make at least some bucks with their
> products and the driver is part of the product. So they may want to
> release a driver which is "closed source".

Usually, the driver doesn't play a large role in product differentiation,
at least not in a positive way. Also, we must balance the value
closed-sourcing the driver may have for a company, against the damage
this does to Linux development.

Now what's at stake ? Look at the Windows world. Also there, companies
could release their drivers as Open Source. Quick, how many do this ?
Almost none. So, given the choice, most companies have defaulted to
closed source. Consistently complaining when a company tries to release
only closed source drivers for Linux seems to generally have the desired
effect of making them change their policy.

So if we'd follow your line of reasoning, we'd end up with almost all
drivers being closed-source. Since drivers are an essential part of any
Linux kernel, this would essentially mean that all of the Linux kernel
would be subjected to the constraints of closed-source development.

Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what
you expect from Linux. After all, you strongly disagree with the main
common denominator of Linux developers, that it be Open Source.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

Re: [LONG RANT] Re: Linux stifles innovation...

[Jeff Garzik]

On Mon, 19 Feb 2001, Werner Almesberger wrote:
> Now what's at stake ? Look at the Windows world. Also there, companies
> could release their drivers as Open Source. Quick, how many do this ?
> Almost none. So, given the choice, most companies have defaulted to
> closed source. Consistently complaining when a company tries to release
> only closed source drivers for Linux seems to generally have the desired
> effect of making them change their policy.

FWIW, -every single- Windows driver source code I've seen has been
bloody awful.  Asking them to release that code would probably result in
embarrassment.  Same reasoning why many companies won't release hardware
specifications...  The internal docs are bad.  Really bad.

	Jeff

Re: [LONG RANT] Re: Linux stifles innovation...

[Nicholas Knight]

----- Original Message -----
From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
To: "Werner Almesberger" <Werner.Almesberger@epfl.ch>
Cc: "Henning P. Schmiedehausen" <hps@tanstaafl.de>;
<linux-kernel@vger.kernel.org>
Sent: Monday, February 19, 2001 3:07 AM
Subject: Re: [LONG RANT] Re: Linux stifles innovation...


> On Mon, 19 Feb 2001, Werner Almesberger wrote:
> > Now what's at stake ? Look at the Windows world. Also there, companies
> > could release their drivers as Open Source. Quick, how many do this ?
> > Almost none. So, given the choice, most companies have defaulted to
> > closed source. Consistently complaining when a company tries to release
> > only closed source drivers for Linux seems to generally have the desired
> > effect of making them change their policy.
>
> FWIW, -every single- Windows driver source code I've seen has been
> bloody awful.  Asking them to release that code would probably result in
> embarrassment.  Same reasoning why many companies won't release hardware
> specifications...  The internal docs are bad.  Really bad.

While I understand that internal docs and source are often simply a mess, I
fail to see why this should prevent a company from releasing specs or
source.
Sure somebody will come along and say "What on earth were you people
THINKING?!", and then they'll get over it and do something useful with the
specs and/or source to the drivers (or if they don't, somebody else will)
I seriously doubt it'd lead to a company seeing a drop in sales because of
it... and even if they did, I'd say it's a calculated risk, as they could
well pick up a higher number of new customers than the number of old
customers they lost due to wider ranging support.
And even if their specs and code were the worst peices of trash on the
planet, I'd still thank them for opening them up to the public.

-NK

Re: [LONG RANT] Re: Linux stifles innovation...

[David Lang]

before you go to far in condemming companies, note that even transmeta is
in this situation with their docs. when Linus was asked about
documentation for the longrun config stuff he stated that whil trasmeta
was planning to release both docs and source, they were not willing to
release them in the state that they are in currently.

and to be perfectly honest, they do have a point, if the internal
documentation is so poor, releaseing it will cause a flood of calls for
clarification of the docs. it's better to spend the time before release to
fix it then to spend the time (a much larger chunk of time) after the
release explaining it multiple times AND fixing the docs.

sometimes companies are not willing to spend that much time on what they
see as a minor market. that's just the fact of life.

the real fix isn't to yell at the companies, it's to show them that it is
a significant market and worth them spending their money there.

David Lang


 On Mon, 19 Feb
2001, Nicholas Knight wrote:

> Date: Mon, 19 Feb 2001 03:28:56 -0800
> From: Nicholas Knight <tegeran@home.com>
> To: Jeff Garzik <jgarzik@mandrakesoft.com>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [LONG RANT] Re: Linux stifles innovation...
>
> ----- Original Message -----
> From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
> To: "Werner Almesberger" <Werner.Almesberger@epfl.ch>
> Cc: "Henning P. Schmiedehausen" <hps@tanstaafl.de>;
> <linux-kernel@vger.kernel.org>
> Sent: Monday, February 19, 2001 3:07 AM
> Subject: Re: [LONG RANT] Re: Linux stifles innovation...
>
>
> > On Mon, 19 Feb 2001, Werner Almesberger wrote:
> > > Now what's at stake ? Look at the Windows world. Also there, companies
> > > could release their drivers as Open Source. Quick, how many do this ?
> > > Almost none. So, given the choice, most companies have defaulted to
> > > closed source. Consistently complaining when a company tries to release
> > > only closed source drivers for Linux seems to generally have the desired
> > > effect of making them change their policy.
> >
> > FWIW, -every single- Windows driver source code I've seen has been
> > bloody awful.  Asking them to release that code would probably result in
> > embarrassment.  Same reasoning why many companies won't release hardware
> > specifications...  The internal docs are bad.  Really bad.
>
> While I understand that internal docs and source are often simply a mess, I
> fail to see why this should prevent a company from releasing specs or
> source.
> Sure somebody will come along and say "What on earth were you people
> THINKING?!", and then they'll get over it and do something useful with the
> specs and/or source to the drivers (or if they don't, somebody else will)
> I seriously doubt it'd lead to a company seeing a drop in sales because of
> it... and even if they did, I'd say it's a calculated risk, as they could
> well pick up a higher number of new customers than the number of old
> customers they lost due to wider ranging support.
> And even if their specs and code were the worst peices of trash on the
> planet, I'd still thank them for opening them up to the public.
>
> -NK
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [LONG RANT] Re: Linux stifles innovation...

[Nicholas Knight]

----- Original Message -----
From: "David Lang" <dlang@diginsite.com>
To: "Nicholas Knight" <tegeran@home.com>
Cc: "Jeff Garzik" <jgarzik@mandrakesoft.com>; <linux-kernel@vger.kernel.org>
Sent: Monday, February 19, 2001 3:36 AM
Subject: Re: [LONG RANT] Re: Linux stifles innovation...


> before you go to far in condemming companies, note that even transmeta is
> in this situation with their docs. when Linus was asked about
> documentation for the longrun config stuff he stated that whil trasmeta
> was planning to release both docs and source, they were not willing to
> release them in the state that they are in currently.
>

Yes I did read what Linus said, and I did consider that when I wrote this, I
still don't feel that it should stop them if they plan to release it and it
might be quite some time before they have it in what they consider a
releasable state (if a company wants to clean things up before releasing
them, great, but if it's going to be a while, I'm saying that they
should *consider* simply releasing them in a given state)

> and to be perfectly honest, they do have a point, if the internal
> documentation is so poor, releaseing it will cause a flood of calls for
> clarification of the docs. it's better to spend the time before release to
> fix it then to spend the time (a much larger chunk of time) after the
> release explaining it multiple times AND fixing the docs.
>
> sometimes companies are not willing to spend that much time on what they
> see as a minor market. that's just the fact of life.
>
> the real fix isn't to yell at the companies, it's to show them that it is
> a significant market and worth them spending their money there.

Please understand that I'm not really condemming anyone or anything, I
saying that I did not see the point in keeping it all closed simply because
the source/docs are a mess.
I do understand that they may have reason for not wanting to release things
in that state, but I'm not sure it should stop them if at all possible, as
even messy, undocumented code, and bad spec sheets, is better than nothing
at all.

There's something else I was going to add in my original note but failed to.
(warning, painfully obvious paragraph ahead)
I belive that if companies would write drivers and specs from the beginning
with the intention of releasing at least the specs if not the specs and
source, then we'd probably wind up with better products as well as cleaner
code and spec sheets.
Prehaps it's time someone gave the companies a little nudging (possibly with
a penguin beak? :).

>
> David Lang
>

-NK

>
>  On Mon, 19 Feb
> 2001, Nicholas Knight wrote:
>
> > Date: Mon, 19 Feb 2001 03:28:56 -0800
> > From: Nicholas Knight <tegeran@home.com>
> > To: Jeff Garzik <jgarzik@mandrakesoft.com>
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: [LONG RANT] Re: Linux stifles innovation...
> >
> > ----- Original Message -----
> > From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
> > To: "Werner Almesberger" <Werner.Almesberger@epfl.ch>
> > Cc: "Henning P. Schmiedehausen" <hps@tanstaafl.de>;
> > <linux-kernel@vger.kernel.org>
> > Sent: Monday, February 19, 2001 3:07 AM
> > Subject: Re: [LONG RANT] Re: Linux stifles innovation...
> >
> >
<snip>
> > While I understand that internal docs and source are often simply a
mess, I
> > fail to see why this should prevent a company from releasing specs or
> > source.
> > Sure somebody will come along and say "What on earth were you people
> > THINKING?!", and then they'll get over it and do something useful with
the
> > specs and/or source to the drivers (or if they don't, somebody else
will)
> > I seriously doubt it'd lead to a company seeing a drop in sales because
of
> > it... and even if they did, I'd say it's a calculated risk, as they
could
> > well pick up a higher number of new customers than the number of old
> > customers they lost due to wider ranging support.
> > And even if their specs and code were the worst peices of trash on the
> > planet, I'd still thank them for opening them up to the public.
> >
> > -NK

Re: [LONG RANT] Re: Linux stifles innovation...

[Jeff Garzik]

On Mon, 19 Feb 2001, Nicholas Knight wrote:
> From: "Jeff Garzik" <jgarzik@mandrakesoft.com>

> > FWIW, -every single- Windows driver source code I've seen has been
> > bloody awful.  Asking them to release that code would probably result in
> > embarrassment.  Same reasoning why many companies won't release hardware
> > specifications...  The internal docs are bad.  Really bad.
> 
> While I understand that internal docs and source are often simply a mess, I
> fail to see why this should prevent a company from releasing specs or
> source.
> Sure somebody will come along and say "What on earth were you people
> THINKING?!", and then they'll get over it and do something useful with the
> specs and/or source to the drivers (or if they don't, somebody else will)
> I seriously doubt it'd lead to a company seeing a drop in sales because of
> it... and even if they did, I'd say it's a calculated risk, as they could
> well pick up a higher number of new customers than the number of old
> customers they lost due to wider ranging support.
> And even if their specs and code were the worst peices of trash on the
> planet, I'd still thank them for opening them up to the public.

You might thank them.  The other opinion is... people look at the
newly-released garbage source code, and say "wow, the driver I'm running
is shit.  I'm switching to another type of hardware."  etc.

Maybe harmless, maybe PR disaster.

	Jeff

Re: [LONG RANT] Re: Linux stifles innovation...

[Nicholas Knight]

----- Original Message -----
From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
To: "Nicholas Knight" <tegeran@home.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, February 19, 2001 3:47 AM
Subject: Re: [LONG RANT] Re: Linux stifles innovation...


> On Mon, 19 Feb 2001, Nicholas Knight wrote:
> > From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
>

<snip>

> > While I understand that internal docs and source are often simply a
mess, I
> > fail to see why this should prevent a company from releasing specs or
> > source.
> > Sure somebody will come along and say "What on earth were you people
> > THINKING?!", and then they'll get over it and do something useful with
the
> > specs and/or source to the drivers (or if they don't, somebody else
will)
> > I seriously doubt it'd lead to a company seeing a drop in sales because
of
> > it... and even if they did, I'd say it's a calculated risk, as they
could
> > well pick up a higher number of new customers than the number of old
> > customers they lost due to wider ranging support.
> > And even if their specs and code were the worst peices of trash on the
> > planet, I'd still thank them for opening them up to the public.
>
> You might thank them.  The other opinion is... people look at the
> newly-released garbage source code, and say "wow, the driver I'm running
> is shit.  I'm switching to another type of hardware."  etc.
>
> Maybe harmless, maybe PR disaster.

As I said, calculated risk.
I suppose if it was in a truely horrible state and the company wasn't a
large company such as IBM or HP that could probably afford to take the risk,
I could understand them being unwilling to release the source and spec
sheets.
Double edged swords run rampant in the computer industry... *sigh*

My dream is probably quite similar to that of every geek on earth... open,
standard protocols and API's for *everything* that allows for quick and easy
driver and software development, another layer if you will, but getting
hundreds of companies that tend to be addicted to closed everything to agree
on the standards would probably be next to impossible... prehaps it's time
some thought went into how to make this a reality, or are large scale
efforts for this already going on that I haven't noticed?

>
> Jeff

-NK

Re: [LONG RANT] Re: Linux stifles innovation...

[Werner Almesberger]

Jeff Garzik wrote:
> FWIW, -every single- Windows driver source code I've seen has been
> bloody awful.  Asking them to release that code would probably result in
> embarrassment.

Maybe a good analogy is that drivers are to hardware companies like
excrements are to living creatures: in order to stay alive, they have
to produce them, but you don't put much love into their production,
and their internals (like their development) may be a little
disgusting.

>  Same reasoning why many companies won't release hardware
> specifications...  The internal docs are bad.  Really bad.

A fair number of hardware documents I have came with "here's all the
material you'll need, but please don't show this to anyone" (but no
NDA), which is fine with me: it doesn't complicate development in any
way, and in those few cases where I really needed to share a document,
they were flexible enough to allow this.

Of course, it's better if documentation is entirely in the public too,
but considering the typical overhead of clearing a document for public
release, I can understand why companies frequently don't do it.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P . Schmiedehausen]

On Mon, Feb 19, 2001 at 05:07:02AM -0600, Jeff Garzik wrote:
> On Mon, 19 Feb 2001, Werner Almesberger wrote:
> > Now what's at stake ? Look at the Windows world. Also there, companies
> > could release their drivers as Open Source. Quick, how many do this ?
> > Almost none. So, given the choice, most companies have defaulted to
> > closed source. Consistently complaining when a company tries to release
> > only closed source drivers for Linux seems to generally have the desired
> > effect of making them change their policy.
> 
> FWIW, -every single- Windows driver source code I've seen has been
> bloody awful.  Asking them to release that code would probably result in
> embarrassment.  Same reasoning why many companies won't release hardware
> specifications...  The internal docs are bad.  Really bad.

Because they start off bloody awful examples. From the DDK. And they
have noone to ask but M$. And they hire a student or a contract
company to write a driver after ambigous specs from the DDK.  Or they
just reiterate on a chip-vendor-supported driver again and again
(Quick, can anyone say "NVidia"?). And who certificates (hah!) a
driver written after the DDK to run on an OS? Right, the vendor of
both. =:-)

And the public documentation must be cleared by a lawyer to not
accidentially release IP of another company. And they must be reworked
by a tech writer to be readable for people that "can't go to office
#307 and ask Fred about the wiring details".

All boils down to money, IMHO, not always to bad will. Sometimes,
yes. Most of the time, the CFO will just as the project manager:
"Costs how much? Earns how much?".

I would even like think, that some HW companies would release drivers
as open source if they would be able to find individuals or contract
companies, that are willing to sign NDAs to use the inhouse
information for writing a driver without leaking the information
itself out.

I know of some companies that do that kind of contract work. 
Unfortunately most of the time for more exotic HW.

BTW: Lawyer question: 

"I release a driver as open source under, BSD license. May I put it
into the kernel source tree or must I compile it as a separate
loadable module for not being in GPL violation."

According to my understanding of the loadable module issue and the GPL
of the kernel, I must distribute the source separated from the kernel
source and may only compile as loadable module. 

Would twin licensing solve this? But then I must not pull changes from
the GPL tree back into my BSD tree and distribute this BSD tree under
BSD license, because this license allows a vendor binary only
distribution which is forbidden by the GPL'ed changes. And I must not
pose the "changes to the GPL'ed sources can be pulled back into the
BSD sources" restriction on the tree because then I am already in
violation of the GPL ("must not put additional restrictions on").

So, is it legal to put changes to a twin licensed driver in the Linux
kernel tree back into the same driver in the BSD tree?

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [LONG RANT] Re: Linux stifles innovation...

[Paul Jakma]

On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:

> So, is it legal to put changes to a twin licensed driver in the Linux
> kernel tree back into the same driver in the BSD tree?

IANAL, but AIUI:

if the changes are made the copyright holder then they may do whatever
they want. (release the changes only under one licence, both, none,
etc..)

if small changes are made by a 3rd party (eg a patch) and submitted
back to the copyright holder, then it is almost safe to presume that
the copyright holder may incorporate those changes without ceding
copyright in any way. (then see first point)

if major changes are made by a 3rd party then (i think) 3rd party has
copyright over their changes, and so, either:

-copyright holder of the original work would need to comply with the
licence of the derived work. (eg if GPL, then changes can't go back
into the BSD version)

or:

- copyright holder of the original work would need express permission
from the copyright holder of the derived work to use it under a
different licence.

but IANAL most obviously... :)

>
> 	Regards
> 		Henning

--paulj

Re: [LONG RANT] Re: Linux stifles innovation...

[Alan Cox]

> So, is it legal to put changes to a twin licensed driver in the Linux
> kernel tree back into the same driver in the BSD tree?

Just make it plain that patches and contributions to that driver must be
dual licensed. We have several shared drivers with BSD and most people seem
happy that small fixes to a dual or BSD licensed drivers should go back under
the original license. In fact I'd say I'm not the only one who would find it
impolite otherwise.

Re: [LONG RANT] Re: Linux stifles innovation...

[Jes Sorensen]

>>>>> "Jeff" == Jeff Garzik <jgarzik@mandrakesoft.com> writes:

Jeff> On Mon, 19 Feb 2001, Werner Almesberger wrote:
>> Now what's at stake ? Look at the Windows world. Also there,
>> companies could release their drivers as Open Source. Quick, how
>> many do this ?  Almost none. So, given the choice, most companies
>> have defaulted to closed source. Consistently complaining when a
>> company tries to release only closed source drivers for Linux seems
>> to generally have the desired effect of making them change their
>> policy.

Jeff> FWIW, -every single- Windows driver source code I've seen has
Jeff> been bloody awful.  Asking them to release that code would
Jeff> probably result in embarrassment.  Same reasoning why many
Jeff> companies won't release hardware specifications...  The internal
Jeff> docs are bad.  Really bad.

Trust me, commercial UNIX drivers aren't any better.

Jes

Re: [LONG RANT] Re: Linux stifles innovation...

[Brian May]

>>>>> "Jeff" == Jeff Garzik <jgarzik@mandrakesoft.com> writes:

    Jeff> FWIW, -every single- Windows driver source code I've seen
    Jeff> has been bloody awful.  Asking them to release that code
    Jeff> would probably result in embarrassment.  Same reasoning why
    Jeff> many companies won't release hardware specifications...  The
    Jeff> internal docs are bad.  Really bad.

Speaking as a user, I would much prefer to use an open source driver
that is "bloody awful" rather then a closed source driver that still
might be "bloody awful", unless I am confident that the vendor will
support me if I encounter a bug. (IMHO "bloody awful" means "awfully
buggy").

In the past, I have had a case where my AGFA scanner stopped working,
as the software kept coming up with illegal operation errors.
Technical support were not the least bit interested in helping (no one
else has reported having the same problem), but instead blamed the
problem on my computer (try reinstalling it again, maybe this time it
will work?) Or: bring the scanner in, and if the same problem occurs
on our computer, we will fix it, otherwise we will have to charge you
for testing it.

At one stage I tricked the consultant into copying down the CPU
register information, but I got the strong impression that they
weren't interested in diagnosing the bug (they probably didn't have the
programmers anymore).

I ended up having to reinstall the entire MS-operating system on the
computer so it would work again. However, my feeling is that if I knew
what the problem was, it would have been easy to work around, eg. by
editing the appropriate entry in the system registry. I couldn't do
determine this myself though, without access to the source code.

(the scanner in question died about 1 month after warranty expired,
with very little use, so I went and purchased a HP scanner instead.)
-- 
Brian May <bam@snoopy.apana.org.au>

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P . Schmiedehausen]

On Mon, Feb 19, 2001 at 11:53:14AM +0100, Werner Almesberger wrote:
> Henning P. Schmiedehausen wrote:

> Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what
> you expect from Linux. After all, you strongly disagree with the main
> common denominator of Linux developers, that it be Open Source.

No, I don't. I don't at all. But I prefer a more pragmatic approach to
the developers and companies who don't.

And yes, there _is_ IMHO a difference in telling someone on LKM,
especially someone without deeper knowledge that is lookin for help:

"You're using a non-open source driver, so we can't help you. Please
ask your vendor for support."

and

"Fuck off, <insert binary vendor, software or distribution> Luser".

("Der Ton macht die Musik". Sorry don't know the equal english
expression).

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [LONG RANT] Re: Linux stifles innovation...

[Werner Almesberger]

Henning P . Schmiedehausen wrote:
> No, I don't. I don't at all. But I prefer a more pragmatic approach to
> the developers and companies who don't.

I actually think it's good if we appear to be a little more "hard-liners"
than we really are. If companies assume that only open source will get
them anywhere, they'll err on the safe side. In the end, this is likely
to be to their own benefit: they won't waste time designing not-quite
open models that fail in the end (and may generate a lot of bad blood),
and can focus directly on options that make everybody happy.

> And yes, there _is_ IMHO a difference in telling someone on LKM,
> especially someone without deeper knowledge that is lookin for help:

Yes, also rejection can be delivered in a civilized way.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

Re: [LONG RANT] Re: Linux stifles innovation...

[David Howells]

I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented and seems
to change almost on a week-by-week basis anyway. I've done my share of chasing
the current kernel revision with drivers that aren't part of the kernel tree:
by the time you update the driver to work with the current kernel revision,
there's a new one out, and the driver doesn't compile with it.

David

Re: [LONG RANT] Re: Linux stifles innovation...

[Jeff Garzik]

On Mon, 19 Feb 2001, David Howells wrote:
> I suspect part of the problem with commercial driver support on Linux is that
> the Linux driver API (such as it is) is relatively poorly documented

In-kernel documentation, agreed.

_Linux Device Drivers_ is a good reference for 2.2 and below.

> and seems
> to change almost on a week-by-week basis anyway. I've done my share of chasing
> the current kernel revision with drivers that aren't part of the kernel tree:
> by the time you update the driver to work with the current kernel revision,
> there's a new one out, and the driver doesn't compile with it.

This is entirely in your imagination.  Driver APIs are stable across the
stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18,
2.4.0 through whatever.

	Jeff

Re: [LONG RANT] Re: Linux stifles innovation...

[Mikulas Patocka]

> > I suspect part of the problem with commercial driver support on Linux is that
> > the Linux driver API (such as it is) is relatively poorly documented
> 
> In-kernel documentation, agreed.
> 
> _Linux Device Drivers_ is a good reference for 2.2 and below.

And do implementators of generic kernel functions and developers of device
drivers respect it? And how can they respect it if it's a commercial book?

> > and seems
> > to change almost on a week-by-week basis anyway. I've done my share of chasing
> > the current kernel revision with drivers that aren't part of the kernel tree:
> > by the time you update the driver to work with the current kernel revision,
> > there's a new one out, and the driver doesn't compile with it.
> 
> This is entirely in your imagination.  Driver APIs are stable across the
> stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18,
> 2.4.0 through whatever.

No true. Do you remember for example the mark_buffer_dirty change in some
2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was
changed so that it could block). 

Another example of bug that comes from the lack of specification is
calling of get_free_pages by non-running processes that caused lockups on
all kernels < 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). 

Having documentation could prevent this kind of bugs. You don't need too
long texts, just a brief description: "this function may be called from
process/bh/interrupt context, it may/may not block, it may/may not be
called in TASK_[UN]INTERURPTIBLE state, it may take these locks."

With documentation developers would be able to change implementation of
kernel functions without the need to recheck all drivers that use them. 

Saying "code is the specification" is not good.

Mikulas

Re: [LONG RANT] Re: Linux stifles innovation...

[Jeff Garzik]

On Mon, 19 Feb 2001, Mikulas Patocka wrote:

> > > I suspect part of the problem with commercial driver support on Linux is that
> > > the Linux driver API (such as it is) is relatively poorly documented
> > 
> > In-kernel documentation, agreed.
> > 
> > _Linux Device Drivers_ is a good reference for 2.2 and below.
> 
> And do implementators of generic kernel functions and developers of device
> drivers respect it? And how can they respect it if it's a commercial book?

_Linux Device Drivers_ documents the 2.2 (and previous) API, and
thus refutes the argument that the kernel API is poorly documented.
Since the publication of the book -succeeds- the publication of the
APIs, your questions are not applicable.


> > > and seems
> > > to change almost on a week-by-week basis anyway. I've done my share of chasing
> > > the current kernel revision with drivers that aren't part of the kernel tree:
> > > by the time you update the driver to work with the current kernel revision,
> > > there's a new one out, and the driver doesn't compile with it.
> > 
> > This is entirely in your imagination.  Driver APIs are stable across the
> > stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18,
> > 2.4.0 through whatever.
> 
> No true. Do you remember for example the mark_buffer_dirty change in some
> 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was
> changed so that it could block). 
> 
> Another example of bug that comes from the lack of specification is
> calling of get_free_pages by non-running processes that caused lockups on
> all kernels < 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). 
> 
> Having documentation could prevent this kind of bugs.

Hardly.  No documentation is often -better- than bad documentation.

> You don't need too
> long texts, just a brief description: "this function may be called from
> process/bh/interrupt context, it may/may not block, it may/may not be
> called in TASK_[UN]INTERURPTIBLE state, it may take these locks."
> 
> With documentation developers would be able to change implementation of
> kernel functions without the need to recheck all drivers that use them. 

Anytime you change implementation, you gotta check all drivers that use
them.  I know, I'm one of the grunts that does such reviews and changes.

> Saying "code is the specification" is not good.

I'm not arguing against documentation.  That is dumb.  But the code is
ALWAYS canonical.  Not docs.

	Jeff

The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )

[Mikulas Patocka]

> > > > I suspect part of the problem with commercial driver support on Linux is that
> > > > the Linux driver API (such as it is) is relatively poorly documented
> > > 
> > > In-kernel documentation, agreed.
> > > 
> > > _Linux Device Drivers_ is a good reference for 2.2 and below.
> > 
> > And do implementators of generic kernel functions and developers of device
> > drivers respect it? And how can they respect it if it's a commercial book?
> 
> _Linux Device Drivers_ documents the 2.2 (and previous) API, and
> thus refutes the argument that the kernel API is poorly documented.
> Since the publication of the book -succeeds- the publication of the
> APIs, your questions are not applicable.

What does it say about mark_buffer_dirty blocking or schedule and
TASK_[UN]INTERRUPTIBLE issues? If it says nothing, it is bad
documentation. If it says something, kernel developers do not respect it
and it is useless documentation...

> > > > and seems
> > > > to change almost on a week-by-week basis anyway. I've done my share of chasing
> > > > the current kernel revision with drivers that aren't part of the kernel tree:
> > > > by the time you update the driver to work with the current kernel revision,
> > > > there's a new one out, and the driver doesn't compile with it.
> > > 
> > > This is entirely in your imagination.  Driver APIs are stable across the
> > > stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18,
> > > 2.4.0 through whatever.
> > 
> > No true. Do you remember for example the mark_buffer_dirty change in some
> > 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was
> > changed so that it could block). 
> > 
> > Another example of bug that comes from the lack of specification is
> > calling of get_free_pages by non-running processes that caused lockups on
> > all kernels < 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). 
> > 
> > Having documentation could prevent this kind of bugs.
> 
> Hardly.

Imagine that there is specification of mark_buffer_dirty. That
specification says that
	1. it may not block
	2. it may block

In case 1. implementators wouldn't change it to block in stable kernel
	relese because they don't want to violate the specification.

In case 2. implementators of ext2 wouldn't assume that it doesn't block
	even if it doesn't in current implementation.

In both cases, the bug wouldn't be created.

> No documentation is often -better- than bad documentation.

Of course. But good documentation is better than no documentation :-)

> > You don't need too
> > long texts, just a brief description: "this function may be called from
> > process/bh/interrupt context, it may/may not block, it may/may not be
> > called in TASK_[UN]INTERURPTIBLE state, it may take these locks."
> > 
> > With documentation developers would be able to change implementation of
> > kernel functions without the need to recheck all drivers that use them. 
> 
> Anytime you change implementation, you gotta check all drivers that use
> them.  I know, I'm one of the grunts that does such reviews and changes.

Anytime you change implementation of syscalls, you gotta check all
applications that use them ;-) Luckily not - because there is
specification and you can check that syscalls conform to the
specification, not apps. 

> > Saying "code is the specification" is not good.
> 
> I'm not arguing against documentation.  That is dumb.  But the code is
> ALWAYS canonical.  Not docs.

Let's see:

There are parts of code (1) that set state to TASK_[UN]INTERRUPTIBLE and
then call some other complex functions, like page fault handlers. (for
example tcp in 2.2)

There are parts of code (2) that call schedule to yield the process
assuming that the state is TASK_RUNNING. (including some drivers) 

Sooner or later will happen, that subroutine called from part (1) get
somehow to part (2) and the process locks up.


Now implementators of TCP will say: that driver is buggy. Everybody should
set state=TASK_RUNNING before calling schedule to yield the process. 

Implementators of driver will say: TCP is buggy - no one should call my
driver in TASK_[UN]INTERRUPTIBLE state.

Who is right? If there is no specification....

Mikulas

Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )

[Eric W. Biederman]

Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> writes:

> Imagine that there is specification of mark_buffer_dirty. That
> specification says that
> 	1. it may not block
> 	2. it may block
> 
> In case 1. implementators wouldn't change it to block in stable kernel
> 	relese because they don't want to violate the specification.
> 
> In case 2. implementators of ext2 wouldn't assume that it doesn't block
> 	even if it doesn't in current implementation.

Whenever the question has been asked the answer is always assume anything
in the kernel outside of the current function blocks.  

> In both cases, the bug wouldn't be created.

Nope.  It looks like someone made a mistake in ext2...

> 
> Anytime you change implementation of syscalls, you gotta check all
> applications that use them ;-) Luckily not - because there is
> specification and you can check that syscalls conform to the
> specification, not apps. 

Not normally.  The rule is that syscall don't change period.  The
internal kernel interface is different.  It is allowed to change.

As for syscall changing auditing most apps did happen when the LFS
spec was put together.  So you would have an implementation that would
keep most apps from failing on large files.

> > > Saying "code is the specification" is not good.
> > 
> > I'm not arguing against documentation.  That is dumb.  But the code is
> > ALWAYS canonical.  Not docs.
> 
> Let's see:

> Who is right? If there is no specification....

Hmm.  The developers should get together and pow wow when the problem
is noticed.  When it is finally talked out about how it should happen
then the code should get fixed accordingly.

It isn't about right and wrong it is about working code.  Not that
documenting things doesn't help.  And 2.4 is going in that direction...

Eric

Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )

[Albert D. Cahalan]

Mikulas Patocka writes:

> Imagine that there is specification of mark_buffer_dirty. That
> specification says that
> 	1. it may not block
> 	2. it may block
> 
> In case 1. implementators wouldn't change it to block in stable kernel
> 	relese because they don't want to violate the specification.

One of these things must happen:

a. follow the specification, even if that makes code slow and contorted
b. change the specification
c. ignore the specification
d. get rid of the specification

Option "a" will not be accepted around here. Sorry. The best you can
hope for is option "b". Since that is hard work (want to help?) we
often end up not using a specification... hopefully by just not
having one, instead of by ignoring one.

Not saying it doesn't suck to have things undocumented, but at least
you don't have to reverse-engineer a multi-megabyte binary kernel to
find out what is going on.

>> Anytime you change implementation, you gotta check all drivers that use
>> them.  I know, I'm one of the grunts that does such reviews and changes.
>
> Anytime you change implementation of syscalls, you gotta check all
> applications that use them ;-) Luckily not - because there is
> specification and you can check that syscalls conform to the
> specification, not apps. 

Syscalls are more stable, but they may be changed after many years
of a transition period. The C library hides some of this from users.

> Now implementators of TCP will say: that driver is buggy. Everybody should
> set state=TASK_RUNNING before calling schedule to yield the process. 
> 
> Implementators of driver will say: TCP is buggy - no one should call my
> driver in TASK_[UN]INTERRUPTIBLE state.
> 
> Who is right? If there is no specification....

The driver is buggy, unless the TCP maintainer can be convinced
that TCP is buggy. TCP is a big chunk of code that most people use,
while the driver is not so huge or critical.

The TCP maintainers do not seem to be sadistic bastards hell-bent on
breaking your drivers. API changes usually have a good reason.

Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )

[Mikulas Patocka]

> One of these things must happen:
> 
> a. follow the specification, even if that makes code slow and contorted
> b. change the specification
> c. ignore the specification
> d. get rid of the specification
> 
> Option "a" will not be accepted around here. Sorry.

It should be followed in stable releases. (and usually is - except for few
cases - and except that there is no specification, just unwritten rules).

> The best you can
> hope for is option "b". Since that is hard work (want to help?) we
> often end up not using a specification... hopefully by just not
> having one, instead of by ignoring one.


> > Now implementators of TCP will say: that driver is buggy. Everybody should
> > set state=TASK_RUNNING before calling schedule to yield the process. 
> > 
> > Implementators of driver will say: TCP is buggy - no one should call my
> > driver in TASK_[UN]INTERRUPTIBLE state.
> > 
> > Who is right? If there is no specification....
> 
> The driver is buggy, unless the TCP maintainer can be convinced
> that TCP is buggy. TCP is a big chunk of code that most people use,
> while the driver is not so huge or critical.
> 
> The TCP maintainers do not seem to be sadistic bastards hell-bent on
> breaking your drivers. API changes usually have a good reason.

Why should block device developers read TCP/IP code? And only after
reading significant amount of it they realize that they can be called in
TASK_INTERRUPTIBLE state. 

They will most likely read other block drivers, find using schedule
without setting state and use it also that way. 

The only way to tell developers to always set state before using schedule
is to write it to specification.

Mikulas

Re: The lack of specification

[Russell King]

Albert D. Cahalan writes:
> The TCP maintainers do not seem to be sadistic bastards hell-bent on
> breaking your drivers. API changes usually have a good reason.

And when the API does change, like it has between Linux 2.2 and Linux 2.4,
an email gets sent to this list describing the change of API.  Search
this lists archives to find out:

1. the reasons for the change
2. a complete description of the new bits of the API

There are projects around to try to pick this stuff up and put it on the
web in one place - its called the Kernel Wiki, and iirc it is on
sourceforge.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: The lack of specification

[Eli Carter]

Russell King wrote:
> 
> Albert D. Cahalan writes:
> > The TCP maintainers do not seem to be sadistic bastards hell-bent on
> > breaking your drivers. API changes usually have a good reason.
> 
> And when the API does change, like it has between Linux 2.2 and Linux 2.4,
> an email gets sent to this list describing the change of API.  Search
> this lists archives to find out:
> 
> 1. the reasons for the change
> 2. a complete description of the new bits of the API
> 
> There are projects around to try to pick this stuff up and put it on the
> web in one place - its called the Kernel Wiki, and iirc it is on
> sourceforge.

It's here: http://kernelbook.sourceforge.net:80/wiki/?KernelWiki
BUT.. it's currently dead and has been since December.
I'd really like to see this brought back...

Eli
--------------------.              Rule of Accuracy: When working toward
Eli Carter          |               the solution of a problem, it always 
eli.carter@inet.com `--------------------- helps if you know the answer.

Re: [LONG RANT] Re: Linux stifles innovation...

[Richard B. Johnson]

On Mon, 19 Feb 2001, Jeff Garzik wrote:

> On Mon, 19 Feb 2001, David Howells wrote:
> > I suspect part of the problem with commercial driver support on Linux is that
> > the Linux driver API (such as it is) is relatively poorly documented
> 
> In-kernel documentation, agreed.
> 
> _Linux Device Drivers_ is a good reference for 2.2 and below.
> 
> > and seems
> > to change almost on a week-by-week basis anyway. I've done my share of chasing
> > the current kernel revision with drivers that aren't part of the kernel tree:
> > by the time you update the driver to work with the current kernel revision,
> > there's a new one out, and the driver doesn't compile with it.
> 
> This is entirely in your imagination.  Driver APIs are stable across the
> stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18,
> 2.4.0 through whatever.
> 
> 	Jeff
> 

One of the latest module killers was the opaque type, "THIS_MODULE",
put at the beginning of struct file_operations. This happened between
2.4.0 and 2.4.x.  So it's not "imagination".

It is well understood that there will be changes to the driver APIs, but
some could be better thought out to accomplish what must be accomplished,
but at the same time, minimize the code changes to existing drivers.

While on the subject of compatibility, I just put 1 gb of memory in
one of my machines at home this weekend, with 256 mb sticks now costing
under $US 80, I figured it was about time. The machine would not boot
with Linux 2.4.1 just Uncompressing .... then nothing. I had to remove one
memory stick. I recompiled with "high memory" enabled, CONFIG_HIGHMEM4G.

I was unable to use the new kernel because the drivers I need for
`initrd` all had undefined symbols relating to some high memory stuff.
This, in spite of the fact that I did:

cp .config ..
make clean
make distclean
cp ../.config
make oldconfig
make dep
make bzImage
make modules
make modules_install

I can't understand how changes in memory management could possibly
affect drivers! They should not care where memory comes from! If
a driver, calling kmalloc() or whatever, needs to know anything
about where the pages made available were stashed, then something's
broken, plain and simple.

Also, with 4 gb of address space in ix86 machines, we should not
have any problems accessing memory until the sum of all the
RAM, plus the sum of all the address-space needed for PCI resources,
plus anything below 1 megabyte, plus the physical memory required
for PTEs and kernel resources, starts to get near 4 gb. Presently,
the address limit without "highmem hacks" is less than 1 gb. This
needs some work.  It looks as though somebody guessed that 'PAGE_OFFSET'
imposed some kind of limit. It doesn't as long as it's summed, not ORed
(some early code I looked at ORed in PAGE_OFFSET in several places,
destroying the linearity of address arithmetic).

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: [LONG RANT] Re: Linux stifles innovation...

[Jeff Garzik]

On Mon, 19 Feb 2001, Richard B. Johnson wrote:
> One of the latest module killers was the opaque type, "THIS_MODULE",
> put at the beginning of struct file_operations. This happened between
> 2.4.0 and 2.4.x.  So it's not "imagination".

Richard,

Time to join the rest of us on planet Earth.

That was added in 2.4.0-test2, and was most definitely in 2.4.0 release.

	Jeff

Re: [LONG RANT] Re: Linux stifles innovation...

[Alan Cox]

> One of the latest module killers was the opaque type, "THIS_MODULE",
> put at the beginning of struct file_operations. This happened between
> 2.4.0 and 2.4.x.  So it's not "imagination".

No it happened before 2.4.0

Re: [LONG RANT] Re: Linux stifles innovation...

[Keith Owens]

On Mon, 19 Feb 2001 10:58:36 -0500 (EST), 
"Richard B. Johnson" <root@chaos.analogic.com> wrote:
>I was unable to use the new kernel because the drivers I need for
>`initrd` all had undefined symbols relating to some high memory stuff.
>This, in spite of the fact that I did:
>
>cp .config ..
>make clean
>make distclean
>cp ../.config
>make oldconfig
>make dep
>make bzImage
>make modules
>make modules_install

FAQ: http://www.tux.org/lkml/#s8-8

Re: [LONG RANT] Re: Linux stifles innovation...

[Andre Hedrick]

On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:

> And yes, there _is_ IMHO a difference in telling someone on LKM,
> especially someone without deeper knowledge that is lookin for help:
> 
> "You're using a non-open source driver, so we can't help you. Please
> ask your vendor for support."

Henning,

Lets be realistic here.  If I take my BMW (M series) into the shop because
it has problem yet I tell the German Mechanic that he may not look under
the hood because there is a secret "wonder blunder" inside.  Where do you
think that mechanic is going to tell you to go??

This is the motor(kernel-space) not the paint(user-space).
 
You have admitted that you are an "End-User"(of the kernel) and that you
generally write user-space packages.  I have yet to understand why you are
going out of bounds.  It is clear that you have read to many of my person
best flame-wars here on LKML where I know I must have earned :
	"Arse of the Year, 2000 :: LKML"

> "Fuck off, <insert binary vendor, software or distribution> Luser".

And you slammed me for being rude and ugly??  In my defense of code and
work that I publish, but heavily enforce the license and terms of use.
Since I am aware that about 96% of all linux boxes today use some form of
ATA/ATAPI, it is important that I recover all know fixes public/private
to help everyone.

> ("Der Ton macht die Musik". Sorry don't know the equal english
> expression).

I now see the joy in watching someone go nuts here on LKML.

Respectfully,

Andre Hedrick
Linux ATA Development

ps. Please keep up the entertainment, I am getting a good belly-laugh
    of what I must have looked like in the past.

Re: Linux stifles innovation...

[Francois Romieu]

Alan Cox <alan@lxorguk.ukuu.org.uk> écrit :
[...]
> > For example, if there were six different companies that marketed ethernet 
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> > with different "features" that were of value to you. Instead, you have 
> > crappy GPL code that locks up under load, and its not worth spending 
> 
> Umm I find the driver very reliable. And actually I have choice of two
> eepro100 drivers eepro100.c and e100.c so you cant even pick an example.
> 
> Of course your keenness to let people write alternative free drivers for
> your etinc pci card is extremely well known. Fortunately despite your best
> efforts there is now a choice in 2.4

Some words from the Ural mountains...
I wouldn't suggest to use my code in a production environment today (that's
why it's labelled 'EXPERIMENTAL' :o) ):
- I'm bad at handling Receive Data Overflow events. Here I suffer
from the lack of ability to trigger it. Now that I'm sharing my flat
with a (decent) traffic analyzer, I should be able to fix that.
- there are issues with the upper layers (I must do some more test
and document the whole). 
- the current way to handle the 'DSCC4 sometime forgets events' failure is
really gross and sub-optimal.

I've found time to buy a brand new computer and it should *really* help for 
these two points.

So far, my driver hasn't the required reliability that one expects to 
build a 4 ports router. Etinc's one may be better at this now*.
Well, I'll fix it. No need to be a genius.

Dennis, thanks to your closed source vision, I found an opportunity to 
fill a gap. Now, some people are willing to make $$$ with me.


*but it's not that difficult to find a way to crash it. A "Don't do that"
section on Etincs site would nicely replace the "Mine is bigger than yours" 
pages.

-- 
Ueimor

Re: Linux stifles innovation...

[Dan Hollis]

On Fri, 16 Feb 2001, Dennis wrote:
> The biggest thing that the linux community does to stifle innovation is to
> bash commercial vendors trying to make a profit by whining endlessly about
> "sourceless" distributions and recommending "open-source" solutions even
> when they are wholly inferior. You're only hurting yourselves in the long
> run. In that respect MS is correct, because those with the dollars to
> innovate will stay away.

So I take it you support M$ on the legislation bit also...

-Dan

Re: Linux stifles innovation...

[David D.W. Downey]

ROTFL, man this guy is funny.



On Fri, 16 Feb 2001, Dennis wrote:

> At 02:48 PM 02/16/2001, Jesse Pollard wrote:
> >On Fri, 16 Feb 2001, Andrew Scott wrote:
> > >On 15 Feb 2001, at 9:49, fsnchzjr wrote:
> > >
> > >> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> > >> Nice little article on how we're all going to die of herpes from our
> > >> repeated exposition to Linux...
> > >>
> > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> > >> g=ltnc
> > >
> > >That's about as self-serving a statement as I've ever seen. If this
> > >'Jim Alchin' actually believes what he's saying, he's got to be one
> > >of the worlds biggest fools, and if he doesn't believe what he's
> > >saying, well there aren't too many words that would accurately
> > >describe what he is.
> > >
> > >It's pretty funny in some ways, e.g. "We can build a better product
> > >than Linux...", which begs the question, "Well, why don't you?".
> > >Perhaps it costs too much?
>
> objective, arent we?
>
> There is much truth to the concept, although Microsoft should not be ones
> to comment on it as such.
>
> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you. Instead, you have
> crappy GPL code that locks up under load, and its not worth spending
> corporate dollars to fix it because you have to give away your work for
> free under GPL. And since there is a "free" driver that most people can
> use, its not worth building a better mousetrap either because the market is
> too small. So, the handful of users with problems get to "fit it
> themselves", most of whom cant of course.
>
> Theres also the propensity for mediocre stuff to get into the kernel
> because some half-baked programmer was willing to contribute some code. The
> 50% of the kernel that remains "experimental" ad infinitum is evidence of that.
>
> The biggest thing that the linux community does to stifle innovation is to
> bash commercial vendors trying to make a profit by whining endlessly about
> "sourceless" distributions and recommending "open-source" solutions even
> when they are wholly inferior. You're only hurting yourselves in the long
> run. In that respect MS is correct, because those with the dollars to
> innovate will stay away.
>
> DB
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA

Re: Linux stifles innovation... [way O.T.]

[John Cavan]

Dennis wrote:
> objective, arent we?

You might ask yourself the same question...

> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you. Instead, you have
> crappy GPL code that locks up under load, and its not worth spending
> corporate dollars to fix it because you have to give away your work for
> free under GPL. And since there is a "free" driver that most people can
> use, its not worth building a better mousetrap either because the market is
> too small. So, the handful of users with problems get to "fit it
> themselves", most of whom cant of course.

A large bulk of the investment in Linux is starting to come in from
hardware manufacturers, notably IBM. These companies see Linux as a
means to sell more hardware, not as a means to sell software. This is
critical, because it means that it IS worth the money to make the driver
perform correctly, GPL or not, because a bad driver means no sales.

You can't argue from the standpoint of "small market" and then the
destruction of the market itself. By definition, in order for the
software market to be significantly damaged, Linux (and other open
source projects) would have to hold more than a small percentage of the
market. Hence, your market just got big and if you make hardware, you
better make a good driver.

[snip general name calling and other sorts of bashing - remember,
objective?]

John

Re: Linux stifles innovation...

[Mike A. Harris]

On Fri, 16 Feb 2001, Dennis wrote:

>The biggest thing that the linux community does to stifle innovation is to
>bash commercial vendors trying to make a profit by whining endlessly about
>"sourceless" distributions and recommending "open-source" solutions even
>when they are wholly inferior. You're only hurting yourselves in the long
>run. In that respect MS is correct, because those with the dollars to
>innovate will stay away.

Try telling that to IBM, Intel, Compaq, Hewlett Packard, Dell,
SGI, and a handful of other _major_ computer companies that now
realize the importance of open source.

Seriously, get a copy of Eric S. Raymond's book, "The Cathedral
and the Bazaar" (or view it online at http://www.opensource.org),
and read through it.  It is very well written and covers all
aspects of what you are fearing - in a positive way.

Linux is one of the most stable operating systems ever written.
That's not just advocacy, that is fact.  Drivers marked
experimental are not just experimental - some are, but a lot are
not, they just have not had anyone send in loud positive
feedback, and so the maintainers left them that way.

If you think the various crud commercial OS's out there are
stable and have no experimental code in them, and that drivers do
not crash or have bugs, you haven't been computing for long.

At any rate, nobody has a gun to your head - go use something
else that works for you.

----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Free Software advocate
          This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
Press every key to continue.

Re: Linux stifles innovation...

[Matt D. Robinson]

The day the Linux kernel splinters into multiple, distinct efforts is the
day I'll believe the kernel is fully into progress over "preference".  Right
now, Alan accepts what he thinks should go into stable kernels, and Linus
accepts what he thinks should go into future kernels.  I'm not saying they
aren't doing the right things, or that the system doesn't work, but it's
hardly what I would call a progressive movement.  It's simply long,
drawn-out evolution at best.

I'm surprised the major vendors haven't created their own consortium
by now to create a Linux kernel they think is best suited for their own
hardware.  But then again, they probably still spend all their time worrying
about whether their efforts will be "accepted" into the mainstream Linux
kernel.  Now _that's_ what I consider to be stifling innovation and
progression.

Kind of off-topic, but whatever ...

--Matt

"Mike A. Harris" wrote:
> On Fri, 16 Feb 2001, Dennis wrote:
> 
> >The biggest thing that the linux community does to stifle innovation is to
> >bash commercial vendors trying to make a profit by whining endlessly about
> >"sourceless" distributions and recommending "open-source" solutions even
> >when they are wholly inferior. You're only hurting yourselves in the long
> >run. In that respect MS is correct, because those with the dollars to
> >innovate will stay away.
> 
> Try telling that to IBM, Intel, Compaq, Hewlett Packard, Dell,
> SGI, and a handful of other _major_ computer companies that now
> realize the importance of open source.
> 
> Seriously, get a copy of Eric S. Raymond's book, "The Cathedral
> and the Bazaar" (or view it online at http://www.opensource.org),
> and read through it.  It is very well written and covers all
> aspects of what you are fearing - in a positive way.
> 
> Linux is one of the most stable operating systems ever written.
> That's not just advocacy, that is fact.  Drivers marked
> experimental are not just experimental - some are, but a lot are
> not, they just have not had anyone send in loud positive
> feedback, and so the maintainers left them that way.
> 
> If you think the various crud commercial OS's out there are
> stable and have no experimental code in them, and that drivers do
> not crash or have bugs, you haven't been computing for long.
> 
> At any rate, nobody has a gun to your head - go use something
> else that works for you.

Re: Linux stifles innovation...

[Mike A. Harris]

On Fri, 16 Feb 2001, Matt D. Robinson wrote:

>The day the Linux kernel splinters into multiple, distinct efforts is the
>day I'll believe the kernel is fully into progress over "preference".  Right
>now, Alan accepts what he thinks should go into stable kernels, and Linus
>accepts what he thinks should go into future kernels.  I'm not saying they
>aren't doing the right things, or that the system doesn't work, but it's
>hardly what I would call a progressive movement.  It's simply long,
>drawn-out evolution at best.
>
>I'm surprised the major vendors haven't created their own consortium
>by now to create a Linux kernel they think is best suited for their own
>hardware.  But then again, they probably still spend all their time worrying
>about whether their efforts will be "accepted" into the mainstream Linux
>kernel.  Now _that's_ what I consider to be stifling innovation and
>progression.
>
>Kind of off-topic, but whatever ...

Basically it boils down to this.. By continuing this thread here,
I'm preaching to the choir, and I'd rather not waste my time on
those with no clue of the open source movement.  The other
alterative is to stick up for open source, and debate you until
I'm blue in the face - and you wont change your mind anyways,
and considering you're the minority here.. who cares?

Thread == dead.

----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Free Software advocate
          This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
Red Hat Linux:  http://www.redhat.com
Download for free:  ftp://ftp.redhat.com/pub/redhat/redhat-6.2/

Re: Linux stifles innovation...

[Matt D. Robinson]

"Mike A. Harris" wrote:
> On Fri, 16 Feb 2001, Matt D. Robinson wrote:
> 
> >The day the Linux kernel splinters into multiple, distinct efforts is the
> >day I'll believe the kernel is fully into progress over "preference".  Right
> >now, Alan accepts what he thinks should go into stable kernels, and Linus
> >accepts what he thinks should go into future kernels.  I'm not saying they
> >aren't doing the right things, or that the system doesn't work, but it's
> >hardly what I would call a progressive movement.  It's simply long,
> >drawn-out evolution at best.
> >
> >I'm surprised the major vendors haven't created their own consortium
> >by now to create a Linux kernel they think is best suited for their own
> >hardware.  But then again, they probably still spend all their time worrying
> >about whether their efforts will be "accepted" into the mainstream Linux
> >kernel.  Now _that's_ what I consider to be stifling innovation and
> >progression.
> >
> >Kind of off-topic, but whatever ...
> 
> Basically it boils down to this.. By continuing this thread here,
> I'm preaching to the choir, and I'd rather not waste my time on
> those with no clue of the open source movement.  The other
> alterative is to stick up for open source, and debate you until
> I'm blue in the face - and you wont change your mind anyways,
> and considering you're the minority here.. who cares?
> 
> Thread == dead.

Mike, next time, read someone's post before responding, okay?
If you think I don't care about open source, perhaps you weren't
paying enough attention.  I'd like to see open source evolve even
faster than it does now.  If you somehow missed that, then go back
and read what I wrote again.  And I'm sure you can find much
more positive ways to defend open source than responding in the
way you just did -- your tone projects the kind of animosity that
causes these closed vs. open source debates in the first place.

My feeling is we should splinter the kernel development for
different purposes (enterprise, UP, security, etc.).  I'm sure
it isn't a popular view, but I feel it would allow faster progression
of kernel functionality and features in the long run.  And that's
simply a different view than you have.  It's certainly not one
that is against the open source movement (as you've implied).

--Matt (http://oss.sgi.com/projects/lkcd)

Re: Linux stifles innovation...

[Werner Almesberger]

Matt D. Robinson wrote:
> My feeling is we should splinter the kernel development for
> different purposes (enterprise, UP, security, etc.).  I'm sure
> it isn't a popular view, but I feel it would allow faster progression
> of kernel functionality and features in the long run.

"enterprise" XOR security ? I think you understand the problem with
your approach well ;-)

Linux scales well from PDAs to large clusters. This is quite an
achievement. Other operating systems are not able to match this.
So why do you think that Linux should try to mimic their flaws ?
Out of pity ?

BTW, parallel development does happen all the time. The point of
convergence in a single "mainstream" kernel is that you benefit
from all the work that's been going on while you did the stuff
you care most about.

- Werner (having pity with the hungry looking trolls)

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

Re: Linux stifles innovation...

[Matt D. Robinson]

Werner Almesberger wrote:
> 
> Matt D. Robinson wrote:
> > My feeling is we should splinter the kernel development for
> > different purposes (enterprise, UP, security, etc.).  I'm sure
> > it isn't a popular view, but I feel it would allow faster progression
> > of kernel functionality and features in the long run.
> 
> "enterprise" XOR security ? I think you understand the problem with
> your approach well ;-)

Actually I do.  Perhaps I should define enterprise as "big iron".  In
that way, enterprise kernels would be far more innovative than a
secure kernel (which cares less about performance gains and large
features and more about just being "secure").  Unless you meant
something else and I'm misinterpreting what you've stated. :)

> Linux scales well from PDAs to large clusters. This is quite an
> achievement. Other operating systems are not able to match this.
> So why do you think that Linux should try to mimic their flaws ?
> Out of pity ?

I always considered SGI's kernels, from the low-end system up to
the large server configurations, to scale well.  Certainly it didn't
work on PDAs. :)  If you consider it a flaw for vendors to be able
to create their own Linux kernels based on optimizations
for their hardware and their customers, then that's a horrible
perspective on overall open source progression.  In fact, I think
if some of these vendors created their own kernel trees, it would
inevitably lead to inclusion of the best features into the primary
kernel tree.  Where's the harm in that?

> BTW, parallel development does happen all the time. The point of
> convergence in a single "mainstream" kernel is that you benefit
> from all the work that's been going on while you did the stuff
> you care most about.

Agreed.  It's great to have a "primary" kernel.  I'd like to see
more splintered kernels (not smaller project efforts), that's all.
And I don't think that convergence happens quickly or efficiently
enough, despite all the great work Linus and Alan do.

> - Werner (having pity with the hungry looking trolls)

--Matt

Re: Linux stifles innovation...

[Werner Almesberger]

Matt D. Robinson wrote:
> Actually I do.  Perhaps I should define enterprise as "big iron".  In
> that way, enterprise kernels would be far more innovative than a
> secure kernel (which cares less about performance gains and large
> features and more about just being "secure").

Hmm, and if you want a secure "big iron" ? Do you then start another
branch merging from both lines, or try to merge all the "enterprise"
enhancements into the "secure" system or vice versa ? If the latter
is easy, why was the split needed in the first place ? If it isn't
easy, will you succeed ? After all, you're facing the integration of
a large portion of code, and you only have a probably small "special
interest" group of people for it.

> In fact, I think
> if some of these vendors created their own kernel trees, it would
> inevitably lead to inclusion of the best features into the primary
> kernel tree.  Where's the harm in that?

Temporary splits or "private" add-ons are not a problem. In fact,
this happens all the time. If there are more fundamental and
permanent splits, I would expect it to become increasingly difficult
to maintain compatibility for components. This should affect drivers
first, then deeper regions of the kernel (e.g. networking, then MM).

Actually, there is a live experiment of this nature going on: with
BSD, you have several specialized lines. I'm not following their
development, but maybe somebody who does could comment on how they
compare in terms of compatibility among themselves, and in terms of
features/drivers with Linux.

Also, code that is supposed to run on multiple platforms easily
degenerates into a wild collection of #ifdefs, or requires the
addition of further abstraction layers. (*) Again, the quality of BSD
drivers (both in readability and efficiency) should be indicative for
whether my assumption is true.

(* Further abstraction layers can sometimes be very efficient, e.g.
   the UP/SMP support in Linux. The hard part is to put them at the
   right place. If your kernels are sufficiently different, you may
   end up with translation modules at fairly deep layers, e.g.
   instead of, say, VFS in all kernels providing the same set of
   functions, you'd translate between VFS variants in your file
   system driver, which is probably less efficient, and much more
   likely to result in bugs.)

In my personal experience, it's already painful enough to maintain
a piece of software that should run in 2.2 and 2.3 kernels, despite
rather good compatibility support.

> And I don't think that convergence happens quickly or efficiently
> enough, despite all the great work Linus and Alan do.

One of the largest obstacles to covergence that I've seen so far is
that some groups isolate their work too much. Rapid convergence is
only possible if all relevant parties understand what's going on, at
least at the point of what happens at interfaces. This means that
large projects should be done openly, with occasional announcements
on linux-kernel. Building that killer subsystem in-house until
perfection is reached, and then submitting a multi-megabyte patch
isn't going to make anybody happy.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

mharris@opensourceadvocate.org (Mike A. Harris) writes:

>On Fri, 16 Feb 2001, Dennis wrote:

>>The biggest thing that the linux community does to stifle innovation is to
>>bash commercial vendors trying to make a profit by whining endlessly about
>>"sourceless" distributions and recommending "open-source" solutions even
>>when they are wholly inferior. You're only hurting yourselves in the long
>>run. In that respect MS is correct, because those with the dollars to
>>innovate will stay away.

>Try telling that to IBM, Intel, Compaq, Hewlett Packard, Dell,
>SGI, and a handful of other _major_ computer companies that now
>realize the importance of open source.

No. They spent some small money on it and wait and see how it works
out. If it doesnt't, well, life goes on.

If IBM, Intel, Compaq, HP, Dell, SGI and other companies would
wholeheartedly drop their Windows support in favour of Linux, that I
would call "a move". If HP would spent only 5% of their driver writing
buget for Windows into Linux driver development, that I would call "a
move". 

Everything else is just "Keeping our options open".

In this market, there are IMHO only two companies that have themselves
openly and clearly committed: SUN and Microsoft.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Linux stifles innovation...

[Robert Read]

On Sat, Feb 17, 2001 at 12:41:57PM +0000, Henning P. Schmiedehausen wrote:
> ....
> If HP would spent only 5% of their driver writing
> buget for Windows into Linux driver development, that I would call "a
> move". 

Have you seen this: http://hp.sourceforge.net/ 

I certainly don't know what the percentage is (or care), but I'd call
that "a move."

robert

Re: Linux stifles innovation...

[Henning P . Schmiedehausen]

On Sat, Feb 17, 2001 at 02:58:45PM +0100, Jean Francois Micouleau wrote:
> 
> On Sat, 17 Feb 2001, Henning P. Schmiedehausen wrote:
> 
> > If IBM, Intel, Compaq, HP, Dell, SGI and other companies would
> > wholeheartedly drop their Windows support in favour of Linux, that I
> > would call "a move". If HP would spent only 5% of their driver writing
> > buget for Windows into Linux driver development, that I would call "a
> > move". 
> 
> I'm wondering if the $600 000 HP gave to VA linux and myself last year is
> only 5% of their driver budget.

> Henning, HP is supporting linux and the open source movement. They are
> paying people to port linux to the ia64 platform and the hp-pa risc.

Yes. They want to sell the IA64 and the HP-PA hardware. So it is
logically for them to fund people and companies that port the kernel
or build OS software for their hardware.

> They are supporting the open source movement by paying people like me to
> improve Samba.

Yes. They want to sell products which use this special piece of software.

I don't see HP supporting software authors to write CD-ROM burning
software for all CDROM writers just to be able to bundle Linux
software with their CDROM writers [just watching an HP commercial on
TV].

IMHO, this is no "basic change in company policy". HP and many other
companies understood that they have two ways to conduct their business
in the future: Being dependent on a company that dictates how to write
software, being forced to live with the way that company wants future
products to be and the fact that this company will always have an edge
over their competitors. Or the will support open _protocols_ like
CORBA, TCP/IP, XML and the like to keep their closed source products
working on many (especially their own) platforms and avoid the
strangle hold of a single company.

Linux is ideal for them because no company has "a grip" on the OS. 
This is good!

But is it "commitment to open source"? Or just "keeping all options
open"? Because these companies still support their products on M$. 

Most of the programs are in newer, larger and more mature versions for
Windows. Why? Did you ever try to write a non-web based GUI program
for Linux? For which Linux? Which desktop (besides using statically
linked motif applications or bare metal X11)? Which version of the
desktop? What tools do you get? How mature are the tools, especially
GUI builders and IDEs? Most developers in bigger companies are not
kernel wizards but just average run-of-the-mill-have-a-grip-on-c++
developers who code after specs.

Most companies simply use Java and leave the details to the VM. If you
write for Windows, you have an ugly and complicated API with lots of
bugs, but the API itself is stable since six (!) years.  You can write
programs that run on 95/98/ME/NT/2000 unchanged. Writing them sucks
but it is possible. For Linux to do so, you must use almost bare X11.

Don't get me wrong. I am _happy_ that there are big companies
recognizing, funding and supporting Linux. But then it is for Linux to
grow mature and recognize that these companies don't do it because
they think "Linux is cool". They do it because they think "Linux is
business. Linux is profit. Linux helps us to avoid the strangle hold
of M$" No news here. No basic direction change here. They do Windows
and anything else for exactly the same reasons.

And they don't do desktop applications besides java applications and
Web stuff.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Linux stifles innovation...

[Alan Olsen]

On Fri, 16 Feb 2001, Dennis wrote:

> objective, arent we?

Pot. Kettle. Black.

> There is much truth to the concept, although Microsoft should not be ones 
> to comment on it as such.

What truth?  I have seen more "innovation" in the Open Source movement
than I ever have in my 18+ years of being a professional programmer.

I don't see how having the source open removes "intelectual property",
except by showing that huge portions of the concept are flawed.

> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> with different "features" that were of value to you. Instead, you have 
> crappy GPL code that locks up under load, and its not worth spending 
> corporate dollars to fix it because you have to give away your work for 
> free under GPL. And since there is a "free" driver that most people can 
> use, its not worth building a better mousetrap either because the market is 
> too small. So, the handful of users with problems get to "fit it 
> themselves", most of whom cant of course.

Strange.  I have not heard of any problems with that driver, except for
issues where the original hardware vendor kept implimentation details from
the open source community.  (Citeing "IP issues".)

> Theres also the propensity for mediocre stuff to get into the kernel 
> because some half-baked programmer was willing to contribute some code. The 
> 50% of the kernel that remains "experimental" ad infinitum is evidence of that.

You must be looking at a different kernel.

I have seen little in the kernel that was "half baked".  There have been
some things put in to test if they were good ideas.  That is far different
than half-baked.  Most of the bad ideas never get to the kernel.  Linus or
Alan kick them out before they ever get that far.

> The biggest thing that the linux community does to stifle innovation is to 
> bash commercial vendors trying to make a profit by whining endlessly about 
> "sourceless" distributions and recommending "open-source" solutions even 
> when they are wholly inferior. You're only hurting yourselves in the long 
> run. In that respect MS is correct, because those with the dollars to 
> innovate will stay away.

You claim that "open source solutions are wholely inferior to closed
source solutions".

Hmmmm... 

Then why does everyone run with Apache instead of IIS?  Could it be that
IIS is a piece of crap?

Feature for feature I would rather use PHP 4 over ColdFusion any day.

Sendmail is MUCH more stable than Exchange.  (Even if it has config files
that look like they were designed by Carlos Castanada on a bad day.) If
not Sendmail, there are a couple of other Open Source mail programs that
are much superior in quality than the closed source counterparts.

As for the Linux kernel being "shoddy"...  

Since when?

I can leave my Linux box running over night and actually have it do
things!  I cannot say the same for Windows.  I leave that running (same
hardware, different OS) and it is usually dead by dawn.

But your argument is even more bogus than that.

It seems that you argument boils down to a couple of thing...

"Closed source is better because you pay money for it."  

"Closed source is superior because we have a company name and you don't."

Sorry, but most of the people who develop Open Source are profesional
programmers.  They just have a different motivation.  

Open Source is motivated by pride in what you can do and a desire to help
others by sharing that. They don't hide behind a wall of lawyers to keep
people from finding out what they did wrong.

I found out a long time ago that most "Trade Secret" claims were bogus.
It was either a common technique that had been adapted to a particular
purpose or it was being used as an excuse to hide how bad the code really
was.

But my experiences with Open Source, as well as the others I know who use
it are quite telling.

If I have a problem with an Open Source program I can look at the code and
fix it.  Or I can report the bug and it will get fixed soon after. The
programmers involved put the effort into it because their name is
attached.

My experiences with closed source companies are not as good.

In many cases, I was ignored because I did not represent a fortune 500
company.  If the problem got fixed at all, it would be months before I saw
it and usually in a later release that I would have to pay for.  (Usually
having features added that I neither wanted or would ever use.)  In some
cases (like Microsoft security bugs) it would be treated like a public
relations problem instead of a software and quality issue.

I have also seen cases where problems were buried in development because
"no one will find out and if they do, we will just blame Microsoft".

I understand your desire to make money off what you do for a living. I do
object to you taring what I do as somehow damaging to the software
industry as a whole.  (Especially since the closed source software
industry has been poaching off the open source community for years.
Microsoft seeking enlightenment with WinXP is only a minor example.)

I don't see how hiding how something works adds value to the process.

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
    "In the future, everything will have its 15 minutes of blame."

Re: Linux stifles innovation...

[rjd]

Dennis wrote:
...
> objective, arent we?
Nope. Are you claiming to be?

> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
... Rant deleted

I had a problem with eepro100.
It was fixed same night cause I had the source.
Don't even try to compare with MickyS**t.

> The biggest thing that the linux community does to stifle innovation is to 
> bash commercial vendors trying to make a profit by whining endlessly about 
> "sourceless" distributions and recommending "open-source" solutions even 
> when they are wholly inferior. You're only hurting yourselves in the long 
> run. In that respect MS is correct, because those with the dollars to 
> innovate will stay away.

When companys with less than a dozen people think it's worth while paying
someone like me to develop code exclusivly for Linux we've got to have a
chance. Source to binary ratio is probably 70/30 mainly because of code
tied up in previous companys but they are trying.

The project they're funding now is more like 90% GPL. Of course I could be
producing crap code. 20 years kernel hacking and a cybernetics degree can't
mean as much as being an MSCE.


ps. This is definately a message from home and a bottom of a glass of whisky.
-- 
	Bob Dunlop	rjd@xyzzy.clara.co.uk

RE: Linux stifles innovation...

[Neal Dias]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's not about facts, it's not about the truth, it's not about Jim
Allchin being an idiot or deluded. It's about propaganda,
misinformation, and marketing. It's about business. Nothing new, nor
unexpected. And to the comment "It is not American to steal", well,
it may not be "American", but it's for sure been part of the way of
doing business in this country for years. It's not right, it's not
ideal, but it IS the way it's done in too many cases. 

Neal Dias
UNIX Systems Administrator, Sunglass Hut International, MIS Dept.
office: (305) 648-6479  wk. email:NDias@sunglasshut.com
mobile: (786) 368-5742  pvt. email:emperor.1@netzero.net
**********************************************************************
Whoever fights monsters should see to it that in the process he does
not become a monster. And when you look into an abyss, the abyss also
looks into you. -Nietzsche

Any opinions expressed above or below are entirely my own and may not
reflect those of my employers. The information contained in this
e-mail message is confidential, intended only for the receipt and use
of the individual(s) or entity(s) named above. If the reader of this
email message is not the intended recipient, or the employee or agent
responsible for its delivery to the intended and or addressed
recipient, you are hereby notified that any review, dissemination,
distribution or copying of this communication is strictly prohibited
except at the express consent of its author.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBOo3VDsUVRGLQ1PaaEQKnWwCcCb+J3BbV/AQLCB20mzLn/1e8HmkAoK+u
zXoDl5pPc5Z1uihfhOMrQy+I
=wE+Z
-----END PGP SIGNATURE-----

Re: Linux stifles innovation...

[Augustin Vidovic]

On Fri, Feb 16, 2001 at 05:27:31PM -0500, Dennis wrote:
> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> with different "features" that were of value to you. Instead, you have 
> crappy GPL code that locks up under load, and its not worth spending 

1- GPL code is the opposite of crap
2- in that case, it's not the software, but the hardware which
   was locking up under load

In addition, it would have been impossible to fix the problem if the code
was not GPL.

-- 
Augustin Vidovic                   http://www.vidovic.org/augustin/
"Nous sommes tous quelque chose de naissance, musicien ou assassin,
 mais il faut apprendre le maniement de la harpe ou du couteau."

Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

vido@ldh.org (Augustin Vidovic) writes:

>1- GPL code is the opposite of crap

No. A license doesn't automatically make good code.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Linux stifles innovation...

[Roeland Th. Jansen]

On Sat, Feb 17, 2001 at 12:46:30PM +0000, Henning P. Schmiedehausen wrote:
> >1- GPL code is the opposite of crap
> 
> No. A license doesn't automatically make good code.

true but at least with GPL, people can work on crap GPL code and make
it good. that's an option you don't have with closed source.

-- 
Grobbebol's Home                   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel       | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |        on Usenet.             _\_v  

Re: Linux stifles innovation...

[Dr. Kelsey Hudson]

On Sat, 17 Feb 2001, Augustin Vidovic wrote:

> 1- GPL code is the opposite of crap

By saying this, you are implying that all pieces of code released under
the GPL are 'good' pieces of code. I can give you several examples of code
where this is not the case; several I have written for my own use, as a
matter of fact.

Software is only as 'good' as the effort the programmer who wrote it put
into it. Spend an hour writing a device driver while watching TV, eating
food, and after a couple dozen beers, and release it under the GPL. Is it
good code? probably not. :p

This isn't, however, to say that I think commercial code is better than
GPL code... They both have their merits and deficiencies, so I value both
equally based upon this (although all software *should* be free...)

Just my .02.

 Kelsey Hudson                                           khudson@ctica.com 
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------     

Re: Linux stifles innovation...

[Augustin Vidovic]

On Wed, Feb 21, 2001 at 03:00:26PM -0800, Dr. Kelsey Hudson wrote:
> On Sat, 17 Feb 2001, Augustin Vidovic wrote:
> 
> > 1- GPL code is the opposite of crap
> 
> By saying this, you are implying that all pieces of code released under
> the GPL are 'good' pieces of code.

If you want to rephrase it like that, ok, but then you must not forget
why these pieces of code are 'good' : because everybody have access to the
source code and may debug or improve it as needed.

To the contrary, the commercially distributed closed software may be
nicely coded (sometimes), but how can you know ? You don't have acess to
the source code. All you can do if you want to modify it is to disassemble
it. In some countries this solution is even illegal.

That's why a GPLed piece of code, whatever ugly it may look, is far better,
because you have the _liberty_ to modify it. That's the exact contrary of
crap, because there is no reason to throw it into the trashcan. A GPLed
code has the potential of living as long asd there exists a need to ru it.
A closed code can live only on one architecture, and thus is doomed to
the dumpster.

Re: Linux stifles innovation...

[Dr. Kelsey Hudson]

On Thu, 22 Feb 2001, Augustin Vidovic wrote:
> On Wed, Feb 21, 2001 at 03:00:26PM -0800, Dr. Kelsey Hudson wrote:
> > By saying this, you are implying that all pieces of code released under
> > the GPL are 'good' pieces of code.
> 
> If you want to rephrase it like that, ok, but then you must not forget
> why these pieces of code are 'good' : because everybody have access to the
> source code and may debug or improve it as needed.

'good' in this case was meant to mean working properly, well-coded,
does-what-it's-suppossed-to-do, eg not broken in one way or
another. English should have a better word that 'good...' 

 Kelsey Hudson                                           khudson@ctica.com 
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------     

Re: Linux stifles innovation...

[Jonathan Morton]

At 11:00 pm +0000 21/2/2001, Dr. Kelsey Hudson wrote:
>On Sat, 17 Feb 2001, Augustin Vidovic wrote:
>
>> 1- GPL code is the opposite of crap
>
>By saying this, you are implying that all pieces of code released under
>the GPL are 'good' pieces of code. I can give you several examples of code
>where this is not the case; several I have written for my own use, as a
>matter of fact.
>
>Software is only as 'good' as the effort the programmer who wrote it put
>into it. Spend an hour writing a device driver while watching TV, eating
>food, and after a couple dozen beers, and release it under the GPL. Is it
>good code? probably not. :p
>
>This isn't, however, to say that I think commercial code is better than
>GPL code... They both have their merits and deficiencies, so I value both
>equally based upon this (although all software *should* be free...)

I was going to stay out of this after a few days back, but I'll put in one
last point in favour of this:

I have seen good commercial software and extremely bad GPL software.  Here
are some examples:

Good commercialware:
- CorelXARA, by Computer Concepts, which totally blew CorelDRAW out of the
water on release (but then Corel failed to market it and instead nabbed all
the good ideas, tsk tsk)
- the assembler/programmer/emulator for my Motorola 68HC08 microcontroller

Both of these were developed by relatively small companies which don't have
to kowtow to shareholders every 5 minutes.

Terrible GPLware:
- VNC Server for Macintosh, AT&T version 3.3.2 (I tried to debug this and
eventually gave up and rewrote it from scratch)
- Some architectures' ports of the Linux kernel, at least in their current
state (has anyone actually tried to *compile* the PPC kernel since
2.4.<whatever> besides me?)

In the former case, I was able to take the few useful pieces of code and
re-use them in the replacement - which I was *paid* to write, but is still
GPL'ed in the spirit of the VNC project.  In the latter case, people can
see and experience the problem, and get on with fixing it as and when they
need to and/or get time to.  This is somewhat different in nature to, say,
WinNT which dumped the Alpha platform overnight...

I'll shut up now, especially as this isn't exactly the right place for this
discussion...

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----

Re: Linux stifles innovation...

[Alan Cox]

> - Some architectures' ports of the Linux kernel, at least in their current
> state (has anyone actually tried to *compile* the PPC kernel since
> 2.4.<whatever> besides me?)

Yes it compiles beautifully. Just remember to get it from the ppc tree
because its not merged yet

Re: Linux stifles innovation...

[Wakko Warner]

> - Some architectures' ports of the Linux kernel, at least in their current
> state (has anyone actually tried to *compile* the PPC kernel since
> 2.4.<whatever> besides me?)

Have you tried comiling 2.2.x where x > 13 on an m68k mac or 2.4.x on an
m68k mac?  doesn't happen.  The patches I found for 2.2 didn't work, kernel
oopsed on loading the network driver.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Linux stifles innovation...

[David Weinehall]

On Fri, Feb 23, 2001 at 07:14:48AM -0500, Wakko Warner wrote:
> > - Some architectures' ports of the Linux kernel, at least in their current
> > state (has anyone actually tried to *compile* the PPC kernel since
> > 2.4.<whatever> besides me?)
> 
> Have you tried comiling 2.2.x where x > 13 on an m68k mac or 2.4.x on an
> m68k mac?  doesn't happen.  The patches I found for 2.2 didn't work, kernel
> oopsed on loading the network driver.

Have you submitted patches to Alan (for v2.2.x) or Linus (for v2.4.x)
to fix this?!


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Linux stifles innovation...

[Geert Uytterhoeven]

On Fri, 23 Feb 2001, David Weinehall wrote:
> On Fri, Feb 23, 2001 at 07:14:48AM -0500, Wakko Warner wrote:
> > > - Some architectures' ports of the Linux kernel, at least in their current
> > > state (has anyone actually tried to *compile* the PPC kernel since
> > > 2.4.<whatever> besides me?)
> > 
> > Have you tried comiling 2.2.x where x > 13 on an m68k mac or 2.4.x on an
> > m68k mac?  doesn't happen.  The patches I found for 2.2 didn't work, kernel
> > oopsed on loading the network driver.
> 
> Have you submitted patches to Alan (for v2.2.x) or Linus (for v2.4.x)
> to fix this?!

Linux/m68k 2.4.x runs on some platforms. Also note that Linux/m68k is not 100%
merged with Linus/Alan yet. The mac-specific patches in the m68k tree that
weren't merged are on hold until all issues are sorted out[*], cfr. the
linux-m68k list.

Note to Wakko: feel free to join the project! As usual, we can use the
manpower!!

Gr{oetje,eeting}s,

						Geert

[*] This includes, but is not limited to:
      - reports that they work
      - reports that they work after applying patch foo
      - drivers shared with the PPC folks must be sorted out with them first
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Linux stifles innovation...

[Mike Pontillo]

>
> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you. Instead, you have
> crappy GPL code that locks up under load, and its not worth spending
> corporate dollars to fix it because you have to give away your work for
> free under GPL. And since there is a "free" driver that most people can
> use, its not worth building a better mousetrap either because the market
is
> too small. So, the handful of users with problems get to "fit it
> themselves", most of whom cant of course.
>

     Assuming I am a corporate entity and I need to spend a few bucks to fix
a GPL driver, just because I fix it and deploy my fix on my corporation's
internal network machines -- and quite possibly benefit the hell out of
myself and my company -- that does not mean that I have to release my work
for free under the GPL. Of course, the *nice* thing to do would be to
release it under the GPL even if I was only using the fix internally -- but
I am under no obligation to do that, if, say, I just wanted to keep ahead of
my competitors. Maybe I was planning to wait awhile so I could get ahead in
my market. Maybe I'm just an IP freak and I want to keep my code to myself.
Whatever. My understanding is that the only restrictions I have is that I
can't sell or distribute the darned thing. If, say for example I needed to
fix that driver so that it would work on my new WhizBang 2001 Corporate
Server that is about to hit the market, then I would be making money on the
hardware, and as an added bonus my company looks good because it has an
"open" driver for its server. (no matter that it "had" to under the GPL)

Mike Pontillo

[OT]Re: Linux stifles innovation...

[Gregory Maxwell]

On Fri, Feb 16, 2001 at 11:20:54PM -0800, Mike Pontillo wrote:
[snip]
>      Assuming I am a corporate entity and I need to spend a few bucks to fix
> a GPL driver, just because I fix it and deploy my fix on my corporation's
> internal network machines -- and quite possibly benefit the hell out of
> myself and my company -- that does not mean that I have to release my work
> for free under the GPL. Of course, the *nice* thing to do would be to
> release it under the GPL even if I was only using the fix internally -- but
> I am under no obligation to do that, if, say, I just wanted to keep ahead of
> my competitors. Maybe I was planning to wait awhile so I could get ahead in
> my market. Maybe I'm just an IP freak and I want to keep my code to myself.
> Whatever. My understanding is that the only restrictions I have is that I
> can't sell or distribute the darned thing. If, say for example I needed to
> fix that driver so that it would work on my new WhizBang 2001 Corporate
> Server that is about to hit the market, then I would be making money on the
> hardware, and as an added bonus my company looks good because it has an
> "open" driver for its server. (no matter that it "had" to under the GPL)

No, you can sell it as well, but you have to give the buyer the same rights
you got (under the GPL), this still has value as you can sell it for any
price you want and you can add other value to yours sales (sure, after the
first couple sales people will be able to find it for free on the net or
included in the kernel, but if they want your support for it, they need pay
you).

Re: Linux stifles innovation...

[Vesselin Atanasov]

Hahahaha.
Dennis, the only linux network drivers that I have had serious problems
with were yours. They caused kernel panic on 2.0.30+ every 6 hours. Of
course I did not have the source to fix them. In comparision eepro100
works rock solid on all of my machines that use it.

Will I use some binary only drivers again? No thanks!

On Fri, 16 Feb 2001, Dennis wrote:

> At 02:48 PM 02/16/2001, Jesse Pollard wrote:
> >On Fri, 16 Feb 2001, Andrew Scott wrote:
> > >On 15 Feb 2001, at 9:49, fsnchzjr wrote:
> > >
> > >> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> > >> Nice little article on how we're all going to die of herpes from our
> > >> repeated exposition to Linux...
> > >> 
> > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> > >> g=ltnc
> > >
> > >That's about as self-serving a statement as I've ever seen. If this
> > >'Jim Alchin' actually believes what he's saying, he's got to be one
> > >of the worlds biggest fools, and if he doesn't believe what he's
> > >saying, well there aren't too many words that would accurately
> > >describe what he is.
> > >
> > >It's pretty funny in some ways, e.g. "We can build a better product
> > >than Linux...", which begs the question, "Well, why don't you?".
> > >Perhaps it costs too much?
> 
> objective, arent we?
> 
> There is much truth to the concept, although Microsoft should not be ones 
> to comment on it as such.
> 
> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> with different "features" that were of value to you. Instead, you have 
> crappy GPL code that locks up under load, and its not worth spending 
> corporate dollars to fix it because you have to give away your work for 
> free under GPL. And since there is a "free" driver that most people can 
> use, its not worth building a better mousetrap either because the market is 
> too small. So, the handful of users with problems get to "fit it 
> themselves", most of whom cant of course.
> 
> Theres also the propensity for mediocre stuff to get into the kernel 
> because some half-baked programmer was willing to contribute some code. The 
> 50% of the kernel that remains "experimental" ad infinitum is evidence of that.
> 
> The biggest thing that the linux community does to stifle innovation is to 
> bash commercial vendors trying to make a profit by whining endlessly about 
> "sourceless" distributions and recommending "open-source" solutions even 
> when they are wholly inferior. You're only hurting yourselves in the long 
> run. In that respect MS is correct, because those with the dollars to 
> innovate will stay away.
> 
> DB
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Linux stifles innovation...

[Dennis]

At 05:20 PM 02/16/2001, Alan Cox wrote:
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > with different "features" that were of value to you. Instead, you have
> > crappy GPL code that locks up under load, and its not worth spending
>
>Umm I find the driver very reliable. And actually I have choice of two
>eepro100 drivers eepro100.c and e100.c so you cant even pick an example.

both lock up under load. You dont run a busy ISP i guess. The fact that 
they come out with a new release every few minutes is clear evidence that 
it is problematic.

Intel doesnt sell the e100.o driver, so they couldnt give a rats ass if it 
doesnt perform. Note that the DO sell the drivers for other platforms, and 
they support them, a win for the other platforms.

DB

Emerging Technologies, Inc.
-------------------------------------------------------------------------------------


http://www.etinc.com
ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX
Multiport T1 and HSSI/T3 UNIX-based Routers
Bandwidth Management Standalone Systems
Bandwidth Management software for LINUX and FreeBSD

Re: Linux stifles innovation...

[Mohammad A. Haque]

I'm using these drivers just fine on a couple of streaming servers that
get hit pretty hard.

Dennis wrote:
> both lock up under load. You dont run a busy ISP i guess. The fact that
> they come out with a new release every few minutes is clear evidence that
> it is problematic.

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/ 
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================

Re: Linux stifles innovation...

[Alan Cox]

> both lock up under load. You dont run a busy ISP i guess. The fact that 
> they come out with a new release every few minutes is clear evidence that 
> it is problematic.

I've been technical director of an ISP. I help manage sites that have not
insignificant loads and no eepro100 driver problems. For that matter there
are porn sites using eepro100 drivers.

> Intel doesnt sell the e100.o driver, so they couldnt give a rats ass if it 

Your information is wrong. But then it usually is. If you are large corporation
and would care to talk to Intel they will be happy to discuss it further.

Of course the single biggest problem with the eepro100 is closedness, and people
in Intel with attitudes like yours who refuse to release full documentation.

Alan

Re: Linux stifles innovation...

[Dennis]

At 03:47 PM 02/17/2001, Alan Cox wrote:
> > both lock up under load. You dont run a busy ISP i guess. The fact that
> > they come out with a new release every few minutes is clear evidence that
> > it is problematic.
>
>I've been technical director of an ISP. I help manage sites that have not
>insignificant loads and no eepro100 driver problems. For that matter there
>are porn sites using eepro100 drivers.
>
> > Intel doesnt sell the e100.o driver, so they couldnt give a rats ass if it
>
>Your information is wrong. But then it usually is. If you are large 
>corporation
>and would care to talk to Intel they will be happy to discuss it further.

I can lock both of them up in 10 seconds with a simple test.

Why would anyone want to "discuss" paying intel when the license allows you 
to distribute it for nothing? Its clearly designed as an alternative to GPL 
for commercial vendors.

There have been ongoing complaints and discussions over eepro100 problems 
on many of the lists that I know you monitor, so why are you in denial 
about it?


>Of course the single biggest problem with the eepro100 is closedness, and 
>people
>in Intel with attitudes like yours who refuse to release full documentation.


LINUX has no formal documentation, so are you guilty of "closedness" also? 
(ie "where is the 2.4 device driver spec?"), You have source to the e100 
driver (which handles initialization properly,  unlike the eepro driver), 
so what more documentation do you need? it seems that intel is being as 
"open" as the LInux camp, actually more so. At least with the eepro you can 
get the docs under non-disclosure. Under LInux you have no chance unless 
someone feels like helping you.

DB

Re: Linux stifles innovation...

[Alan Cox]

> Why would anyone want to "discuss" paying intel when the license allows you 
> to distribute it for nothing? Its clearly designed as an alternative to GPL 
> for commercial vendors.

Because if you bother to talk to Intel about your problems Im sure they will
give you a quote to work on it

Re: Linux stifles innovation...

[Dennis]

>
>Fortunately despite your best efforts there is now a choice in 2.4

When is that specification for 2.4 drivers going to be available? Talk 
about "stifling the marketplace"!!! Vendors cant even write reliable 
drivers if they want to.

db

Re: Linux stifles innovation...

[Francois Romieu]

Dennis <dennis@etinc.com> écrit :
[...]
> When is that specification for 2.4 drivers going to be available? Talk 
> about "stifling the marketplace"!!! Vendors cant even write reliable 
> drivers if they want to.

May be said vendors should give a look at l-k between 2.2 and 2.4 instead
of spending their time ranting at low quality of source code on l-k, 
FreeBSD-hackers and elsewhere, shouldn't they ?

-- 
Ueimor

Re: Linux stifles innovation...

[Alan Cox]

> When is that specification for 2.4 drivers going to be available? Talk 
> about "stifling the marketplace"!!! Vendors cant even write reliable 
> drivers if they want to.

Its called the source code, which includes example driver skeletons. WHere
is the documentation for writing your own etinc drivers

Re: Linux stifles innovation...

[Dennis]

At 05:31 PM 02/16/2001, Dan Hollis wrote:
>On Fri, 16 Feb 2001, Dennis wrote:
> > The biggest thing that the linux community does to stifle innovation is to
> > bash commercial vendors trying to make a profit by whining endlessly about
> > "sourceless" distributions and recommending "open-source" solutions even
> > when they are wholly inferior. You're only hurting yourselves in the long
> > run. In that respect MS is correct, because those with the dollars to
> > innovate will stay away.
>
>So I take it you support M$ on the legislation bit also...


No. You conveniently snipped the part where I said that Microsoft is not 
one to talk. They "stifle the market" in other ways, like not completely 
documenting the OS for their own advantage.

DB


>-Dan

RE: Linux stifles innovation...

[Dennis]

At 08:34 PM 02/16/2001, Neal Dias wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>It's not about facts, it's not about the truth, it's not about Jim
>Allchin being an idiot or deluded. It's about propaganda,
>misinformation, and marketing. It's about business. Nothing new, nor
>unexpected. And to the comment "It is not American to steal", well,
>it may not be "American", but it's for sure been part of the way of
>doing business in this country for years. It's not right, it's not
>ideal, but it IS the way it's done in too many cases.


Its not a "stealing" issue. Its about whether its worthwhile, dollar-wise, 
to finance innovation. With free source, its not, because you have to give 
away  your investment and then anyone can use it equally. Secondly, the 
"open-source" community openly shuns binary distributions (A. Cox never 
misses an opportunity), so there is no avenue for commercial innovation 
that is "worthwhile".

Dennis


>Neal Dias
>UNIX Systems Administrator, Sunglass Hut International, MIS Dept.
>office: (305) 648-6479  wk. email:NDias@sunglasshut.com
>mobile: (786) 368-5742  pvt. email:emperor.1@netzero.net
>**********************************************************************
>Whoever fights monsters should see to it that in the process he does
>not become a monster. And when you look into an abyss, the abyss also
>looks into you. -Nietzsche
>
>Any opinions expressed above or below are entirely my own and may not
>reflect those of my employers. The information contained in this
>e-mail message is confidential, intended only for the receipt and use
>of the individual(s) or entity(s) named above. If the reader of this
>email message is not the intended recipient, or the employee or agent
>responsible for its delivery to the intended and or addressed
>recipient, you are hereby notified that any review, dissemination,
>distribution or copying of this communication is strictly prohibited
>except at the express consent of its author.
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>
>iQA/AwUBOo3VDsUVRGLQ1PaaEQKnWwCcCb+J3BbV/AQLCB20mzLn/1e8HmkAoK+u
>zXoDl5pPc5Z1uihfhOMrQy+I
>=wE+Z
>-----END PGP SIGNATURE-----
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Michael Bacarella]

On Sat, Feb 17, 2001 at 02:38:29PM -0500, Dennis wrote:
> >It's not about facts, it's not about the truth, it's not about Jim
> >Allchin being an idiot or deluded. It's about propaganda,
> >misinformation, and marketing. It's about business. Nothing new, nor
> >unexpected. And to the comment "It is not American to steal", well,
> >it may not be "American", but it's for sure been part of the way of
> >doing business in this country for years. It's not right, it's not
> >ideal, but it IS the way it's done in too many cases.
 
> Its not a "stealing" issue. Its about whether its worthwhile, dollar-wise, 
> to finance innovation. With free source, its not, because you have to give 
> away  your investment and then anyone can use it equally.

Untrue.

Ogg Vorbis is a perfect example of free software innovation. It is one
of the most advanced audio codecs available to date. The libraries are
LGPL'd and the specifications are now and forever public. An audio
codec is only the beginning.

The fact that it's freely available and patent unencumbered can only
be good for it's investors, who happen to be hardware vendors and
content providers (among others).

Funding free software innovation is only a bad idea if the principle way you
plan to make money with it is by controlling it's use (such as MP3).

> Secondly, the 
> "open-source" community openly shuns binary distributions (A. Cox never 
> misses an opportunity), so there is no avenue for commercial innovation 
> that is "worthwhile".

As they should. Binary distributions are always inferior. I'm glad to
have a binary instead of nothing, but I really should've had the
foresight to buy better supported hardware. 


-- 
Michael Bacarella <mbac@nyct.net>
Technical Staff / System Development,
New York Connect.Net, Ltd.

Re: Linux stifles innovation...

[James A. Sutherland]

On Sat, 17 Feb 2001, Michael Bacarella wrote:

> On Sat, Feb 17, 2001 at 02:38:29PM -0500, Dennis wrote:
> > >It's not about facts, it's not about the truth, it's not about Jim
> > >Allchin being an idiot or deluded. It's about propaganda,
> > >misinformation, and marketing. It's about business. Nothing new, nor
> > >unexpected. And to the comment "It is not American to steal", well,
> > >it may not be "American", but it's for sure been part of the way of
> > >doing business in this country for years. It's not right, it's not
> > >ideal, but it IS the way it's done in too many cases.
>
> > Its not a "stealing" issue. Its about whether its worthwhile, dollar-wise,
> > to finance innovation. With free source, its not, because you have to give
> > away  your investment and then anyone can use it equally.
>
> Untrue.
>
> Ogg Vorbis is a perfect example of free software innovation. It is one
> of the most advanced audio codecs available to date. The libraries are
> LGPL'd and the specifications are now and forever public. An audio
> codec is only the beginning.

Yes, Ogg Vorbis is an excellent example.

> The fact that it's freely available and patent unencumbered can only
> be good for it's investors, who happen to be hardware vendors and
> content providers (among others).

It's a shame those investors didn't invest in a WWW site for it: it was
being run on someone's DSL line at home. Their ISP has now folded, leaving
them offline without a site to host www.vorbis.com on...

> Funding free software innovation is only a bad idea if the principle way you
> plan to make money with it is by controlling it's use (such as MP3).

Yes. The people who "developed" CSS had to keep it proprietary because
that was all they had: if they were able and willing to make money by
selling real products for a reasonable price, they wouldn't need
"security" through obscurity and court cases.

> > Secondly, the
> > "open-source" community openly shuns binary distributions (A. Cox never
> > misses an opportunity), so there is no avenue for commercial innovation
> > that is "worthwhile".
>
> As they should. Binary distributions are always inferior.

Not really. Souce availability does not automatically make a piece of
software good, nor does a lack of source make it bad. Having the source
code is a good thing, but it doesn't affect the quality of the software
itself.

> I'm glad to have a binary instead of nothing, but I really should've
> had the foresight to buy better supported hardware.

Yes. I just wish it were a bit easier to determine which hardware that
is...


James.

Re: Linux stifles innovation... [way O.T.]

[Dennis]

At 05:59 PM 02/16/2001, John Cavan wrote:
>Dennis wrote:
> > objective, arent we?
>
>You might ask yourself the same question...
>
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > with different "features" that were of value to you. Instead, you have
> > crappy GPL code that locks up under load, and its not worth spending
> > corporate dollars to fix it because you have to give away your work for
> > free under GPL. And since there is a "free" driver that most people can
> > use, its not worth building a better mousetrap either because the market is
> > too small. So, the handful of users with problems get to "fit it
> > themselves", most of whom cant of course.
>
>A large bulk of the investment in Linux is starting to come in from
>hardware manufacturers, notably IBM. These companies see Linux as a
>means to sell more hardware, not as a means to sell software. This is
>critical, because it means that it IS worth the money to make the driver
>perform correctly, GPL or not, because a bad driver means no sales.


Thats wrong. The eepro100 is a great example. It works for most people, so 
the market for an improved one is very limited. Your market is not the 
whole community, only the community that needs something better. IBM will 
simply blame linux if it cant handle a situation. They arent supporting 
linux, they are only taking advantage of the fact that people want it.

BSDI is distributing FreeBSD now. They havent done anything useful to 
support it. They are just cashing in on it.

DB

Re: Linux stifles innovation... [way O.T.]

[Michael H. Warfield]

On Sat, Feb 17, 2001 at 02:56:15PM -0500, Dennis wrote:
> At 05:59 PM 02/16/2001, John Cavan wrote:
> >Dennis wrote:
> > > objective, arent we?
> >
> >You might ask yourself the same question...

> > > For example, if there were six different companies that marketed ethernet
> > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > > with different "features" that were of value to you. Instead, you have
> > > crappy GPL code that locks up under load, and its not worth spending
> > > corporate dollars to fix it because you have to give away your work for
> > > free under GPL. And since there is a "free" driver that most people can
> > > use, its not worth building a better mousetrap either because the market is
> > > too small. So, the handful of users with problems get to "fit it
> > > themselves", most of whom cant of course.

> >A large bulk of the investment in Linux is starting to come in from
> >hardware manufacturers, notably IBM. These companies see Linux as a
> >means to sell more hardware, not as a means to sell software. This is
> >critical, because it means that it IS worth the money to make the driver
> >perform correctly, GPL or not, because a bad driver means no sales.


> Thats wrong. The eepro100 is a great example. It works for most people, so 
> the market for an improved one is very limited. Your market is not the 
> whole community, only the community that needs something better. IBM will 
> simply blame linux if it cant handle a situation. They arent supporting 
> linux, they are only taking advantage of the fact that people want it.

	Excuse me?  A 1 billion dolar investment in Linux is not supporting
it?  Setting up tier 1 and tier 2 support services for a half a dozen
distributions is not supporting it?  Porting their AIX file systems and
applications is not supporting it?  Porting it to the 390 is not supporting
it?  You bet'cha they are taking advantage of the fact that people want it.
They would be damn fools in business if they didn't take advantage of that.
And that means supporting it.  It's to their advantage to support it and
they see it.  You must have a really bizzare idea of what support means...

> BSDI is distributing FreeBSD now. They havent done anything useful to 
> support it. They are just cashing in on it.

	And your point is???

> DB

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: Linux stifles innovation... [way O.T.]

[Henning P. Schmiedehausen]

mhw@wittsend.com (Michael H. Warfield) writes:

> Excuse me?  A 1 billion dolar investment in Linux is not
>supporting it?

On their own hardware.

> Setting up tier 1 and tier 2 support services for a half a dozen
>distributions is not supporting it?  

For their own hardware.

> Porting their AIX file systems and applications is not supporting
> it?

Keeping their legacy customer base on their products. Showing a
migration path that stays on their products and does not move to M$ or
another vendor.

> Porting it to the 390 is not supporting it?

Their own hardware.

>  You bet'cha they are taking advantage of the fact that people want
> it.  They would be damn fools in business if they didn't take
> advantage of that.

They want to stay in business. They don't want to lose their
customers. I remember an interview with an IBM exec which went along
the lines "We're supporting 25 different OS. Linux is OS #26. So, no
news for us here".

> And that means supporting it.  It's to their advantage to support it
> and they see it.  You must have a really bizzare idea of what
> support means...

It means "keep my customer base happy with me, so they give me more
bucks".

I'm sure, that their business plan with Linux says "we get two bucks
for every every one that we spend". IBM is an iron vendor. They have a
strong software product line but their first target is selling "IBM
software on an IBM supported OS on IBM hardware". And if the "IBM
supported OS" is not M$ Windows, which they have to pay a license fee
for but a "license-free OS" which is even developed for them, it's
good for them. And they get "community recognition" and a good press
thrown in for free.

It's "win - win" for them. And, BTW, for us and Linux too, which is a
good thing.

	Regards
		Henning

P.S.: Oh, look a me. Living in an environment where IBM are the good
guys. The horrors. The horrors. ;-)

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Linux stifles innovation... [way O.T.]

[John Cavan]

"Henning P. Schmiedehausen" wrote:
> 
> mhw@wittsend.com (Michael H. Warfield) writes:
> 
> > Excuse me?  A 1 billion dolar investment in Linux is not
> >supporting it?
> 
> On their own hardware.

Which is really the point and they won't be the only ones. If IBM wants
to attract and keep customers on their hardware, they will ensure that
the software and Linux drivers for it run very well, if Linux is going
to be their main play to sell hardware. The same will hold true for
other hardware manufacturers, including those the make video cards,
modems, etc, as Linux grows in the marketplace.

Linux will not displace the software industry, it will eventually
displace the commodity portions of it. This is what has Microsoft
afraid, since commodity software is their real play, games and specialty
software isn't. The fact is, the majority of software is written
in-house and through contracted professional services work, not off the
shelf. Linux will make that side of the industry even more valuable, it
will empower the developers and the businesses that hire them to do even
more than they can today. It will empower them to do it right.

As for games and similar specialties, they aren't going anywhere. It
costs far too much money to produce a high-end game and the open source
world either can't afford it or can't produce it fast enough to support
the market.

So Allchin's flag waving is simple posturing. Microsoft may become
irrelevant, but the software industry won't.

John

Re: Linux stifles innovation... [way O.T.]

[Gerhard Mack]

On Sat, 17 Feb 2001, Dennis wrote:

> BSDI is distributing FreeBSD now. They havent done anything useful to 
> support it. They are just cashing in on it.

That's BS last I heard they were merging their SMP support.

Btw have you submitted bug reports for your networking card? If not you
have no one to blame but yourself for the fact that it's not working on
your system.

	Gerhard


--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Linux stifles innovation...

[Dennis]

At 07:01 PM 02/16/2001, Alan Olsen wrote:
>On Fri, 16 Feb 2001, Dennis wrote:
>
> > There is much truth to the concept, although Microsoft should not be ones
> > to comment on it as such.
>
>What truth?  I have seen more "innovation" in the Open Source movement
>than I ever have in my 18+ years of being a professional programmer.

You are confusing "progress" with "innovation". If there is only 1 choice, 
thats not innovation. Expanding on a bad idea, or even a good one, is not 
innovation.

Designing something differently to make it better is innovation.  I suppose 
you could argue that redesigning linux every few  years is innovation, but 
unfortunately its the same cast of characters doing it, so its not very 
innovative.

DB




>I don't see how having the source open removes "intelectual property",
>except by showing that huge portions of the concept are flawed.
>
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > with different "features" that were of value to you. Instead, you have
> > crappy GPL code that locks up under load, and its not worth spending
> > corporate dollars to fix it because you have to give away your work for
> > free under GPL. And since there is a "free" driver that most people can
> > use, its not worth building a better mousetrap either because the 
> market is
> > too small. So, the handful of users with problems get to "fit it
> > themselves", most of whom cant of course.
>
>Strange.  I have not heard of any problems with that driver, except for
>issues where the original hardware vendor kept implimentation details from
>the open source community.  (Citeing "IP issues".)
>
> > Theres also the propensity for mediocre stuff to get into the kernel
> > because some half-baked programmer was willing to contribute some code. 
> The
> > 50% of the kernel that remains "experimental" ad infinitum is evidence 
> of that.
>
>You must be looking at a different kernel.
>
>I have seen little in the kernel that was "half baked".  There have been
>some things put in to test if they were good ideas.  That is far different
>than half-baked.  Most of the bad ideas never get to the kernel.  Linus or
>Alan kick them out before they ever get that far.
>
> > The biggest thing that the linux community does to stifle innovation is to
> > bash commercial vendors trying to make a profit by whining endlessly about
> > "sourceless" distributions and recommending "open-source" solutions even
> > when they are wholly inferior. You're only hurting yourselves in the long
> > run. In that respect MS is correct, because those with the dollars to
> > innovate will stay away.
>
>You claim that "open source solutions are wholely inferior to closed
>source solutions".
>
>Hmmmm...
>
>Then why does everyone run with Apache instead of IIS?  Could it be that
>IIS is a piece of crap?
>
>Feature for feature I would rather use PHP 4 over ColdFusion any day.
>
>Sendmail is MUCH more stable than Exchange.  (Even if it has config files
>that look like they were designed by Carlos Castanada on a bad day.) If
>not Sendmail, there are a couple of other Open Source mail programs that
>are much superior in quality than the closed source counterparts.
>
>As for the Linux kernel being "shoddy"...
>
>Since when?
>
>I can leave my Linux box running over night and actually have it do
>things!  I cannot say the same for Windows.  I leave that running (same
>hardware, different OS) and it is usually dead by dawn.
>
>But your argument is even more bogus than that.
>
>It seems that you argument boils down to a couple of thing...
>
>"Closed source is better because you pay money for it."
>
>"Closed source is superior because we have a company name and you don't."
>
>Sorry, but most of the people who develop Open Source are profesional
>programmers.  They just have a different motivation.
>
>Open Source is motivated by pride in what you can do and a desire to help
>others by sharing that. They don't hide behind a wall of lawyers to keep
>people from finding out what they did wrong.
>
>I found out a long time ago that most "Trade Secret" claims were bogus.
>It was either a common technique that had been adapted to a particular
>purpose or it was being used as an excuse to hide how bad the code really
>was.
>
>But my experiences with Open Source, as well as the others I know who use
>it are quite telling.
>
>If I have a problem with an Open Source program I can look at the code and
>fix it.  Or I can report the bug and it will get fixed soon after. The
>programmers involved put the effort into it because their name is
>attached.
>
>My experiences with closed source companies are not as good.
>
>In many cases, I was ignored because I did not represent a fortune 500
>company.  If the problem got fixed at all, it would be months before I saw
>it and usually in a later release that I would have to pay for.  (Usually
>having features added that I neither wanted or would ever use.)  In some
>cases (like Microsoft security bugs) it would be treated like a public
>relations problem instead of a software and quality issue.
>
>I have also seen cases where problems were buried in development because
>"no one will find out and if they do, we will just blame Microsoft".
>
>I understand your desire to make money off what you do for a living. I do
>object to you taring what I do as somehow damaging to the software
>industry as a whole.  (Especially since the closed source software
>industry has been poaching off the open source community for years.
>Microsoft seeking enlightenment with WinXP is only a minor example.)
>
>I don't see how hiding how something works adds value to the process.
>
>alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
>Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
>     "In the future, everything will have its 15 minutes of blame."

Re: Linux stifles innovation...

[James A. Sutherland]

On Sat, 17 Feb 2001, Dennis wrote:

> At 07:01 PM 02/16/2001, Alan Olsen wrote:
> >On Fri, 16 Feb 2001, Dennis wrote:
> >
> > > There is much truth to the concept, although Microsoft should not be ones
> > > to comment on it as such.
> >
> >What truth?  I have seen more "innovation" in the Open Source movement
> >than I ever have in my 18+ years of being a professional programmer.
>
> You are confusing "progress" with "innovation".

Not necessarily: both exist in open source projects.

> If there is only 1 choice, thats not innovation.

You are confusing "innovation" with "competition".

> Expanding on a bad idea, or even a good one, is not innovation.

Correct. Having the idea in the first place is innovation.

> Designing something differently to make it better is innovation.  I suppose
> you could argue that redesigning linux every few  years is innovation, but

Not really. Changing Linux to take advantage of some new concept would be
innovation. Adding a new feature would be innovation.

> unfortunately its the same cast of characters doing it, so its not very
> innovative.

There is no need for innovation to involve different/new PEOPLE, just new
IDEAS.


James.

Re: Linux stifles innovation...

[Michael H. Warfield]

On Sat, Feb 17, 2001 at 03:05:36PM -0500, Dennis wrote:
> At 07:01 PM 02/16/2001, Alan Olsen wrote:
> >On Fri, 16 Feb 2001, Dennis wrote:

> > > There is much truth to the concept, although Microsoft should not be ones
> > > to comment on it as such.

> >What truth?  I have seen more "innovation" in the Open Source movement
> >than I ever have in my 18+ years of being a professional programmer.

> You are confusing "progress" with "innovation". If there is only 1 choice, 
> thats not innovation. Expanding on a bad idea, or even a good one, is not 
> innovation.

	I think you are obviously the one who is confused.  You are right.
If there is only 1 choice, that's not innovation.  And that's what closed
source is.  Open source is typically castigated because it HAS SO MANY
choices.  We are often overwhelmed by choices.  Sometimes, those choices
narrow through natural selection and evolution, and that's a good thing too.
Close source is the mono-choice.  You take what the vendor gives you and
that's it.  If it doesn't work, tough, wait for the next release cycle
and pay us again to fix our bugs.  That's real innovative.

> Designing something differently to make it better is innovation.  I suppose 
> you could argue that redesigning linux every few  years is innovation, but 
> unfortunately its the same cast of characters doing it, so its not very 
> innovative.

	I think I agree with the comment that I've seen more innovation in
the open source movement than anything that has come out of closed source.
One could very safely argue that the entire Internet grew out of a form
of Open Source movement.  Closed source gave us things like EDI and SNA
and SDLC and a host of other proprietary ideas and networks that have been
buried by the Internet.  "Profs" (IBM's idea of E-Mail) was swamped by SMTP.
The Web originated in Open Source.  Entire markets have sprung up where
there was none before out of Open Source.

	No...  Close Source and proprietary protocols are then anthema to
BOTH progress and innovation.  When innovation is done in a close arena, it
gets done for closed limited ideas and tightly restricted to what profits
the inventors and nothing more.  It's when it becomes more open that the
real innovation occurs and things are created that the original inventors
never envisioned.

	Without Open Source and it's predecessors, we would not have the
Internet as we know it today.  Companies back then (and I worked for
some of them) could not envision a network as we know it now.  Several
of them saw no future what so ever in the "Internet".  One of them even
went so far as to proclaim that Novell was the be all and end all of
networking and nothing would ever amount to anything on this petty worthless
Internet thing.

	History has proved them wrong and history has proved that Open
Source is the provider of choices not the limiter of choices.

> DB

> >I don't see how having the source open removes "intelectual property",
> >except by showing that huge portions of the concept are flawed.
> >
> > > For example, if there were six different companies that marketed ethernet
> > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > > with different "features" that were of value to you. Instead, you have
> > > crappy GPL code that locks up under load, and its not worth spending
> > > corporate dollars to fix it because you have to give away your work for
> > > free under GPL. And since there is a "free" driver that most people can
> > > use, its not worth building a better mousetrap either because the 
> > market is
> > > too small. So, the handful of users with problems get to "fit it
> > > themselves", most of whom cant of course.
> >
> >Strange.  I have not heard of any problems with that driver, except for
> >issues where the original hardware vendor kept implimentation details from
> >the open source community.  (Citeing "IP issues".)
> >
> > > Theres also the propensity for mediocre stuff to get into the kernel
> > > because some half-baked programmer was willing to contribute some code. 
> > The
> > > 50% of the kernel that remains "experimental" ad infinitum is evidence 
> > of that.
> >
> >You must be looking at a different kernel.
> >
> >I have seen little in the kernel that was "half baked".  There have been
> >some things put in to test if they were good ideas.  That is far different
> >than half-baked.  Most of the bad ideas never get to the kernel.  Linus or
> >Alan kick them out before they ever get that far.
> >
> > > The biggest thing that the linux community does to stifle innovation is to
> > > bash commercial vendors trying to make a profit by whining endlessly about
> > > "sourceless" distributions and recommending "open-source" solutions even
> > > when they are wholly inferior. You're only hurting yourselves in the long
> > > run. In that respect MS is correct, because those with the dollars to
> > > innovate will stay away.
> >
> >You claim that "open source solutions are wholely inferior to closed
> >source solutions".
> >
> >Hmmmm...
> >
> >Then why does everyone run with Apache instead of IIS?  Could it be that
> >IIS is a piece of crap?
> >
> >Feature for feature I would rather use PHP 4 over ColdFusion any day.
> >
> >Sendmail is MUCH more stable than Exchange.  (Even if it has config files
> >that look like they were designed by Carlos Castanada on a bad day.) If
> >not Sendmail, there are a couple of other Open Source mail programs that
> >are much superior in quality than the closed source counterparts.
> >
> >As for the Linux kernel being "shoddy"...
> >
> >Since when?
> >
> >I can leave my Linux box running over night and actually have it do
> >things!  I cannot say the same for Windows.  I leave that running (same
> >hardware, different OS) and it is usually dead by dawn.
> >
> >But your argument is even more bogus than that.
> >
> >It seems that you argument boils down to a couple of thing...
> >
> >"Closed source is better because you pay money for it."
> >
> >"Closed source is superior because we have a company name and you don't."
> >
> >Sorry, but most of the people who develop Open Source are profesional
> >programmers.  They just have a different motivation.
> >
> >Open Source is motivated by pride in what you can do and a desire to help
> >others by sharing that. They don't hide behind a wall of lawyers to keep
> >people from finding out what they did wrong.
> >
> >I found out a long time ago that most "Trade Secret" claims were bogus.
> >It was either a common technique that had been adapted to a particular
> >purpose or it was being used as an excuse to hide how bad the code really
> >was.
> >
> >But my experiences with Open Source, as well as the others I know who use
> >it are quite telling.
> >
> >If I have a problem with an Open Source program I can look at the code and
> >fix it.  Or I can report the bug and it will get fixed soon after. The
> >programmers involved put the effort into it because their name is
> >attached.
> >
> >My experiences with closed source companies are not as good.
> >
> >In many cases, I was ignored because I did not represent a fortune 500
> >company.  If the problem got fixed at all, it would be months before I saw
> >it and usually in a later release that I would have to pay for.  (Usually
> >having features added that I neither wanted or would ever use.)  In some
> >cases (like Microsoft security bugs) it would be treated like a public
> >relations problem instead of a software and quality issue.
> >
> >I have also seen cases where problems were buried in development because
> >"no one will find out and if they do, we will just blame Microsoft".
> >
> >I understand your desire to make money off what you do for a living. I do
> >object to you taring what I do as somehow damaging to the software
> >industry as a whole.  (Especially since the closed source software
> >industry has been poaching off the open source community for years.
> >Microsoft seeking enlightenment with WinXP is only a minor example.)
> >
> >I don't see how hiding how something works adds value to the process.
> >
> >alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
> >Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
> >     "In the future, everything will have its 15 minutes of blame."
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

mhw@wittsend.com (Michael H. Warfield) writes:

>	No...  Close Source and proprietary protocols are then anthema to
>BOTH progress and innovation.  When innovation is done in a close arena, it

These are two different things! Proprietary protocols are the death to
variety and customer choice! 

I personally are perfectly happy with closed source and open
protocols. Show me a compareable product to BEA WebLogic, which is
free. But if I consider this closed source program to suck, I can
still take my application and deploy it on a free EJB container with a
free servlet engine. I don't lose with closed source here. And the
closed source vendor is forced to compete with open source
products. Which in the end gives me a better product. I'm happy with
upgrades and release cycles where I get one new release and some bug
fixes in six months. Not a new release all two days. And I'm happy
that I can call a support line or open a bug ticket with a
vendor. Yes, there are vendors which care about bug tickets and fix
bugs in their products.

The division "Open Source - all bugs are fixed in shortest time"
vs. "Close Source - no bugs are fixed at all and only updates are
sold" is IMHO plain wrong. And e.g. in Germany, where there is
something called "Gewaehrleistungsfrist" which is six months after
selling a product, vendors are held by the law (!) to fix bugs. And
again, companies like M$ try to circument this with "EULAs" which,
according to some lawyers do not uphold in court. But according to my
knowledge, noone in Germany has ever tried to sue M$ to force them to
comply to this law.

Microsoft tries to circumvent this competition with proprietary
protocols and non-interchangeablity. Why do they bash Java? Why do
they push something like C#? Because they don't want _NO_
competition. They "embrace and extend". And the patent the extensions.

Many other companies take the challenge of open source and open
protocols and try to compete with open source products. And they do it
really well! I have to see Oracle to lose a significant percentage of
their Enterprise RDBMS to free software (And please don't quote me the
"Nasa switches to MySQL" article. This is fine but then again for them, 
Oracle wasn't a good choice in the first place. ;-) )

Innovation today happens with protocols. With ideas. With interoperability.  
On the Internet. Open Source and Closed Source are competitors and
open source and free software _forces_ company to make better software
if they want to compete.

Microsoft tries to avoid the competition and wants to lock their
customers into the Windows - IIS - ASP - .NET - C# cycle with
proprietary protocols, languages and platforms, because then they know
that for these customers, changing into _any_ other environment (be it
the LAMP, FreeBSD-PostgreSQL-Python, Zope, Oracle, Cold Fusion or
anything _else_) is so hard, that the customers won't do. 

Setting up a network of "Microsoft certified professionals" which
repeat the ideology from Redmond on and on, really helps here. It is
almost like the roman-catholic church. ;-)

Microsoft don't really care about "Open Source", "Closed Source", GNU,
Linux, BSD and all the stuff. They only care about "Competition" and
"Market share". Anything that endangers their market share is a
threat.

>	Without Open Source and it's predecessors, we would not have the
>Internet as we know it today.  Companies back then (and I worked for

No. Without Cisco and Sun, we wouldn't have a working internet at
all. And they do closed products with open protocols. And that's IMHO
the point.

>some of them) could not envision a network as we know it now.  Several
>of them saw no future what so ever in the "Internet".  One of them even
>went so far as to proclaim that Novell was the be all and end all of
>networking and nothing would ever amount to anything on this petty worthless
>Internet thing.

>	History has proved them wrong and history has proved that Open
>Source is the provider of choices not the limiter of choices.

No. Open protocols and Open ideas are. Open source is just a part of
the whole picture. Every company that tries to lock their customers
into their products, are a threat to the Internet and to users and
customers. That's where Novell from your example failed. They failed
because of IPX and their inability to adjust to the emerging IP
environment.

Novell failed because they tried to push a small vertical, expensive
product (file and print serving) when a competitor started to give the
"peer-to-peer" and server network away with their baseline product
("Windows"). Not because they made a close source product.

"We give away for free, what you sell". Microsoft got Novell with
this. They got Netscape with this. They will try to get the next
competitor with this, too. They can't get Linux with this and that's
why they're afraid. And that's where such a Linux-bashing article
comes from.

	Regards
		Henning
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Linux stifles innovation...

[Alan Olsen]

On Sat, 17 Feb 2001, Dennis wrote:

> At 07:01 PM 02/16/2001, Alan Olsen wrote:
> >On Fri, 16 Feb 2001, Dennis wrote:
> >
> > > There is much truth to the concept, although Microsoft should not be ones
> > > to comment on it as such.
> >
> >What truth?  I have seen more "innovation" in the Open Source movement
> >than I ever have in my 18+ years of being a professional programmer.
> 
> You are confusing "progress" with "innovation". If there is only 1 choice, 
> thats not innovation. Expanding on a bad idea, or even a good one, is not 
> innovation.

"You keep using that word. i don't think it means what you think it
means."

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
    "In the future, everything will have its 15 minutes of blame."

Re: Linux stifles innovation...

[Dr. Kelsey Hudson]

On Sat, 17 Feb 2001, Alan Olsen wrote:
> "You keep using that word. i don't think it means what you think it
> means."

 ...To quote Indigo Montoya, speaking to Vuzinni, from "The Princess
Bride" :)

One hell of a story :)

 Kelsey Hudson                                           khudson@ctica.com 
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------     

Re: Linux stifles innovation...

[Felix von Leitner]

Thus spake Dennis (dennis@etinc.com):
> You are confusing "progress" with "innovation". If there is only 1 choice, 
> thats not innovation. Expanding on a bad idea, or even a good one, is not 
> innovation.

This is bizarre.

Please name one innovation in the history of mankind that could not be
seen as expanding on a different idea or even cloning an idea from
someone else (for example, nature).

Dennis, do you have a single argument or are you going to post bizarre
statements like this forever?  Please just say so, so people cann
killfile you now.

Felix

Re: Linux stifles innovation...

[Dennis]

At 07:10 PM 02/16/2001, rjd@xyzzy.clara.co.uk wrote:
>Dennis wrote:
>...
> > objective, arent we?
>Nope. Are you claiming to be?
>
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
>... Rant deleted
>
>I had a problem with eepro100.
>It was fixed same night cause I had the source.
>Don't even try to compare with MickyS**t.


good commercial drivers dont need fixing. another point. You are arguing 
that having source is required to fix crappy code, which i agree with.

You "guys" like to have source, and there is nothing wrong with that. But 
requiring that all code be distributed as source DOES stifle innovation. 
Its as simple as that.

Re: Linux stifles innovation...

[Michael H. Warfield]

On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote:
> At 07:10 PM 02/16/2001, rjd@xyzzy.clara.co.uk wrote:
> >Dennis wrote:
> >...
> > > objective, arent we?
> >Nope. Are you claiming to be?
> >
> > > For example, if there were six different companies that marketed ethernet
> > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> >... Rant deleted
> >
> >I had a problem with eepro100.
> >It was fixed same night cause I had the source.
> >Don't even try to compare with MickyS**t.


> good commercial drivers dont need fixing. another point. You are arguing 
> that having source is required to fix crappy code, which i agree with.

	Then good commercial drivers == blivit.

	Ain't no such critter.  They are always late and buggy and then
take forever to get fixed.  Nature of the close source development cycle
with deadlines and project managers that say "we can afford to wait any
longer, we have to ship it now and fix the bugs after release".

> You "guys" like to have source, and there is nothing wrong with that. But 
> requiring that all code be distributed as source DOES stifle innovation. 
> Its as simple as that.

	Sorry but it's time to pull it out, smell the air, and buy a clue.
There are people out there right now delivering binary modules and binary
pieces for device drivers in the kernel.  I'm working with one right now.
They are providing partial sources with a binary library (this is the
Lucent WaveLan wvlan2_cs drivers).  Nothing is required.  But binary drivers
don't get the support from the open source people that the open source
drivers get.  Sounds reasonable to me.  There are other binary only drivers
(to say nothing of applications) both freeware and payware out there.  I've
got people working on some myself.  So your arguement that "requiring that
all code be distributed as source DOES stifle innovation" fails on it's
premise because it's NOT REQUIRED.  Just don't expect us to kiss your merry
ass and fall over backwards meeting your demands when you DO deliver a
binary only driver.  If people like it, fine.  If they don't, whose problem
is that?  The idea that nobody will pay for OpenSource software is a myth.
I buy software for Linux all the time.  I buy closed source software and
I buy open source software.  The only difference is the presence of the
sources.  So what.  Tell me how that makes those products less innovative?

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: Linux stifles innovation...

[Gregory Maxwell]

On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote:
> good commercial drivers dont need fixing. another point. You are arguing 
> that having source is required to fix crappy code, which i agree with.

Too bad we havn't seen much (any?) good closed-source (what you ment to say
when you said commercial above) drivers for Linux, including the steaming
pile of garbage your company ships.
 
> You "guys" like to have source, and there is nothing wrong with that. But 
> requiring that all code be distributed as source DOES stifle innovation. 
> Its as simple as that.

Like Microsoft you seem to confuse 'innovation' with 'being able to dictate
the terms of how I will extort money from others'.

Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

greg@linuxpower.cx (Gregory Maxwell) writes:

>when you said commercial above) drivers for Linux, including the steaming
>pile of garbage your company ships.

"hostile behaviour of the open source community towards people that
don't agree to their ideas".

q.e.d. Thanks.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Linux stifles innovation...

[Bob Taylor]

In message <96o9uf$j4h$1@forge.intermeta.de>, "Henning P. 
Schmiedehausen" write
s:
> greg@linuxpower.cx (Gregory Maxwell) writes:
> 
> >when you said commercial above) drivers for Linux, including the steaming
> >pile of garbage your company ships.
> 
> "hostile behaviour of the open source community towards people that
> don't agree to their ideas".

As I am a member of this community and have not exhibited such 
behavior to you, please include me *out* of such general 
condemnation.
BTW, your conclusion is *false*

-- 
+---------------------------------------------------------------+
| Bob Taylor             Email: brtaylor@inreach.com            |
|---------------------------------------------------------------|
| Like the ad says, at 300 dpi you can tell she's wearing a     |
| swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you   |
| can tell it's painted on. I suppose at 2400 dpi you can tell  |
| if the paint is giving her a rash. (So says Joshua R. Poulson)|
+---------------------------------------------------------------+

Re: Linux stifles innovation...

[Andre Hedrick]

On Sat, 17 Feb 2001, Dennis wrote:

> good commercial drivers dont need fixing. another point. You are arguing 
> that having source is required to fix crappy code, which i agree with.
> 
> You "guys" like to have source, and there is nothing wrong with that. But 
> requiring that all code be distributed as source DOES stifle innovation. 
> Its as simple as that.

And when your customer gets screw because you refuse to update your binary
driver because you do not know or have had the chance to follow any
evolving API, you are going to blame us in OPEN source, right.

Meanwhile the API changes may have boosted the performance factor and you
have screw yourself and customer base because you are to lame to see the
value of open source.

Some time ago I proposed CLAPI, and you are one of the venders that would 
benefit from such a beast.  This model would have required you to LGPL a
kernel library that would have all the functional IP (that is not IP) that
is to lame to be placed into the hardware.  If your hardware is so flakey
that you have to pump/prime it for operations....well....you get the
point.

If I recall you and your company on one of the worst offenders of taking
code (GPL or not) and changing it and putting it out as binaries.  I am
surprized that you have not been taken down yet.  Then if someone asks for
the return of the code base and changes because they can under the terms
of the license that you removed from that code, you charge them a fee and
suggest actionable terms if any disclosure into the public form from
where it came.

Regards,

Andre Hedrick
Linux ATA Development

Re: Linux stifles innovation...

[Michael H. Warfield]

On Sat, Feb 17, 2001 at 02:38:19PM -0800, Andre Hedrick wrote:
> On Sat, 17 Feb 2001, Dennis wrote:
> > good commercial drivers dont need fixing. another point. You are arguing 
> > that having source is required to fix crappy code, which i agree with.

> > You "guys" like to have source, and there is nothing wrong with that. But 
> > requiring that all code be distributed as source DOES stifle innovation. 
> > Its as simple as that.

> And when your customer gets screw because you refuse to update your binary
> driver because you do not know or have had the chance to follow any
> evolving API, you are going to blame us in OPEN source, right.

	At our office, we actually had a sysadmin suggest that the reason
we had problems with viruses propagating was because they couldn't put
everyone on Exchange (some of us use Unix/Linux) and that was causing the
problems.  Of course...  Operating systems which are immune to these things
are to blame for the epidemics on the ones that are suceptible.  That
makes sense.  Grrrr....  Of course the availablity of quality drivers with
sources are the reason for crappy closed source drivers...  I can see his
reasoning (isn't that scary).  <;-/=/

	Actually, it does make a perverted sort of sense.  If we didn't
have systems that didn't have these problems, nobody would think that
there was anything wrong.  They would just think that "of course, this
is what you expect from suppliers".  They would have no yardstick to
measure against, so rebooting a computer once a day or having a blue
screen would just be part of the normal experience.  So we DO contribute
to his problems!  We provide a standard which he can not live up to or
even pursue given the manpower and talent he may have (or not have).
How is he suppose to innovate when the Open Source community is setting
such a high standard for him?  :->=>

> Meanwhile the API changes may have boosted the performance factor and you
> have screw yourself and customer base because you are to lame to see the
> value of open source.
> 
> Some time ago I proposed CLAPI, and you are one of the venders that would 
> benefit from such a beast.  This model would have required you to LGPL a
> kernel library that would have all the functional IP (that is not IP) that
> is to lame to be placed into the hardware.  If your hardware is so flakey
> that you have to pump/prime it for operations....well....you get the
> point.
> 
> If I recall you and your company on one of the worst offenders of taking
> code (GPL or not) and changing it and putting it out as binaries.  I am
> surprized that you have not been taken down yet.  Then if someone asks for
> the return of the code base and changes because they can under the terms
> of the license that you removed from that code, you charge them a fee and
> suggest actionable terms if any disclosure into the public form from
> where it came.

	Well...  Yeah...  Of course, Andre.  Can you see how that stiffles
his innovation.

> Regards,

	Later!

> Andre Hedrick
> Linux ATA Development

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: Linux stifles innovation...

[Stefan Smietanowski]

Hi.

Thought I'd toss my 0.02sek into the discussion.

> > > objective, arent we?
> >Nope. Are you claiming to be?
> >
> > > For example, if there were six different companies that marketed ethernet
> > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> >... Rant deleted
> >
> >I had a problem with eepro100.
> >It was fixed same night cause I had the source.
> >Don't even try to compare with MickyS**t.
> 
> good commercial drivers dont need fixing. another point. You are arguing
> that having source is required to fix crappy code, which i agree with.

Ok, tell that to my SBLive that absolutely loves jumping and jittering
on my SMP box under Win2k. Creative have been notified. Ever since they
released their first driver for it...

So if they would've had their driver out in the open I'm sure SOMEONE,
if not me, would've squashed the bug already.

So you're right, good commercial drivers don't need fixing.
Also, good open-source drivers don't need fixing.
Good drivers don't need fixing! Of course they don't!

But crap coding is crap coding no matter what license/distribution form
you put it under, be it open source, closed source or whatnot.

// Stefan

Re: Linux stifles innovation...

[Peter Samuelson]

[Dennis]
> For example, if there were six different companies that marketed
> ethernet drivers for the eepro100, you'd have a choice of which one
> to buy..perhaps with different "features" that were of value to
> you. Instead, you have crappy GPL code that locks up under load, and
> its not worth spending corporate dollars to fix it because you have
> to give away your work for free under GPL. And since there is a
> "free" driver that most people can use, its not worth building a
> better mousetrap either because the market is too small. So, the
> handful of users with problems get to "fit it themselves", most of
> whom cant of course.

You may have a point but device drivers are a piss-poor example.  Say
Linux does take over the world, and eepro100 continues to lock up under
load.  Who loses?  Intel.  People will quit buying their motherboards
and PCI cards.  So for whom is it worth spending corporate dollars
fixing eepro100?  Again, Intel.  If word were to get out "avoid Intel
network cards, the driver is crap", you can bet they will fix it.

If this hasn't happened yet, it's because Intel doesn't see enough
market in Linux to bother.  And if so, so what?  There are plenty of
motherboards with pcnet32 and 3c9xx chips.

Peter

Re: Linux stifles innovation...

[Hristo Doichev]

On the surface you seem to make some good points.
In reality ... ?? 
Money doesn't buy the ability to innovate!
OSS doesn't, magically, enhance the ability to innovate, aither!
No one can predict where and why an innovation occurs.

The only thing that OSS does to MS is to prohibit them for capitalizing
on ideas that are born within the OSS community. This must hurt them (MS)
since there are a lot of cool ideas they (MS) would like to snatch. Just take
a look at the list of companies acquired by MS. Considering the amount of 
money MS puts into software R&D there should be nothing left for the rest of 
the world to discover or invent?! :-0 
If anything, MS is the prime example of immature and unreliable code 
(applications). Money doesn't even guarantee stability and usability of your
applications. Perhaps you are one of those rare souls that has absolutely 
no problems with MS products which, mind you, up until now were not 
experimental. On the other hand Windows XP stands, obviously, for Windows 
eXPeriment. 

Innovations by hackers that developed KDE and Gnome can change the way you 
use your computer. For instance, have you been to www.eazel.com? While
Nautilus is of no interest to me you can run an entire Linux Desktop over the 
internet by just using your browser. Try the demo ... pull up a console and 
fire off some commands, try GnuCash or something!!!! 
It is super cool and it is great technology that comes for free with just 
about all Linux distributions. I bet MS would like to be able to do the same 
...

regards.
Hristo Doichev



On Friday 16 February 2001 14:27, Dennis wrote:
> At 02:48 PM 02/16/2001, Jesse Pollard wrote:
> >On Fri, 16 Feb 2001, Andrew Scott wrote:
> > >On 15 Feb 2001, at 9:49, fsnchzjr wrote:
> > >> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> > >> Nice little article on how we're all going to die of herpes from our
> > >> repeated exposition to Linux...
> >
> > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html
> >?ta
> >
> > >> g=ltnc
> > >
> > >That's about as self-serving a statement as I've ever seen. If this
> > >'Jim Alchin' actually believes what he's saying, he's got to be one
> > >of the worlds biggest fools, and if he doesn't believe what he's
> > >saying, well there aren't too many words that would accurately
> > >describe what he is.
> > >
> > >It's pretty funny in some ways, e.g. "We can build a better product
> > >than Linux...", which begs the question, "Well, why don't you?".
> > >Perhaps it costs too much?
>
> objective, arent we?
>
> There is much truth to the concept, although Microsoft should not be ones
> to comment on it as such.
>
> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you. Instead, you have
> crappy GPL code that locks up under load, and its not worth spending
> corporate dollars to fix it because you have to give away your work for
> free under GPL. And since there is a "free" driver that most people can
> use, its not worth building a better mousetrap either because the market is
> too small. So, the handful of users with problems get to "fit it
> themselves", most of whom cant of course.
>
> Theres also the propensity for mediocre stuff to get into the kernel
> because some half-baked programmer was willing to contribute some code. The
> 50% of the kernel that remains "experimental" ad infinitum is evidence of
> that.
>
> The biggest thing that the linux community does to stifle innovation is to
> bash commercial vendors trying to make a profit by whining endlessly about
> "sourceless" distributions and recommending "open-source" solutions even
> when they are wholly inferior. You're only hurting yourselves in the long
> run. In that respect MS is correct, because those with the dollars to
> innovate will stay away.
>
> DB
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Byron Albert]

A good article on linux today about this.
http://linuxtoday.com/news_story.php3?ltsn=2001-02-15-003-20-OP

Byron


fsnchzjr wrote:

> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> Nice little article on how we're all going to die of herpes from our
> repeated exposition to Linux...
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> g=ltnc
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/