RE: Nvidia and its choice to read the GPL "differently"

RE: Nvidia and its choice to read the GPL "differently"

[Larry Sendlosky]

Richard, 

We all know that "Linux" would not be where it is today without
the GNU software. I don't recall seeing one post in this
looonnngg thread that tries to say otherwise. Myself, and many others,
are very grateful for your and the FSF's work. PLEASE, stop hitting us
over the head with GNU/Linux. 

I'm sure there are many other "things" that have gotten broad public
attention and the real people or organizations behind it have not gotten
the credit they deserve either by what the "thing" is called or by
the press, etc. Only the people truly involved with the "thing"
know who is responsible. I think the same applies here. 

And, why is it only *you* beating us over the head with GNU/Linux?
Where's the rest for the GNU (non-linux specific) contributors?
Why aren't they bitching/whining too?

Like I said before, we aren't the people you have to educate/convince.
If it really means that much to you (and it seems to me that it does),
then you should be taking out magazine ads and buying time on TV
to reach the uneducated masses.


-----Original Message-----
From: Larry McVoy [mailto:lm@bitmover.com]
Sent: Thursday, January 09, 2003 6:39 PM
To: Richard Stallman
Cc: Vlad@Vlad.geekizoid.com; linux-kernel@vger.kernel.org
Subject: Re: Nvidia and its choice to read the GPL "differently"


On Thu, Jan 09, 2003 at 06:14:20PM -0500, Richard Stallman wrote:
> GNU, the system we were developing, was most of the early GNU/Linux
> system in 1992.  GNU in 1992 included non-GNU packages such as X11,
> and TeX.

Wow.  That might be one for the quotes file:

    "GNU ... was of the early GNU/Linux system.  GNU ... included non-GNU"

Well, that certainly explains a lot.  If you define GNU as "anything
which might be found on a Linux distro including non-GNU packages",
your position starts to make a certain twisted sense.  Only one problem
with that: if it wasn't GNU, it wasn't GNU, which means, Richard, you
are crackin' smoke and may need a vacation.  19 years of hard effort is 
a long time, have you considered retirement?  You've certainly earned it.

Oh, by the way, have you updated the GNU kernel pages to reflect the new
proper name: Linux/Hurd?  I'd really appreciate it if you could get to that.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
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: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

I think Gnu in the name is a great idea (debian uses it already, I
think).  It helps point out that Linus Torvalds didn't create this great
thing that most people call linux (his namesake).  Linus Torvalds didn't
create and wants nothing to do with the windowing system or user
components, which most end users would consider what their experience
with linux is (whether they use guis or the command line) -- especially
non-tech-heads.  Linus torvalds did not create the compilers or
libraries the developers use.  Linus torvalds simply created a bare
bones kernel -- a piece of the operating system which literally does
almost nothing.  Thanks to the GPL others helped him grow the kernel,
and he's been a good leader in that he's let others give him lot of free
code changes to include in his namesake system.

He just got lucky on his timing... Anyone studying operating systems at
the time (and heck, I remember owning a book "Creating your own 32-bit
operating system" by SAMS publishing and being inspired, and I also
owned "Disecting DOS" which was a nice analysis of a DOS-like operating
system at the code-level book w/disk).  If I had been familiar with UNIX
at the time I had those books, I might've written ROBIX before LINUX
came around, and released it on an even lesser than less GPL whereby
anyone who wanted could do whatever they wanted with it however they
wanted, commercially or not, open-sourcely-or-not.

-Rob

On Fri, 2003-01-10 at 10:29, Larry Sendlosky wrote:
> Richard, 
> 
> We all know that "Linux" would not be where it is today without
> the GNU software. I don't recall seeing one post in this
> looonnngg thread that tries to say otherwise. Myself, and many others,
> are very grateful for your and the FSF's work. PLEASE, stop hitting us
> over the head with GNU/Linux. 
> 
> I'm sure there are many other "things" that have gotten broad public
> attention and the real people or organizations behind it have not gotten
> the credit they deserve either by what the "thing" is called or by
> the press, etc. Only the people truly involved with the "thing"
> know who is responsible. I think the same applies here. 
> 
> And, why is it only *you* beating us over the head with GNU/Linux?
> Where's the rest for the GNU (non-linux specific) contributors?
> Why aren't they bitching/whining too?
> 
> Like I said before, we aren't the people you have to educate/convince.
> If it really means that much to you (and it seems to me that it does),
> then you should be taking out magazine ads and buying time on TV
> to reach the uneducated masses.
> 
> 
> -----Original Message-----
> From: Larry McVoy [mailto:lm@bitmover.com]
> Sent: Thursday, January 09, 2003 6:39 PM
> To: Richard Stallman
> Cc: Vlad@Vlad.geekizoid.com; linux-kernel@vger.kernel.org
> Subject: Re: Nvidia and its choice to read the GPL "differently"
> 
> 
> On Thu, Jan 09, 2003 at 06:14:20PM -0500, Richard Stallman wrote:
> > GNU, the system we were developing, was most of the early GNU/Linux
> > system in 1992.  GNU in 1992 included non-GNU packages such as X11,
> > and TeX.
> 
> Wow.  That might be one for the quotes file:
> 
>     "GNU ... was of the early GNU/Linux system.  GNU ... included non-GNU"
> 
> Well, that certainly explains a lot.  If you define GNU as "anything
> which might be found on a Linux distro including non-GNU packages",
> your position starts to make a certain twisted sense.  Only one problem
> with that: if it wasn't GNU, it wasn't GNU, which means, Richard, you
> are crackin' smoke and may need a vacation.  19 years of hard effort is 
> a long time, have you considered retirement?  You've certainly earned it.
> 
> Oh, by the way, have you updated the GNU kernel pages to reflect the new
> proper name: Linux/Hurd?  I'd really appreciate it if you could get to that.

Re: Nvidia and its choice to read the GPL "differently"

[Larry McVoy]

On Fri, Jan 10, 2003 at 08:58:44PM -0500, Rob Wilkens wrote:
> If I had been familiar with UNIX
> at the time I had those books, I might've written ROBIX ...

If I had ham, I could make ham and eggs, if I had some eggs.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 21:07, Larry McVoy wrote:
> On Fri, Jan 10, 2003 at 08:58:44PM -0500, Rob Wilkens wrote:
> > If I had been familiar with UNIX
> > at the time I had those books, I might've written ROBIX ...
> 
> If I had ham, I could make ham and eggs, if I had some eggs.

Precisely my point.. If I had ham, and If I had eggs, I knew (and know)
enough to make ham and eggs.  Or whatever it was we were talking about.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Larry McVoy]

On Fri, Jan 10, 2003 at 09:13:22PM -0500, Rob Wilkens wrote:
> On Fri, 2003-01-10 at 21:07, Larry McVoy wrote:
> > On Fri, Jan 10, 2003 at 08:58:44PM -0500, Rob Wilkens wrote:
> > > If I had been familiar with UNIX
> > > at the time I had those books, I might've written ROBIX ...
> > 
> > If I had ham, I could make ham and eggs, if I had some eggs.
> 
> Precisely my point.. If I had ham, and If I had eggs, I knew (and know)
> enough to make ham and eggs.  Or whatever it was we were talking about.

You missed my point.  Which was: you said you could have done what Linus
has done if only you had the knowledge, timing, and leadership skills.
I was pointing out that that is a lot of "if onlys".
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 21:17, Larry McVoy wrote:
> On Fri, Jan 10, 2003 at 09:13:22PM -0500, Rob Wilkens wrote:
> > On Fri, 2003-01-10 at 21:07, Larry McVoy wrote:
> > > On Fri, Jan 10, 2003 at 08:58:44PM -0500, Rob Wilkens wrote:
> > > > If I had been familiar with UNIX
> > > > at the time I had those books, I might've written ROBIX ...
> > > 
> > > If I had ham, I could make ham and eggs, if I had some eggs.
> > 
> > Precisely my point.. If I had ham, and If I had eggs, I knew (and know)
> > enough to make ham and eggs.  Or whatever it was we were talking about.
> 
> You missed my point.  Which was: you said you could have done what Linus
> has done if only you had the knowledge, timing, and leadership skills.
> I was pointing out that that is a lot of "if onlys".
I never said any of that, I simply said (in the above quoted message)
that I could make ham and eggs).  

I'm not interested in getting into a pissing contest with linux
torvalds, even he claims he doesn't have leadership skills (read his
biography), and I'm not claiming to either.  His programming skills are
questionable, because if they were so good then I shouldn't be seeing
hundreds of [PATCH] messages coming through every day.

By the way, on the topic of my operating systems knowledge, I should
comment that I later in life became a professional operating systems
developer working on real-time UNIX operating systems kernel, library,
and user-level code development.  

I'm not working now, but that is due to health issues.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Larry McVoy]

On Fri, Jan 10, 2003 at 09:38:38PM -0500, Rob Wilkens wrote:
> I'm not interested in getting into a pissing contest with linux
> torvalds, even he claims he doesn't have leadership skills 

Bob Young says he doesn't know anything about technology, so does 
Scott McNealy.  Lots of really smart and skilled people deny their 
own skills.  That doesn't mean you should believe them.  They are
making an effort to make you feel good.  Don't take it too literally.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 21:41, Larry McVoy wrote:
> On Fri, Jan 10, 2003 at 09:38:38PM -0500, Rob Wilkens wrote:
> > I'm not interested in getting into a pissing contest with linux
> > torvalds, even he claims he doesn't have leadership skills 
> 
> Bob Young says he doesn't know anything about technology, so does 
> Scott McNealy.  Lots of really smart and skilled people deny their 
> own skills.  That doesn't mean you should believe them.  They are
> making an effort to make you feel good.  Don't take it too literally.

Bob Young and Scott McNealy are managers, they know marketting and
business, not technology.  

Linux Torvalds knows "some" technology, and he's proud not to, for
example, know anything about what goes on in user land.

He actually claimed in his biography that "apache" was a distribution of
linux that is commonly used as a web server, apparently not knowing that
apache is a cross platform web server that runs on multiple platforms.

Anyway... To back up his comment of no leadership skills, he readily
points out in the book that he quickly was promoted then again demoted
at transmeta when he became (briefly) a team leader.  He just didn't
have what it took to be a leader, no leadership qualities or skills
whatsoever.  He's proud of that.

I'm glad to work with a guy like that, though, because it also means his
ego ain't so high.  I'm more likely to contribute kernel code or
suggestions freely back and forth with a person like that.  Whereas if
he were on a high horse, I'd say "whoa, there, bud, why should I give my
changes to you again?"...  That may be in part why he takes the attitude
he has though..

Of course, I don't 'really' know him.  I've only read about him.. I'm
new to this list, if it's not obvious.  

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Larry McVoy]

On Sat, Jan 11, 2003 at 03:26:12AM +0000, Alan Cox wrote:
> On Sat, 2003-01-11 at 02:07, Larry McVoy wrote:
> > On Fri, Jan 10, 2003 at 08:58:44PM -0500, Rob Wilkens wrote:
> > > If I had been familiar with UNIX
> > > at the time I had those books, I might've written ROBIX ...
> > 
> > If I had ham, I could make ham and eggs, if I had some eggs.
> 
> Its not ham you need its utter arrogance and a complete lack of understanding
> that writing an OS is a seriously hard problem. There is a whole world of
> mysticism around the concept of a 'beginners mind' although to me
> "Im sorry nobody told me it was impossible" sums it up far better.

Indeed.  Lots of things which are hard look easy to people who haven't 
done them.  Operating systems don't have a corner on that market.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 22:26, Alan Cox wrote:
> On Sat, 2003-01-11 at 02:07, Larry McVoy wrote:
> > On Fri, Jan 10, 2003 at 08:58:44PM -0500, Rob Wilkens wrote:
> > > If I had been familiar with UNIX
> > > at the time I had those books, I might've written ROBIX ...
> > 
> > If I had ham, I could make ham and eggs, if I had some eggs.
> 
> Its not ham you need its utter arrogance and a complete lack of understanding
> that writing an OS is a seriously hard problem. There is a whole world of
> mysticism around the concept of a 'beginners mind' although to me
> "Im sorry nobody told me it was impossible" sums it up far better.

It depends what you're starting with, and what your goals are.

If your goal is to write an operating system that runs on all hardware
and does everything for everyone, then, yes, impossible would seem to
fit.

But what I was writing about specifically said that I've read the book
dissecting dos in the distant past, as mentioned, and the slightly
thicker book, writing your own 32-bit operating system, again in the
distant past, and I've written dos-based interrupt handlers to use a
mouse in a dos text app, and I've taken college courses in operating
systems design and implementation, and even back in 1996 I've taken a
course specifically on Linux implementation (a kernel hacking class).  

Had my goal at the time been as simple as Linus' goal was an been to
just get a simple terminal emulator and grow it slowly, I don't think
impossible would have described the task.  I think "a project that I do
in my spare time and show to nobody" would more likely have described
it.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 21:54, Larry McVoy wrote:
> Indeed.  Lots of things which are hard look easy to people who haven't 
> done them.  Operating systems don't have a corner on that market.

Of all the things that computer software programmers do, writing
operating systems is among the most simplistic of those tasks.

Of that, I am certain.

That is why my first job out of college was as an Operating Systems
Kernel Programmer.

That is what they call "low level programming" and that kind of
programming is looked down upon by most other programmers.

High-level languages (stuff like delphi and visual basic) are grown-up
languages and tools where you can create more substantial programs using
more substantial areas of your brain.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Zwane Mwaikambo]

On Fri, 10 Jan 2003, Rob Wilkens wrote:

> On Fri, 2003-01-10 at 21:54, Larry McVoy wrote:
> > Indeed.  Lots of things which are hard look easy to people who haven't 
> > done them.  Operating systems don't have a corner on that market.
> 
> Of all the things that computer software programmers do, writing
> operating systems is among the most simplistic of those tasks.

okay

> Of that, I am certain.

okay
 
> That is why my first job out of college was as an Operating Systems
> Kernel Programmer.
>
> That is what they call "low level programming" and that kind of
> programming is looked down upon by most other programmers.
> 
> High-level languages (stuff like delphi and visual basic) are grown-up
> languages and tools where you can create more substantial programs using
> more substantial areas of your brain.

Please say you're simply trolling...

-- 
function.linuxpower.ca

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 22:11, Zwane Mwaikambo wrote:
> Please say you're simply trolling...

Sorry, started to get a bit off-topic.  Not trolling, though no matter
what the topic and no matter what the list, people always assume that
I'm a troll when they first meet me.  I guess they don't realize that I
think differently.  If you get used to me, you'll realize that I'm just
crazy and can either ignore me (plonk me as Larry McVoy did) or laugh at
me.  

Whatever you do, I laugh at myself in the end too, and won't be insulted
-- I am proud to report that I take four different psychiatric
medications, and still have hallucinations and delusions regularly, so I
certainly won't claim to be normal by any standard.

Of course, on an intelligence test given at the hospital (same one that
diagnosed me as schizoaffective), I was scored as "high superior
intelligence" which (to you) might mean that there's a chance there's
something useful that might occasionally come out of my mouth.  It's
doubtful, but if plonk me, you'll never know.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[John Adams]

On Friday 10 January 2003 09:58 pm, Rob Wilkens wrote:
>
> Of all the things that computer software programmers do, writing
> operating systems is among the most simplistic of those tasks.

I think we have an under-bridge dweller.

Re: Nvidia and its choice to read the GPL "differently"

[Tom Sightler]

> He just got lucky on his timing... Anyone studying operating systems at
> the time (and heck, I remember owning a book "Creating your own 32-bit
> operating system" by SAMS publishing and being inspired, and I also
> owned "Disecting DOS" which was a nice analysis of a DOS-like operating
> system at the code-level book w/disk)

You could also argue that GNU got lucky on it's timing, otherwise we might
still be waiting on a "GNU OS" rather than arguing over how important it is
to put GNU in front of Linux.

Later,
Tom

Re: Nvidia and its choice to read the GPL "differently"

[Alan Cox]

On Sat, 2003-01-11 at 02:07, Larry McVoy wrote:
> On Fri, Jan 10, 2003 at 08:58:44PM -0500, Rob Wilkens wrote:
> > If I had been familiar with UNIX
> > at the time I had those books, I might've written ROBIX ...
> 
> If I had ham, I could make ham and eggs, if I had some eggs.

Its not ham you need its utter arrogance and a complete lack of understanding
that writing an OS is a seriously hard problem. There is a whole world of
mysticism around the concept of a 'beginners mind' although to me
"Im sorry nobody told me it was impossible" sums it up far better.

Alan
--
        "Whatever you do will be insignificant,
                but it is very important that you do it."
                -- Gandhi

Re: Nvidia and its choice to read the GPL "differently"

[Brian Tinsley]

Rob Wilkens wrote:

>High-level languages (stuff like delphi and visual basic) are grown-up
>languages and tools where you can create more substantial programs using
>more substantial areas of your brain.
>
>  
>
That's got to be one of the most sick and twisted statements I've ever 
heard in my life, especially given the "programming languages" referenced.

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 22:16, John Adams wrote:
> On Friday 10 January 2003 09:58 pm, Rob Wilkens wrote:
> >
> > Of all the things that computer software programmers do, writing
> > operating systems is among the most simplistic of those tasks.
> 
> I think we have an under-bridge dweller.

No, simply a person who has worked in all areas of computing
technology..

Resume in brief:

B.S. in Computer Science may 1996, Clemson University

May 1996-April 1998 - Senior Engineer (Operating Systems - Real Time
Division) - Concurrent Computer Coporation. -- Original Title was Lead
Software Engineer -- in my short timespan there, I received a 25% raise
and a new title, and that still wasn't enough to keep me there.

April 1998-Present - Software Developer (Contract work, can't discuss,
but it's in Delphi, I'm happy to report that one reason I'm moving to
Linux more is that Borland is doing a better job with Kylix, it's Linux
version of Delphi).

June 1998-May 2001 - LAN Administrator - New York State Courts .. 

May 2001-June/July 2001 - Senior Enigneer - Geo-Centers.  I only worked
for two months until I became disabled with my illness.  I was working
here on a Beowulf cluster (Linux, redhat 6.2), I was the only one there
responsible for administration (web, cvs, that kind of thing), and
programming (developed several simulation apps, using GTK, C, TCP/IP
sockets, etc.).

Short career history, but I'm young.

Now, thanks to my illness, I'm not working.. So I've got free time. 
Pardon me if my viewpoint differs form other religious linux zealots on
the list, or some of the holier than thou kernel developers.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Hans Sgier]

On Fri, 10 Jan 2003, Rob Wilkens wrote:
> No, simply a person who has worked in all areas of computing
> technology..
>
> Resume in brief:

Now, would J.R.R.Tolkien have ever considered to get the resume of a
troll written down?

Is there any chance that ridiculous thread is coming to an end?

Greets

Hans

Re: Nvidia and its choice to read the GPL "differently"

[yodaiken]

On Fri, Jan 10, 2003 at 09:58:45PM -0500, Rob Wilkens wrote:
> On Fri, 2003-01-10 at 21:54, Larry McVoy wrote:
> > Indeed.  Lots of things which are hard look easy to people who haven't 
> > done them.  Operating systems don't have a corner on that market.
> 
> Of all the things that computer software programmers do, writing
> operating systems is among the most simplistic of those tasks.
> 
> Of that, I am certain.
> 

That is so damn true. Larry, for example, was unemployed and
without job prospects when he read my book, "The one minute OS
developer". He immediately got a job at Sun designing operating
systems including kernels and the more important stuff, like
"fortune".  Nearly anyone can pick this up. Val Henson's mom even 
learned to write operating systems when she found knitting 
and the Black-Scholes theorem too challenging. 
Once you have the 
difference between tabs and spaces down, the rest is a joke.


-- 
---------------------------------------------------------
Victor Yodaiken : certainly not speaking for anyone, even myself.

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 22:48, Hans Sgier wrote:
> On Fri, 10 Jan 2003, Rob Wilkens wrote:
> > No, simply a person who has worked in all areas of computing
> > technology..
> >
> > Resume in brief:
> 
> Now, would J.R.R.Tolkien have ever considered to get the resume of a
> troll written down?

Probably, I have Lord of the rings sitting atop my monitor (and no, I
don't own many books, and I haven't read this one) and it seems pretty
thick.  There are probably many unimportant details in the book (much
like the resume would be an unimportant detail of such a troll as
myself), judging from the horrible movies that I've seen so far, both
movies were basically filled with long drawn out battle scenes when the
simple story line is that "everyone wants the ring that makes them
invisible, but it's a bad ring because it makes you do bad things".

> Is there any chance that ridiculous thread is coming to an end?

I received a private e-mail saying that not even RMS considers the
kernel to be gnu.  I would've argued that it containing the GPL was
enough for it to be considered Gnu, but then, I guess it's not really. 
I don't know enough, so I'm dropping it.

> Greets

Best wishes... And I understand if more than half the list has plonked
me silently by now.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 22:52, yodaiken@fsmlabs.com wrote:
> "fortune".  Nearly anyone can pick this up. Val Henson's mom even 

Writing fortune is probably far more complicated than writing the
kernel.  By that, of course, I mean writing the individual fortunes
which fortune spits out

It's also more useful.  The kernel, by itself, does nothing.  It's like
saying "the cpu is the most important part of the computer".  Yeah, but
without the a bios, what can you do with it?  (Actually, a lot, if you
can bootstrap the OS by other means, but you need hardware engineers to
help you with that, and I've done it.)  

An OS is just another layer in the onion..  What's nice is that in an
ideal world, that software follows standards..  Linux is still trying to
find it's way in that respect it seems (for example, today I found that
my 2.4 oss sound driver no longer works just right in the 2.5 kernel nor
is it likely to be supported in the future since some SuSE specific
sound system is replacing it -- I guess SuSE gave Torvalds some stock
options or similar.)  Also, the once perfectly functioning nvidia kernel
driver (the subject of this message) no longer works in newer kernels --
whereas if there were a standard interface for such things, nvidia could
freely keep their source closed while providing a driver that would
solve people's problems.

At least windows a few years back standardized on the wdm (windows
driver model) whereby there was a standard interface for what a driver
looked like and what it's interface to the kernel was (whether the
platform was the dos-based windows 9x or NT-based Windows 2000/XP). 
This is not to say that I'm "trolling" by extolling the virtues of
windows over linux..  I'm just pointing out what I know in this area.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Brian Tinsley]

Rob Wilkens wrote:

>The reality of the world is that those languages (well, I can only
>really speak for delphi, which is also available for linux), let you
>build on other people's code (or other code you've written) and actually
>do something useful without reinventing the wheel every time you want to
>accomplish something.
>
Now I've really grown tired of that line over the course of my career. 
It's not a matter of what language you are using, it's all about good 
design and reuse. I've got plenty of C libraries and C++ classes (and 
now some Java classes) I wrote way back in the Ice Age that, in some 
form or another, myself and a lot of others still use today.

The true "reality" of those languages is that they are designed for so 
called "developers" that cannot possibly comprehend the operations and 
information that the language hides from them!

OK, so I'm partially joking in that last statement :)  Remember the old 
acronym "RAD"? I will certainly give credit to tools like Delphi in that 
respect (Visual Basic, however, makes me sick - Basic should have died 
with the Commodore 64 and TRS80).

Re: Nvidia and its choice to read the GPL "differently"

[J Sloan]

No offense,  but if you're not here to discuss
kernel development issues, you are off-topic,
and ought to find a more suitable forum for
your messages -

Best Regards,

Joe

Rob Wilkens wrote:

>On Fri, 2003-01-10 at 22:16, John Adams wrote:
>  
>
>>On Friday 10 January 2003 09:58 pm, Rob Wilkens wrote:
>>    
>>
>>>Of all the things that computer software programmers do, writing
>>>operating systems is among the most simplistic of those tasks.
>>>      
>>>
>>I think we have an under-bridge dweller.
>>    
>>
>
>No, simply a person who has worked in all areas of computing
>technology..
>
>Resume in brief:
>
>B.S. in Computer Science may 1996, Clemson University
>
>May 1996-April 1998 - Senior Engineer (Operating Systems - Real Time
>Division) - Concurrent Computer Coporation. -- Original Title was Lead
>Software Engineer -- in my short timespan there, I received a 25% raise
>and a new title, and that still wasn't enough to keep me there.
>
>April 1998-Present - Software Developer (Contract work, can't discuss,
>but it's in Delphi, I'm happy to report that one reason I'm moving to
>Linux more is that Borland is doing a better job with Kylix, it's Linux
>version of Delphi).
>
>June 1998-May 2001 - LAN Administrator - New York State Courts .. 
>
>May 2001-June/July 2001 - Senior Enigneer - Geo-Centers.  I only worked
>for two months until I became disabled with my illness.  I was working
>here on a Beowulf cluster (Linux, redhat 6.2), I was the only one there
>responsible for administration (web, cvs, that kind of thing), and
>programming (developed several simulation apps, using GTK, C, TCP/IP
>sockets, etc.).
>
>Short career history, but I'm young.
>
>Now, thanks to my illness, I'm not working.. So I've got free time. 
>Pardon me if my viewpoint differs form other religious linux zealots on
>the list, or some of the holier than thou kernel developers.
>
>-Rob
>
>-
>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: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Fri, 2003-01-10 at 23:41, J Sloan wrote:
> No offense,  but if you're not here to discuss
> kernel development issues, you are off-topic,
> and ought to find a more suitable forum for
> your messages -
> 
> Best Regards,
> 
> Joe



No offense, but you need to learn to quote relevantly, and snip where
appropriate.  

Also, the FAQ to the LKML specifically says to write your message below
the text of what you quote.

Anyway, I'm here to discuss the kernel.  The issue at hand was whether
the kernel should be renamed.  I didn't bring up the topic, I was only
chiming in with an opinion.  As the topic went on, things got further
off-topic as can happen.

"renaming of a kernel" is a topic relevant to a kernel mailing list.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Andre Hedrick]

Gee, can all of us who have a business add there name to the thread
subject?  Look at all the advertising Nvidia is getting for free.
All they have to do is make a half step to the direction of more open
sourced, and they become the darling winner take all.

I positive Larry would love to have his product added.
Victor could enjoy the extra name caching in hits for it all.
Last time I checked I was bang 100K+ growth in website hit logs per day.

For all of the rants Nvidia Marketing must be in hog heaven!

Cheers,

Andre Hedrick
LAD Storage Consulting Group

OT: Renaming the kernel??!?!?!? (Was Re: Nvidia and its choice to read the GPL "differently")

[Brian Davids]

Rob Wilkens wrote:

> Anyway, I'm here to discuss the kernel.  The issue at hand was
> whether the kernel should be renamed.  I didn't bring up the topic, I
> was only chiming in with an opinion.  As the topic went on, things
> got further off-topic as can happen.
> 
> "renaming of a kernel" is a topic relevant to a kernel mailing list.

Maybe you should read the e-mails a bit more carefully.  The issue
you're refering to is NOT renaming the kernel, but rather what people
believe the collection of kernel, libraries, and user-land tools should
properly be called.  I don't think I've ever seen RMS (or anyone else
for that matter) say that the kernel itself should be called anything
other than Linux.  The controversy is what peoples' ideas of what
constitutes the operating system are and what to call it.


Brian Davids

Re: Nvidia and its choice to read the GPL "differently"

[Martin J. Bligh]

> I'm just pointing out what I know in this area.

I think you've very ably described exactly what you know in this area.

M.

Re: Nvidia and its choice to read the GPL "differently"

[Tomas Szepe]

> [robw@optonline.net]
> 
> High-level languages (stuff like delphi and visual basic) are grown-up
> languages and tools where you can create more substantial programs using
> more substantial areas of your brain.

Alan, would you happen to know of a graduate of the Al Viro school of Direct
Method in Diplomacy and Polite Conversation who would be available to comment
on today's valuable posts by Mr. Wilkens?

T.

Re: Nvidia and its choice to read the GPL "differently"

[Ryan Anderson]

On Fri, Jan 10, 2003 at 06:54:49PM -0800, Larry McVoy wrote:
> On Sat, Jan 11, 2003 at 03:26:12AM +0000, Alan Cox wrote:
> > Its not ham you need its utter arrogance and a complete lack of understanding
> > that writing an OS is a seriously hard problem. There is a whole world of
> > mysticism around the concept of a 'beginners mind' although to me
> > "Im sorry nobody told me it was impossible" sums it up far better.
> 
> Indeed.  Lots of things which are hard look easy to people who haven't 
> done them.  Operating systems don't have a corner on that market.

For a slightly off-topic example for those interested - Turbine Games
(www.turbinegames.com) has talked about this a bit in their history, if
I'm remembering correctly - literally, they just didn't know that the
game they were building "couldn't be done", so they did it.

-- 

Ryan Anderson
  sometimes Pug Majere

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Sat, 2003-01-11 at 01:01, Tomas Szepe wrote:
> Alan, would you happen to know of a graduate of the Al Viro school of Direct
> Method in Diplomacy and Polite Conversation who would be available to comment
> on today's valuable posts by Mr. Wilkens?

Please, There's no reason to be diplomatic and polite with me.. If you
haven't notice, I've been neither diplomatic nor polite in my comments
or statement of opinions.

Some people don't like them.  heh, that's their right.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Tom Sightler]

> Anyway, I'm here to discuss the kernel.  The issue at hand was whether
> the kernel should be renamed.  I didn't bring up the topic, I was only
> chiming in with an opinion.  As the topic went on, things got further
> off-topic as can happen.
>
> "renaming of a kernel" is a topic relevant to a kernel mailing list.

Are you sure?  Based on reading the GNU page the stance seems to be that the
"OS" should be called GNU/Linux.  I don't see anything that says the kernel
should be renamed, only that when referring to the system as a whole it
would be better to be called GNU/Linux.  That's what makes this discussion
offtopic, it's not the kernel's name that GNU is complaining about and this
is the kernel list.

Later,
Tom

Re: Nvidia and its choice to read the GPL "differently"

[Andre Hedrick]

Well let's add one more to the Advertising Minute for Nvidia.

For someone who published their resume on this thread, and then was asked
nicely to stop the thread, and can not or will not, I am sure your future
employer should take notice.

Individual requires a large Clue Bat to grasp various issues and requests.

Cheers,


On Sat, 11 Jan 2003, Rob Wilkens wrote:

> On Sat, 2003-01-11 at 01:01, Tomas Szepe wrote:
> > Alan, would you happen to know of a graduate of the Al Viro school of Direct
> > Method in Diplomacy and Polite Conversation who would be available to comment
> > on today's valuable posts by Mr. Wilkens?
> 
> Please, There's no reason to be diplomatic and polite with me.. If you
> haven't notice, I've been neither diplomatic nor polite in my comments
> or statement of opinions.
> 
> Some people don't like them.  heh, that's their right.
> 
> -Rob
> 
> -
> 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/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: Nvidia and its choice to read the GPL "differently"

[Mark Mielke]

On Fri, Jan 10, 2003 at 10:20:09PM -0500, Tom Sightler wrote:
> > He just got lucky on his timing... Anyone studying operating systems at
> > the time (and heck, I remember owning a book "Creating your own 32-bit
> > operating system" by SAMS publishing and being inspired, and I also
> > owned "Disecting DOS" which was a nice analysis of a DOS-like operating
> > system at the code-level book w/disk)
> You could also argue that GNU got lucky on it's timing, otherwise we might
> still be waiting on a "GNU OS" rather than arguing over how important it is
> to put GNU in front of Linux.

As far as I am concerned, we still *are* waiting for a "GNU OS", or rather
*THE* "GNU OS" that Richard Stallman keeps talking about as having been
almost complete in 1992, but even in 2003, is not ready to be rolled out.

This very truth - the fact that Richard Stallman's people have taken
more than 10 years, and they still are not done, suggests that the
existence of an OS such as Linux is not an 'accident' related to
certain skillsets colliding at a random interval, such as the original
poster wishes to suggest.

*Microsoft*... now *that* is a 'certain skillsets colliding at random
interval' scenario... :-)

Oops... I think I just extended this thread. Damn.

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Sat, 2003-01-11 at 14:41, Andre Hedrick wrote:
> Well let's add one more to the Advertising Minute for Nvidia.
> 
> For someone who published their resume on this thread, and then was asked
> nicely to stop the thread, and can not or will not, I am sure your future
> employer should take notice.
> 
> Individual requires a large Clue Bat to grasp various issues and requests.
> 
> Cheers,

I also published on this thread that I was mentally ill, which I'm sure
employers will look equally kindly on :-).  I am unemployed, so if I was
actually hoping to be hired that's not the kind of thing I would post
here.

Geesh.  You're, by the way, yet another poster who didn't read the
mailing list FAQ which says to write your message below the quoted
text.  You really should read it before you use the mailing list.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Kurt Garloff]

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

Hi Rob,

On Fri, Jan 10, 2003 at 09:38:38PM -0500, Rob Wilkens wrote:
> I'm not interested in getting into a pissing contest with linux
> torvalds, even he claims he doesn't have leadership skills (read his
> biography), and I'm not claiming to either.  His programming skills are
> questionable, because if they were so good then I shouldn't be seeing
> hundreds of [PATCH] messages coming through every day.

You're new to Linux, aren't you?
Or terribly presumptous.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations    <K.Garloff@TUE.NL>     [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

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

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Sat, 2003-01-11 at 16:44, Kurt Garloff wrote:
> You're new to Linux, aren't you?
> Or terribly presumptous.

A little of both, but not too much of either.

I'd say "New to linux" but I've been using it on and off since 1995 or
earlier.

I'd say terribly presumptuous, but I don't think it is presumptuous to
say that if there are many patches (bug fixes, mostly) coming in that
the code that was originally there was of questionable quality.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Chief Gadgeteer]

On Sat, 2003-01-11 at 14:53, Rob Wilkens wrote:
> I'd say terribly presumptuous, but I don't think it is presumptuous to
> say that if there are many patches (bug fixes, mostly) coming in that
> the code that was originally there was of questionable quality.

OK, then you do not know shit about software engineering within the FOSS
development paradigm.

-- 
Chief Gadgeteer
Elegant Innovations

Re: Nvidia and its choice to read the GPL "differently"

[Kurt Garloff]

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

Hi Rob,

You seem to serious ...

On Sat, Jan 11, 2003 at 04:53:33PM -0500, Rob Wilkens wrote:
> I'd say terribly presumptuous, but I don't think it is presumptuous to
> say that if there are many patches (bug fixes, mostly) coming in that
> the code that was originally there was of questionable quality.

It is presumptuous. Very much so.

1. A patch does not necessarily indicate something is wrong with the
   original code. It may only show that people have ideas on how to
   do things better, more efficiently, more nicely or to support
   new features or hardware.
2. If a patch fixes a bug, you should be aware that the complexity
   of an operating system is slightly higher than you think.
   We're talking about a general purpose operating system that works
   in real life and solves problems there. Not a toy system or a
   specialized one.
3. The amount of supported subsystems and hardware of the Linux kernel
   is enormous. The hardware you deal with very often already is complex
   and/or buggy. And needs things you never even thought about when
   doing userspace programs before. Like protection from concurrent 
   accesses to hardware.
4. In kernel land, you have less tools available than a normal programmer
   has. Things you assume just to be there and to work in userland programs
   are unavailable and have to be done by yourself. Like I/O. Memory
   allocation and management. 
5. The impact of a bug in kernel is much higher than in a normal program.

It is naïve to believe that the fact that many bugs are found indicates 
poor quality of a code. 

Just compare the stability of Linux to other operating systems. Take 
the toy OSes that most desktop users prefer or the somewhat better
alternatives offered for professional customers by the same company
on the one side. Take commercial Un*ces on the other.
And then consider the amount of things that Linux does have support for 
in kernel. For example the IPv4 stack or netfilter. And take into account
the amount of hardware Linux supports. Think about performance as well.
Think about conforming to specifications, like POSIX.

It's amazing. And most people would not have believed that this can work,
certainly not outside of a very tightly controlled process in a company.
It does. 
And this is the merit of many enthusiasts and last not least Linus.

Questioning the skills of the people involved is ridicolous at best.
You also think that those people doing research on operating systems
in CS departments are just doing simplistic stuff?

Go and start to work on a free software project of comparable size.
If you think you can do it, create Robix. If your enthusiast enough,
and technically good enough, you will find people who find it exciting
and will help you.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations    <K.Garloff@TUE.NL>     [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

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

Re: Nvidia and its choice to read the GPL "differently"

[Vojtech Pavlik]

On Sat, Jan 11, 2003 at 04:53:33PM -0500, Rob Wilkens wrote:
> On Sat, 2003-01-11 at 16:44, Kurt Garloff wrote:
> > You're new to Linux, aren't you?
> > Or terribly presumptous.
> 
> A little of both, but not too much of either.
> 
> I'd say "New to linux" but I've been using it on and off since 1995 or
> earlier.
> 
> I'd say terribly presumptuous, but I don't think it is presumptuous to
> say that if there are many patches (bug fixes, mostly) coming in that
> the code that was originally there was of questionable quality.

Very interesting idea. But not correct.

The reason is code rot(*). You have never to stop maintaining and patching
and fixing the code to keep it working. A perfectly good and clean code,
if you don't touch it, becomes crusty and smelly over time(**). This is why
the number of patches daily entering the kernel is actually a sign of good
overall code quality. ;)

(*)
	http://www.tuxedo.org/~esr/jargon/html/entry/software-rot.html
	http://www.tuxedo.org/~esr/jargon/html/entry/bit-rot.html

(**)
	One of the reasons for this is that the hardware changes over
	time. Another is that the requirements of what it is expected to
	do change over time. And yet another is that due to the above
	changes the rest of the code gets updated and the parts that
	were not touched do not interoperate properly any more.

Huh. And now I'll be getting all the e-mails following in this thread.

-- 
Vojtech Pavlik
SuSE Labs

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Sat, 2003-01-11 at 17:36, Vojtech Pavlik wrote:
> > I'd say terribly presumptuous, but I don't think it is presumptuous to
> > say that if there are many patches (bug fixes, mostly) coming in that
> > the code that was originally there was of questionable quality.
> 
> Very interesting idea. But not correct.
> 
> The reason is code rot(*). 

Which by definition you gave on the tuxedo.org site is a lack of
robustness in the original code.  Again, pointing to the fact that the
original code was not well designed, and hence the term "kernel hacking"
being more relevant than "software engineering" when it comes to linux.

Of course, that is what makes it fun.. 

> You have never to stop maintaining and patching
> and fixing the code to keep it working. 

That's a software developers dream: Never to become obsolete.  

One problem I remember UNIX having, and I don't know if this has been
addressed yet, was that UNIX systems that I used to work on had a
forthcoming "Year 2036 or Year 2037" (thereabouts) bug coming whereby
they had no method of representing years beyond that year because dates
were stored as the number of [seconds|minutes|days] since a certain
date.  I'm curious if Linux has this same kind of problem, and if we'll
be seeing a rush of "Year 2037 bug fixers" the way we saw year 2000 bug
fixers in 2000 years.

I mention the above to stay relevant to the linux-kernel mailing list,
though forgive me if this is a non-kernel (i.e. library) issue.  The
line between kernel and library is always blurry from a programmer's
perspective.

> A perfectly good and clean code,
> if you don't touch it, becomes crusty and smelly over time(**). 

Per your comment, re: hardware changing over time, why can't linux just
come up with a nice binary plug-in driver architecture (ok, it has
kernel modules, but from one compile of a kernel to another, the modules
aren't portable).  If there were a module plug-in architecture, the
kernel code wouldn't have to change much to support new hardware.

A little "design time" up front (in other words) would save a lot of
coding time later...

Also -- Why hasn't there been a move to something like CVS for the
kernel -- perhaps with linus being the cvs 'god' or whatever the person
who authorizes changes to the code is called.  This way you get to
always have the latest code, and check the changes back in without using
an ancient mail text-based interface, and you can describe your changes
(which get forever stored with the change), and changes can always be
backed out.  Remember, I'm a newbie, so point me to the FAQ if this is
there.

> This is why
> the number of patches daily entering the kernel is actually a sign of good
> overall code quality. ;)

Oh, I should've known there was a smiley coming <smirk>

-Rob
[Pushing the NVIDIA thread further because I have one of these damned
cards and want support for it in the 2.5+ kernels.]

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Sat, 2003-01-11 at 17:26, Kurt Garloff wrote:
> It is presumptuous. Very much so.

I'll accept that on face value, and take your comments five comments as
good pieces of information which I'll comment only briefly on.

> 1. A patch does not necessarily indicate something is wrong with the
>    original code. It may only show that people have ideas on how to
>    do things better, more efficiently, more nicely or to support
>    new features or hardware.

"Idea on how to do things better" implies "well, gee, it wasn't done so
great to begin with" :-) which was kinda my point.  

By the way, if I sounded too serious, i'm having fun, otherwise I
wouldn't be wasting my time here.

> 2. If a patch fixes a bug, you should be aware that the complexity
>    of an operating system is slightly higher than you think.
>    We're talking about a general purpose operating system that works
>    in real life and solves problems there. Not a toy system or a
>    specialized one.

The complexity may be somewhat less than you think.  If you break the OS
down into components, then take a look at any one of those compnents,
you can look at, study, and understand, and probably explain exactly
what any one of those components do at the code level (possibly even if
they are drivers for devices you are unfamiliar with).  Build up your
understanding of all of those little components, then you realize that
it's not as complex as you think.  The whole is just the sum of its
parts, and the parts are not that complex.

> 3. The amount of supported subsystems and hardware of the Linux kernel
>    is enormous. The hardware you deal with very often already is complex
>    and/or buggy. And needs things you never even thought about when
>    doing userspace programs before. Like protection from concurrent 
>    accesses to hardware.

I've thought about concurrent access to hardware from multiple
processors, and didn't like it -- but that's where "Simple" (not
complex) concepts like spinlocks come in (call 'em mutexes or semaphores
or whatever your buzzword of choice is).  You wait for the resource to
become available then you access it.

As per buggy hardware, the software should _not_ have to support it. 
The software should report that the hardware has a bug and stop. 
Otherwise, you wind up writing really bad code for other hardware at the
same time that you're trying to work with one particular piece of bad
hardware.

> 4. In kernel land, you have less tools available than a normal programmer
>    has. Things you assume just to be there and to work in userland programs
>    are unavailable and have to be done by yourself. Like I/O. Memory
>    allocation and management. 

You have the same tools, but they have different names.  For example,
instead of "printf" you have "printk", sure it's implemented in the
kernel itself, but it's there.  As per memory management, if you wanted
the kernel to do it for you, why the hell would you need to write a
kernel.

> 5. The impact of a bug in kernel is much higher than in a normal program.

Yeah, kernel processes have access to all memory, while user programs
run in protected mode.  Among other things.  With responsibility comes
power they say, or was it the other way around :-)

> It is naïve to believe that the fact that many bugs are found indicates 
> poor quality of a code. 

It is equally naive to discard the possibility.  On the other hand, we
don't see the list of bugs that are fixed on a daily basis internally at
companies like microsoft.  

> Just compare the stability of Linux to other operating systems. 

There aren't any comparable systems for stability.

> Go and start to work on a free software project of comparable size.
> If you think you can do it, create Robix. If your enthusiast enough,
> and technically good enough, you will find people who find it exciting
> and will help you.

The enthusiastic enough part will be the tough part...  Why do something
which is already done?  If I can do it better, who am I trying to do it
for and why?  As they say "Code it first, then talk", well, I'm not
coding at this stage, so I guess I have no right to talk then.

-Rob

The GPL, the kernel, and everything else.

[Ryan Anderson]

(subject changed to make Andre happy. :)

I'm also certain replying is a bad idea... *sigh* but anyway...

On Sat, Jan 11, 2003 at 05:57:50PM -0500, Rob Wilkens wrote:
> On Sat, 2003-01-11 at 17:36, Vojtech Pavlik wrote:
> 
> Per your comment, re: hardware changing over time, why can't linux just
> come up with a nice binary plug-in driver architecture (ok, it has
> kernel modules, but from one compile of a kernel to another, the modules
> aren't portable).  If there were a module plug-in architecture, the
> kernel code wouldn't have to change much to support new hardware.

Because, to a large extent, for the core kernel developers, the existing
system is fine.

Nobody wants to design an API/ABI that is big, covers all possible
cases, and is excessively complex.  The API that modules ( and drivers )
use is designed to solve the current problem space.  When a new feature,
driver or problem needs to be added or fixed, the problem space has
changed, and the interface changes a little bit in turn.  Usually (not
always), the person that changed the interface cycles through the
drivers that are in the tree, and fixes them up.  (The cases where this
doesn't happen are, I believe, generally ones where two different but
related interfaces coexist for a long period of time, and as the older
interface is phased out, there is a semi-painful transition period.)

> A little "design time" up front (in other words) would save a lot of
> coding time later...

What makes you think that design doesn't occur?  Read through the OLS
papers to understand just how many talented people *are* doing design.
The difference may be that, on this list, you see a active work in
progress.  ("Stream of consciousness" might not be a bad analogy)

> Also -- Why hasn't there been a move to something like CVS for the
> kernel -- perhaps with linus being the cvs 'god' or whatever the person
> who authorizes changes to the code is called.  This way you get to
> always have the latest code, and check the changes back in without using
> an ancient mail text-based interface, and you can describe your changes
> (which get forever stored with the change), and changes can always be
> backed out.  Remember, I'm a newbie, so point me to the FAQ if this is
> there.

There is, but it's not CVS.  CVS has... issues when you get into complex
project structures (not so much the complexity of the code - but how the
projects are managed).  CVS wouldn't permit the decentralized nature of
development on other archictures in quite the same manner as the tool
Linus *has* chosen to use - BitKeeper.  (And no - that's not meant to be
an advertisement for BK so much as an acknowledgement that CVS collapses
under branching nightmares.)

Now, this thread should be well and truly dead soon, with any luck.  I
know I'm going to try to resist perpetuating it.


-- 

Ryan Anderson
  sometimes Pug Majere

[OT] Noise on lkml (was Re: Nvidia and its choice to read the GPL "differently")

[J Sloan]

Rob Wilkens wrote:

>I'd say terribly presumptuous, but I don't think it is presumptuous to
>say that if there are many patches (bug fixes, mostly) coming in that
>the code that was originally there was of questionable quality.
>

Your statements are at once so arrogant, yet
so ignorant, it's hard to know where to even
begin - but you are quite mistaken on several
fronts; each new message from you reveals an
unbridgeable gulf, of which you do not even
seem aware.

I won't even begin to put together a point by
point correction, it's all too tedious, and it's
possible that you are here just to annoy and
wear down the developers anyway -

Please start sending in patches or discussing
kernel code, or even doing testing - if not, you
might wish to seek out a different forum for
your messages, where you might find a more
receptive audience - I'll refrain from making
specific suggestions at this time.

Best Regards,

Joe

Re: [OT] Noise on lkml (was Re: Nvidia and its choice to read the GPL "differently")

[Rob Wilkens]

On Sat, 2003-01-11 at 20:44, J Sloan wrote:
> I won't even begin to put together a point by
> point correction, it's all too tedious, and it's
> possible that you are here just to annoy and
> wear down the developers anyway -

I've only written a total of maybe 5-6 messages to the list, and maybe 4
of them were off topic because of a previous off-topic message by
somebody else (such as yours).  I don't see how "i" am specifically
designed to wear down developers, though I'll apologize for any comments
I made earlier about the simplicity of kernel development:  I should
comment that it was kernel development I was doing (professionally) when
I had my first two mental breakdowns, so it should be no surprise to
discover that despite the fact that superficially it seemed like easy
work at the time, it can be a stress inducing kind of work which is
somewhat tedious in nature (trying to get various hardware to work just
right, or reversing bit/byte orders for various platforms or that sort
of thing).  

> Please start sending in patches or discussing
> kernel code, or even doing testing - if not, you
> might wish to seek out a different forum for
> your messages, where you might find a more
> receptive audience - I'll refrain from making
> specific suggestions at this time.

I fixed a bug in my kernel (2.4.20), and here's the unified diff with
the hack I put in place, it's not a fix because I don't know enough
about the floppy driver to fix it the right way--- it's called a hack. 
I'm sure if I looked at the problem longer I could fix it right, but it
looks like in 2.5.56 the floppy driver has been rewritten somewhat, but
the problem, I believe, is still there and reproducable (code to
reproduce it is below).

<---Begin--->

--- floppy.c.orig	2003-01-07 21:51:49.000000000 -0500
+++ floppy.c	2003-01-10 15:54:56.000000000 -0500
@@ -3874,7 +3874,7 @@
 		UCLEARF(FD_DISK_CHANGED);
 		if (cf)
 			UDRS->generation++;
-		if (NO_GEOM){
+		if (/*NO_GEOM*/1){
 			/* auto-sensing */
 			int size = floppy_blocksizes[MINOR(dev)];
 			if (!size)


<---End--->

Please note that the above error fixes the following test case.  IF you
have no floppy in the A: drive and run the following test.c code
repeatedly you will find you get different results every time you run
it.  I left the commented sections in the code to illustrate that it
only happens with fd0u1440 as opposed to fd0.

<---Begin--->
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>

#define O_LARGEFILE	0100000

 main()
{	
	int fd,bits;

/*	fd=open("/dev/fd0",O_WRONLY|O_CREAT|O_TRUNC);*/

	/*fd=open("/dev/fd0",O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE);*/
	fd=open("/dev/fd0u1440",O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE);
	
	printf ("fd=%d\n",fd);
	perror("error was: ");
}
<---End--->

Note that O_LARGEFILE isn't meaningful, it was put there because I was
imitating a system call that I saw the "dd" command making when doing an
"strace" (System Call Trace) do when it was failing.

This is a silly and trivial bug, but someone reported it.  Until I get
some acknowledgement of any kind on my first kernel patch submittal, it
seems silly to submit more, even if the acknowledgement is someone
telling me "try to fix it the right way so it doesn't break anything
else" which may involve adding a few more lines of code.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Mark Mielke]

On Sat, Jan 11, 2003 at 06:23:23PM -0500, Rob Wilkens wrote:
> On Sat, 2003-01-11 at 17:26, Kurt Garloff wrote:
> > It is presumptuous. Very much so.
> I'll accept that on face value, and take your comments five comments as
> good pieces of information which I'll comment only briefly on.

Also take into account that your claim to faim -- vxWorks, a real time
commercial operating system, may not of the same calibre as Linux.

Why do I doubt the calibre of vxWorks? People I trust who work on RT systems
have told me that in many cases, products with RT requirements can perform
better on Linux, than on vxWorks. (Better meaning managing a higher capacity
without significant side effects)

For your suggestion that writing an operating system is not hard -- I
agree with your chosen qualification of 'a'. Most anybody who passes
1st year in CS at university can complete 'a' DOS-like operating
system.

Not just anybody could take this operating system to the next step in
less than a year. I consider Linux several steps above DOS.

Also, FYI, most of the patches that I see coming through here are patches
to *other* people's code, usually code that has not existed more than a
few months. Which doesn't mean that Linus' code is flawless.

Just -- evolution has a price. Sometimes bad, inefficient, or last generation
code must be heavily maintained, or thrown completely out, to be replaced
by code that itself may contain bugs. Since this is "Linux-devel", and not
"Linux-stable", I don't see how you could expect anything else. How many
patches do you see for Linux-2.0.x, or Linux-2.2.x? You'll note that the
majority are for Linux-2.5.x and then Linux-2.4.x. Do the math. Figure it
out.

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Sat, 2003-01-11 at 22:33, Mark Mielke wrote:
> On Sat, Jan 11, 2003 at 06:23:23PM -0500, Rob Wilkens wrote:
> > On Sat, 2003-01-11 at 17:26, Kurt Garloff wrote:
> > > It is presumptuous. Very much so.
> > I'll accept that on face value, and take your comments five comments as
> > good pieces of information which I'll comment only briefly on.
> 
> Also take into account that your claim to faim -- vxWorks, a real time
> commercial operating system, may not of the same calibre as Linux.

I never mentioned VxWorks (This is bad, someone is actually keeping
track and researching my background).  But that was a product at a
company I used to work for.. Joe Korty (whom I saw just submitted a
patch from a machine I used to have an account on) who works for that
company can probably tell you more about VxWorks than I can.  Hopefully
he doesn't remember me.

VxWorks, or PowerMAX or PowerUX or whatever they're calling it now
(names changed several times while I worked there) was basically AT&T
SVR4, with some custom enhancements.

> Why do I doubt the calibre of vxWorks? People I trust who work on RT systems

The company probably went downhill after I left in 1998 :-).  I was
releasing (personally) at least 7-10 modifications to the kernel a week
on average.  Joe Korty was probably the only other developer there who
was almost as productive at the time.  The rest of their team were a
bunch of very knowledgeable yet "comfortable" people who looked like
they were basically happy to rest on their laurels (they had fast
performing hardware, and they had exclusive knowledge of the software,
so they didn't "have" to work harder).  There were of course several
contractors there who were productive, but anyone working on a contract
is going to be more productive than a salaried person for the sole
reason that they _have_ to prove their worth.

Yep, If there is anyone reading this list whom I ever hoped to use as a
personal reference in the future, I probably just ruled that out :-).  I
figure as long as the career is in the toilet, might as well flush.

> For your suggestion that writing an operating system is not hard -- I
> agree with your chosen qualification of 'a'. Most anybody who passes
> 1st year in CS at university can complete 'a' DOS-like operating
> system.

Thank You, that was my only point.  Of course, I would say 3rd or 4th
year -- at least in a U.S. university.  As per whether "anybody" could
take it to the next level, that is just an elitist viewpoint you have
which you are free to keep.  When you think of what is involved in, for
example, memory management, it's not all that complicated.  I downloaded
the document that Mel Gorman wrote (a thesis, it claims) and while it's
nice, so far I've read the first 14 pages of the text and haven't even
seen anything about the VMM -- it's all been about what a tar is, how
big the kernel has grown, why CVS isn't used (which is interesting to
read), but nothing yet about the virtual memory manager which is what I
picked up the document for.  I guess for free one can't complain.

> Also, FYI, most of the patches that I see coming through here are patches
> to *other* people's code, usually code that has not existed more than a
> few months. Which doesn't mean that Linus' code is flawless.

Can you explain, then, why I submitted a patch to the floppy driver
minutes ago :-).  You would think that's the kind of thing they would've
gotten working long ago.  Of course, I don't know enough to get a floppy
drive working at all, so I'm duly impressed with that basic ability.

> Just -- evolution has a price. 

Actually, you can download it free at www.ximian.com .. They may sell it
to you on CD for a price, though.  It's what I'm using to write this
e-mail.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Valdis.Kletnieks]

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

On Sat, 11 Jan 2003 18:23:23 EST, Rob Wilkens said:

> As per buggy hardware, the software should _not_ have to support it. 
> The software should report that the hardware has a bug and stop. 
> Otherwise, you wind up writing really bad code for other hardware at the
> same time that you're trying to work with one particular piece of bad
> hardware.

Er? Rob? You got a prescription for them pharmaceuticals?



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

Re: Nvidia and its choice to read the GPL "differently"

[Rob Wilkens]

On Sat, 2003-01-11 at 23:00, Valdis.Kletnieks@vt.edu wrote:
> On Sat, 11 Jan 2003 18:23:23 EST, Rob Wilkens said:
> 
> > As per buggy hardware, the software should _not_ have to support it. 
> > The software should report that the hardware has a bug and stop. 
> > Otherwise, you wind up writing really bad code for other hardware at the
> > same time that you're trying to work with one particular piece of bad
> > hardware.
> 
> Er? Rob? You got a prescription for them pharmaceuticals?
> 

Sadly, I can't share my prescriptions... But they're on file at the
pharmacy:
	Zyprexa, for psychosis (calming effect, "major tranquilizer") 
	Topamax (mood stabilizer, and weight control)
	Neurontin (mood stabilizer)
	Klonopin (anti-anxiety, "minor tranquilizer")

Klonopin can be addictive (controlled substance), and has even been
reported in the news as a date rape drug because of how effective it
is.  

-Rob

Re: [OT] Noise on lkml (was Re: Nvidia and its choice to read the GPL "differently")

[Scott Murray]

On Sat, 11 Jan 2003, Rob Wilkens wrote:

> On Sat, 2003-01-11 at 20:44, J Sloan wrote:
> > I won't even begin to put together a point by
> > point correction, it's all too tedious, and it's
> > possible that you are here just to annoy and
> > wear down the developers anyway -
> 
> I've only written a total of maybe 5-6 messages to the list, and maybe 4
> of them were off topic because of a previous off-topic message by
> somebody else (such as yours).
[snip]

FYI, looking in my l-k folder, with the next message you sent, you have
posted 22 messages in the last 3 days, only 3 of which had subject lines
not related to the ongoing flamewar.

Scott


-- 
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: scottm@somanetworks.com

Re: The GPL, the kernel, and everything else.

[Rob Wilkens]

On Sat, 2003-01-11 at 20:06, Ryan Anderson wrote:
> Because, to a large extent, for the core kernel developers, the existing
> system is fine.

If you're designing a system for kernel developers use, then that's
fine.  But if you want to see linux proliferate to the average desktop
(and I do), then you've got to look at the bigger picture.  There
_should_ be a way for a company like nvidia to build a binary driver,
adn ship it in binary form, maybe even digitally signed the way
microsoft allows digital signing of drivers so you know the driver is
legit and OK.  

> progress.  ("Stream of consciousness" might not be a bad analogy)

It's actually a good analogy.  What mailing list (if not the kernel
mailing list) do I sign up for if I want to read about the design
aspects of the kernel.  I realize and understand if this is an exclusive
members-only list that doesn't allow the likes of me into its
membership.

> There is, but it's not CVS.  CVS has... issues when you get into complex

I just read about bitkeeper in the "Virtual Memory Manager" document
someone posted tonight (of all the places to learn about it)...

Anyway, I've put that document aside, but will probably get back to it
later.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[David Schwartz]

On Sat, 11 Jan 2003 22:33:25 -0500, Mark Mielke wrote:

>Why do I doubt the calibre of vxWorks? People I trust who work on RT
>systems
>have told me that in many cases, products with RT requirements can
>perform
>better on Linux, than on vxWorks. (Better meaning managing a higher
>capacity without significant side effects)

	This is an atrocious way to compare a real-time operating system to 
a non-real-time operating system. One would expect that real-time's 
benefits also come at a cost, otherwise all operating systems would 
be real-time operating systems.

	Perhaps Linux can handle more web clients than vxWorks, but can 
Linux guarantee that if the temperature in the core coolant exceeds 
350 degrees, the secondary pump circuit will be activated within 13 
milliseconds?

	A cheap hammer can drive in more nails than a top of the line 
screwdriver.

	DS

Re: The GPL, the kernel, and everything else.

[David Lang]

Rob, there are problems with your first statement here.

1. some developers are militant about not wanting to have binary drivers
(as is shown by this flamewar)

2. modules not only need to be called with the correct parameters, they
also need to do the proper locking. as locking evolves what needs to be
done by the module changes. This can only be solved by every module doing
locking 'just in casee' at which point the unessasary locking becomes a
significant performance issue (Larry McVoy has written a document about
why locking is bad and why excessive locking is very bad, search archives
for the link to his site)

3. you say that 'all that is needed' is to design an API that covers every
possible function a module needs. the problem is that if you try doing
this you end up with several results.

A. the API is very complex (since it does cover every possible
application)

B. the glue logic to translate the API to and from the internal kernel
implementations adds additional complexity (with probable errors) and robs
performance from the system (especially over time as the internel kernel
structures change)

C. the API includes a lot of things that are never used (remember it
covers everything you can think someone may possibly want to do, not just
the things that people actually do) unused code is a bad thing, it never
gets tested so bugs can live there for a LONG time, and it eats up memory
that the system should use for doing actual work.

4. since no designer (or group of designers) can think of everything your
API is going to be incomplete anyway. you can either pretend this isn't
the case and limit yourself to the things that you origionally imagined,
change your API (and now what do you do with things that used the
origional one, support two different versions of the API??? that's a
disaster for performance), or recognise up front that kernel modules are
very dependant on the exact implementation of the kernel internals at
which point it doesn't make sense to try and define a specific API, they
are just part of the kernel that's not always loaded (this is what Linux
has chosen to do)

as for signing kernel modules as being 'good' you have a serious problem
in the Linux world that there is no central authority to do any such
signing. the closest there is to that is when the module is made part of a
core source tree and then gets supported and maintained along with
everything else, but binary-only modules can't be done that way.

David Lang



 On Sat, 11 Jan 2003, Rob Wilkens wrote:

> Date: Sat, 11 Jan 2003 23:15:31 -0500
> From: Rob Wilkens <robw@optonline.net>
> To: Ryan Anderson <ryan@michonline.com>
> Cc: Linux kernel list <linux-kernel@vger.kernel.org>
> Subject: Re: The GPL, the kernel, and everything else.
>
> On Sat, 2003-01-11 at 20:06, Ryan Anderson wrote:
> > Because, to a large extent, for the core kernel developers, the existing
> > system is fine.
>
> If you're designing a system for kernel developers use, then that's
> fine.  But if you want to see linux proliferate to the average desktop
> (and I do), then you've got to look at the bigger picture.  There
> _should_ be a way for a company like nvidia to build a binary driver,
> adn ship it in binary form, maybe even digitally signed the way
> microsoft allows digital signing of drivers so you know the driver is
> legit and OK.
>
> > progress.  ("Stream of consciousness" might not be a bad analogy)
>
> It's actually a good analogy.  What mailing list (if not the kernel
> mailing list) do I sign up for if I want to read about the design
> aspects of the kernel.  I realize and understand if this is an exclusive
> members-only list that doesn't allow the likes of me into its
> membership.
>
> > There is, but it's not CVS.  CVS has... issues when you get into complex
>
> I just read about bitkeeper in the "Virtual Memory Manager" document
> someone posted tonight (of all the places to learn about it)...
>
> Anyway, I've put that document aside, but will probably get back to it
> later.
>
> -Rob
>
> -
> 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: The GPL, the kernel, and everything else.

[Rob Wilkens]

On Sat, 2003-01-11 at 23:21, David Lang wrote:
> 1. some developers are militant about not wanting to have binary drivers
> (as is shown by this flamewar)

Well, at least _this_ particular "flamewar" is relevant to the kernel
list.  Also, please read the lkml FAQ which specifically says to write
your message below any quoted text .. http://www.tux.org/lkml/#s3-9 --
See the part about RFC 1855...

Do these developers include the primary developer, Linus?  He's the one
ultimately responsible for the decision for the maintenance of the
kernel which almost everyone (ok, everyone) uses.  If he's militant
about it, then I guess it's pointless to argue about it.  I got the
feeling from reading his biography ("Just for fun" - that's the title)
that he's the type to let others duke it out and he lets them decide
without really caring which technology makes it into the kernel.

> 2. modules not only need to be called with the correct parameters, they
> also need to do the proper locking. as locking evolves what needs to be
> done by the module changes. This can only be solved by every module doing
> locking 'just in casee' at which point the unessasary locking becomes a
> significant performance issue (Larry McVoy has written a document about
> why locking is bad and why excessive locking is very bad, search archives
> for the link to his site)

I don't need to read an article to know why locking is bad.  However, if
we can broadly generalize drivers into categories (instead of just
"modules", for example, there could be a generic "video module"
structure and that could have a specific kind of locking that a video
driver would need, and the same would go for other specific types of
drivers).

> 3. you say that 'all that is needed' is to design an API that covers every
> possible function a module needs. the problem is that if you try doing
> this you end up with several results.
> 
> A. the API is very complex (since it does cover every possible
> application)

Start simple -- like I said above.. Split the "modules" into categorized
modules and implement one or two subtypes at a time.  For example, leave
the generic "modules" and add a "video module" as above and give it a
specific API which may be complex but less complex than imagined since
it targets a specific piece of functionality.  Other modules can be
devised by studying what drivers are already in the kernel.

I'll avoid replying to points B and C, but I read them..  In part, they
are addressed by the above.

> 4. since no designer (or group of designers) can think of everything your
> API is going to be incomplete anyway. you can either pretend this isn't
> the case and limit yourself to the things that you origionally imagined,
> change your API (and now what do you do with things that used the

Why is it that Windows doesn't seem to have a problem providing a
generic binary driver interface -- one that is portable accross
operating systems as mentioned before -- drivers which work on Windows
98 are binary compatible with Windows 2000 and Windows XP despite major
difference in the systems never mind minor kernel changes.

I'd suggest that a linux kernel developer get their hands on a copy of
the specs for the wdm (windows device driver model) and learn what
useful information they can from it.  

> as for signing kernel modules as being 'good' you have a serious problem
> in the Linux world that there is no central authority to do any such
> signing. 

Microsoft uses Verisign I believe, which is a company linux commands
like "whois" already use to do nameserver lookups for example.  It's a
third party, and hardware manufacturers probably already have
certificates from them.

-Rob

Re: The GPL, the kernel, and everything else.

[David Lang]

On Sat, 11 Jan 2003, Rob Wilkens wrote:

> > 2. modules not only need to be called with the correct parameters, they
> > also need to do the proper locking. as locking evolves what needs to be
> > done by the module changes. This can only be solved by every module doing
> > locking 'just in casee' at which point the unessasary locking becomes a
> > significant performance issue (Larry McVoy has written a document about
> > why locking is bad and why excessive locking is very bad, search archives
> > for the link to his site)
>
> I don't need to read an article to know why locking is bad.  However, if
> we can broadly generalize drivers into categories (instead of just
> "modules", for example, there could be a generic "video module"
> structure and that could have a specific kind of locking that a video
> driver would need, and the same would go for other specific types of
> drivers).

the problem is that the locking that's nessasary for a storage driver
depends on the locking that's implemented in the filesystem that's calling
the driver. that locking changes over time.

it used to be that locking was simple, you took the BKL and that was it
(and then only if you needed to, if you were only called from a place that
already heldthe BKL you didn't need to do anything)

as time goes on and existing algorithms are replaced by others the locking
requirements change. useing my example above, if the filesystem layer is
changed so that it no longer needs the BKL then the storage driver needs
to aquire it itself (if it needs it, not all of them will)

> > 4. since no designer (or group of designers) can think of everything your
> > API is going to be incomplete anyway. you can either pretend this isn't
> > the case and limit yourself to the things that you origionally imagined,
> > change your API (and now what do you do with things that used the
>
> Why is it that Windows doesn't seem to have a problem providing a
> generic binary driver interface -- one that is portable accross
> operating systems as mentioned before -- drivers which work on Windows
> 98 are binary compatible with Windows 2000 and Windows XP despite major
> difference in the systems never mind minor kernel changes.
>
> I'd suggest that a linux kernel developer get their hands on a copy of
> the specs for the wdm (windows device driver model) and learn what
> useful information they can from it.

I don't know what you've been running, but windows device drivers are not
compatable across all the different versions of windows (try installing a
windows 9x driver in NT for example).

> > as for signing kernel modules as being 'good' you have a serious problem
> > in the Linux world that there is no central authority to do any such
> > signing.
>
> Microsoft uses Verisign I believe, which is a company linux commands
> like "whois" already use to do nameserver lookups for example.  It's a
> third party, and hardware manufacturers probably already have
> certificates from them.

verisign does not decide what drivers to sign, microsoft does, microsoft
signs them useing a key they got from verisign. that's a very different
situation.

David Lang

Re: The GPL, the kernel, and everything else.

[Stephen Satchell]

At 11:55 PM 1/11/03 -0500, Rob Wilkens wrote:
> > as for signing kernel modules as being 'good' you have a serious problem
> > in the Linux world that there is no central authority to do any such
> > signing.
>
>Microsoft uses Verisign I believe, which is a company linux commands
>like "whois" already use to do nameserver lookups for example.  It's a
>third party, and hardware manufacturers probably already have
>certificates from them.

Microsoft doesn't use Verisign for its driver signing -- it's a proprietary 
system that is hard-wired into Windows.  I would guess you are confusing 
SSL certificates with module signatures.

As for "whois" you will find the default host for the GNU version is 
"whois.crsnic.net", which is not Verisign.

Microsoft signs modules that passes their test suite, and for which vendors 
pay a pretty penny (five digits' worth in US Dollars, if I recall 
correctly).  There is no comparable central authority for Linux or GNU 
software, nor would vendors be interested in spending the kind of dollars 
that would be associated with that sort of certification.  If they would, I 
would LOVE to start such a business.

Satch



-- 
The human mind treats a new idea the way the body treats a strange
protein:  it rejects it.  -- P. Medawar
This posting is for entertainment purposes only; it is not a legal opinion.

Re: The GPL, the kernel, and everything else.

[Rob Wilkens]

Below are two messages I wrote tonight but forgot to "reply all" so got
sent only to individuals.. In case others were interested in reading
(and probably none are, so I summarize in one e-mail), I quote both
below:

           From: 
Rob Wilkens
<robw@optonline.net>
       Reply-To: 
robw@optonline.net
             To: 
David Lang
<david.lang@digitalinsight.com>
        Subject: 
Re: The GPL, the
kernel, and
everything else.
           Date: 
12 Jan 2003
00:32:16 -0500

On Sun, 2003-01-12 at 00:10, David Lang wrote:
> the problem is that the locking that's nessasary for a storage driver
> depends on the locking that's implemented in the filesystem that's
calling
> the driver. that locking changes over time.

I suppose I should learn more about the locking requirements of the file
system before I comment further.  I'm fairly new to the linux kernel,
and haven't done kernel hacking much at all for the past 5 years.  I'm a
bit rusty, which is not to infringe on the trademark held by someone
else on the list.

> I don't know what you've been running, but windows device drivers are
not
> compatable across all the different versions of windows (try
installing a
> windows 9x driver in NT for example).

Actually, Windows 9x drivers will work on Windows NT (if you count
Windows 2000 as part of the Windows NT family).  That is the case if and
only if the driver conforms to the wdm.  

I'm too tired to read it now and summarize it, but here's an
introductory document on it:

http://www.microsoft.com/hwdev/driver/wdm/wdm.asp

-Rob




     From: 
Rob Wilkens
<robw@optonline.net>
 Reply-To: 
robw@optonline.net
       To: 
Stephen
Satchell
<list@fluent2.pyramid.net>
  Subject: 
Re: The GPL,
the kernel,
and
everything
else.
     Date: 
12 Jan 2003
00:25:49
-0500

On Sun, 2003-01-12 at 00:12, Stephen Satchell wrote:
> Microsoft doesn't use Verisign for its driver signing -- it's a
proprietary 
> system that is hard-wired into Windows.  I would guess you are
confusing 
> SSL certificates with module signatures.
> 
> As for "whois" you will find the default host for the GNU version is 
> "whois.crsnic.net", which is not Verisign.

My mistake in both of the above cases, Thanks for the correction.

> Microsoft signs modules that passes their test suite, and for which
vendors 
> pay a pretty penny (five digits' worth in US Dollars, if I recall 
> correctly).  There is no comparable central authority for Linux or GNU
> software, nor would vendors be interested in spending the kind of
dollars 
> that would be associated with that sort of certification.  If they
would, I 
> would LOVE to start such a business.

This is a perfect example of "If you build it, they will come".  I think
I read somewhere that some linux-based systems actually sell for over a
million dollars a pop (granted these are something like 64-processor
custom systems).  I don't think you'll find NT systems in that price
range.  That being the case, I'm quite sure that certain vendors would
love to say that their hardware is certified.

As an example from a parallel dimension: How is the RHCE certification
doing in popularity? 

Or for that matter LPIC (I've only taken and passed LPI 101 myself).

With both RHCE and LPI, People have taken the idea of certification and
the idea of linux and learned that you can make money.  Maybe not a lot
(who knows) but enough to justify doing it.  Red Hat probably makes more
money on training and certification than they do on sales since what
they sell is a free system.

Switching back to our original problem domain: There's no reason that
you can't offer a certification service for linux hardware drivers that
does much the same kind of testing that microsoft does on windows
hardware drivers, and then offer your seal of approval.  Sure, you'll
have to prove that your certification is meaningful and worthwhile, but
if LPI and RHCE can get some people to pay, why can't another
organizaton do it on the hardware driver front?  I'll tell you why: 
There is no standard binary hardware driver interface for any class of
device and hence no ability to run a generic test suite to validate that
it will work on all versions of a linux kernel beyond version <x>.

Of course, I could be as wrong here as I was about microsoft's signing
technology.

-Rob

Re: Nvidia and its choice to read the GPL "differently"

[Chuck Wolber]

> > As per buggy hardware, the software should _not_ have to support it.  
> > The software should report that the hardware has a bug and stop.  
> > Otherwise, you wind up writing really bad code for other hardware at
> > the same time that you're trying to work with one particular piece of
> > bad hardware.

Good point! It's time we stopped supporting those Intel processors...


-- 
 Quantum Linux Laboratories - ACCELERATING Business with Linux Technology
   * Education			|
   * Integration		| http://www.quantumlinux.com
   * Support			| chuckw@quantumlinux.com

"Those who don't understand UNIX are condemned to reinvent it, poorly." 
			-- Henry Spencer

Re: Nvidia and its choice to read the GPL "differently"

[Andrew McGregor]

--On Saturday, January 11, 2003 17:57:50 -0500 Rob Wilkens 
<robw@optonline.net> wrote:

> [Pushing the NVIDIA thread further because I have one of these damned
> cards and want support for it in the 2.5+ kernels.]

The canonical place to look for this is www.minion.de

Andrew

Intel And Kenrel Programming (was: Nvidia is a great company)

[Rob Wilkens]

On Sun, 2003-01-12 at 02:47, Chuck Wolber wrote:
> > > As per buggy hardware, the software should _not_ have to support it.  
> > > The software should report that the hardware has a bug and stop.  
> > > Otherwise, you wind up writing really bad code for other hardware at
> > > the same time that you're trying to work with one particular piece of
> > > bad hardware.
> 
> Good point! It's time we stopped supporting those Intel processors...

Ignorring the well popularized floating point bug in the pentium, to
which there was a bug, are there many other bugs you run accross in the
pentium while kernel programming?

-Rob

Re: Intel And Kenrel Programming (was: Nvidia is a great company)

[Alan Cox]

On Sun, 2003-01-12 at 14:42, Rob Wilkens wrote:
> Ignorring the well popularized floating point bug in the pentium, to
> which there was a bug, are there many other bugs you run accross in the
> pentium while kernel programming?

There are actually very few chips we don't have to deal with some kind
of errata on, and the newer more complex chips generally have the larger
collections of errata. 

One thing that has been helpful is the microcode update stuff Intel did, we
hit  few bugs that up to date microcode kill off

Re: Intel And Kenrel Programming (was: Nvidia is a great company)

[Rob Wilkens]

On Sun, 2003-01-12 at 11:45, Alan Cox wrote:
> There are actually very few chips we don't have to deal with some kind
> of errata on, and the newer more complex chips generally have the larger
> collections of errata. 
> 
> One thing that has been helpful is the microcode update stuff Intel did, we
> hit  few bugs that up to date microcode kill off
> 

The hardware engineers, in my experience, will not refer to those issues
as bugs, but rather as misdocumented features... No?  I mean if an
errata is enough to work around the problem, then the documentation was
clearly the problem, and not the hardware implementation.

As per the microcode updates, I noticed RedHat 8 was autoupdating
microcode on each boot IIRC. I've since switched to Debian and don't
know that it does this.  Should I be concerned?

-Rob

Re: Intel And Kenrel Programming (was: Nvidia is a great company)

[Alan Cox]

On Sun, 2003-01-12 at 16:58, Rob Wilkens wrote:
> The hardware engineers, in my experience, will not refer to those issues
> as bugs, but rather as misdocumented features... No?  I mean if an
> errata is enough to work around the problem, then the documentation was
> clearly the problem, and not the hardware implementation.

Intel seperate out things that are docmentation errors, clarifications
and actual bugs. They publish regular errata documents listing these,
and when they do decide to turn a flaw into a specification update they
document that too. AMD likewise.

Some vendors may not do this, but the x86 CPU vendors seem to do a good
job.

> As per the microcode updates, I noticed RedHat 8 was autoupdating
> microcode on each boot IIRC. I've since switched to Debian and don't
> know that it does this.  Should I be concerned?

It depends on your chip revisions. For example the O(1) scheduler will trigger 
very occasional random crashes or reboots with early PII Xeon microcode sets.
I'm sure Debian has a package for this somewhere.

Alan

Re: Intel And Kenrel Programming

[Samuli Suonpaa]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> For example the O(1) scheduler will trigger very occasional random
> crashes or reboots with early PII Xeon microcode sets. I'm sure
> Debian has a package for this somewhere.

Something like this, I guess:

$ apt-cache show microcode.ctl
Package: microcode.ctl
[...]
Description: Intel IA32 CPU Microcode Utility
 The microcode_ctl utility is a companion to the IA32 microcode driver
 written by Tigran Aivazian <tigran@veritas.com>. The utility has two
 uses:
 .
 a) it decodes and sends new microcode to the kernel driver to be
    uploaded to Intel IA32 family processors. (Pentium Pro, PII,
    Celeron, PIII, Xeon, Pentium 4 etc.)
 b) it signals the kernel driver to release any buffers it may hold
 .
 The microcode update is volatile and needs to be uploaded on each
 system boot i.e. it doesn't re-flash your CPU permanently, reboot and
 it reverts back to the old microcode. The ideal place to load
 microcode is in BIOS, but most vendors never update it!
 .
 To enable microcode update, I need some kernel support, thus I need
 the linux kernel 2.2.18 or later, or 2.4.0 or later.

Suonpää...

Re: Intel And Kenrel Programming (was: Nvidia is a great company)

[Valdis.Kletnieks]

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

On Sun, 12 Jan 2003 16:45:24 GMT, Alan Cox said:
> One thing that has been helpful is the microcode update stuff Intel did, we
> hit  few bugs that up to date microcode kill off

http://www.urbanmyth.org/microcode/ says that microcode_ctl 1.06 is the
latest, dated all the way back to 11 Jun 2001.  Is that in fact the most
recent?  In this industry, I alway worry when "most recent" is 18 months
old.

Hopefully it's the most recent because no further errata have been found.;)

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


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

Re: Nvidia and its choice to read the GPL "differently"

[Richard B. Johnson]

On Sat, 11 Jan 2003, David Schwartz wrote:

[SNIPPED...]
> 
> 	A cheap hammer can drive in more nails than a top of the line 
> screwdriver.
> 
> 	DS

I like that! Reading this' month's "Computer", I noted that VxWorks
was reported to be used in the busses of satellites, i.e., manages
the IIC bus. That sounds like a good place for it. Unfortunately,
the hype is that it "runs all the satellites and is the operating
system of choice for satellites in high-radiation environments..."

VxWorks looks like this:

       void interrupt_stuff() {
           do_it();
       }

	main() {
            setup_stuff();
            for(;;) {
              funct0();
              funct1();
              funct2();
              functn();
            }
        }

    It's a big loop. Now, this might be okay for something that runs
the same events over and over again, an elevator controller, or the
"smarts" behind some protocol manager. But it would really suck if
funct0() ended up taking 1 second and functn() needs service in one 
millisecond. So, it's up to the function designer to make certain
that no function or, in some cases all functions combined, takes
more than the required latency specification to execute.

At some point, as complexity increases, you need to preempt. Preemption
takes some worse-case time. It's at that point that a system designer
will (should) throw out VxWorks and use some variation of Linux.

As system complexity continues to increase, eventually it becomes
best (currently, if it doesn't get screwed up) to use unmodified
Linux because it is optimized for "desktop" operation, meaning
it is optimized for systems of unknown complexity.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: The GPL, the kernel, and everything else.

[Mark H. Wood]

On Sat, 11 Jan 2003, Rob Wilkens wrote:
> On Sat, 2003-01-11 at 20:06, Ryan Anderson wrote:
> > Because, to a large extent, for the core kernel developers, the existing
> > system is fine.
>
> If you're designing a system for kernel developers use, then that's
> fine.  But if you want to see linux proliferate to the average desktop
> (and I do), then you've got to look at the bigger picture.  There
> _should_ be a way for a company like nvidia to build a binary driver,
> adn ship it in binary form, maybe even digitally signed the way
> microsoft allows digital signing of drivers so you know the driver is
> legit and OK.

Right there you've put your finger on a problem.  Many core developers are
working hard to make sure that this never happens.  See arguments in favor
of open source.

It looks to me as though an underlying, larger problem is that there are
several distinct communities which are all interested in Linux, but which
have divergent values.  Developers, for example, want something that's fun
to develop or is personally useful, and take steps to prevent commercial
interests' spoiling their experience.  Others want a Windows-killer and
obsess about the desktop, or installation, or other ease-of-use-by-those-
who'd-rather-not-think-about-computers issues.  Still others *are*
commercial interests, and want to figure out how to make money in this
space (some worrying about how to avoid killing the goose which lays the
golden eggs, others intent on short-term profit and caring nothing for the
goose's long-term welfare).

Me, I could care less whether Linux achieves world domination.  The
business desktop is to me an utterly uninteresting problem.  The only
reason I worry about things like market penetration is that competing
products' companies keep interfering with my decision to use Linux when
addressing problems for which it is a good fit.  Like it or not, I need a
certain amount of "bandwagon effect" for Linux in order to impress those
who are impressed by such things, since some of them can preempt the
decision as to which platform I use for any given assignment.  I wouldn't
care if I were the only Linux user on earth, if I didn't have to defend my
professional prerogatives.

So, you need to look at the *really* big picture.  There are people who
think the way you do, and people who don't, and it would be a worthy
challenge to find a way to somewhat satisfy both groups.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".

Re: The GPL, the kernel, and everything else.

[venom]

On Thu, 16 Jan 2003, Mark H. Wood wrote:

> Date: Thu, 16 Jan 2003 11:28:42 -0500 (EST)
> From: Mark H. Wood <mwood@IUPUI.Edu>
> To: Linux kernel list <linux-kernel@vger.kernel.org>
> Subject: Re: The GPL, the kernel, and everything else.
>
>
> So, you need to look at the *really* big picture.  There are people who
> think the way you do, and people who don't, and it would be a worthy
> challenge to find a way to somewhat satisfy both groups.
>

please look at this new run queue thing in process context for kernel modules,
and the fact that non GPL modules cannot create an own queue, but have to use
the default one (all queue are managed by a kernel thread).
As you see, for linux 2.6 the big picture will acquire a new element.
(Personally I do like it a lot, as mutch as I like all the run queue approach)

This as quite interesting implications, since it is a penalty for binary only
modules.

Luigi

Re: The GPL, the kernel, and everything else.

[John Alvord]

On Thu, 16 Jan 2003 11:28:42 -0500 (EST), "Mark H. Wood"
<mwood@IUPUI.Edu> wrote:

>On Sat, 11 Jan 2003, Rob Wilkens wrote:
>> On Sat, 2003-01-11 at 20:06, Ryan Anderson wrote:
>> > Because, to a large extent, for the core kernel developers, the existing
>> > system is fine.
>>
>> If you're designing a system for kernel developers use, then that's
>> fine.  But if you want to see linux proliferate to the average desktop
>> (and I do), then you've got to look at the bigger picture.  There
>> _should_ be a way for a company like nvidia to build a binary driver,
>> adn ship it in binary form, maybe even digitally signed the way
>> microsoft allows digital signing of drivers so you know the driver is
>> legit and OK.
>
>Right there you've put your finger on a problem.  Many core developers are
>working hard to make sure that this never happens.  See arguments in favor
>of open source.
>
>It looks to me as though an underlying, larger problem is that there are
>several distinct communities which are all interested in Linux, but which
>have divergent values.  Developers, for example, want something that's fun
>to develop or is personally useful, and take steps to prevent commercial
>interests' spoiling their experience.  Others want a Windows-killer and
>obsess about the desktop, or installation, or other ease-of-use-by-those-
>who'd-rather-not-think-about-computers issues.  Still others *are*
>commercial interests, and want to figure out how to make money in this
>space (some worrying about how to avoid killing the goose which lays the
>golden eggs, others intent on short-term profit and caring nothing for the
>goose's long-term welfare).
>
>Me, I could care less whether Linux achieves world domination.  The
>business desktop is to me an utterly uninteresting problem.  The only
>reason I worry about things like market penetration is that competing
>products' companies keep interfering with my decision to use Linux when
>addressing problems for which it is a good fit.  Like it or not, I need a
>certain amount of "bandwagon effect" for Linux in order to impress those
>who are impressed by such things, since some of them can preempt the
>decision as to which platform I use for any given assignment.  I wouldn't
>care if I were the only Linux user on earth, if I didn't have to defend my
>professional prerogatives.
>
>So, you need to look at the *really* big picture.  There are people who
>think the way you do, and people who don't, and it would be a worthy
>challenge to find a way to somewhat satisfy both groups.

Given the inertia of existing applications and documents in business
[read Microsoft Office] you also need to get Microsoft on board as an
application provider. There are many business applications written in
COBOL running on zSeries machines because of similiar inertia,
regardless of how much hardware costs could be saved...

john alvord