Re: Coding style - a non-issue

Re: Coding style - a non-issue

[RaúlNúñez de Arenas Coronado]

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

    Hi Jeff and Paul :)

>"Paul G. Allen" wrote:
>> IMEO, there is but one source as reference for coding style: A book by
>> the name of "Code Complete". (Sorry, I can't remember the author and I
>> no longer have a copy. Maybe my Brother will chime in here and fill in
>> the blanks since he still has his copy.)
>Hungarian notation???
>That was developed by programmers with apparently no skill to
>see/remember how a variable is defined.  IMHO in the Linux community
>it's widely considered one of the worst coding styles possible.

    Not at all... Hungarian notation is not so bad, except it is only
understood by people from hungary. So the name }:))) I just use it
when I write code for Hungary or secret code that no one should
read...

>>  - Short variable/function names that someone thinks is descriptive but
>> really isn't.
>not all variable names need their purpose obvious to complete newbies. 
>sometimes it takes time to understand the code's purpose, in which case
>the variable names become incredibly descriptive.

    Here you are right. The code can be seen really as a book: you
can start reading at the middle and yet understand some of the story,
but it's far better when you start at the beginning ;))) Moreover,
most of the variable and function names in the kernel code are quite
descriptive, IMHO.

    Of course, more comments and more descriptive names doesn't harm,
but some times they bloat the code...

    Raúl

Re: Coding style - a non-issue

[Paul G. Allen]

"Raúl Núñez de Arenas Coronado" wrote:
> 
> >Hungarian notation???
> >That was developed by programmers with apparently no skill to
> >see/remember how a variable is defined.  IMHO in the Linux community
> >it's widely considered one of the worst coding styles possible.
> 
>     Not at all... Hungarian notation is not so bad, except it is only
> understood by people from hungary. So the name }:))) I just use it
> when I write code for Hungary or secret code that no one should
> read...

I prefer Pig Latin myself. ;)

> 
> >>  - Short variable/function names that someone thinks is descriptive but
> >> really isn't.
> >not all variable names need their purpose obvious to complete newbies.
> >sometimes it takes time to understand the code's purpose, in which case
> >the variable names become incredibly descriptive.
> 
>     Here you are right. The code can be seen really as a book: you
> can start reading at the middle and yet understand some of the story,
> but it's far better when you start at the beginning ;))) Moreover,
> most of the variable and function names in the kernel code are quite
> descriptive, IMHO.
> 

There's no way on earth I would ever start reading at the beginning of 3
million lines of code just so I can understand bobsdriver.o, which is
only 10,000 lines. I should not have to start at the beginning of
bobsdrvier.o either if I only needed to solve one problem in one
function somewhere near the end of it.

I have worked on several large projects and have rarely known how every
piece of any of them worked. I didn't have to. I only needed to know
about the portion(s) I was responsible for. I was able to do that with
the better projects because they were commented correctly and were
rather self documenting.

>     Of course, more comments and more descriptive names doesn't harm,
> but some times they bloat the code...
> 

Actually it bloats the source (we all know C++ bloats the resulting code
;), but what's wrong with that? At least a person can understand what's
going on and get to coding, instead of deciphering.

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[Tim Hockin]

> >     Of course, more comments and more descriptive names doesn't harm,
> > but some times they bloat the code...
> > 
> 
> Actually it bloats the source (we all know C++ bloats the resulting code
> ;), but what's wrong with that? At least a person can understand what's
> going on and get to coding, instead of deciphering.

I'd happily download 50 MB kernel tarballs, if the extra 25 MB were
ACCURATE and UP TO DATE comments.

Re: Coding style - a non-issue

[Ragnar Hojland Espinosa]

On Fri, Nov 30, 2001 at 12:17:43PM -0800, Paul G. Allen wrote:
> Actually it bloats the source (we all know C++ bloats the resulting code
> ;), but what's wrong with that? At least a person can understand what's
> going on and get to coding, instead of deciphering.

Yes, I do see the smiley, but since its not clear to me on whether its meant
as a "j/k" or not, and being tried of listening the same shit for years,
I'll have to add that C++ does not bloat code. 

-- 
____/|  Ragnar Højland      Freedom - Linux - OpenGL |    Brainbench MVP
\ o.O|  PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
 =(_)=  "Thou shalt not follow the NULL pointer for  | (www.brainbench.com)
   U     chaos and madness await thee at its end."

RE: Coding style - a non-issue

[Dana Lacoste]

> One one thing he simple appears to have forgotten: Operating 
> systems have a *purpose*.

You're forgetting that Linus makes a kernel, not an OS.

This isn't the Linux OS Mailing List, it's the Linux Kernel Mailing List.

How can Linus be expected to make a formal design for a kernel
when he has no control over how the kernel is used?
(This being the strength of Linux : it can be used almost everywhere)

If you want an _OS_ try one of the BSD's : they have a declared purpose,
after all :)

Dana Lacoste
Peregrine Systems
Ottawa, Canada

Re: Coding style - a non-issue

[Tommy Reynolds]

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

In view of the 100's of messages spawned by this topic, I can only be thankful
that this is a "non-issue" ;-)  Just imagine a substantive topic like, maybe,
Linux!

---------------------------------------------+-----------------------------
Tommy Reynolds                               | mailto: <reynolds@redhat.com>
Red Hat, Inc., Embedded Development Services | Phone:  +1.256.704.9286
307 Wynn Drive NW, Huntsville, AL 35805 USA  | FAX:    +1.256.837.3839
Senior Software Developer                    | Mobile: +1.919.641.2923

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

RE: Re: Coding style - a non-issue

[n7ekg]

I have been following this thread with a mixture of amusement and exasperation - amusement that intelligent people like Linus, who ought to know better, are spouting this evolution stuff, and exasperation that some people think that because someone's an expert in one thing, they are an expert in all things.

The idea of genetic evolution itself is complete nonsense - biological systems don't evolve genetically, they evolve environmentally.  Biological systems change as a result of random mutation, and what doesn't work doesn't survive.  What people try to pass off as evolution is simply the less fit not surviving to pass on their bad genes.  Sort of like the hundred monkeys idea.

But that is all completely irrelevent to coding, since it is extremely inefficient for systems to "evolve" based on trial and error.  The way modern systems evolve is based on (hopefully) *intelligent* selection - I write a patch, submit it to Linus.  He doesn't accept it, throw it in the kernel, and that's it - he looks at it, what it does, and decides if it fits in the Grand Scheme of things - kernel efficiency, speed, flexibility, extensability, and maintainability - and *then* decides if it makes it in.  They key difference is that in nature, mutation is random because it can afford to be - in coding, it isn't because we don't have thousands or millions of years to find out whether or not something works or not.

That being said, I am well aware that "genetic programming" has made some progress in that direction, mainly because it doesn't take millenia to figure out what works and what doesn't.  But that's a long way from "evolving" an entire operating system.  I don't believe for a moment that homo sapiens "evolved" from pond scum although I might believe that some fellow homo sapiens *are* pond scum!) - it only makes sense that we are a created species, and that Homo Erectus ans all the rest were early genetic experiments.  Who created homo sapiens is beyond the scope of this discussion ;)

Original Message:
-----------------
From: Larry McVoy lm@bitmover.com
Date: Sun, 02 Dec 2001 12:25:26 -0800
To: vonbrand@sleipnir.valparaiso.cl, yodaiken@fsmlabs.com, linux-kernel@vger.kernel.org
Subject: Re: Coding style - a non-issue


On Sat, Dec 01, 2001 at 08:18:06PM -0300, Horst von Brand wrote:
> Victor Yodaiken <yodaiken@fsmlabs.com> said:
> > Linux is what it is because of design, not accident. And you know
> > that better than anyone.
> 
> I'd say it is better because the mutations themselves (individual patches)
> go through a _very_ harsh evaluation before being applied in the "official"
> sources. 

Which is exactly Victor's point.  That evaluation is the design.  If the 
mutation argument held water then Linus would apply *ALL* patches and then
remove the bad ones.  But he doesn't.  Which just goes to show that on this
mutation nonsense, he's just spouting off.
-- 
---
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/

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Re: Coding style - a non-issue

[Brandon McCombs]

On Sun, 2 Dec 2001 15:53:46 -0500
"n7ekg@swbell.net" <n7ekg@swbell.net> wrote:

> I have been following this thread with a mixture of amusement and exasperation - amusement that intelligent people like Linus, who ought to know better, are spouting this evolution stuff, and exasperation that some people think that because someone's an expert in one thing, they are an expert in all things.

No offense toward anyone but I find that many non-religious people can be found in the CompSci area of expertise. I'm not sure why this is but besides myself and another friend all the other people I know in that general field are atheists. It would only make sense that we would hear atheist type remarks within these discussions just as we would hear Christian remarks in another field of expertise that seems to attract Christians.

> 
> The idea of genetic evolution itself is complete nonsense - biological systems don't evolve genetically, they evolve environmentally.  Biological systems change as a result of random mutation, and what doesn't work doesn't survive.  What people try to pass off as evolution is simply the less fit not surviving to pass on their bad genes.  Sort of like the hundred monkeys idea.

True. Many mutations in human DNA cause the resulting human to be unable to reproduce once they reach the age where a normal human could do so.


> 
> But that is all completely irrelevent to coding, since it is extremely inefficient for systems to "evolve" based on trial and error.  The way modern systems evolve is based on (hopefully) *intelligent* selection - I write a patch, submit it to Linus.  He doesn't accept it, throw it in the kernel, and that's it - he looks at it, what it does, and decides if it fits in the Grand Scheme of things - kernel efficiency, speed, flexibility, extensability, and maintainability - and *then* decides if it makes it in.  They key difference is that in nature, mutation is random because it can afford to be - in coding, it isn't because we don't have thousands or millions of years to find out whether or not something works or not.

We have a way of being able to direct the evolution of our code as we can control the bad parts and teh good parts and what gets added and what doesn't.  We have no control over our DNA (human genetics may have proven me wrong already but if not, it shouldn't take more than a few months more) so mutations in the human race are more random.

> 
> That being said, I am well aware that "genetic programming" has made some progress in that direction, mainly because it doesn't take millenia to figure out what works and what doesn't.  But that's a long way from "evolving" an entire operating system.  I don't believe for a moment that homo sapiens "evolved" from pond scum although I might believe that some fellow homo sapiens *are* pond scum!) - 

*finally* someone who doesn't believe in evolution of the human race.  As a side note, i've heard some people say that a bolt of lightning triggered some proteins to start growing into single celled organisms and then into what we now call today human beings.  I take offense that I came from a single celled organism.  I believe the more complex an object or system is the less randomness can be added in order to arrive at the current/final version. I think we all agree the human body is the most complex object in the universe so how can we say that our existence was an accident?

An operating system is a complex system as well. We all know code doesn't evolve on its own to generate an operating system right? :) It has to be created and as time goes on code forks are sometimes introduced.  In humans that could be somewhat akin to whites, blacks, asians, etc.  But they were all created from the code that God started with. He just released his source code(dna) a little later in the development tree than some people may have wanted so there was no point in letting us evolve into something more as we were already different enough. :)

>it only makes sense that we are a created species, and that Homo Erectus ans all the rest were early genetic > experiments.  Who created homo sapiens is beyond the scope of this discussion ;)

It is beyond the scope. If we attempted that topic we would be branded as close-minded even though the others (read: non-religious) can do it and they defend themselves by saying its free speech.

my time is out for this post.
brandon

Re: Coding style - a non-issue

[Alexander Viro]

On Sun, 2 Dec 2001, Brandon McCombs wrote:

[snip badly-formatted creationism advocacy]

Please, learn to
	* use line breaks
	* be intellectually honest
	* be at least remotely on-topic

*plonk*

Re: Coding style - a non-issue

[Jonathan Abbey]

brandon wrote:
|
|  *finally* someone who doesn't believe in evolution of the human race.
| As a side note, i've heard some people say that a bolt of lightning
| triggered some proteins to start growing into single celled organisms
| and then into what we now call today human beings.  I take offense
| that I came from a single celled organism.  I believe the more complex
| an object or system is the less randomness can be added in order to
| arrive at the current/final version. I think we all agree the human
| body is the most complex object in the universe so how can we say that
| our existence was an accident?

Again, a complete misunderstanding of evolution.  Evolution is itself
a design process.. it is simply a design process that admits to an
literally unthinkable amount of complexity.  No individual or team of
individuals, no matter how intelligent, could sit down and create from
scratch the Linux kernel as it exists today.  There are tons and tons
of design elements in the code that emerged from trial and error, and
from interactions between the hardware to be supported, the user level
code to run on it, and the temporal exigencies of the kernel code
itself.  The fact that humans applied thought to all (well, at least
to some) of the changes made doesn't mean that the overarching dynamic
isn't an evolutionary one.

Taking offense at evolution having produced us from simpler organisms
is like taking offense at the rain, or the sun setting at night.  We
can now look at life and actually read the code, and see how much is
held in common and how much varies between different organisms, just
as surely as we can with all of the linux kernels over the last ten
years.  Both systems have lots of characteristics in common, and for
perfect reasons.

Linus is right.

-------------------------------------------------------------------------------
Jonathan Abbey 				              jonabbey@arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
Ganymede, a GPL'ed metadirectory for UNIX     http://www.arlut.utexas.edu/gash2

Re: Coding style - a non-issue

[Trever L. Adams]

> *finally* someone who doesn't believe in evolution of the human race.  As a side note, i've heard some people say that a bolt of lightning triggered some proteins to start growing into single celled organisms and then into what we now call today human beings.  I take offense that I came from a single celled organism.  I believe the more complex an object or system is the less randomness can be added in order to arrive at the current/final version. I think we all agree the human body is the most complex object in the universe so how can we say that our existence was an accident?
>

I personally will stay out of the religious side of this argument,
having been flamed for standing up for any religious stand point on this
list.

However, I just finished my two bio classes for my CS degree.  It is
interesting that you mention this lightening theory.  My bio book (sorry
no references and no quotes, maybe later) stated that many people
(60's-80's) have tried very hard to duplicate and find conditions
whereby simple molecules could even form basic RNA or other such
biological/organic compounds.  They had some very minimal success.  In
the end it was concluded that the methods they were trying probably
would never have created RNA and other such things that may have
assembled a cell.  Some of these tests were based on this lightening
theory.

Maybe such spontaneous life could have happened another way... I don't
really know.

As for software evolution.  I would have to weigh in with my opinion
being somewhere between Linus and many others.  Software does evolve. 
Just about any human project does.  This is one reason why there are
"versions", "editions", etc.  You can only design so much.  Then you go
back and evolve it.  Is Linus right that there was nearly no design??  I
think he would know best about the earliest roots of Linux.  However, I
think he is wrong that now there is no design (though there may be no
master plan, which would mean it is controlled evolution more than
engineered/designed).

Anyway, I will sink back into silence for now.

Trever Adams

Re: Coding style - a non-issue

[Khyron]

In response to:

> "it works/does not work for me" is not testing. Testing
> is _actively_ trying to break things, _very_ preferably
> by another person that wrote the code and to do it
> in documentable and reproducible way. I don't see many
> people doing it.

from "Stanislav Meduna <stano@meduna.org>", Alan Cox said:

"If you want a high quality, tested supported kernel which
has been through extensive QA then use kernel for a
reputable vendor, or do the QA work yourself or with other
people. We have kernel janitors, so why not kernel QA
projects ?

"However you'll need a lot of time, a lot of hardware and
a lot of attention to procedure"

But in his earlier e-mail, Stanislav Meduna said:

"Evolution does not have the option to vote with its feet.
The people do. While Linux is not much more stable than it
was and goes through a painful stabilization cycle on every
major release, Windows does go up with the general stability with
every release. W2k were better than NT, XP are better than W2k.
Windows (I mean the NT-branch) did never eat my filesystems.
Bad combination of USB and devfs was able to do this in half
an hour, and this was *VENDOR KERNEL* that did hopefully get
more testing than that what is released to the general public.
I surely cannot recommend using 2.4 to our customers."

which seems to negate the point Alan was attempting to make.

Just thought I'd set the record straight.

NOTE: Emphasis mine.


"Everyone's got a story to tell, and everyone's got some pain.
 And so do you. Do you think you are invisble?
 And everyone's got a story to sell, and everyone is strange.
 And so are you. Did you think you were invincible?"
 	- "Invisible", Majik Alex

Re: Coding style - a non-issue

[Alan Cox]

> Bad combination of USB and devfs was able to do this in half
> an hour, and this was *VENDOR KERNEL* that did hopefully get
> more testing than that what is released to the general public.
> I surely cannot recommend using 2.4 to our customers."

So change vendor. There are reasons Red Hat for example does not ship devfs.
It's never been good enough to pass inspection let alone coverage or stress
testing it.

Re: Coding style - a non-issue

[Stanislav Meduna]

Hello,

wow, what a nice discussion. I am reading the l-k through an
archive, so please forgive me if I am going to say something
that was already said, but I did not yet read it.


Linus wrote:
> Don't underestimate the power of survival of the fittest.

Well, your theory is really an interesting view on the
software development. However, I think that there are
some points that need some more discussion.

First, you are probably right in the long-term. The nature
did have enough time for excursions in one or another
direction - the "project" of life is several orders of magnitude
older than a single generation. You say that it is possible
to help the evolution. But you still need many generations
to be sure that a good result at some stage is not only some
statistical variance.
 
The technology does not IMHO work that way - Linux (Unix
in all its flavours, Windows, ...) is very young.
We are not in the stage where life exists for millions
of years. We are in the stage where the first cells
have formed and are still quite vulnerable. There is only
a thin line between survival as a kind and extinction (sp?).
I think that in this stage not ignoring the role of
the design is a good thing (and no, I don't believe in God :-)).

Besides that, are you talking about evolution in general,
or about evolution of a particular kind? The competition
is not the same in these cases.

> - massive undirected parallel development ("trial and error") 

This is not what is happening here. The parallelism does
exist but is not massive in any way. There are not thousands
of people writing the same stuff. There are not even thousands
of people able to write a good bug report on a particular bug.
There are maybe three (as in the VM recently) authors of some
subsystem and in the end effect there is a God (or two after
a brief disagreement :-)) that decides. No way is this analogous
to the natural selection where the decision happens statistically
on a whole population. This works between Linux and Windows,
but not between implementation ideas.


Al Viro wrote:
> Fact of life: we all suck at reviewing our own code. You, me,
> Ken Thompson, anybody - we tend to overlook bugs in the code
> we'd written. Depending on the skill we can compensate

Absolutely. But what I really miss is an early-warning system.
No matter how good Linus might be in reviewing the submissions,
he cannot catch it all - nobody is _that_ good.

What I feel hurts the Linux is that the testing standards
are very, very low. Heck, Linus does not probably even compile
the code he releases with the widely used configuration options
(otherwise a non-compiling loop.o would not be possible).

Throwing releases onto the public is not testing. Saying
"it works/does not work for me" is not testing. Testing
is _actively_ trying to break things, _very_ preferably
by another person that wrote the code and to do it
in documentable and reproducible way. I don't see many
people doing it.


Linus wrote:
> And I will go further and claim that  no  major software project
> that has been successful in a general marketplace (as opposed
> to niches) has ever gone through those nice lifecycles they
> tell you about in CompSci classes.

Well, I don't know what they tell in the classes now - I am 33
and in this area the theories change much faster than practice :-)

> Have you  ever  heard of a project that actually started off
> with trying to figure out what it should do, a rigorous design
> phase, and a implementation phase?

I have heard of projects that did succeeded doing well defined
revision cycles with each cycle figuring out what more or better
it should do, the design of it (more or less rigorous),
implementation, then something what you forgot :-) - testing
and deployment.

The project I am working on now (a process control system)
exists for 15 years and is quite successful. It is vertical
market, not horizontal, but hardly a niche. More control
_did_ help it at one stage, where we had a little quality
crisis.


Maybe it is just because people tend to forget the wrong
things, but I have a strong feeling that Linux starts
to have problems with quality that we did not see before,
at least not in this amount. We are nearly a year in
the stable series and we need to change fundamental things
that broadly affect other parts - VM, devfs, ...  This is
not evolution, this is surgery. USB support was one big
argument for 2.4, yet it is far from stable.

My opinion is, that you are _very_ good at maintaining general
overview of a big chunk of code together with being able
to maintain a general direction that makes sense. I don't
think I know someone other that is able to do this. But
I also think that the kernel is in the stage where this
won't be much longer possible even for you. I have seen
software projects going through some kind of crisis
and the symptoms tended be very similar. In the early
stages there are tools (version management, bug reporting
system) and policies (testing standards) that can help.
In the later stages the crisis is in the management.
I cannot say from the outside (I am not doing active kernel
development), in what stage (if in any) the kernel is.
But I have the gut feeling that something should be done.

Evolution does not have the option to vote with its feet.
The people do. While Linux is not much more stable than it
was and goes through a painful stabilization cycle on every
major release, Windows does go up with the general stability with
every release. W2k were better than NT, XP are better than W2k.
Windows (I mean the NT-branch) did never eat my filesystems.
Bad combination of USB and devfs was able to do this in half
an hour, and this was vendor kernel that did hopefully get
more testing than that what is released to the general public.
I surely cannot recommend using 2.4 to our customers.

And frankly, I see the Microsoft borrowing ideas from the open
community. They make things more open - slow, but they are.
They are going to give out compilers for free and charge
for the (quite good and IMHO worth the money) IDE. They are
building communities. Guess why?...

You might of course say that you don't care - the nature
also basically does not care where the evolution is going.
I would like to see more control in the kernel development,
especially regarding quality standards.

Regards
-- 
                                 Stano

Re: Coding style - a non-issue

[Alan Cox]

> "it works/does not work for me" is not testing. Testing
> is _actively_ trying to break things, _very_ preferably
> by another person that wrote the code and to do it
> in documentable and reproducible way. I don't see many
> people doing it.

If you want a high quality, tested supported kernel which has been through
extensive QA then use kernel for a reputable vendor, or do the QA work
yourself or with other people. We have kernel janitors, so why not kernel QA
projects ?

However you'll need a lot of time, a lot of hardware and a lot of attention
to procedure

Alan

Re: Coding style - a non-issue

[Davide Libenzi]

On Sat, 1 Dec 2001, Alan Cox wrote:

> > "it works/does not work for me" is not testing. Testing
> > is _actively_ trying to break things, _very_ preferably
> > by another person that wrote the code and to do it
> > in documentable and reproducible way. I don't see many
> > people doing it.
>
> If you want a high quality, tested supported kernel which has been through
> extensive QA then use kernel for a reputable vendor, or do the QA work
> yourself or with other people. We have kernel janitors, so why not kernel QA
> projects ?

I know a Co. that has its headquarters about 200 miles north of where I
live that has the more organized development/qa cycle and still I won't change
Linux for their kernel even under weapon menace.



- Davide

Re: Coding style - a non-issue

[Stanislav Meduna]

> > "it works/does not work for me" is not testing. Testing
> > is _actively_ trying to break things, _very_ preferably
> > by another person that wrote the code and to do it
> > in documentable and reproducible way. I don't see many
> > people doing it.
> 
> If you want a high quality, tested supported kernel which has been through
> extensive QA then use kernel for a reputable vendor, or do the QA work
> yourself or with other people.

Correct. But this has one problem - it is splitting resources.
Pushing much of the QA work later in the process means
that the bugs are found later, that there is more people
doing this as absolutely necessary and that much more
communication (and this can be the most important bottleneck)
is needed as necessary.

The need of the VM change is probably a classical example -
why was it not clear at the 2.4.0-pre1, that the current
implementation is broken to the point of no repair? I am
not seeking who is guilty, it is irrelevant, but I think
there is a lesson to be learned and I would like to see
the cause to be identified and steps to be taken that move
such experiments into the development series. The 2.2 also
had issues, but 2.4 has IMHO more issues that are not
localized and fixable without affecting other parts.

Evolution does not need to be efficient. I still think that
software development should be - if we loose half a year,
the more organized competitor will be more than happy.

As a user of the vendor's kernel I have no idea what to do
with a bug. The vendor kernel has hundreds of patches that
are or are not, fully or partially merged into the mainstream
for various reasons - you know this surely much better
than I do :-) Now where do I send a bug report and -
more important - where do I look when I want to have
all available information to an issue, so I can be
more specific (or cancel the report completely because
it is clearly duplicate)? Should I consult my vendor's
bugzilla, systems of all other vendors, l-k and specialized
mailing lists of the given subsystem? I doubt that
many of us will...

There is no single place where the bug reports are sent and -
much more important - where their history can be viewed.
The kernel itself has nothing but linux-kernel (overloaded
with tons of non-relevant stuff such as this thread :-))
and probably various TODO lists of the developers.

I really feel that at least the information should be
centralized so that the info can be hyperlinked. You work
with the kernel so closely that you are probably able
to keep the track of the important issues. 99% of users
wanting to at least report bugs are not. Finding something
in the l-k is hard, but even the managers can normally
operate an issue tracking system - I see them doing it
every day :-)

The classical tools such as version control or issue tracking
system were discussed many times and were rejected - not
by evolution, but by one-man decision. linux-kernel does
not show me when and _why_ something was changed. Changelogs
are big step in the right direction, but I think that more
is needed. Frankly, I think that managing the submissions
in a mail folder of Linus is not the right way of doing this
for a project of this size.

I understand that it is impossible for Linus to write a meaningful
comment and to check in a changeset each time he decides to
accept stuff. I think that at some time he will be forced
to give some write-access to a mainstream branch to a few
other people (btw, this final review is imho in strong conflict
with his evolution theory).

> We have kernel janitors, so why not kernel QA projects ?

Yes, this should be probably discussed. If a development
can be distributed and quite organized at the same time,
so can probably the testing. I have already seen such project
somewhere on the web - no idea where they are now.

But an effective QA project is not possible without support
from the developers themselves. Black-box testing is only
one kind of tests. If a design is not documented, it is
much more harder to try to break it.

> However you'll need a lot of time, a lot of hardware and
> a lot of attention to procedure

I know - our QA department sits next door and this is userspace
application, so hardware does not matter :-)

Regards
-- 
                                       Stano

Re: Coding style - a non-issue

[Rik van Riel]

On Sun, 2 Dec 2001, Stanislav Meduna wrote:

> The need of the VM change is probably a classical example -
> why was it not clear at the 2.4.0-pre1, that the current
> implementation is broken to the point of no repair?

It wasn't broken to the point of no repair until Linus
started integrating use-once and dropping bugfixes.

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[Alan Cox]

> The need of the VM change is probably a classical example -
> why was it not clear at the 2.4.0-pre1, that the current
> implementation is broken to the point of no repair? I am

Because nobody had run good test sets by then - anyway it was repairable.
Linus kept ignoring, refusing and merging conflicting patches. The -ac tree
since 2.4.9-ac or so with Rik's actual fixes he wanted Linus to takes passes
the Red Hat test suite. 2.4.16 kind of passes it now. 

It had nothing to do with the VM being broken and everything to do with
what Linus applied. As it happens it looks like the new VM is better
performing for low loads which is good, but the whole VM mess wasn't bad QA
and wasn't bad design.

Linus was even ignoring patches that fixed comments in the VM code that
referenced old behaviour. And due to the complete lack of VM documentation
at the moment I can only assume he's been dropping Andrea's VM comments/docs 
too.

Alan

Re: Coding style - a non-issue

[Stanislav Meduna]

> The -ac tree since 2.4.9-ac or so with Rik's actual fixes
> he wanted Linus to takes passes the Red Hat test suite.
> 2.4.16 kind of passes it now. 

Is the test suite (or at least part of it) public, or is it
considered to be a trade-secret of Red Hat? I see there
is a "Red Hat Ready Test Suite" - is this a part of it?

Regards
-- 
                              Stano

Re: Coding style - a non-issue

[Alan Cox]

> Is the test suite (or at least part of it) public, or is it
> considered to be a trade-secret of Red Hat? I see there
> is a "Red Hat Ready Test Suite" - is this a part of it?

The main Red Hat test suite is a version of Cerberus (originally from VA
and much extended), its all free software and its available somewhere
although I don't have the URL to hand, Arjan ?

Re: Coding style - a non-issue

[Chris Ricker]

On Sun, 2 Dec 2001, Alan Cox wrote:

> > Is the test suite (or at least part of it) public, or is it
> > considered to be a trade-secret of Red Hat? I see there
> > is a "Red Hat Ready Test Suite" - is this a part of it?
> 
> The main Red Hat test suite is a version of Cerberus (originally from VA
> and much extended), its all free software and its available somewhere
> although I don't have the URL to hand, Arjan ?

I think it's at <http://people.redhat.com/bmatthews/cerberus/>

later,
chris

-- 
Chris Ricker                                               kaboom@gatech.edu

For if we may compare infinities, it would
seem to require a greater infinity of power
to cause the causes of effects, than to
cause the effects themselves.
        -- Erasmus Darwin

Re: Coding style - a non-issue

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Sun, 2 Dec 2001 16:57:46 +0000 (GMT)

   The main Red Hat test suite is a version of Cerberus (originally from VA
   and much extended), its all free software and its available somewhere
   although I don't have the URL to hand, Arjan ?

http://people.redhat.com/bmatthews/cerberus/

Re: Coding style - a non-issue

[Horst von Brand]

Stanislav Meduna <stano@meduna.org> said:
> "Alan Cox" at dec 01, 2001 09:18:15 said:

[...]

> > If you want a high quality, tested supported kernel which has been through
> > extensive QA then use kernel for a reputable vendor, or do the QA work
> > yourself or with other people.

> Correct. But this has one problem - it is splitting resources.
> Pushing much of the QA work later in the process means
> that the bugs are found later, that there is more people
> doing this as absolutely necessary and that much more
> communication (and this can be the most important bottleneck)
> is needed as necessary.

Have you got any idea how QA is done in closed environments?

> The need of the VM change is probably a classical example -
> why was it not clear at the 2.4.0-pre1, that the current
> implementation is broken to the point of no repair?

Perhaps because of the same phenomenon that made MS state "WinNT 4.0 has no
flaws" when asked about a nasty problem shortly after release, and it is
now at sp6a + numerous "hotfixes". Like Win2k which now has sp2. Like
Solaris, which still is being fixed. Etc, ad nauseam. Complex software
*has* bugs, bugs which aren't apparent except under unsusual circumstances
are rarely found in the first round of bug chasing.

[...]

> As a user of the vendor's kernel I have no idea what to do
> with a bug.

Report it to the vendor, through the documented channels?
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Coding style - a non-issue

[Stanislav Meduna]

Horst von Brand wrote:

> Have you got any idea how QA is done in closed environments?

Yes I do. I write commercial sofware for 10 years and have
experience with QA systems in two companies, one of them
major. I think I have seen the full range of QA in various projects -
from a complete negation to a silly buerocratic inefficient one.

> Complex software *has* bugs, bugs which aren't apparent
> except under unsusual circumstances are rarely found in the
> first round of bug chasing.

Sure. But we now have 2.4.16, not 2.4.0 and guess what? -
there is a big thread about fs corruption going right now
in the l-k  :-( This should _not_ happen in the stab{le,ilizing}
series and if it happened, the cause should be identified
and measures taken.

I for one think that the kernel has overgrown its current
development model and that some _incremental_ steps
in the direction of both more formal control and delegation
of responsibilities are needed. I think that the most active
kernel developers should discuss the future of the development
model, as they are the only ones that can really come up
with a solution.

It is of course only my opinion - if I am alone having it, forget it.

> > As a user of the vendor's kernel I have no idea what to do
> > with a bug.
> 
> Report it to the vendor, through the documented channels?

Did this. It is two months, I did some cornering of the problem
and augmented the report several times. The issue is still NEW,
without any response asking to try a patch, supply more details
or such. Yes, this speaks more of the vendor than of the Linux.
But what impression do you think the average user gets from
such experience?

Regards
-- 
                                                       Stano

Re: Coding style - a non-issue

[Horst von Brand]

"Stanislav Meduna" <stano@meduna.org> said:
> Horst von Brand wrote:

[...]

> > Complex software *has* bugs, bugs which aren't apparent
> > except under unsusual circumstances are rarely found in the
> > first round of bug chasing.

> Sure. But we now have 2.4.16, not 2.4.0 and guess what? -
> there is a big thread about fs corruption going right now
> in the l-k  :-( This should _not_ happen in the stab{le,ilizing}
> series and if it happened, the cause should be identified
> and measures taken.

Glitches _do_ happen. IIRC, there have been _less_ in 2.4.x than before
(might just be skewed perspective...).

> I for one think that the kernel has overgrown its current
> development model and that some _incremental_ steps
> in the direction of both more formal control and delegation
> of responsibilities are needed. I think that the most active
> kernel developers should discuss the future of the development
> model, as they are the only ones that can really come up
> with a solution.

Right. Or somebody has to fork off a "QA-linux". Or people should help with
QA (kernel-janitors, delelop tests, run tests and report back, ...)

[...]

> > > As a user of the vendor's kernel I have no idea what to do
> > > with a bug.
> > 
> > Report it to the vendor, through the documented channels?
> 
> Did this. It is two months, I did some cornering of the problem
> and augmented the report several times. The issue is still NEW,
> without any response asking to try a patch, supply more details
> or such. Yes, this speaks more of the vendor than of the Linux.

Change vendor. That is one of the beauties of Linux: If your vendor doesn't
get their act together, you can switch.

> But what impression do you think the average user gets from
> such experience?

Bad, no doubt. But fear not, with the "marvelous engineering" of some
vendors of closed products you wait for _years_ for fixes to severe bugs.
So in perspective Linux only looks bad. They look horrible ;-/
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Coding style - a non-issue

[Mohammad A. Haque]

On Saturday, December 1, 2001, at 03:39 , Stanislav Meduna wrote:
> Throwing releases onto the public is not testing. Saying
> "it works/does not work for me" is not testing. Testing
> is _actively_ trying to break things, _very_ preferably
> by another person that wrote the code and to do it
> in documentable and reproducible way. I don't see many
> people doing it.

If someone sent me a whole slew of hardware and provided a me with a 
steady income so I didn't have to work, I could do this. But fact of the 
matter is, most of the people working on the kernel are doing it not for 
a living, but for fun or they enjoy it. They probably don't have the 
endless fields of hardware that vendors do. If the above is what you 
want, stick with vendor releases and not Linus (or maintainer) releases.

--

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

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

Re: Coding style - a non-issue

[John Alvord]

On Sat, 1 Dec 2001 21:39:16 +0100 (CET), Stanislav Meduna
<stano@meduna.org> wrote:

>Hello,
>
>wow, what a nice discussion. I am reading the l-k through an
>archive, so please forgive me if I am going to say something
>that was already said, but I did not yet read it.
>
>
>Linus wrote:
>> Don't underestimate the power of survival of the fittest.
>
>Well, your theory is really an interesting view on the
>software development. However, I think that there are
>some points that need some more discussion.
>
>First, you are probably right in the long-term. The nature
>did have enough time for excursions in one or another
>direction - the "project" of life is several orders of magnitude
>older than a single generation. You say that it is possible
>to help the evolution. But you still need many generations
>to be sure that a good result at some stage is not only some
>statistical variance.
To make the process interesting long term, you need the periodic mass
extinction to open up ecologic windows for new development. Absent
that you would wind up stuck in some local optimum.
> 
>The technology does not IMHO work that way - Linux (Unix
>in all its flavours, Windows, ...) is very young.
>We are not in the stage where life exists for millions
>of years. We are in the stage where the first cells
>have formed and are still quite vulnerable. There is only
>a thin line between survival as a kind and extinction (sp?).
>I think that in this stage not ignoring the role of
>the design is a good thing (and no, I don't believe in God :-)).
>
>Besides that, are you talking about evolution in general,
>or about evolution of a particular kind? The competition
>is not the same in these cases.
>
>> - massive undirected parallel development ("trial and error") 
>
>This is not what is happening here. 
The current Linux environment is much like the accelerated change
observed in directed breeding... say with breeding dogs or horses...
with an "intelligence" pushing toward desired characteristics (instead
of blind nature) progress is very rapid.

john alvord

Re: Coding style - a non-issue

[Tim Hockin]

At 09:43 PM 11/30/01 -0800, Stephen Satchell wrote:

> Most of the bad-but-not-obviously-bad ideas get rooted out by people trying
> them and finding them to be wanting.  Take, for example, the VM flap in the
>
Ahh right, like the OOM killer.  There's a brilliant idea that got rooted
out to where it belongs...

> The "Linux Way" as I understand it is to release early and release
> often.  That means that we go through a "generation" of released code every

And disregard the "mutations" that have already been "selected for" (to
carry the analogy) in other systems.  And disregard any edge-case that is
"too hard" or "too rare" or "involves serious testing".

> Now that I've stretched the analogy as far as I care to, I will stop
> now.  Please consider the life-cycle of the kernel when thinking about what
> Linus said.

I can't consider joe.random developer adding a feature as a "mutation".
It's just not analogous in my mind.

RE: Coding style - a non-issue

[Galappatti, Kishantha]

i agree with that dana. Sure coding style is important but lets not get
personal here. I personally think there should be an established coding
style that should be kept to as much as possible but the way to implement
that is by helping the contributors to do so with tools etc, not by
castigating them in a "hall of shame". Isn't open source about inclusion and
creativity?
Just my opinion. 

--kish

-----Original Message-----
From: Dana Lacoste [mailto:dana.lacoste@peregrine.com]
Sent: Friday, November 30, 2001 1:19 PM
To: 'Larry McVoy'; Henning Schmiedehausen
Cc: Jeff Garzik; linux-kernel@vger.kernel.org
Subject: RE: Coding style - a non-issue


Any chance that you guys could calm down a bit?

I bet the guys in Redmond who were referred to
earlier are enjoying it, but it's just trash for
the rest of us....

> Henning, perhaps you can explain to me how the following isn't a 
> 
> 	"I don't do XYZ"
> 
> 	"XYZ"
> 
> statement?

This one I understood though :
Al made a personal attack.  He defended against the attack,
and preluded his defence with a disclaimer.

This issue has gone beyond productivity to personal name calling
and spurious defence.  Can we all just move on a bit maybe?

Thanks

--
Dana Lacoste      - Linux Developer
Peregrine Systems -  Ottawa, Canada
-
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: Coding style - a non-issue

[Dana Lacoste]

Any chance that you guys could calm down a bit?

I bet the guys in Redmond who were referred to
earlier are enjoying it, but it's just trash for
the rest of us....

> Henning, perhaps you can explain to me how the following isn't a 
> 
> 	"I don't do XYZ"
> 
> 	"XYZ"
> 
> statement?

This one I understood though :
Al made a personal attack.  He defended against the attack,
and preluded his defence with a disclaimer.

This issue has gone beyond productivity to personal name calling
and spurious defence.  Can we all just move on a bit maybe?

Thanks

--
Dana Lacoste      - Linux Developer
Peregrine Systems -  Ottawa, Canada

Re: Coding style - a non-issue

[Mohammad A. Haque]

On Friday, November 30, 2001, at 01:19 , Dana Lacoste wrote:

> This issue has gone beyond productivity to personal name calling
> and spurious defence.  Can we all just move on a bit maybe?

Heh, are you kidding, This is LKML. It's gonna be beaten into the ground 
and then some.

For what it's worth, most professional programmers I've interacted with 
always adhere to the programming style of where they are working, 
regardless of the way they personally program.
--

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

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

Coding style - a non-issue

[Peter Waltenberg]

The problem was solved years ago.

"man indent"

Someone who cares, come up with an indentrc for the kernel code, and get it
into Documentation/CodingStyle
If the maintainers run all new code through indent with that indentrc
before checkin, the problem goes away.
The only one who'll incur any pain then is a code submitter who didn't
follow the rules. (Exactly the person we want to be in pain ;)).


Then we can all get on with doing useful things.

Cheers
Peter

Re: Coding style - a non-issue

[Russell King]

On Thu, Nov 29, 2001 at 09:29:26AM +1000, Peter Waltenberg wrote:
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).

See: linux/scripts/Lindent

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

Re: Coding style - a non-issue

[Alan Cox]

> The problem was solved years ago.
> 
> "man indent"
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle

The problem was solved years ago.

scripts/Lindent

Re: Coding style - a non-issue

[Robert Love]

On Wed, 2001-11-28 at 18:29, Peter Waltenberg wrote:

> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).

See scripts/lindent in your source tree ... does just this.

	Robert Love

Re: Coding style - a non-issue

[Alexander Viro]

On Thu, 29 Nov 2001, Peter Waltenberg wrote:

> The problem was solved years ago.
> 
> "man indent"
> 
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).

indent does _not_ solve the problem of:
	* buggers who think that MyVariableIsBiggerThanYourVariable is a
good name
	* buggers who define a function with 42 arguments and body being
	return (foo == bar) ? TRUE : FALSE;
	* buggers who add 1001st broken implementation of memcmp(), call it
FooTurdCompare and prepend it with 20x80 block comment.
	* buggers who use typedefs like WORD, DWORD, BYTE, IMANIDIOTSHOOTME
and other crap from the same source (OK, they don't write the last one
explicitly - not that it wasn't obvious from the rest of their, ahem, code).
	* buggers who use Hungarian notation for no good reason and come up
with structure fields that sound like street names from R'Lyeh
	* buggers who introduce wrappers for standard kernel stuff - like,
say it, typedef int Int32; and sprinkle their crap with per-architecture
ifdefs.
	* buggers who think that cpp is Just The Thing and produce turds that
would make srb cringe in disgust.

Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
wankers (both individual and coprorat ones) responsible, their code and
commentary on said code...

Re: Coding style - a non-issue

[Larry McVoy]

> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> wankers (both individual and coprorat ones) responsible, their code and
> commentary on said code...

Please, please, please, I'm begging you, please do this.  It's the only way
people learn quickly.  Being nice is great, but nothing works faster than 
a cold shower of public humiliation :-)
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Davide Libenzi]

On Wed, 28 Nov 2001, Larry McVoy wrote:

> > Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> > wankers (both individual and coprorat ones) responsible, their code and
> > commentary on said code...
>
> Please, please, please, I'm begging you, please do this.  It's the only way
> people learn quickly.  Being nice is great, but nothing works faster than
> a cold shower of public humiliation :-)

Well, I don't know about "Hall of Shame" but having an "Hall of Flame"
without you two guys is like going at the OktoberFest being abstemious :)



- Davide

Re: Coding style - a non-issue

[Henning P. Schmiedehausen]

Larry McVoy <lm@bitmover.com> writes:

>> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
>> wankers (both individual and coprorat ones) responsible, their code and
>> commentary on said code...

>Please, please, please, I'm begging you, please do this.  It's the only way
>people learn quickly.  Being nice is great, but nothing works faster than 
>a cold shower of public humiliation :-)

Cool. I can really see it. "foo inc." releases a GPL driver for Linux
and gets publically humiliated in the "linux source code hall of
shame". Perfect. I can hear the laughter from Redmond over here (and
it is 12000km away).

Press release:

"If you support Linux, you may get flamed and humiliated in public for
doing so. Don't do it."

Grow up. There is more to life than coding style that is not "Al Viro
compatible (TM)".

Sigh, sometimes, sometimes, I _really_ understand the BSD folks when
they call the Linux community "a bunch of unkempt nerds that need to
get a life". If they only would use sane init scripts. ;-) 

	Regards
		Henning

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

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

Re: Coding style - a non-issue

[Larry McVoy]

On Fri, Nov 30, 2001 at 10:00:00AM +0000, Henning P. Schmiedehausen wrote:
> Larry McVoy <lm@bitmover.com> writes:
> 
> >> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> >> wankers (both individual and coprorat ones) responsible, their code and
> >> commentary on said code...
> 
> >Please, please, please, I'm begging you, please do this.  It's the only way
> >people learn quickly.  Being nice is great, but nothing works faster than 
> >a cold shower of public humiliation :-)
> 
> Cool. I can really see it. "foo inc." releases a GPL driver for Linux
> and gets publically humiliated in the "linux source code hall of
> shame". Perfect. I can hear the laughter from Redmond over here (and
> it is 12000km away).
> 
> Sigh, sometimes, sometimes, I _really_ understand the BSD folks when
> they call the Linux community "a bunch of unkempt nerds that need to
> get a life". 

Perhaps it would be illuminating to know that I was BSD hacker, 
and that I learned the value of this particular technique from
Sun's kernel group, who once upon a time were the best BSD group
on the planet.  It might also be illuminating to consider that 
this technique of getting people to listen is still in use at
Sun to this day.

Perhaps Sun's professionalism is not what you'd like to see here.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Henning Schmiedehausen]

On Fri, 2001-11-30 at 16:26, Larry McVoy wrote:

Hi,

> Perhaps it would be illuminating to know that I was BSD hacker, 
> and that I learned the value of this particular technique from

I know. You tell us this again and again. Please stop patronizing.

> Sun's kernel group, who once upon a time were the best BSD group
> on the planet.  It might also be illuminating to consider that 
> this technique of getting people to listen is still in use at
> Sun to this day.

It might be enlightening to you that a closed users group of SUN coders
is not compareable to a worldwide distributed environment of thousands
of people and companies.

> 
> Perhaps Sun's professionalism is not what you'd like to see here.#

You tell me, that SUN treated _CUSTOMERS_ and companies that wanted to
support SunOS 4.1.x like that? If yes, then I definitely know why they
went SysV. Surely noone wanted BSD any longer.

I would consider the internal development groups in SUN that treated
each other like this also "in need of a change". :-)

	Regards
		Henning

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

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

Re: Coding style - a non-issue

[Jeff Garzik]

The security community has shown us time and again that public shaming
is often the only way to motivate vendors into fixing security
problems.  Yes, even BSD security guys do this :)

A "Top 10 ugliest Linux kernel drivers" list would probably provide
similar motivation.

	Jeff


-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: Coding style - a non-issue

[Henning Schmiedehausen]

On Fri, 2001-11-30 at 17:47, Jeff Garzik wrote:

Hi,

> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems.  Yes, even BSD security guys do this :)
> 
> A "Top 10 ugliest Linux kernel drivers" list would probably provide
> similar motivation.

A security issue is an universal accepted problem that most of the time
has a reason and a solution.

Coding style, however, is a very personal thing that start with "shall
we use TABs or not? (Jakarta: No. Linux: Yes ...) and goes on to "Is a
preprocessor macro a good thing or not" until variable names (Al Viro:
Names with more than five letters suck. :-) Java: Non-selfdescriptive
names suck. Microsoft: Non-hungarian names suck) and so on.

And you really want to judge code just because someone likes to wrap
code in preprocessor macros or use UPPERCASE variable names? 

Come on. That's a _fundamental_ different issue than dipping vendors in
their own shit if they messed up and their box/program has a security
issue. Code that you consider ugly as hell may be seen as "easily
understandable and maintainable" by the author. If it works and has no
bugs, so what? Just because it is hard for you and me to understand (cf.
"mindboggling unwind routines in the NTFS" (I thing Jeff Merkey stated
it like this). It still seems to work quite well.

Are you willing to judge "ugliness" of kernel drivers? What is ugly? Are
Donald Beckers' drivers ugly just because they use (at least on 2.2)
their own pci helper library? Is the aic7xxx driver ugly because it
needs libdb ? Or is ugly defined as "Larry and Al don't like them"? :-)

Flaming about coding style is about as pointless as flaming someone
because he supports another sports team. There is no universal accepted
coding style. Not even in C.

	Regards
		Henning

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

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

Re: Coding style - a non-issue

[Martin Dalecki]

Henning Schmiedehausen wrote:
> Flaming about coding style is about as pointless as flaming someone
> because he supports another sports team. There is no universal accepted
> coding style. Not even in C.

Bull shit: indent -kr is the way to go. It ever was...

Re: Coding style - a non-issue

[Larry McVoy]

On Fri, Nov 30, 2001 at 06:15:28PM +0100, Henning Schmiedehausen wrote:
> On Fri, 2001-11-30 at 17:47, Jeff Garzik wrote:
> > The security community has shown us time and again that public shaming
> > is often the only way to motivate vendors into fixing security
> > problems.  Yes, even BSD security guys do this :)
> > 
> > A "Top 10 ugliest Linux kernel drivers" list would probably provide
> > similar motivation.
> 
> A security issue is an universal accepted problem that most of the time
> has a reason and a solution.
> 
> And you really want to judge code just because someone likes to wrap
> code in preprocessor macros or use UPPERCASE variable names? 

Henning, in any long lived source base, coding style is crucial.  People
who think that coding style is personal are just wrong.  Let's compare,
shall we?

Professional: the coding style at this job looks like XYZ, ok, I will now
    make my code look like XYZ.

Amateur: my coding style is better than yours.

I think that if you ask around, you'll find that the pros use a coding 
style that isn't theirs, even when writing new code.  They have evolved
to use the prevailing style in their environment.  I know that's true for
me, my original style was 4 space tabs, curly braces on their own line,
etc.  I now code the way Bill Joy codes, fondly known as Bill Joy normal
form.

Anyway, if you think any coding style is better than another, you completely
miss the point.  The existing style, whatever it is, is the style you use.
I personally despise the GNU coding style but when I make changes there,
that's what I use because it is their source base, not mine.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Daniel Phillips]

Hi Larry,

On November 30, 2001 06:27 pm, Larry McVoy wrote:
> I think that if you ask around, you'll find that the pros use a coding 
> style that isn't theirs, even when writing new code.  They have evolved
> to use the prevailing style in their environment.  I know that's true for
> me, my original style was 4 space tabs, curly braces on their own line,
> etc.  I now code the way Bill Joy codes, fondly known as Bill Joy normal
> form.

Err, because you're still working at Sun?  I'll just ignore that last little 
non sequitur, your comment about professionals adapting to the prevailing 
standards is right on.

On the other hand, the idea of a coding style hall of shame - publicly 
humiliating kernel contributers - is immature and just plain silly.  It's 
good to have a giggle thinking about it, but that's where it should stop.

--
Daniel

Re: Coding style - a non-issue

[Alexander Viro]

On Fri, 30 Nov 2001, Daniel Phillips wrote:

> On the other hand, the idea of a coding style hall of shame - publicly 
> humiliating kernel contributers - is immature and just plain silly.  It's 
> good to have a giggle thinking about it, but that's where it should stop.

Damnit, Daniel, are you deliberately trying to tempt me into doing that?

Re: Coding style - a non-issue

[Larry McVoy]

On Fri, Nov 30, 2001 at 06:49:11PM +0100, Daniel Phillips wrote:
> On the other hand, the idea of a coding style hall of shame - publicly 
> humiliating kernel contributers - is immature and just plain silly.  It's 
> good to have a giggle thinking about it, but that's where it should stop.

If you've got a more effective way of getting people to do the right thing,
lets hear it.  Remember, the goal is to protect the source base, not your,
my, or another's ego.

I used to think Sun's approach was pretty brutal, and I still do actually.
But I haven't found anything else which works as well.  I don't use that
technique at BitMover, instead I rewrite code that I find offensive.  That's
less annoying to the engineers but it is also a lot more costly in terms of
my time.  Since we're a small company, I can keep up.  When we double in
size, I won't be able to do so and I suspect we'll revert to the Sun way.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Daniel Phillips]

On November 30, 2001 07:13 pm, Larry McVoy wrote:
> On Fri, Nov 30, 2001 at 06:49:11PM +0100, Daniel Phillips wrote:
> > On the other hand, the idea of a coding style hall of shame - publicly 
> > humiliating kernel contributers - is immature and just plain silly.  It's 
> > good to have a giggle thinking about it, but that's where it should stop.
> 
> If you've got a more effective way of getting people to do the right thing,
> lets hear it.  Remember, the goal is to protect the source base, not your,
> my, or another's ego.

Yes, lead by example, it's at least as effective.  Maybe humiliation works at 
Sun, when you're getting a paycheck, but in the world of volunteer 
development it just makes people walk.

--
Daniel

Re: Coding style - a non-issue

[Larry McVoy]

On Fri, Nov 30, 2001 at 07:43:01PM +0100, Daniel Phillips wrote:
> On November 30, 2001 07:13 pm, Larry McVoy wrote:
> > On Fri, Nov 30, 2001 at 06:49:11PM +0100, Daniel Phillips wrote:
> > > On the other hand, the idea of a coding style hall of shame - publicly 
> > > humiliating kernel contributers - is immature and just plain silly.  It's 
> > > good to have a giggle thinking about it, but that's where it should stop.
> > 
> > If you've got a more effective way of getting people to do the right thing,
> > lets hear it.  Remember, the goal is to protect the source base, not your,
> > my, or another's ego.
> 
> Yes, lead by example, it's at least as effective.  

I'd like to see some data which backs up that statement.  My experience is
that that is an unsupportable statement.  You'd need to know how effective
the Sun way is, have seen multiple development organizations using that 
way and other ways, and have watched the progress.

I'm in a somewhat unique position in that I have a lot of ex-Sun engineers
using BitKeeper and I have a pretty good idea how fast they make changes.
It's a lot faster and a lot more consistent than the Linux effort, in fact,
there is no comparison.

I'm not claiming that the coding style is the source of their speed, but
it is part of the culture which is the source of their speed.

As far as I can tell, you are just asserting that leading by example is
more effective.  Am I incorrect?  Do you have data?  I have piles which
shows the opposite.

> Maybe humiliation works at 
> Sun, when you're getting a paycheck, but in the world of volunteer 
> development it just makes people walk.

Huh.  Not sure I agree with that either.  It's definitely a dicey area
but go through the archives (or your memory if it is better than mine)
and look at how the various leaders here respond to bad choices.  It's
basically public humiliation.  Linus is especially inclined to speak
his mind when he sees something bad.  And people stick around.

I think the thing you are missing is that what I am describing is a lot
like boot camp.  Someone with more knowledge and experience than you 
yells at your every mistake, you hate it for a while, and you emerge
from boot camp a stronger person with more skills and good habits as
well as a sense of pride.  If there was a way to "lead by example" and
accomplish the same goals in the same time, don't you think someone 
would have figured that out by now?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Daniel Phillips]

On November 30, 2001 08:05 pm, Larry McVoy wrote:
> Huh.  Not sure I agree with that either.  It's definitely a dicey area
> but go through the archives (or your memory if it is better than mine)
> and look at how the various leaders here respond to bad choices.  It's
> basically public humiliation.  Linus is especially inclined to speak
> his mind when he sees something bad.  And people stick around.

There's an additional pattern, you'll notice that the guys who end up wearing 
the dung are the ones with full time Linux programming jobs, who basically 
have no option but to stick around.  Do that to every newbie and after a 
while we'll have a smoking hole in the ground where Linux used to be.

A simple rule to remember is: when code is bad, criticize the code, not the 
coder.

> I think the thing you are missing is that what I am describing is a lot
> like boot camp.  Someone with more knowledge and experience than you 
> yells at your every mistake, you hate it for a while, and you emerge
> from boot camp a stronger person with more skills and good habits as
> well as a sense of pride.

Thanks, but I'll spend my summer in some other kind of camp ;-)  I'm sure it 
works for some people, but mutual respect is more what I'm used to and prefer.

> If there was a way to "lead by example" and
> accomplish the same goals in the same time, don't you think someone 
> would have figured that out by now?

Somebody did, and as hard as it is for some to fit it into their own model of 
the universe, there is somebody leading by example, not running a command 
economy but a self-organizing meritocracy.  Do we achieve the same goals in 
the same time?  Sometimes it doesn't seem like it, but because this thing 
just keeps crawling relentlessly forward on a thousand fronts, in the end we 
accomplish even more than Sun does.

--
Daniel

Re: Coding style - a non-issue

[Larry McVoy]

This is my last post on this topic, I don't think I can say more than I have.

On Fri, Nov 30, 2001 at 10:54:39PM +0100, Daniel Phillips wrote:
> On November 30, 2001 08:05 pm, Larry McVoy wrote:
> > Huh.  Not sure I agree with that either.  It's definitely a dicey area
> > but go through the archives (or your memory if it is better than mine)
> > and look at how the various leaders here respond to bad choices.  It's
> > basically public humiliation.  Linus is especially inclined to speak
> > his mind when he sees something bad.  And people stick around.
> 
> There's an additional pattern, you'll notice that the guys who end up wearing 
> the dung are the ones with full time Linux programming jobs, who basically 
> have no option but to stick around.  Do that to every newbie and after a 
> while we'll have a smoking hole in the ground where Linux used to be.
> 
> A simple rule to remember is: when code is bad, criticize the code, not the 
> coder.

Your priorities are upside down.  The code is more important than the
coder, it will outlive the coder's interest in that code.  Besides,
this isn't some touchy feely love fest, it's code.  It's suppose to
work and work well and be maintainable.  You don't get that by being
"nice", you get that by insisting on quality.  If being nice worked,
we wouldn't be having this conversation.

> > I think the thing you are missing is that what I am describing is a lot
> > like boot camp.  Someone with more knowledge and experience than you 
> > yells at your every mistake, you hate it for a while, and you emerge
> > from boot camp a stronger person with more skills and good habits as
> > well as a sense of pride.
> 
> Thanks, but I'll spend my summer in some other kind of camp ;-)  I'm sure it 
> works for some people, but mutual respect is more what I'm used to and prefer.

The problem here is that you are assuming that yelling at someone means
that you don't respect that someone.  Nothing could be further from the
truth.  If you didn't respect them enough to think you could get good 
results from them, I doubt you'd be yelling at them in the first place.
Don't confuse intense demands for excellence with a lack of respect,
that's not the case.

> > If there was a way to "lead by example" and
> > accomplish the same goals in the same time, don't you think someone 
> > would have figured that out by now?
> 
> Somebody did, and as hard as it is for some to fit it into their own model of 
> the universe, there is somebody leading by example, not running a command 
> economy but a self-organizing meritocracy.  Do we achieve the same goals in 
> the same time?  Sometimes it doesn't seem like it, but because this thing 
> just keeps crawling relentlessly forward on a thousand fronts, in the end we 
> accomplish even more than Sun does.

Bah.  Daniel, you are forgetting that I know what Sun has done first hand
and I know what Linux has done first hand.  If you think that Linux is
at the same level as Sun's OS or ever will be, you're kidding yourself.
Linux is really cool, I love it, and I use it every day.  But it's not
comparable to Solaris, sorry, not even close.  I'm not exactly known for
my love of Solaris, you know, in fact I really dislike it.  But I respect
it, it can take a licking and keep on ticking.  Linux isn't there yet
and unless the development model changes somewhat, I'll stand behind my
belief that it is unlikely to ever get there.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Andrew Morton]

Larry McVoy wrote:
> 
> Linux isn't there yet
> and unless the development model changes somewhat, I'll stand behind my
> belief that it is unlikely to ever get there.

I am (genuinely) interested in what changes you think are needed.

-

Re: Coding style - a non-issue

[rddunlap]

On Fri, 30 Nov 2001, Andrew Morton wrote:

| Larry McVoy wrote:
| >
| > Linux isn't there yet
| > and unless the development model changes somewhat, I'll stand behind my
| > belief that it is unlikely to ever get there.
|
| I am (genuinely) interested in what changes you think are needed.

Same here, regarding both development model and OS functionality,
reliability, etc.
-- 
~Randy

Re: Coding style - a non-issue

[Rik van Riel]

On Fri, 30 Nov 2001, Andrew Morton wrote:
> Larry McVoy wrote:
> > Linux isn't there yet
> > and unless the development model changes somewhat, I'll stand behind my
> > belief that it is unlikely to ever get there.
>
> I am (genuinely) interested in what changes you think are needed.

I'm very interested too, though I'll have to agree with Larry
that Linux really isn't going anywhere in particular and seems
to be making progress through sheer luck.

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[Daniel Phillips]

Hi Rik,

On December 1, 2001 01:35 am, Rik van Riel wrote:
> On Fri, 30 Nov 2001, Andrew Morton wrote:
> > Larry McVoy wrote:
> > > Linux isn't there yet
> > > and unless the development model changes somewhat, I'll stand behind my
> > > belief that it is unlikely to ever get there.
> >
> > I am (genuinely) interested in what changes you think are needed.
> 
> I'm very interested too, though I'll have to agree with Larry
> that Linux really isn't going anywhere in particular and seems
> to be making progress through sheer luck.

You just reminded me of Minnesota Fats most famous quote:

  "The more I practice, the luckier I get"

--
Daniel

Re: Coding style - a non-issue

[Linus Torvalds]

On Fri, 30 Nov 2001, Rik van Riel wrote:
>
> I'm very interested too, though I'll have to agree with Larry
> that Linux really isn't going anywhere in particular and seems
> to be making progress through sheer luck.

Hey, that's not a bug, that's a FEATURE!

You know what the most complex piece of engineering known to man in the
whole solar system is?

Guess what - it's not Linux, it's not Solaris, and it's not your car.

It's you. And me.

And think about how you and me actually came about - not through any
complex design.

Right. "sheer luck".

Well, sheer luck, AND:
 - free availability and _crosspollination_ through sharing of "source
   code", although biologists call it DNA.
 - a rather unforgiving user environment, that happily replaces bad
   versions of us with better working versions and thus culls the herd
   (biologists often call this "survival of the fittest")
 - massive undirected parallel development ("trial and error")

I'm deadly serious: we humans have _never_ been able to replicate
something more complicated than what we ourselves are, yet natural
selection did it without even thinking.

Don't underestimate the power of survival of the fittest.

And don't EVER make the mistake that you can design something better than
what you get from ruthless massively parallel trial-and-error with a
feedback cycle. That's giving your intelligence _much_ too much credit.

Quite frankly, Sun is doomed. And it has nothing to do with their
engineering practices or their coding style.

		Linus

Re: Coding style - a non-issue

[Mike Castle]

On Fri, Nov 30, 2001 at 04:50:34PM -0800, Linus Torvalds wrote:
> Well, sheer luck, AND:
>  - free availability and _crosspollination_ through sharing of "source
>    code", although biologists call it DNA.
>  - a rather unforgiving user environment, that happily replaces bad
>    versions of us with better working versions and thus culls the herd
>    (biologists often call this "survival of the fittest")
>  - massive undirected parallel development ("trial and error")

Linux is one big genetic algorithms project?

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Coding style - a non-issue

[Davide Libenzi]

On Fri, 30 Nov 2001, Mike Castle wrote:

> On Fri, Nov 30, 2001 at 04:50:34PM -0800, Linus Torvalds wrote:
> > Well, sheer luck, AND:
> >  - free availability and _crosspollination_ through sharing of "source
> >    code", although biologists call it DNA.
> >  - a rather unforgiving user environment, that happily replaces bad
> >    versions of us with better working versions and thus culls the herd
> >    (biologists often call this "survival of the fittest")
> >  - massive undirected parallel development ("trial and error")
>
> Linux is one big genetic algorithms project?

It is more subtle, look better inside :)



- Davide

Re: Coding style - a non-issue

[Jamie Lokier]

Mike Castle wrote:
> Linux is one big genetic algorithms project?

No but I'm sure the VM layer is :-)

-- Jamie

Re: Coding style - a non-issue

[Rik van Riel]

On Sat, 1 Dec 2001, Jamie Lokier wrote:
> Mike Castle wrote:
> > Linux is one big genetic algorithms project?
>
> No but I'm sure the VM layer is :-)

I guess we now know the reason Linus purposefully
makes sure no comment ever matches the code ;/

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[Daniel Phillips]

On December 1, 2001 05:27 pm, Rik van Riel wrote:
> On Sat, 1 Dec 2001, Jamie Lokier wrote:
> > Mike Castle wrote:
> > > Linux is one big genetic algorithms project?
> >
> > No but I'm sure the VM layer is :-)
> 
> I guess we now know the reason Linus purposefully
> makes sure no comment ever matches the code ;/

2.5 is now open, I'm sure Linus will take patches to fix comment bugs now.

--
Daniel

Re: Coding style - a non-issue

[Petko Manolov]

:-)) This made my day..  May be my week. :-))

100% agree (better not play gods) and i think this is the end of
the discussion.


		Petko


Linus Torvalds wrote:

> On Fri, 30 Nov 2001, Rik van Riel wrote:
> 
>>I'm very interested too, though I'll have to agree with Larry
>>that Linux really isn't going anywhere in particular and seems
>>to be making progress through sheer luck.
>>
> 
> Hey, that's not a bug, that's a FEATURE!
> 
> You know what the most complex piece of engineering known to man in the
> whole solar system is?
> 
> Guess what - it's not Linux, it's not Solaris, and it's not your car.
> 
> It's you. And me.
> 
> And think about how you and me actually came about - not through any
> complex design.
> 
> Right. "sheer luck".
> 
> Well, sheer luck, AND:
>  - free availability and _crosspollination_ through sharing of "source
>    code", although biologists call it DNA.
>  - a rather unforgiving user environment, that happily replaces bad
>    versions of us with better working versions and thus culls the herd
>    (biologists often call this "survival of the fittest")
>  - massive undirected parallel development ("trial and error")
> 
> I'm deadly serious: we humans have _never_ been able to replicate
> something more complicated than what we ourselves are, yet natural
> selection did it without even thinking.
> 
> Don't underestimate the power of survival of the fittest.
> 
> And don't EVER make the mistake that you can design something better than
> what you get from ruthless massively parallel trial-and-error with a
> feedback cycle. That's giving your intelligence _much_ too much credit.
> 
> Quite frankly, Sun is doomed. And it has nothing to do with their
> engineering practices or their coding style.
> 
> 		Linus

Re: Coding style - a non-issue

[Tim Hockin]

> I'm deadly serious: we humans have _never_ been able to replicate
> something more complicated than what we ourselves are, yet natural
> selection did it without even thinking.

a very interesting argument, but not very pertinent - we don't have 10's of
thousands of year or even really 10's of years.  We have to use intellect
to root out the obviously bad ideas, and even more importantly the
bad-but-not-obviously-bad ideas.

> Quite frankly, Sun is doomed. And it has nothing to do with their
> engineering practices or their coding style.

I'd love to hear your thoughts on why.

Re: Coding style - a non-issue

[Linus Torvalds]

On Fri, 30 Nov 2001, Tim Hockin wrote:
>
> > I'm deadly serious: we humans have _never_ been able to replicate
> > something more complicated than what we ourselves are, yet natural
> > selection did it without even thinking.
>
> a very interesting argument, but not very pertinent - we don't have 10's of
> thousands of year or even really 10's of years.  We have to use intellect
> to root out the obviously bad ideas, and even more importantly the
> bad-but-not-obviously-bad ideas.

Directed evolution - ie evolution that has more specific goals, and faster
penalties for perceived failure, works on the scale of tens or hundreds of
years, not tens of thousands. Look at dog breeding, but look even more at
livestock breeding, where just a few decades have made a big difference.

The belief that evolution is necessarily slow is totally unfounded.

HOWEVER, the belief that _too_ much direction is bad is certainly not
unfounded: it tends to show up major design problems that do not show up
with less control. Again, see overly aggressive breeding of some dogs
causing bad characteristics, and especially the poultry industry.

And you have to realize that the above is with entities that are much more
complex than your random software project, and where historically you have
not been able to actually influence anything but selection itself.

Being able to influence not just selection, but actually influencing the
_mutations_ that happen directly obviously cuts down the time by another
large piece.

In short, your comment about "not pertinent" only shows that you are
either not very well informed about biological changes, or, more likely,
it's just a gut reaction without actually _thinking_ about it.

Biological evolution is alive and well, and does not take millions of
years to make changes. In fact, most paleolontologists consider some of
the changes due to natural disasters to have happened susprisingly fast,
even in the _absense_ of "intelligent direction".

Of course, at the same time evolution _does_ heavily tend to favour
"stable" life-forms (sharks and many amphibians have been around for
millions of years). That's not because evolution is slow, but simply
because good lifeforms work well in their environments, and if the
environment doesn't change radically they have very few pressures to
change.

There is no inherent "goodness" in change. In fact, there are a lot of
reasons _against_ change, something we often forget in technology. The
fact that evolution is slow when there is no big reason to evolve is a
_goodness_, not a strike against it.

> > Quite frankly, Sun is doomed. And it has nothing to do with their
> > engineering practices or their coding style.
>
> I'd love to hear your thoughts on why.

You heard them above. Sun is basically inbreeding. That tends to be good
to bring out specific characteristics of a breed, and tends to be good for
_specialization_. But it's horrible for actual survival, and generates a
very one-sided system that does not adapt well to change.

Microsoft, for all the arguments against them, is better off simply
because of the size of its population - they have a much wider consumer
base, which in turn has caused them largely to avoid specialization. As a
result, Microsoft has a much wider appeal - and suddenly most of the
niches that Sun used to have are all gone, and its fighting for its life
in many of its remaining ones.

Why do you think Linux ends up being the most widely deployed Unix? It's
avoided niches, it's avoided inbreeding, and not being too directed means
that it doesn't get the problems you see with unbalanced systems.

Face it, being one-sided is a BAD THING. Unix was dying because it was
becoming much too one-sided.

Try to prove me wrong.

		Linus

Re: Coding style - a non-issue

[Horst von Brand]

Tim Hockin <thockin@hockin.org> said:
> "Linus Torvalds" at Nov 30, 2001 04:50:34 PM said:
> > I'm deadly serious: we humans have _never_ been able to replicate
> > something more complicated than what we ourselves are, yet natural
> > selection did it without even thinking.
> 
> a very interesting argument, but not very pertinent - we don't have 10's of
> thousands of year or even really 10's of years.  We have to use intellect
> to root out the obviously bad ideas, and even more importantly the
> bad-but-not-obviously-bad ideas.

If you look at what people in the evolutionistic algorithms camp are doing,
you'll see them consider "mutations" that force movement in the "best"
direction (steepest ascent), not just at random, and similarly other
"intelligent" genetic operators.

In any case, what Linus is saying isn't just "go and change stuff at
random" either..., this is clearly a metaphor. An apt one.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Coding style - a non-issue

[Victor Yodaiken]

On Fri, Nov 30, 2001 at 04:50:34PM -0800, Linus Torvalds wrote:
> 
> You know what the most complex piece of engineering known to man in the
> whole solar system is?
> 
> Guess what - it's not Linux, it's not Solaris, and it's not your car.
> 
> It's you. And me.
> 
> And think about how you and me actually came about - not through any
> complex design.
> 
> Right. "sheer luck".

Somehow this does not give me a warm and fuzzy feeling about
the length of the next Linux kernel development cycle. 

> And don't EVER make the mistake that you can design something better than
> what you get from ruthless massively parallel trial-and-error with a
> feedback cycle. That's giving your intelligence _much_ too much credit.

Linux is what it is because of design, not accident. And you know
that better than anyone.
If mindless rooting about could make a good OS,  then we'd all be using 
[ in a rare moment of good sense I don't finish this sentence ]

The question is whether Linux can still be designed at
current scale.




> Quite frankly, Sun is doomed. And it has nothing to do with their
> engineering practices or their coding style.

The San Andreas fault? 

Re: Coding style - a non-issue

[Linus Torvalds]

On Fri, 30 Nov 2001, Victor Yodaiken wrote:
>
> > And don't EVER make the mistake that you can design something better than
> > what you get from ruthless massively parallel trial-and-error with a
> > feedback cycle. That's giving your intelligence _much_ too much credit.
>
> Linux is what it is because of design, not accident. And you know
> that better than anyone.

Let's just be honest, and admit that it wasn't designed.

Sure, there's design too - the design of UNIX made a scaffolding for the
system, and more importantly it made it easier for people to communicate
because people had a mental _model_ for what the system was like, which
means that it's much easier to discuss changes.

But that's like saying that you know that you're going to build a car with
four wheels and headlights - it's true, but the real bitch is in the
details.

And I know better than most that what I envisioned 10 years ago has
_nothing_ in common with what Linux is today. There was certainly no
premeditated design there.

And I will claim that nobody else "designed" Linux any more than I did,
and I doubt I'll have many people disagreeing. It grew. It grew with a lot
of mutations - and because the mutations were less than random, they were
faster and more directed than alpha-particles in DNA.

> The question is whether Linux can still be designed at
> current scale.

Trust me, it never was.

And I will go further and claim that _no_ major software project that has
been successful in a general marketplace (as opposed to niches) has ever
gone through those nice lifecycles they tell you about in CompSci classes.
Have you _ever_ heard of a project that actually started off with trying
to figure out what it should do, a rigorous design phase, and a
implementation phase?

Dream on.

Software evolves. It isn't designed. The only question is how strictly you
_control_ the evolution, and how open you are to external sources of
mutations.

And too much control of the evolution will kill you. Inevitably, and
without fail. Always. In biology, and in software.

Amen.

		Linus

Re: Coding style - a non-issue

[Larry McVoy]

On Fri, Nov 30, 2001 at 07:15:55PM -0800, Linus Torvalds wrote:
> > The question is whether Linux can still be designed at
> > current scale.
> 
> Trust me, it never was.

Yeah, right, Linus.  We should all go home and turn loose the monkeys and
let them pound on the keyboard.  They'll just as good a job, in fact, by
your reasoning they'll get there faster, they aren't so likely to waste
time trying to design it.

I can't believe the crap you are spewing on this one and I don't think you
do either.  If you do, you need a break.  I'm all for letting people explore,
let software evolve, that's all good.  But somebody needs to keep an eye on
it.

If that's not true, Linus, then bow out.   You aren't needed and *you*
just proved it.  You can't have it both ways.  Either you are here
for a reason or you aren't.  So which is it?  You're arguing that you
don't matter.  I personally don't agree, I think Linux would be a pile
of dog doo without you.  If you don't agree, back off and see what happens.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Linus Torvalds]

On Fri, 30 Nov 2001, Larry McVoy wrote:
>
> I can't believe the crap you are spewing on this one and I don't think you
> do either.  If you do, you need a break.  I'm all for letting people explore,
> let software evolve, that's all good.  But somebody needs to keep an eye on
> it.

Like somebody had to keep an eye on our evolution so that you had a chance
to be around?

Who's naive?

> If that's not true, Linus, then bow out.   You aren't needed and *you*
> just proved it.

Oh, absolutely.

I wish more people realized it. Some people realize it only when they get
really pissed off at me and say "Go screw yourself, I can do this on my
own". And you know what? They are right too, even if they come to that
conclusion for what I consider the wrong reasons.

The reason I'm doing Linux is not because I think I'm "needed". It's
because I enjoy it, and because I happen to believe that I'm better than
most at it. Not necessarily better than everybody else around there, but
good enough, and with the social ties to make me unbeatable right now.

But "indispensable"? Grow up, Larry. You give me too much credit.

And why should I bow out just because I'm not indispenable? Are you
indispensable for the continued well-being of humanity? I believe not,
although you are of course free to disagree. Should you thus "bow out" of
your life just because you're strictly speaking not really needed?

Do I direct some stuff? Yes. But, quite frankly, so do many others. Alan
Cox, Al Viro, David Miller, even you. And a lot of companies, which are
part of the evolution whether they realize it or not. And all the users,
who end up being part of the "fitness testing".

And yes, I actually do believe in what I'm saying.

		Linus

Re: Coding style - a non-issue

[Daniel Phillips]

On December 1, 2001 04:30 am, Larry McVoy wrote:
> I can't believe the crap you are spewing on this one and I don't think you
> do either.  If you do, you need a break.  I'm all for letting people 
> explore, let software evolve, that's all good.  But somebody needs to keep 
> an eye on it.
> 
> If that's not true, Linus, then bow out.   You aren't needed and *you*
> just proved it.  You can't have it both ways.  Either you are here
> for a reason or you aren't.  So which is it?  You're arguing that you
> don't matter.  I personally don't agree, I think Linux would be a pile
> of dog doo without you.  If you don't agree, back off and see what happens.

If you've been involved in any design sessions with Linus - if you could even 
grace them with that name - you know he relies way more on intuition than 
process.  Actually, far from taking the role of the omniscient creator, he 
tends to act more like the survival test.  Not that he's short of the 
necessary skills to do it your way.  I think he does it the way he does it 
because it's fun and interesting and, oh yes, effective.

--
Daniel

Re: Coding style - a non-issue

[Victor Yodaiken]

On Fri, Nov 30, 2001 at 07:15:55PM -0800, Linus Torvalds wrote:
> And I will claim that nobody else "designed" Linux any more than I did,
> and I doubt I'll have many people disagreeing. It grew. It grew with a lot
> of mutations - and because the mutations were less than random, they were
> faster and more directed than alpha-particles in DNA.

Ok. There was no design, just "less than random mutations". 
Deep. 

There was a overall architecture, from Dennis and Ken. There
where a couple of good sound design principles, and there were a 
couple of people with some sense of how it should work together.
None of that is incompatible with lots of trial and error and learn
by doing.

Here's a characteristic good Linux design method ,( or call it "less than random
mutation method" if that makes you feel happy): read the literature,
think hard, try something, implement
it, find it doesn't do what was hoped and tear the whole thing down.
That's design. Undesigned systems use the method of: implement some crap and then try to
engineer the consequences away. 

> 
> > The question is whether Linux can still be designed at
> > current scale.
> 
> Trust me, it never was.

Trust you? Ha.

> And I will go further and claim that _no_ major software project that has
> been successful in a general marketplace (as opposed to niches) has ever
> gone through those nice lifecycles they tell you about in CompSci classes.

That's classic:
	A) "trust me"
	B) now here's a monster bit of misdirection for you to choke on.

Does anyone believe in those stupid software lifcycles?
No.
So does it follow that this has anything to do with design?
No.


> Have you _ever_ heard of a project that actually started off with trying
> to figure out what it should do, a rigorous design phase, and a
> implementation phase?
> 
> Dream on.

I've seen better arguments in slashdot. 

There was no puppet master - ok.
There was no step by step recipe that showed how it should all work - ok
There was no design involved - nope.

Re: Coding style - a non-issue

[Linus Torvalds]

On Fri, 30 Nov 2001, Victor Yodaiken wrote:
>
> Ok. There was no design, just "less than random mutations".
> Deep.

I'm not claiming to be deep, I'm claiming to do it for fun.

I _am_ claiming that the people who think you "design" software are
seriously simplifying the issue, and don't actually realize how they
themselves work.

> There was a overall architecture, from Dennis and Ken.

Ask them. I'll bet you five bucks they'll agree with me, not with you.
I've talked to both, but not really about this particular issue, so I
might lose, but I think I've got the much better odds.

If you want to see a system that was more thoroughly _designed_, you
should probably point not to Dennis and Ken, but to systems like L4 and
Plan-9, and people like Jochen Liedtk and Rob Pike.

And notice how they aren't all that popular or well known? "Design" is
like a religion - too much of it makes you inflexibly and unpopular.

The very architecture of UNIX has very much been an evolution. Sure, there
are some basic ideas, but basic ideas do not make a system.

When they say that the devil is in the details, they are trying to tell
you that the details MATTER. In fact, the details matter quite a lot more
than the design ever does.

> Here's a characteristic good Linux design method ,( or call it "less than random
> mutation method" if that makes you feel happy): read the literature,
> think hard, try something, implement

Hah.

I don't think I've seen very many examples of that particular design
methodology.

It's impressive that you think this is how stuff gets done, but from
personal experience I would say that it's certainly not true to any
noticeable degree. The impressive part is that Linux development could
_look_ to anybody like it is that organized.

Yes, people read literature too, but that tends to be quite spotty. t's
done mainly for details like TCP congestion control timeouts etc - they
are _important_ details, but at the same time we're talking about a few
hundred lines out of 20 _million_.

And no, I'm no tclaiming that the rest is "random". But I _am_ claiming
that there is no common goal, and that most development ends up being done
for fairly random reasons - one persons particular interest or similar.

It's "directed mutation" on a microscopic level, but there is very little
macroscopic direction. There are lots of individuals with some generic
feeling about where they want to take the system (and I'm obviously one of
them), but in the end we're all a bunch of people with not very good
vision.

And that is GOOD.

A strong vision and a sure hand sound like good things on paper. It's just
that I have never _ever_ met a technical person (including me) whom I
would trust to know what is really the right thing to do in the long run.

Too strong a strong vision can kill you - you'll walk right over the edge,
firm in the knowledge of the path in front of you.

I'd much rather have "brownian motion", where a lot of microscopic
directed improvements end up pushing the system slowly in a direction that
none of the individual developers really had the vision to see on their
own.

And I'm a firm believer that in order for this to work _well_, you have to
have a development group that is fairly strange and random.

To get back to the original claim - where Larry idolizes the Sun
engineering team for their singlemindedness and strict control - and the
claim that Linux seems ot get better "by luck": I really believe this is
important.

The problem with "singlemindedness and strict control" (or "design") is
that it sure gets you from point A to point B in a much straighter line,
and with less expenditure of energy, but how the HELL are you going to
consistently know where you actually want to end up? It's not like we know
that B is our final destination.

In fact, most developers don't know even what the right _intermediate_
destinations are, much less the final one. And having somebody who shows
you the "one true path" may be very nice for getting a project done, but I
have this strong belief that while the "one true path" sometimes ends up
being the right one (and with an intelligent leader it may _mostly_ be the
right one), every once in a while it's definitely the wrong thing to do.

And if you only walk in single file, and in the same direction, you only
need to make one mistake to die.

In contrast, if you walk in all directions at once, and kind of feel your
way around, you may not get to the point you _thought_ you wanted, but you
never make really bad mistakes, because you always ended up having to
satisfy a lot of _different_ opinions. You get a more balanced system.

This is what I meant by inbreeding, and the problem that UNIX
traditionally had with companies going for one niche.

(Linux companies also tend to aim for a niche, but they tend to aim for
_different_ niches, so the end result is the very "many different
directions" that I think is what you _want_ to have to survive).

> > And I will go further and claim that _no_ major software project that has
> > been successful in a general marketplace (as opposed to niches) has ever
> > gone through those nice lifecycles they tell you about in CompSci classes.
>
> That's classic:
> 	A) "trust me"
> 	B) now here's a monster bit of misdirection for you to choke on.
>
> Does anyone believe in those stupid software lifcycles?
> No.
> So does it follow that this has anything to do with design?
> No.

Hey, the whole _notion_ of "design" is that you know what you're going to
write, and you design for it.

Or do you have some other meaning of the word "design" that I haven't
heard about.

		Linus

Re: Coding style - a non-issue

[Daniel Phillips]

On December 1, 2001 06:15 am, Linus Torvalds wrote:
> On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> > Here's a characteristic good Linux design method ,( or call it "less than 
> > random mutation method" if that makes you feel happy): read the 
> > literature, think hard, try something, implement
> 
> Hah.
> 
> I don't think I've seen very many examples of that particular design
> methodology.

I do it a little differently: think hard, try something, implement, read the 
literature, repeat as necessary.

--
Daniel

Re: Coding style - a non-issue

[Victor Yodaiken]

On Sat, Dec 01, 2001 at 07:13:55AM +0100, Daniel Phillips wrote:
> On December 1, 2001 06:15 am, Linus Torvalds wrote:
> > On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> > > Here's a characteristic good Linux design method ,( or call it "less than 
> > > random mutation method" if that makes you feel happy): read the 
> > > literature, think hard, try something, implement
> > 
> > Hah.
> > 
> > I don't think I've seen very many examples of that particular design
> > methodology.
> 
> I do it a little differently: think hard, try something, implement, read the 
> literature, repeat as necessary.

Ordering is not key in this recipe.

Re: Coding style - a non-issue

[Daniel Phillips]

On December 1, 2001 09:17 pm, Victor Yodaiken wrote:
> On Sat, Dec 01, 2001 at 07:13:55AM +0100, Daniel Phillips wrote:
> > On December 1, 2001 06:15 am, Linus Torvalds wrote:
> > > On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> > > > Here's a characteristic good Linux design method ,( or call it "less than 
> > > > random mutation method" if that makes you feel happy): read the 
> > > > literature, think hard, try something, implement
> > > 
> > > Hah.
> > > 
> > > I don't think I've seen very many examples of that particular design
> > > methodology.
> > 
> > I do it a little differently: think hard, try something, implement, read the 
> > literature, repeat as necessary.
> 
> Ordering is not key in this recipe.

Right, I'm just saying that's how I typically do it.  A decade ago I'd 
probably have put the 'try something' first, and a decade before that,
'read the litature'.

--
Daniel

Re: Coding style - a non-issue

[Victor Yodaiken]

On Fri, Nov 30, 2001 at 09:15:50PM -0800, Linus Torvalds wrote:
> 
> On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> >
> > Ok. There was no design, just "less than random mutations".
> > Deep.
> 
> I'm not claiming to be deep, I'm claiming to do it for fun.
> 
> I _am_ claiming that the people who think you "design" software are
> seriously simplifying the issue, and don't actually realize how they
> themselves work.

Just to make sure we are speaking the same language, here is what the
Oxford English Dictionary sez
	Design: (1) a plan or scheme conceived in the mind; a project.
	        ...
		(2) a purpose, an intention, an aim
		...
		(3) an end in view, a goal
		...
		(4) A preliminary sketch, a plan or pattern

For the verb we get things like: "draw, sketch, outline, delineate"

> 
> > There was a overall architecture, from Dennis and Ken.
> 
> Ask them. I'll bet you five bucks they'll agree with me, not with you.
> I've talked to both, but not really about this particular issue, so I
> might lose, but I think I've got the much better odds.

You're on.  Send me the $5.
Here's what Dennis Ritchie wrote in his preface to the re-issued Lions
book:
	"you will see in the code an underlying structure that has
	lasted a long time and has managed to accomodate vast changes
	in the computing environment"


> If you want to see a system that was more thoroughly _designed_, you
> should probably point not to Dennis and Ken, but to systems like L4 and
> Plan-9, and people like Jochen Liedtk and Rob Pike.

You appear to be using "design" to mean "complete specification". 
See above.

> 
> And notice how they aren't all that popular or well known? "Design" is
> like a religion - too much of it makes you inflexibly and unpopular.

Memory fades with age, as I know from sad experience, but try to
remember who wrote things like:

	|
	|However, I still would not call "pthreads" designed. 
	|
	|Engineered. Even well done for what it tried to do. But not "Designed".
	|
	|This is like VMS. It was good, solid, engineering. Design? Who needs
	|design? It _worked_.
	|
	|But that's not how UNIX is or should be.  There was more than just
	|engineering in UNIX.  There was Design with a capital "D".  Notions of
	|"process" vs "file", and things that transcend pure engineering.
	|Minimalism.
	|
	|In the end, it comes down to aesthetics.  pthreads is "let's solve a
	|problem".  But it's not answering the big questions in the universe. 
	|It's not asking itself "what is the underlying _meaning_ of threads?".
	|"What is the big picture?".

Some academic twit, no doubt, with no understanding or experience in
actually making a blue collar OS really work.
The same fool once wrote:

> Think about WHY our system call latency beats everybody else on the
> planet. Think about WHY Linux is fast. It's because it's designed
> right.


Please send the $5 soon.

Re: Coding style - a non-issue

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 30.11.01 in <Pine.LNX.4.33.0111302048200.1459-100000@penguin.transmeta.com>:

> On Fri, 30 Nov 2001, Victor Yodaiken wrote:

> > Here's a characteristic good Linux design method ,( or call it "less than
> > random mutation method" if that makes you feel happy): read the
> > literature, think hard, try something, implement
>
> Hah.
>
> I don't think I've seen very many examples of that particular design
> methodology.

Recently, that seems to get popular in gcc. Sometimes, on gc@gcc.gnu.org,  
you'll see a whole thread where people throw one literature reference  
after another at each other.

Maybe a whole 3% of the traffic.


MfG Kai

Re: Coding style - a non-issue

[Davide Libenzi]

On Fri, 30 Nov 2001, Linus Torvalds wrote:

>
> On Fri, 30 Nov 2001, Victor Yodaiken wrote:
> >
> > Ok. There was no design, just "less than random mutations".
> > Deep.
>
> I'm not claiming to be deep, I'm claiming to do it for fun.
>
> I _am_ claiming that the people who think you "design" software are
> seriously simplifying the issue, and don't actually realize how they
> themselves work.
>
> > There was a overall architecture, from Dennis and Ken.
>
> Ask them. I'll bet you five bucks they'll agree with me, not with you.
> I've talked to both, but not really about this particular issue, so I
> might lose, but I think I've got the much better odds.
>
> If you want to see a system that was more thoroughly _designed_, you
> should probably point not to Dennis and Ken, but to systems like L4 and
> Plan-9, and people like Jochen Liedtk and Rob Pike.
>
> And notice how they aren't all that popular or well known? "Design" is
> like a religion - too much of it makes you inflexibly and unpopular.

The most successful software have born from fixing/patching an
initial/simple implementation while the greatest software failures
have born from deep planning and design.
And for successful I mean widely used/apreciated/longlived.
You start with a very limited ( in features ) initial version, people
happen to like it, you sell/distribute it and they're going to ask for new
features.
Some of these new features will fit the initial design some other will
make you patching it in an undesigned way, but you think that you'll fix
it later.
But people are going to like it even more and become more hungry of new
features, some of them will fit in the initial implementation design some
other will introduce crappy patching, but later time is fix time.
And so on.
What is the deep thought in this, it's that if you've time for deep
planning/design it means that nobody is actually using your software and
when your cutting edge, well designed implementation will see the light,
noone is gonna use it because they've already embraced something else.
Not cutting edge, not really deeply designed but a fu*king working real
software that is solving real problems for the 99% of its users.




- Davide

Re: Coding style - a non-issue

[Lars Brinkhoff]

Davide Libenzi <davidel@xmailserver.org> writes:
> What is the deep thought in this, it's that if you've time for deep
> planning/design it means that nobody is actually using your software
> and when your cutting edge, well designed implementation will see
> the light, noone is gonna use it because they've already embraced
> something else.

Also known as "Worse is Better":

  http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html

-- 
Lars Brinkhoff          http://lars.nocrew.org/     Linux, GCC, PDP-10
Brinkhoff Consulting    http://www.brinkhoff.se/    programming

Re: Coding style - a non-issue

[Ingo Molnar]

On Fri, 30 Nov 2001, Linus Torvalds wrote:

> It's "directed mutation" on a microscopic level, but there is very
> little macroscopic direction. There are lots of individuals with some
> generic feeling about where they want to take the system (and I'm
> obviously one of them), but in the end we're all a bunch of people
> with not very good vision.

the fundamental reasons why this happens are the following, special
conditions of our planet:

 - the human brain has a limited capacity, both in terms of 'storage'
   and 'computational power'.

 - the world itself, at least how we understand it currently, is
   inherently random. (Such randomness is the main driving force of
   'structure' as well, it seems.)

 - this planet has limited resources, so 'survival of the fittest' is
   still the main driving force of 'life'.

 - we do not know and understand the rules of our world yet, and chip
   technology (which drives and enables operating systems) is right at the
   edge (and often beyond the edge) of what physics is capable of
   explaining today. We simply do not know what breakthrough (or brick
   wall of performance) might happen in 1, 2 or 5 years. We did not know
   50 years ago that something like 'SMP' would happen and be commonplace
   these days. I mean, often we dont even know what might happen in the
   next minute.

due to these fundamental issues the development of 'technology' becomes
very, very unpredictable. We only have 5 billion brain cells, and there's
no upgrade path for the time being. Software projects such as Linux are
already complex enough to push this limit. And the capacity limits of the
human brain, plus the striving towards something better (driven by human
needs) cause thousands of ambitios people working on parts of Linux in
parallel.

a few things are clear:

- if we knew the rules of this world and knew how to apply them to every
  detail then we'd be building the 'perfect chip' by this christmas, and
  there would probably be no need for anything else, ever.

- if the human brain (and human fingers) had no limits then we'd be
  designing the 'perfect OS' from grounds up and write it in 2 minutes.

- and if the world wasnt random then there would probably be nothing
  on this planet, ever.

but the reality is that we humans have severe limits, and we do not
understand this random world yet, so we'll unevitably have lots of fun
writing random pieces of Linux (or other) code in many many years to come.

in fact, most computer science books are a glaring example of how limited
the human brain is, and how small and useless part of the world we are
able to explain exactly ;-)

and frankly, i'd *very* disappointed if it was possible to predict the
future beyond our lifetime, and if it was possible to design a perfect
enough OS that does not need any changing in the foreseable future. I'd be
a pretty disappointed and bored person, because someone would predict what
happens and we'd only be dumbly following that grand plan. But the reality
is that such grand plan does not exist. One of the exciting things about
developing an OS is that we almost never know what's around the next
corner.

This whole effort called Linux might look structured on the micro-level
(this world *does* appear to have some rules apart of chaos), but it
simply *cannot* be anything better than random on the macro (longterm)
level. So we better admit this to ourselves and adapt to it.

And anyone who knows better knows something that is worth a dozen Nobel
prizes.

	Ingo

Re: Coding style - a non-issue

[Rik van Riel]

On Sun, 2 Dec 2001, Ingo Molnar wrote:

> This whole effort called Linux might look structured on the micro-level
> (this world *does* appear to have some rules apart of chaos), but it
> simply *cannot* be anything better than random on the macro (longterm)
> level. So we better admit this to ourselves and adapt to it.

Note that this screams for some minimal kind of modularity
on the source level, trying to limit the "magic" to as small
a portion of the code base as possible.

Also, natural selection tends to favour the best return/effort
ratio, not the best end result. Letting a kernel take shape
due to natural selection pressure could well result in a system
which is relatively simple, works well for 95% of the population,
has the old cruft level at the upper limit of what's deemed
acceptable and completely breaks for the last 5% of the population.

That is, unless we give those last 5% of the population baseball
bats and Linus his house address, in which case there is some
biological pressure to merge the fixes needed for those folks ;)

regards,

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[Ingo Molnar]

On Sun, 2 Dec 2001, Rik van Riel wrote:

> Note that this screams for some minimal kind of modularity on the
> source level, trying to limit the "magic" to as small a portion of the
> code base as possible.

Linux is pretty modular. It's not dogmatically so, nor does it attempt to
guarantee absolute or externally visible modularity, but most parts of it
are pretty modular.

> Also, natural selection tends to favour the best return/effort ratio,
> not the best end result. [...]

there is no 'effort' involved in evolution. Nature does not select along
the path we went. It's exactly this property why it took 5 billion years
to get here, while Linux took just 10 years to be built from grounds up.
The fact is that bacteria took pretty random paths for 2 billion years to
get to the next level. That's alot of 'effort'. So *once* we have
something that is better, it does not matter how long it took to get
there.

( This kind of 'development effort' is not the same as 'robustness', ie.
the amount of effort needed to keep it at the complexity level it is,
against small perturbations in the environment - but that is a different
kind of effort. )

> [...] Letting a kernel take shape due to natural selection pressure
> could well result in a system which is relatively simple, works well
> for 95% of the population, has the old cruft level at the upper limit
> of what's deemed acceptable and completely breaks for the last 5% of
> the population.

no. An insect that is 95.1% effective digesting banana leafs in the jungle
will completely eradicate a competing insect that is 95.0% effective
digesting banana leaves, within a few hundred generations. (provided both
insects have exactly the same parameters otherwise.) And it does not
matter whether it took 100 million years to get to 95.1%, or just one
lucky set of alpha particles hitting a specific DNA part of the original
insect.

	Ingo

Re: Coding style - a non-issue

[Daniel Phillips]

On December 2, 2001 09:12 pm, Ingo Molnar wrote:
> On Sun, 2 Dec 2001, Rik van Riel wrote:
> > Also, natural selection tends to favour the best return/effort ratio,
> > not the best end result. [...]
> 
> there is no 'effort' involved in evolution. Nature does not select along
> the path we went. It's exactly this property why it took 5 billion years
> to get here, while Linux took just 10 years to be built from grounds up.
> The fact is that bacteria took pretty random paths for 2 billion years to
> get to the next level. That's alot of 'effort'.

One fact that is often missed by armchair evolutionists is that evolution is 
not random.  It's controlled by a mechanism (most obviously: gene shuffling) 
and the mechanism *itself* evolves.  That is why evolution speeds up over 
time.  There's a random element, yes, but it's not the principle element.

The fact that Linux has evolved from nothing to what it is in a mere 10 years 
- 30 if you count the 20 years of Unix that came before it - is due entirely 
to the fact that Nature has evolved a very efficient mechanism (us) to guide 
Linux's evolution.

> So *once* we have something that is better, it does not matter how long it 
> took to get there.

Sure, once you are better than the other guy you're going to eat his lunch.  
But time does matter: a critter that fails to get its evolutionary tail in 
gear before somebody eats its lunch isn't going to get a second chance.

--
Daniel

Re: Coding style - a non-issue

[Stephan von Krawczynski]

On Sun, 2 Dec 2001 19:41:26 +0100
Daniel Phillips <phillips@bonn-fries.net> wrote:

> One fact that is often missed by armchair evolutionists is that evolution is 
> not random.  It's controlled by a mechanism (most obviously: gene shuffling) 
> and the mechanism *itself* evolves.  That is why evolution speeds up over 
> time.  There's a random element, yes, but it's not the principle element.

You mean "controlled" up to the point where your small environment got randomly
hit by a smaller sized stone coming right from the nowhere corner of the
universe, or not?

Regards,
Stephan

Re: Coding style - a non-issue

[Daniel Phillips]

On December 2, 2001 08:04 pm, Stephan von Krawczynski wrote:
> On Sun, 2 Dec 2001 19:41:26 +0100
> Daniel Phillips <phillips@bonn-fries.net> wrote:
> 
> > One fact that is often missed by armchair evolutionists is that evolution is 
> > not random.  It's controlled by a mechanism (most obviously: gene shuffling) 
> > and the mechanism *itself* evolves.  That is why evolution speeds up over 
> > time.  There's a random element, yes, but it's not the principal element.
> 
> You mean "controlled" up to the point where your small environment got randomly
> hit by a smaller sized stone coming right from the nowhere corner of the
> universe, or not?

See "principal" above.  There's a random element in the game of bridge, too,
but it's not the principal element.

--
Daniel

Re: Coding style - a non-issue

[Stephan von Krawczynski]

On Sun, 2 Dec 2001 20:17:33 +0100
Daniel Phillips <phillips@bonn-fries.net> wrote:

> > You mean "controlled" up to the point where your small environment got
randomly
> > hit by a smaller sized stone coming right from the nowhere corner of the
> > universe, or not?
> 
> See "principal" above.  There's a random element in the game of bridge, too,
> but it's not the principal element.

Please name another planet where your controlling principle is proven to even
exist.

For a being that is located on a "very small stage in a vast cosmic arena"
(Carl Sagan) you have a very strong opinion about the big picture. How come you
think you are able to _see_ it at all? 
Wouldn't it be more accurate to simply admit, we _can't_ see it (at least
currently) and therefore it must be referred to as _random_? Obviously nobody
is hindered to try to find more pixels of the big picture. But shouldn't one
keep in mind that the picture is possibly _very_ big, compared to oneself and
the levels of complexity we are adjusted to.

A dropped stone is possibly only falling _down_ relative to _your_ personal
point of view.

Regards,
Stephan

Re: Coding style - a non-issue

[Ingo Molnar]

On Sun, 2 Dec 2001, Daniel Phillips wrote:

> One fact that is often missed by armchair evolutionists is that
> evolution is not random. It's controlled by a mechanism (most
> obviously: gene shuffling) and the mechanism *itself* evolves. That is
> why evolution speeds up over time. There's a random element, yes, but
> it's not the principle element.

claiming that the randomness is not the principle element of evolution is
grossly incorrect.

there are two components to the evolution of species: random mutations and
a search of the *existing* gene space called gene shuffling. (to be more
exact gene shuffling is only possible for species that actually do it -
bacteria dont.)

In fact gene shuffling in modern species is designed to 'search for useful
features rewarded by the environment to combine them in one specimen'. Ie.
the combination of useful features such as 'feathers' or 'wings',
introduced as random mutations of dinosaurs. Gene shuffling does not
result in radically new features.

gene shuffling is just the following rule: 'combine two successful DNA
chains more or less randomly to find out whether we can get the better
genes of the two.'. Since most species reproduce more than once, random
gene shuffling has a chance of combining the best possible genes. Risking
oversimplification, i'd say that genes are in essence invariant 'modules'
of a species' genetic plan, which can be intermixed between entities
without harming basic functionality. A requirement of the gene shuffling
process is that the resulting entity has to remain compatible enough with
the source entities to be able to reproduce itself and intermix its genes
with the original gene pool.

in terms of Linux, various new genes are similar to various patches that
improve the kernel. Some of them produce a kernel that crashes trivially,
those are obviously incorrect. Some of them might or might not be useful
in the future. We dont know how the environment will evolve in the future,
so we better keep all our options open and have a big enough 'gene pool'.
The development of individual patches is 'directed' and 'engineered' in
the sense that they produce a working kernel and they are derived from
some past experience and expectations of future. They might be correct or
incorrect, but judging them is always a function of the 'environment'.
Some patches become 'correct' over time. Eg. the preemptable kernel
patches are gaining significance these days - it was clearly a no-no 3
years ago. This is because the environment has changed, and certain
patches predicted or guessed the direction of technology environment
correctly.

if you look at patches on the micro-level, it has lots of structure, and
most of it is 'engineered'. If you look at it on the macro-level, the
Linux kernel as a whole has

(and gene shuffling itself has another random component as well, it's the
imperfectness of it that is one of the sources of random mutations.)

saying that the randomness of evolution is not the principle element is
like claiming that the current Linux code is sufficient and we only have
to shuffle around existing functions to make it better.

> > So *once* we have something that is better, it does not matter how long it
> > took to get there.
>
> Sure, once you are better than the other guy you're going to eat his
> lunch.  But time does matter: a critter that fails to get its
> evolutionary tail in gear before somebody eats its lunch isn't going
> to get a second chance.

this is another interesting detail: the speed of being able to adopt to a
changing environment does matter.

But the original claim which i replied to was that the cost of developing
a new 'feature' matters. Which i said is not true - evolution does not
care about time of development if the environment is relatively stable, or
is changing slowly. The speed of evolution/development only matters once
the environment changes fast.

So to draw the analogy with Linux - as long as the environment (chip
technology, etc.) changes rapidly, what matters most is the ability to
evolve. But once the environment 'cools down' a bit, we can freely search
for the most perfect features in a stable environment, and we'll end up
being 99.9% perfect (or better). [ The original claim which i replied to
said that we'll end up being 95% perfect and stop there, because further
development is too expensive - this claim i took issue with. ]

In fact this happened a number of times during Linux's lifetime. Eg. the
prospect of SMP unsettled the codebase alot and the (relative) quality of
uniprocessor Linux perhaps even decreased. Once the external environment
has settled down, other aspects of Linux caught up as well.

believe me, there was no 'grand plan'. Initially (5 years ago) Linus said
that SMP does not matter much at the moment, and that nothing should be
done in SMP space that hurts uniprocessors. Today it's exactly the other
way around. And i think it's perfectly possible that there will be a new
paradigm in 5 years.

	Ingo

Re: Coding style - a non-issue

[Pavel Machek]

Hi!

> believe me, there was no 'grand plan'. Initially (5 years ago) Linus said
> that SMP does not matter much at the moment, and that nothing should be
> done in SMP space that hurts uniprocessors. Today it's exactly the other
> way around. 

I hope uniprocessors still matter... SMP is nice, but 90% machines are
still uniprocessors... [Or someone get me SMP ;)]
								Pavel
-- 
"I do not steal MS software. It is not worth it."
                                -- Pavel Kankovsky

Re: Coding style - a non-issue

[Ingo Molnar]

On Sun, 2 Dec 2001, Rik van Riel wrote:

> I think you've pretty much proven how well random
> development works.

i think it's fair to say that we should not increase entropy artificially,
eg. we should not apply randomly generated patches to the kernel tree.

the point is, we should accept the fact that while this world appears to
be governed by rules to a certain degree, the world is also chaotic to a
large degree, and that a Grand Plan That Explains Everything does not
exist. And even if it existed, we are very far away from achieving it, and
even if some friendly alien dropped it on our head, we'd very likely be
unable to get our 5 billion brain cells into a state that is commonly
referred to as 'fully grokking it'.

and having accepted these limitations, we should observe the unevitable
effects of them: that any human prediction of future technology
development beyond 5 years is very, very hypothetical, and thus we must
have some fundamental way of dealing with this unpredictability. (such as
trying to follow Nature's Smart Way Of Not Understanding Much But Still
Getting Some Work Done - called evolution.)

	Ingo

Re: Coding style - a non-issue

[Alan Cox]

> Here's a characteristic good Linux design method ,( or call it "less than random
> mutation method" if that makes you feel happy): read the literature,
> think hard, try something, implement it

That assumes computer science is a functional engineering discipline. Its
not, at best we are at the alchemy stage of progression. You put two things
together it goes bang and you try to work out why.

In many of these fields there is no formal literature. The scientific paper
system in computer science is based on publishing things people already
believe. Much of the rest of the knowledge is unwritten or locked away in
labs as a trade secret, and wil probably never be reused.

Take TCP for example. The TCP protocol is specified in a series of
documents. If you make a formally correct implementation of the base TCP RFC
you won't even make connections. Much of the flow control behaviour, the
queueing and the detail is learned only by being directly part of the
TCP implementing community. You can read  all the scientific papers you
like, it will not make you a good TCP implementor. 

Alan

Re: Coding style - a non-issue

[Victor Yodaiken]

On Sat, Dec 01, 2001 at 08:57:17AM +0000, Alan Cox wrote:
> > Here's a characteristic good Linux design method ,( or call it "less than random
> > mutation method" if that makes you feel happy): read the literature,
> > think hard, try something, implement it
> 
> That assumes computer science is a functional engineering discipline. Its
> not, at best we are at the alchemy stage of progression. You put two things
> together it goes bang and you try to work out why.

Recently, our correspondent from Wales wrote:
	... the changes have been done and
	tested one at a time as they are merged. Real engineering process is the
	only way to get this sort of thing working well.

I really dislike this "alchemy" stuff. It's demeaning and misleading.
All the alchemists ever managed to create were cases of mercury
poisoning.


> In many of these fields there is no formal literature. The scientific paper
> system in computer science is based on publishing things people already
> believe. Much of the rest of the knowledge is unwritten or locked away in
> labs as a trade secret, and wil probably never be reused.
> 
> Take TCP for example. The TCP protocol is specified in a series of
> documents. If you make a formally correct implementation of the base TCP RFC
> you won't even make connections. Much of the flow control behaviour, the
> queueing and the detail is learned only by being directly part of the
> TCP implementing community. You can read  all the scientific papers you
> like, it will not make you a good TCP implementor. 

And you can hack away all you want, you'll never get TCP to work either.
This stuff is a mixture of theory and practice and
whether your theory is picked up from years of experience, boozy
arguments, and thinking, or from a strictly supervised
tour of the library it's theory all the same. 
CS is like any other skilled field. There's a difference between a guy
who knows how to hammer and a master carpenter. 

Re: Coding style - a non-issue

[Alan Cox]

> Recently, our correspondent from Wales wrote:
> 	... the changes have been done and
> 	tested one at a time as they are merged. Real engineering process is the
> 	only way to get this sort of thing working well.

Which doesn't conflict. Engineering does not require science. Science helps
a lot but people built perfectly good brick walls long before they knew why
cement works.

> All the alchemists ever managed to create were cases of mercury
> poisoning.

and chemistry, eventually. You take it as far more demeaning than its meant.

But right now given two chunks of code, I find out what happens by putting
them together not by formal methods. In the case of alchemy v chemistry the
chemists know whether it will probably go bang before they try it (and the
chemical engineers still duck anyway)

Alan

Re: Coding style - a non-issue

[Victor Yodaiken]

On Sat, Dec 01, 2001 at 01:38:11PM +0000, Alan Cox wrote:
> Which doesn't conflict. Engineering does not require science. Science helps
> a lot but people built perfectly good brick walls long before they knew why
> cement works.
> 
> > All the alchemists ever managed to create were cases of mercury
> > poisoning.
> 
> and chemistry, eventually. You take it as far more demeaning than its meant.
> 
> But right now given two chunks of code, I find out what happens by putting
> them together not by formal methods. In the case of alchemy v chemistry the
> chemists know whether it will probably go bang before they try it (and the
> chemical engineers still duck anyway)

Oh come on Alan. You look at a patch and can discard 99% of the really
bad ones _before_ you try them out. How do you do it? Divination? 
Nobody uses formal methods for anything other than generating papers
with more authors than readers. It's true that the academicians
have made a fetish out of the elaborate typesetting that they call
"theory", but in the real world, the distinction between science and
engineering is nothing more than some class snobbery and a rough
categorization of who pays for the work.

If there is a point here, which now seems unlikely, it's that there are
design and engineering skills needed to make real software work.
Neither slashdot nor the formal methods research fellows at Oxford
are capable of generating Linux. 

Re: Coding style - a non-issue

[Stephen Satchell]

[cc list trimmed]

At 07:30 PM 11/30/01 -0800, Larry McVoy wrote:
>Yeah, right, Linus.  We should all go home and turn loose the monkeys and
>let them pound on the keyboard.  They'll just as good a job, in fact, by
>your reasoning they'll get there faster, they aren't so likely to waste
>time trying to design it.

You are confusing the production of Shakespeare with the production of good 
OS code.

The high-level design aspect is that there is a problem to be solved or a 
feature to be provided.  That represents a goal.  Some goals are good and 
some goals are bad.  In many cases, you learn which when you actually do 
the code to implement the goal, and determine whether it helps, hinders, or 
just bloats the OS.

The lower-level design aspect is planning how to achieve the 
goal.  Implementation of the lower-level design in code to achieve the goal 
can contain flaws, flaws that don't appear on paper but raise ugly warts 
when you actually try the implementation out.  In this sense, this is like 
a mutation to achieve a specific effect -- blue eyes, say -- that has a 
disastrous side effect -- it causes the heart to have a single chamber 
instead of four.

This assumes that your, um, mutation even lets the organism live.  Many 
don't.  We call it debugging.


>I can't believe the crap you are spewing on this one and I don't think you
>do either.  If you do, you need a break.  I'm all for letting people explore,
>let software evolve, that's all good.  But somebody needs to keep an eye on
>it.

I don't know you, so I don't know how long you have been in the 
industry.  I've watched Unix evolve from the beginning.  AT&T streams 
versus Berkeley sockets was a wonderful war, and we are all for the better 
for the experimentation because we got the best of both -- especially as I 
was involved in ARPAnet in the beginning and saw the influence of what 
turned into TCP/IP in both environments.  We have different styles of 
system initialization, with some being better for manual management and 
some being better for package management -- and we have both living in the 
world today.  The development of X-terminals was fun, too, to try to 
divorce the requirements for a screen from the system that feeds it, and 
yet today the two different processes run together in a single box without 
too much problem.

These were the products of evolution, of system designers trying to meet a 
need, and the process of getting there was painful and left a lot of 
corpses behind it -- piles of dead code, for sure, but also dead companies 
and burned-out development people.  That's part of the business, 
particularly in the commercial world.

"But someone has to keep an eye on it."  Very true.  After all, in this 
process of natural selection, how do we weed out the mutations that don't 
work?  In the Linux development environment, we have several levels of 
weeding going on.  First, there is peer testing -- people downloading 
patches and trying out new things, which weeds out the worst of the 
mutations.  Then, there are the maintainers who sit in judgement as the 
patches roll by, picking out the deformed ones bodily and making sure that 
two patches that change the same code play nicely with each other.  We then 
have the pre-releases, which for the 2.4 tree were patch-inspected and 
maintained by Linux and by Alan Cox, which people can download and try on 
playpen systems with applications to see if anything subtly nasty crept in 
-- this weeds out a few of the mutations that harm the organism but doesn't 
kill it outright.  Finally, we have a production release into which people 
throw all the varied and wacky applications -- and sometimes an ugly (like 
the VM problem) finally is exposed to the light.

Interestingly, you see a similar development process at commercial software 
vendors and with the successful Open Source projects.  Some of the details 
differ (especially the details on the review process) but the overall 
process is similar.  Why?  It works.

I suggest you check out this site http://www.swebok.org/ and specifically 
download this document 
http://www.swebok.org/documents/stoneman095/Trial_Version_0_95.pdf AND READ 
IT before responding further.  While the Software Engineering Body Of 
Knowledge does not use the exact concepts that Linus used in describing how 
things are done, you will find interesting correlations between what is 
described by this document and the idea that you have called "crap."

Pay particular attention to the section on Validation and Verification.

Stephen Satchell

Re: Coding style - a non-issue

[Zilvinas Valinskas]

On Fri, Nov 30, 2001 at 10:31:24PM -0800, Stephen Satchell wrote:
> [cc list trimmed]
> 
> You are confusing the production of Shakespeare with the production of good 
> OS code.
> 
> The high-level design aspect is that there is a problem to be solved or a 
> feature to be provided.  That represents a goal.  Some goals are good and 
> some goals are bad.  In many cases, you learn which when you actually do 
> the code to implement the goal, and determine whether it helps, hinders, or 
> just bloats the OS.
> 

Sometimes design only _works_ it's way around problems ... 

-- 
Zilvinas Valinskas

Re: Coding style - a non-issue

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 30.11.01 in <Pine.LNX.4.33.0111301907010.1296-100000@penguin.transmeta.com>:

> Have you _ever_ heard of a project that actually started off with trying
> to figure out what it should do, a rigorous design phase, and a
> implementation phase?

Yes.

That one gave rise to _The_Mythical_Man_Month_.

Or in other words, it demonstrated how this was broken enough to create  
one of the more important classics in the field.

MfG Kai

Re: Coding style - a non-issue

[Andreas Dilger]

On Nov 30, 2001  20:02 -0700, Victor Yodaiken wrote:
> On Fri, Nov 30, 2001 at 04:50:34PM -0800, Linus Torvalds wrote:
> > Quite frankly, Sun is doomed. And it has nothing to do with their
> > engineering practices or their coding style.
> 
> The San Andreas fault? 

I wish people would stop saying that, I have never been to California. ;-)

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: Coding style - a non-issue

[Horst von Brand]

Victor Yodaiken <yodaiken@fsmlabs.com> said:

[...]

> Linux is what it is because of design, not accident. And you know
> that better than anyone.

I'd say it is better because the mutations themselves (individual patches)
go through a _very_ harsh evaluation before being applied in the "official"
sources. There is a population of kernels out there (each developer has a
few, distributions check out others, ...), only what survives there has got
a chance to be considered for inclusion.

Sure, this is not the only way Linux moves forward. But it is a large
factor in the success of "Release early. Release often. Take patches from
everywhere."
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Coding style - a non-issue

[Larry McVoy]

On Sat, Dec 01, 2001 at 08:18:06PM -0300, Horst von Brand wrote:
> Victor Yodaiken <yodaiken@fsmlabs.com> said:
> > Linux is what it is because of design, not accident. And you know
> > that better than anyone.
> 
> I'd say it is better because the mutations themselves (individual patches)
> go through a _very_ harsh evaluation before being applied in the "official"
> sources. 

Which is exactly Victor's point.  That evaluation is the design.  If the 
mutation argument held water then Linus would apply *ALL* patches and then
remove the bad ones.  But he doesn't.  Which just goes to show that on this
mutation nonsense, he's just spouting off.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Horst von Brand]

Larry McVoy <lm@bitmover.com> said:
> vonbrand@sleipnir.valparaiso.cl on Sat, Dec 01, 2001 at 08:18:06PM -0300

[...]

> > I'd say it is better because the mutations themselves (individual patches)
> > go through a _very_ harsh evaluation before being applied in the "official"
> > sources. 

> Which is exactly Victor's point.  That evaluation is the design.  If the 
> mutation argument held water then Linus would apply *ALL* patches and then
> remove the bad ones.  But he doesn't.  Which just goes to show that on this
> mutation nonsense, he's just spouting off.

Who is to say that bad mutations can't be weeded out _before_ a full
organism is built? It seems not to happen openly in nature's evolution
(then again, there are non-viable embryos, various DNA repair mechanisms
that seem to go wrong all the time in certain parts of the genome, parts
that mutate very fast while others don't change, ...), but this is just a
metaphor, not a slavish following. We certainly (at least think we) can do
better than just random typing.

In your reading, the environment (which evaluates individuals) is the
design. Right (in the sense that you end up with individuals fit to that
environment), but also very wrong (as many quite different layouts will
work).
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Coding style - a non-issue

[Daniel Phillips]

On December 2, 2001 09:25 pm, Larry McVoy wrote:
> On Sat, Dec 01, 2001 at 08:18:06PM -0300, Horst von Brand wrote:
> > Victor Yodaiken <yodaiken@fsmlabs.com> said:
> > > Linux is what it is because of design, not accident. And you know
> > > that better than anyone.
> > 
> > I'd say it is better because the mutations themselves (individual patches)
> > go through a _very_ harsh evaluation before being applied in the 
"official"
> > sources. 
> 
> Which is exactly Victor's point.  That evaluation is the design.

Nope, that isn't design, that's reacting.

> If the mutation argument held water then Linus would apply *ALL* patches 
> and then remove the bad ones.  But he doesn't.  Which just goes to show
> that on this mutation nonsense, he's just spouting off.

Hogwash ;)  Please see my post above where I point out 'evolution isn't 
random'.  Your genes have a plan, if only a vague one.  It goes something 
like this: "we'll allow random variations, but only along certain lines, 
within limits, and in certain combinations, and we'll try to stick to 
variations that haven't killed us in the past."

Sounds a lot like how Linus does things, huh?

I'm sure Linus does have quite considerable talent for design, but I haven't 
seen him execise it much.  Mostly he acts as a kind of goodness daemon, 
sitting in his little pinhole and letting what he considers 'good' stuff pass 
into the box.  There's no doubt about it, it's different from the way you 
like to develop, you and me both.  Equally clearly, it works pretty well.

--
Daniel

Re: Coding style - a non-issue

[Victor Yodaiken]

On Mon, Dec 03, 2001 at 01:55:08AM +0100, Daniel Phillips wrote:
> I'm sure Linus does have quite considerable talent for design, but I haven't 
> seen him execise it much.  Mostly he acts as a kind of goodness daemon, 
> sitting in his little pinhole and letting what he considers 'good' stuff pass 
> into the box.  There's no doubt about it, it's different from the way you 
> like to develop, you and me both.  Equally clearly, it works pretty well.

This is a good explanation of why Linux may fail as a project, but it is
pure fantasy as to how it has so far succeded as a project. 

The tiny part of system I wrote directly and the larger part that
I got to see up close involved a great deal of design, old fashioned 
careful engineering, and even aesthetic principles of what wasgood
design. 

Don't drink the cool aid. Go back and look in the kernel archives and 
you will see extensive design discussions among all the core developers.
Linus has a point about the development of Linux not being in
accord with some master plan (at least not one anyone admits to) , but 
that's about as far as it goes.

Re: Coding style - a non-issue

[Daniel Phillips]

On December 3, 2001 01:04 pm, Victor Yodaiken wrote:
> On Mon, Dec 03, 2001 at 01:55:08AM +0100, Daniel Phillips wrote:
> > I'm sure Linus does have quite considerable talent for design, but I haven't 
> > seen him exercise it much.  Mostly he acts as a kind of goodness daemon, 
> > sitting in his little pinhole and letting what he considers 'good' stuff pass 
> > into the box.  There's no doubt about it, it's different from the way you 
> > like to develop, you and me both.  Equally clearly, it works pretty well.
> 
> This is a good explanation of why Linux may fail as a project, but it is
> pure fantasy as to how it has so far succeeded as a project. 
> 
> The tiny part of system I wrote directly and the larger part that
      ^^^^^^^^^
> I got to see up close involved a great deal of design, old fashioned 
> careful engineering, and even aesthetic principles of what wasgood
> design. 

You're just supporting the point of view that Linus has been espousing, and 
I personally support:  Linux is engineered at a micro level[1] but evolves
on its own at a macro level.

Sure, Linux evolves with help from Linus, but he acts as a filter, not a 
designer.  When Linus does on rare occasions forget himself and actually 
design something, its micro-engineering like you or I would do.  So if Linux 
is designed, who does do the designing, can you name him?  I can tell you for 
sure it's not Linus.

> Don't drink the cool aid. Go back and look in the kernel archives and 
> you will see extensive design discussions among all the core developers.
> Linus has a point about the development of Linux not being in
> accord with some master plan (at least not one anyone admits to) , but 
> that's about as far as it goes.

Don't worry about me drinking the cool aid, first I already drank it and 
second I'm personally already fully devoted to the notion of design process, 
including all the usual steps:  blue sky, discussion, requirements, data 
design, detail design, prototype, etc. etc.  You'll find the 'paper trails' 
in the archives if you've got the patience to go spelunking, and you'll have 
a hard time finding one of those designs that became a dead end.  This design 
thing does work for me.  It doesn't change the fact that what I'm doing is 
micro-engineering.

I'll get really worried if Linus wakes up one day and decides that from now 
on he's going to properly engineer every aspect of the Linux kernel.  The 
same way I'd feel if Linux got taken over by a committee.

--
Daniel

[1] In places.  All those little warts and occasional pools of sewage are 
clearly not 'engineered'.

Re: Coding style - a non-issue

[Victor Yodaiken]

On Mon, Dec 03, 2001 at 02:20:38PM +0100, Daniel Phillips wrote:
> You're just supporting the point of view that Linus has been espousing, and 
> I personally support:  Linux is engineered at a micro level[1] but evolves
> on its own at a macro level.

If this becomes true, then Linux fails. If the coreLinux designers did
not "get" the UNIX design and understand what was good about Plan9, then
Linux would look like IRIX without quality control. And the engineer
formerly known as Linus has admitted as much in  past .e.g. with the 
comment about UNIX being about "Desgin with a capital D".

> I'll get really worried if Linus wakes up one day and decides that from now 
> on he's going to properly engineer every aspect of the Linux kernel.  The 
> same way I'd feel if Linux got taken over by a committee.

I'm at a loss here. I state that an emphasis on design has been critical
to Linux  and you respond that it would be bad if Linus wanted to
personally engineer every aspect of the Linux kernel. 
In the english language, the word "design" does not have the same
semantics as "control every detail". 

Anyways, enough.



> 
> --
> Daniel
> 
> [1] In places.  All those little warts and occasional pools of sewage are 
> clearly not 'engineered'.
> -
> 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: Coding style - a non-issue

[Ingo Molnar]

On Mon, 3 Dec 2001, Daniel Phillips wrote:

> [...] Please see my post above where I point out 'evolution isn't
> random'.  Your genes have a plan, if only a vague one.  It goes
> something like this: "we'll allow random variations, but only along
> certain lines, within limits, and in certain combinations, and we'll
> try to stick to variations that haven't killed us in the past."

so what you say in essence is that "evolution isnt random, it's random"
;-) The fact that the brownean motion is 'vaguely directed' (ie. evolution
has a limited amount of 'memory' of past experience coded into the DNA)
does not make it less random. Randomness does not have to be completely
undirected - perhaps you know a different definition for 'random'. Just
the fact that we got from bacteria to humans and from bacteria to trees
shows that it's not only random, it's also unstable and chaotic. (the same
initial conditions resulted in multiple, wildly different and almost
completely unrelated set of end results.)

and nobody claimed Linux development was totally (chryptographically)
random. We just claim that Linux development has a fair dose of randomness
and unpredictability besides having a fair dose of structure, and that its
development model is much closer to evolution than to the formal methods
of software development.

at which point i think we finally agree?

	Ingo

Re: Coding style - a non-issue

[David L. Parsley]

Larry McVoy wrote:


> Which is exactly Victor's point.  That evaluation is the design.  If the 
> mutation argument held water then Linus would apply *ALL* patches and then
> remove the bad ones.  But he doesn't.  Which just goes to show that on this
> mutation nonsense, he's just spouting off.


Eh, come on Larry.  You're too smart for this crap (as are others, your 
straw just broke the camel's back).  Linus was just using an analogy to 
illustrate some very valid points.  All analogies break down when 
applied to the nth degree.  Insulting Linus because you've found a spot 
where the analogy breaks is just ludicrous.

regards,
	David

Re: Coding style - a non-issue

[Larry McVoy]

On Sun, Dec 02, 2001 at 08:34:09PM -0500, David L. Parsley wrote:
> Larry McVoy wrote:
> > Which is exactly Victor's point.  That evaluation is the design.  If the 
> > mutation argument held water then Linus would apply *ALL* patches and then
> > remove the bad ones.  But he doesn't.  Which just goes to show that on this
> > mutation nonsense, he's just spouting off.
> 
> Eh, come on Larry.  You're too smart for this crap (as are others, your 
> straw just broke the camel's back).  Linus was just using an analogy to 
> illustrate some very valid points.  All analogies break down when 
> applied to the nth degree.  Insulting Linus because you've found a spot 
> where the analogy breaks is just ludicrous.

This whole mutation crap is ludicrous and if you read through the archives
you can find numerous examples where Linus himself says so.  I have no idea
why he is saying what he is, but that's neither here nor there.  Nonsense
is nonsense, regardless of who says it or why they say it.

Doesn't it strike you the least bit strange that when I challenge Linus to
bow out because he asserts that he isn't needed, this is just some grand
experiment in genetics which is working fine, he says everything would be
fine if he left but he isn't going to because he's having fun?  Isn't that
just a tad convenient?  It's a crock of crap too.  Linus has excellent taste,
better than any OS guy I've run into in 20 years, and if he bowed out a ton
of crap would make it into the kernel that doesn't now.  Genetic mutation
my ass.  If you want an experiment in evolution, then let *everything* into
the kernel.  That's how evolution works, it tries everything, it doesn't
prescreen.  Go read Darwin, go think, there isn't any screening going on,
evolution *is* the screening.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Horst von Brand]

Larry McVoy <lm@bitmover.com> said:

[...]

> Doesn't it strike you the least bit strange that when I challenge Linus to
> bow out because he asserts that he isn't needed, this is just some grand
> experiment in genetics which is working fine, he says everything would be
> fine if he left but he isn't going to because he's having fun?

Hummm... Linux works because there is a harsh evaluation of patches that
try to make it into the stock kernel. There Linus _is_ needed, if nothing
else as a final authority almost everybody respects.

If he enjoys what he is doing, why shouldn't he go on doing it? If he seems
to be doing it right, irrespective of whatever reason (right or terribly
wrong) he gives for it?

>                                                                 Isn't that
> just a tad convenient?  It's a crock of crap too.  Linus has excellent taste,
> better than any OS guy I've run into in 20 years, and if he bowed out a ton
> of crap would make it into the kernel that doesn't now.  Genetic mutation
> my ass.

Accept patches and ideas from all over the place, coupled with evaluation
of said patches and suggestions which weeds out the bad ones before
integration, others when they show wanting after integration is a form of
evolution. No overall direction, no grand design a la OS/360, just design
(sort of) in rather limited areas at a time. Not 100% Darwinian evolution,
with some taints of "acquired traits are inherited", and some (limited)
sense of direction, and also cross movement of traits form others (be it
BSD, or different kernel lines).

>         If you want an experiment in evolution, then let *everything* into
> the kernel.  That's how evolution works, it tries everything, it doesn't
> prescreen.  Go read Darwin, go think, there isn't any screening going on,
> evolution *is* the screening.

Why does the screening have to be at the level of full organisms? It
_looks_ that way because you don't see the busted sperm or broken eggs, or
the stillborn embryos which make up the "preliminary checks show it won't
work" in nature. The process is (hopefully) much more efficient here than
in nature, and visible, that is all.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Coding style - a non-issue

[Ragnar Hojland Espinosa]

On Mon, Dec 03, 2001 at 10:39:08PM -0300, Horst von Brand wrote:
> >         If you want an experiment in evolution, then let *everything* into
> > the kernel.  That's how evolution works, it tries everything, it doesn't
> > prescreen.  Go read Darwin, go think, there isn't any screening going on,
> > evolution *is* the screening.
> 
> Why does the screening have to be at the level of full organisms? It
> _looks_ that way because you don't see the busted sperm or broken eggs, or
> the stillborn embryos which make up the "preliminary checks show it won't
> work" in nature. The process is (hopefully) much more efficient here than
> in nature, and visible, that is all.

And I'd add something more along those lines..

Evolution and selection is about species, not individuals as its commonly
considered, so what might be bad for an individual (getting "screened" at
early ages) might be good for (reproduction of) the species (since it
ensures a better reproduction material quality)  Darwinian evolution doesnt
fit too well in the kernel.

On the other hand we can think of developers' minds as a copy-on-write DNA.
DNA knows when something wont work, so it doesn't try it.   Screening :)

-- 
____/|  Ragnar Højland      Freedom - Linux - OpenGL |    Brainbench MVP
\ o.O|  PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
 =(_)=  "Thou shalt not follow the NULL pointer for  | (www.brainbench.com)
   U     chaos and madness await thee at its end."

Re: Coding style - a non-issue

[Oliver Xymoron]

On Sun, 2 Dec 2001, Larry McVoy wrote:

> If you want an experiment in evolution, then let *everything* into
> the kernel.  That's how evolution works, it tries everything, it doesn't
> prescreen.  Go read Darwin, go think, there isn't any screening going on,
> evolution *is* the screening.

So-called 'natural selection' is only a subset of things that can quite
legitimately be called evolution. And there certainly is screening in
nature, it's called sexual selection.

Linus's point is mainly about parallelism. Many more changes get tried in
the Linux space than could ever happen in a traditional software
development environment.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: Coding style - a non-issue

[Stephen Satchell]

[cc list trimmed]

At 06:02 PM 11/30/01 -0800, Tim Hockin wrote:
> > Linux sez:
> > I'm deadly serious: we humans have _never_ been able to replicate
> > something more complicated than what we ourselves are, yet natural
> > selection did it without even thinking.
>
>a very interesting argument, but not very pertinent - we don't have 10's of
>thousands of year or even really 10's of years.  We have to use intellect
>to root out the obviously bad ideas, and even more importantly the
>bad-but-not-obviously-bad ideas.

Disagree with your position strongly.  It's very pertinent.

Most of the bad-but-not-obviously-bad ideas get rooted out by people trying 
them and finding them to be wanting.  Take, for example, the VM flap in the 
2.4.* tree:  an astonishing side effect of the operation of the VM system 
caused people to come up with one that wasn't so astonishing.  We're not 
sure why the original VM caused such problems.  We fixed it anyway.  (No, I 
played no part in that particular adventure, I was just viewing from the 
sidelines.)

The "Linux Way" as I understand it is to release early and release 
often.  That means that we go through a "generation" of released code every 
few weeks, and a "generation" of beta candidates just about daily...and if 
you include the patches that appear here during every 24 hours, the 
generation cycle is even faster than that.  That means that any mutations 
that are detrimental to the organism are exposed within days -- sometimes 
even hours -- of their introduction into the code base.

When we have a development tree open (as 2.5 is now freshly open) there are 
even more generations of code, which further makes natural selection viable 
as a weeding process for good and bad code.  The difference is that the 
number of people affected by the weeding process is smaller, and the 
probability of killing production systems with mutations becomes 
smaller.  The population of the organism is thus healthier because 
mutations affect a smaller fraction of the population, and the chances of 
expensive illness is reduced.

Beneficial mutations are "back-ported" into the 2.4 and even the 2.2 code 
trees, mutations that have proven their worth by extensive experimentation 
and experience.  Unlike the biological equivalent, this selective spreading 
of mutations further improves the health of the population of organisms.

Now that I've stretched the analogy as far as I care to, I will stop 
now.  Please consider the life-cycle of the kernel when thinking about what 
Linus said.

Just my pair-o-pennies(tm).

Stephen Satchell

Re: Coding style - a non-issue

[Rik van Riel]

On Fri, 30 Nov 2001, Linus Torvalds wrote:

> And don't EVER make the mistake that you can design something better than
> what you get from ruthless massively parallel trial-and-error with a
> feedback cycle. That's giving your intelligence _much_ too much credit.

So, are we going to take out the appendix in 2.5 or will
we continue hoping our kernel doesn't catch an illness
without actually doing anything preventive ?

Biological selection does nothing except removing the weak
ones, it cannot automatically create systems which work well.

In short, I believe the biological selection is just that,
selection. The creation of stuff will need some direction.

regards,

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[Ingo Oeser]

On Sat, Dec 01, 2001 at 09:18:54AM -0200, Rik van Riel wrote:
> Biological selection does nothing except removing the weak
> ones, it cannot automatically create systems which work well.
> 
> In short, I believe the biological selection is just that,
> selection. The creation of stuff will need some direction.

Creation is as simple as: 

1. If you encounter a problem, try to solve it.
2. If you cannot solve it, mark/document/publish it and try to
   work around it for now.
3. If you cannot work around it, leave it to other people and
   offer help.

Which is pretty much what this list here is for ;-)

Regards

Ingo Oeser
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

Re: Coding style - a non-issue

[Rik van Riel]

On Sat, 1 Dec 2001, Ingo Oeser wrote:
> On Sat, Dec 01, 2001 at 09:18:54AM -0200, Rik van Riel wrote:
> > Biological selection does nothing except removing the weak
> > ones, it cannot automatically create systems which work well.
> >
> > In short, I believe the biological selection is just that,
> > selection. The creation of stuff will need some direction.
>
> Creation is as simple as:
>
> 1. If you encounter a problem, try to solve it.
> 2. If you cannot solve it, mark/document/publish it and try to
>    work around it for now.
> 3. If you cannot work around it, leave it to other people and
>    offer help.
>
> Which is pretty much what this list here is for ;-)

4. If the problem cannot be solved with a quick hack by
   one person, give up and switch to another OS.

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[Martin Dalecki]

Rik van Riel wrote:
> 
> On Fri, 30 Nov 2001, Linus Torvalds wrote:
> 
> > And don't EVER make the mistake that you can design something better than
> > what you get from ruthless massively parallel trial-and-error with a
> > feedback cycle. That's giving your intelligence _much_ too much credit.
> 
> So, are we going to take out the appendix in 2.5 or will
> we continue hoping our kernel doesn't catch an illness
> without actually doing anything preventive ?
> 
> Biological selection does nothing except removing the weak
> ones, it cannot automatically create systems which work well.
> 
> In short, I believe the biological selection is just that,
> selection. The creation of stuff will need some direction.
> 
> regards,

One thing Linus doesn't realize is that the most successfull
results of the biological selection are not the high mamals but
simle archaic bacterias. This is the point where his
analogy breaks badly.

One one thing he simple appears to have forgotten: Operating 
systems have a *purpose*. Therefore the stuff one wan't to do with
a system is what is driving it's true developement - this is most
pertinent in the developement of a driver - one does it to
use some kind of hardware it's that simple.

However I agree with him fully that most of the so called 
software engineering methods do not have much in common with
the reality out there and are basically a self exercise.

Re: Coding style - a non-issue

[Stephan von Krawczynski]

On Sun, 02 Dec 2001 17:25:54 +0100
Martin Dalecki <dalecki@evision-ventures.com> wrote:

> One one thing he [Linus] simple appears to have forgotten: Operating 
> systems have a *purpose*.

He didn't. The simple purpose of all being is equal: survival
As it is equal to all, talking about it is pretty redundant.

Regards,
Stephan

Re: Coding style - a non-issue

[Ingo Molnar]

On Sun, 2 Dec 2001, Martin Dalecki wrote:

> One thing Linus doesn't realize is that the most successfull results
> of the biological selection are not the high mamals but simle archaic
> bacterias. This is the point where his analogy breaks badly.

the fact that simple forms of life still exist shows only one thing: often
the environment is so harsh (ie. so *random*) that only the simplest can
survive. This is not 'success', it's a bow towards chaos.

the other reason is that simple forms of life are often just a tool for
higher forms of lifes to exist, or do not matter to the existence of
higher forms of life. Lets note that the human race *did* eradicate
certain strains of bacteria from this planet completely (except some more
or less safe places of storage), such as smallpocks, which pretty much
shows who has 'succeeded'.

	Ingo

Re: Coding style - a non-issue

[Horst von Brand]

Linus Torvalds <torvalds@transmeta.com> said:
> On Fri, 30 Nov 2001, Rik van Riel wrote:
> > I'm very interested too, though I'll have to agree with Larry
> > that Linux really isn't going anywhere in particular and seems
> > to be making progress through sheer luck.

In any case, Larry's suggestion would fracture Linux. Also, Solaris might
be a fine piece of work, but what is commonly called Linux (i.e.,
distributions) is more flexible, easier to use, and friendly
overall. Besides, the kernel handles an insane selection of hardware, and
is able to interoperate with allmost everything else there is. No mean
feat, that one.

> Hey, that's not a bug, that's a FEATURE!

Bingo!
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Coding style - a non-issue

[Rik van Riel]

On Fri, 30 Nov 2001, Linus Torvalds wrote:
> On Fri, 30 Nov 2001, Rik van Riel wrote:
> >
> > I'm very interested too, though I'll have to agree with Larry
> > that Linux really isn't going anywhere in particular and seems
> > to be making progress through sheer luck.
>
> Hey, that's not a bug, that's a FEATURE!

Don't forget the fact that 2.4 is the first kernel you
managed to get stable under high load since 1.2.

Both 2.0 and 2.2 didn't get stable until Alan took over
and Alan's 2.4 fork got stable some 4 months before your
2.4 tree got stable.

I think you've pretty much proven how well random
development works.

regards,

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[H. Peter Anvin]

Followup to:  <20011130140613.F14710@work.bitmover.com>
By author:    Larry McVoy <lm@bitmover.com>
In newsgroup: linux.dev.kernel
> > 
> > A simple rule to remember is: when code is bad, criticize the code, not the 
> > coder.
> 
> Your priorities are upside down.  The code is more important than the
> coder, it will outlive the coder's interest in that code.  Besides,
> this isn't some touchy feely love fest, it's code.  It's suppose to
> work and work well and be maintainable.  You don't get that by being
> "nice", you get that by insisting on quality.  If being nice worked,
> we wouldn't be having this conversation.
> 

So the sensible thing to do is, again, to criticize the code, not the
coder.

There are multiple reasons for that:

a) The code is what counts.
b) People take personal attacks, well, personally.  It causes
   unnecessary bad blood.
c) There are people who will produce beautiful code one minute, and
   complete shitpiles the next one.

If a certain piece of code is a shitpile, go ahead and say so.  Please
do, however, explain why that is, and please give the maintainer a
chance to listen before being flamed publically.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Coding style - a non-issue

[Henning Schmiedehausen]

On Fri, 2001-11-30 at 19:13, Larry McVoy wrote:

> But I haven't found anything else which works as well.  I don't use that
> technique at BitMover, instead I rewrite code that I find offensive.  That's

Sounds like the thing that Mr. Gates did when Microsoft was small. Maybe
there _is_ a point in this.

	Regards
		Henning


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

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

Re: Coding style - a non-issue

[Henning Schmiedehausen]

On Fri, 2001-11-30 at 18:27, Larry McVoy wrote:

Larry

> I think that if you ask around, you'll find that the pros use a coding 
> style that isn't theirs, even when writing new code.  They have evolved
> to use the prevailing style in their environment.  I know that's true for
> me, my original style was 4 space tabs, curly braces on their own line,
> etc.  I now code the way Bill Joy codes, fondly known as Bill Joy normal
> form.

I don't have to ask around. You may want to know that I work in this
industry for about 15 years and write commercial code (that is "code
that ships") since about that time (and I don't run around telling
everybody each and every time about it and what I've already done). I've
written code in a good two dozen languages (including things that really
deserve to die like Comal) and I've worked in projects from "one man
show" to "lots of people in Elbonia also work on this". So, please,
please, Larry, _STOP THE FUCK PATRONIZING OTHERS_. Actually, I try to
consider myself a "pro" in some languages and a bloody amateur in others
(like Lisp or Python). That is "pro" as in "pays his bills with writing
software".

> 
> Anyway, if you think any coding style is better than another, you completely
> miss the point.  The existing style, whatever it is, is the style you use.
> I personally despise the GNU coding style but when I make changes there,
> that's what I use because it is their source base, not mine.

We're in violent agreement here. Unfortunatly we do not agree whether it
is good to force a driver writer (which is, IMHO, most of the time a
well defined entity of one, maybe two or three source code files that
uses a well established (though sometimes changing) API to talk to the
kernel) to convert his style to the linux kernel ("our style is better
than yours, you must convert") or allow him to continue working (and
maintaining) his driver in the kernel tree in his own style. Even if his
variable names contain Uppercase letters.

The question now is, what is "amateur behaviour": Forcing this driver
writer to change or to tolerate his style in his driver? We're still
talking about a driver, not about the VM subsystem or the networking
core.

And will "putting up a list of the ten most ugly drivers with author
names" really persuade this author to change? Or simply to drop out and
write a driver for an OS that may be more tolerant?

That the core components of a large software project must adhere to a
style guide (and the Linux style guide is pretty good, because it is
_SHORT_), there is no disagreement between you and me.

	Regards
		Henning


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

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

Re: Coding style - a non-issue

[Larry McVoy]

Henning, perhaps you can explain to me how the following isn't a 

	"I don't do XYZ"

	"XYZ"

statement?

On Fri, Nov 30, 2001 at 06:53:05PM +0100, Henning Schmiedehausen wrote:
> You may want to know that I work in this
> industry for about 15 years and write commercial code (that is "code
> that ships") since about that time (and I don't run around telling
> everybody each and every time about it and what I've already done). 

That would be the "I don't do XYZ..."

> I've
> written code in a good two dozen languages (including things that really
> deserve to die like Comal) and I've worked in projects from "one man
> show" to "lots of people in Elbonia also work on this".

And this would be the "XYZ".

If you are going to yell at people for a particular behaviour, it's really
more effective if you don't show that behaviour in the midst of your yelling,
wouldn't you agree?  Just a friendly thought.

> So, please, please, Larry, _STOP THE FUCK PATRONIZING OTHERS_.

It would appear that you find everything I say patronizing, regardless of
what it is or how it is said.  I'm sorry about that, but I'm not going
to change how I speak to suit you.  Yell all you want.  I'd suggest
that if you find my emails offensive, you add me to your kill file.

> The question now is, what is "amateur behaviour": Forcing this driver
> writer to change or to tolerate his style in his driver? We're still
> talking about a driver, not about the VM subsystem or the networking
> core.

Your approach to this whole topic is a good example of why I run my own
company and I have absolute authority to fire people at will.  If you 
worked here and you persisted with this approach, you would be fired,
without question.  I don't know how to say it more clearly, I don't
say it lightly, hiring someone, training them, all of that is a huge
investment.  One which I would discard if you couldn't fit in.  Coding
style is part of fitting in, it isn't optional in any code I pay for.

You may have a different view, that's cool, you're entitled.  But realize
that any professional software organization is unlikely to agree with you.
For whatever that is worth.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Coding style - a non-issue

[Mike Fedyk]

On Fri, Nov 30, 2001 at 10:07:29AM -0800, Larry McVoy wrote:
> Henning, perhaps you can explain to me how the following isn't a 
> 
> 	"I don't do XYZ"
> 
> 	"XYZ"
> 
> statement?
> 
> On Fri, Nov 30, 2001 at 06:53:05PM +0100, Henning Schmiedehausen wrote:
> > You may want to know that I work in this
> > industry for about 15 years and write commercial code (that is "code
> > that ships") since about that time (and I don't run around telling
> > everybody each and every time about it and what I've already done). 
> 
> That would be the "I don't do XYZ..."
> 
> > I've
> > written code in a good two dozen languages (including things that really
> > deserve to die like Comal) and I've worked in projects from "one man
> > show" to "lots of people in Elbonia also work on this".
> 
> And this would be the "XYZ".
> 
> If you are going to yell at people for a particular behaviour, it's really
> more effective if you don't show that behaviour in the midst of your yelling,
> wouldn't you agree?  Just a friendly thought.
>

He's basically complaining that you like to point out what you have done in
the past a lot.  Then goes to say that he has qualifications to prove that
his opinion should be listened to.

Not that I've been reading lkml long enough to notice...

> > So, please, please, Larry, _STOP THE FUCK PATRONIZING OTHERS_.
> 
> It would appear that you find everything I say patronizing, regardless of
> what it is or how it is said.  I'm sorry about that, but I'm not going
> to change how I speak to suit you.  Yell all you want.  I'd suggest
> that if you find my emails offensive, you add me to your kill file.
>

I don't know about you, but I wouldn't want to be in anyone's killfile.

> > The question now is, what is "amateur behaviour": Forcing this driver
> > writer to change or to tolerate his style in his driver? We're still
> > talking about a driver, not about the VM subsystem or the networking
> > core.
> 
> Your approach to this whole topic is a good example of why I run my own
> company and I have absolute authority to fire people at will.  If you 
> worked here and you persisted with this approach, you would be fired,
> without question.  I don't know how to say it more clearly, I don't
> say it lightly, hiring someone, training them, all of that is a huge
> investment.  One which I would discard if you couldn't fit in.  Coding
> style is part of fitting in, it isn't optional in any code I pay for.
>

Key words: "pay for".

This is Linux-Kernel.  Each developer is on their own on how they pay the
their bills.  The question is... Why not accept a *driver* that *works* but
the source doesn't look so good?  Maintainability? Yes.  Take the code, and
encourage better code.  Or even convert said initial submission to the
kernel style.

What really needs to happen...

Accept the driver, but also accept future submissions that *only* clean up
the comments.  It has been said that patches with comments and without code
have been notoriously droped.

mf

Re: Coding style - a non-issue

[Alexander Viro]

On Fri, 30 Nov 2001, Mike Fedyk wrote:

> This is Linux-Kernel.  Each developer is on their own on how they pay the
> their bills.  The question is... Why not accept a *driver* that *works* but
> the source doesn't look so good?

Because this "works" may very well include exploitable buffer overruns in
kernel mode.  I had seen that - ioctl() assuming that nobody would pass
it deliberately incorrect arguments and doing something like
	copy_from_user(&foo, arg, sizeof(foo));
	copy_from_user(bar, foo.addr, foo.len);

The problem being, seeing what really happens required half an hour of
wading through the shitload of #defines.  _After_ seeing copy_from_user()
in a macro during greap over the tree - that's what had triggered the
further search.
 
> What really needs to happen...
> 
> Accept the driver, but also accept future submissions that *only* clean up
> the comments.  It has been said that patches with comments and without code
> have been notoriously droped.

Commented pile of shit is still nothing but a pile of shit.  If you comment
Netscape to hell and back it will still remain a festering dungpile.  Same
for NT, GNOME, yodda, yodda...

Re: Coding style - a non-issue

[Rusty Russell]

On Sat, 1 Dec 2001 00:14:54 -0500 (EST)
Alexander Viro <viro@math.psu.edu> wrote:

> 
> 
> On Fri, 30 Nov 2001, Mike Fedyk wrote:
> 
> > This is Linux-Kernel.  Each developer is on their own on how they pay the
> > their bills.  The question is... Why not accept a *driver* that *works* but
> > the source doesn't look so good?
> 
> Because this "works" may very well include exploitable buffer overruns in
> kernel mode.  I had seen that - ioctl() assuming that nobody would pass

And: bad code spreads.  Anyone who has done infrastructure change in the
kernel sees this: people copy (presumed) working code.

Hence I now lean towards "change EVERYTHING" rather than "wrap old source, add
new", and "fix even if not broken", eg. my "set_bit needs a long" patch which
also changed x86-specific code (where it doesn't matter).

Cheers,
Rusty.
-- 
  Anyone who quotes me is an idiot. -- Rusty Russell.

Re: Coding style - a non-issue

[Alan Cox]

> Flaming about coding style is about as pointless as flaming someone
> because he supports another sports team. There is no universal accepted
> coding style. Not even in C.

The kernel has an accepted coding style, both the documented and the
tradition part of it. Using that makes life a lot lot easier for maintaining
the code. Enforcing it there is a good idea, except for special cases
(headers shared with NT has been one example of that).

There are also some nice tools around that will do the first stage import of
a Hungarian NT'ese driver and linuxise it. 

Alan

Re: Coding style - a non-issue

[Alexander Viro]

On 30 Nov 2001, Henning Schmiedehausen wrote:

> issue. Code that you consider ugly as hell may be seen as "easily
> understandable and maintainable" by the author. If it works and has no
> bugs, so what? Just because it is hard for you and me to understand (cf.

... it goes without peer review for years.  And that means bugs.

Fact of life: we all suck at reviewing our own code.  You, me, Ken Thompson,
anybody - we tend to overlook bugs in the code we'd written.  Depending on
the skill we can compensate - there are technics for that, but it doesn't
change the fact that review by clued people who didn't write the thing
tends to show bugs we'd missed for years.

If you really don't know that by your own experience - you don't _have_
experience.  There is a damn good reason for uniform style within a
project: peer review helps.  I've lost the count of bugs in the drivers
that I'd found just grepping the tree.  Even on that level review catches
tons of bugs.  And I have no reason to doubt that authors of respective
drivers would fix them as soon as they'd see said bugs.

"It's my code and I don't care if nobody else can read it" is an immediate
firing offense in any sane place.  It may be OK in academentia, but in the
real life it's simply unacceptable.

It's all nice and dandy to shed tears for poor, abused, well-meaning company
that had made everyone happy by correct but unreadable code and now gets
humiliated by mean ingrates.  Nice image, but in reality the picture is
quite different.  Code _is_ buggy.  That much is a given, regardless of
the origin of that code.  The only question is how soon are these bugs
fixed.  And that directly depends on the amount of efforts required to
read through that code.

Sigh...  Ironic that _you_ recommend somebody to grow up - I would expect
the level of naivety you'd demonstrated from a CS grad who'd never worked
on anything beyond his toy project.  Not from somebody adult.

Re: Coding style - a non-issue

[Henning Schmiedehausen]

On Fri, 2001-11-30 at 18:55, Alexander Viro wrote:

Hi,

> On 30 Nov 2001, Henning Schmiedehausen wrote:
> 
> > issue. Code that you consider ugly as hell may be seen as "easily
> > understandable and maintainable" by the author. If it works and has no
> > bugs, so what? Just because it is hard for you and me to understand (cf.
> 
> ... it goes without peer review for years.  And that means bugs.

That's right. And I didn't say, that _this is a good thing_. The
question was (and is IMHO), "do we put such code into a "hall of driver
writer shame" or do we either just reject the code from the kernel tree
or do we help "the poor misunderstood vendor" to convert.

Simply flaming them down will definitely not help. As someone with your
experience should know, too.

> Sigh...  Ironic that _you_ recommend somebody to grow up - I would expect
> the level of naivety you'd demonstrated from a CS grad who'd never worked
> on anything beyond his toy project.  Not from somebody adult.

You're welcome.

I'm willing to give you a bet: You put up such a "hall of shame" and we
will see what comes first:

a) media echo that "linux core developers start insulting code
committers"

or

b) vendors start cleaning up their code.



	Regards
		Henning

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

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

Re: Coding style - a non-issue

[Pavel Machek]

Hi!

> > Sigh...  Ironic that _you_ recommend somebody to grow up - I would expect
> > the level of naivety you'd demonstrated from a CS grad who'd never worked
> > on anything beyond his toy project.  Not from somebody adult.
> 
> You're welcome.
> 
> I'm willing to give you a bet: You put up such a "hall of shame" and we
> will see what comes first:
> 
> a) media echo that "linux core developers start insulting code
> committers"
> 
> or
> 
> b) vendors start cleaning up their code.

Question is... what hurts us more. Bad press or bad code? I guess bad
code is worse...
								Pavel
-- 
"I do not steal MS software. It is not worth it."
                                -- Pavel Kankovsky

Re: Coding style - a non-issue

[Alan Cox]

> > a) media echo that "linux core developers start insulting code
> > committers"
> > 
> > b) vendors start cleaning up their code.
> 
> Question is... what hurts us more. Bad press or bad code? I guess bad
> code is worse...

What would be much much more constructive isnt quite a hall of shame - its
to build a set of pages that take problem drivers and quote chunks of them
with an explanation of _why_ it is wrong, what should be used instead and
possible the "after" code if it also gets cleaned up.

That way people coming along actually learn something from it. Anyone can
be a critic, its rather harder and much more valuable to be a critic that
actually has positive impacts on what you criticize


Alan

Re: Coding style - a non-issue

[Dave Jones]

On Sun, 2 Dec 2001, Alan Cox wrote:

> What would be much much more constructive isnt quite a hall of shame - its
> to build a set of pages that take problem drivers and quote chunks of them
> with an explanation of _why_ it is wrong, what should be used instead and
> possible the "after" code if it also gets cleaned up.

I planned to do something like this for the kernel-janitor project.
The janitor todo-list is aparently too terse for some people, and
having a perl script to point out problems wasn't enough. Maybe having the
script point to a webpage explaining /why/ xxxx needs changing would be
more useful.

The current TODO list there goes halfway toward this, but needs
expanding, more explanations etc.. Any contributions more than
welcomed.

regards,
Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Coding style - a non-issue

[Rik van Riel]

On Fri, 30 Nov 2001, Alexander Viro wrote:

> Fact of life: we all suck at reviewing our own code.  You, me, Ken
> Thompson, anybody - we tend to overlook bugs in the code we'd written.
> Depending on the skill we can compensate - there are technics for
> that, but it doesn't change the fact that review by clued people who
> didn't write the thing tends to show bugs we'd missed for years.

Absolutely agreed.  Note that this goes hand in hand with
another issue, no matter how scary it may sound to other
people ... <drum roll>

	DOCUMENTATION

Because, without documentation we can only see what code
does and not what it's supposed to do.

This in turn means other people cannot identify bugs in
the code, simply because they're not sure what the code
is supposed to do.

regards,

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[Jeff Garzik]

Diverse coding styles in the Linux kernel create long term maintenance
problems.  End of story.

	Jeff


-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: Coding style - a non-issue

[Keith Owens]

On 30 Nov 2001 18:15:28 +0100, 
Henning Schmiedehausen <hps@intermeta.de> wrote:
>Are you willing to judge "ugliness" of kernel drivers? What is ugly?
>... Is the aic7xxx driver ugly because it needs libdb ? ...

Yes, and no, mainly yes.  Requiring libdb, lex and yacc to to generate
the firmware is not ugly, user space programs can use any tools that
the developer needs.  I have no opinion either way about the driver
code, from what I can tell aic7xxx is a decent SCSI driver, once it is
built.

What is ugly in aic7xxx is :-

* Kludging BSD makefile style into aix7ccc/aicasm/Makefile.  It is not
  compatible with the linux kernel makefile style.

* Using a manual flag (CONFIG_AIC7XXX_BUILD_FIRMWARE) instead of
  automatically detecting when the firmware needs to be rebuilt.  Users
  who set that flag by mistake but do not have libdb, lex and yacc
  cannot compile a kernel.

* Not checking that the db.h file it picked will actually compile and
  link.

* Butchering the modules_install rule to add a special case for aic7xxx
  instead of using the same method that every other module uses.

* Including endian.h in the aic7xxx driver, but endian.h is a user
  space include.  Code that is linked into the kernel or a module
  MUST NOT include user space headers.

* Not correctly defining the dependencies between generated headers and
  the code that includes those headers.  Generated headers require
  explicit dependencies, the only reason it works is because aic7xxx ...

* Ships generated files and overwrites them under the same name.
  Shipping generated files is bad enough but is sometime necessary when
  the end user might not have the tools to build the files (libdb, lex,
  yacc).  Overwriting the shipped files under the same name is asking
  for problem with source repositories and generating spurious diffs.

All of the above problems are caused by a developer who insists on
doing his own makefile style instead of following the kernel standards
for makefiles.  Developers with their own standards are BAD!

BTW, I have made repeated offers to rewrite the aic7xx makefiles for
2.4 but the aic7xxx maintainer refuses to do so.  I _will_ rewrite them
in 2.5, as part of the kernel build 2.5 redesign.

Keith Owens, kernel build maintainer.

Re: Coding style - a non-issue

[Gérard Roudier]

Hi Keith,

When I have had to prepare a Makefile for sym-2 as a sub-directory of
drivers/scsi (sym53c8xx_2), it didn't seem to me that a non-ugly way to do
so was possible. I mean that using sub-directory for scsi drivers wasn't
expected by the normal kernel build procedure. Looking into some network
parts that wanted to do so, I only discovered hacky stuff. This left me in
the situation I had to do this in an ugly way.

As you cannot ignore the scsi driver directory is a mess since years due
to too many sources files in an single directory. Will such ugly-ness be
cleaned up in linux-2.5?

By the way, in my opinion, a software that is as ugly as you describe but
not more looks excellentware to me. :-)

  Gérard.


On Sat, 1 Dec 2001, Keith Owens wrote:

> On 30 Nov 2001 18:15:28 +0100,
> Henning Schmiedehausen <hps@intermeta.de> wrote:
> >Are you willing to judge "ugliness" of kernel drivers? What is ugly?
> >... Is the aic7xxx driver ugly because it needs libdb ? ...
>
> Yes, and no, mainly yes.  Requiring libdb, lex and yacc to to generate
> the firmware is not ugly, user space programs can use any tools that
> the developer needs.  I have no opinion either way about the driver
> code, from what I can tell aic7xxx is a decent SCSI driver, once it is
> built.
>
> What is ugly in aic7xxx is :-
>
> * Kludging BSD makefile style into aix7ccc/aicasm/Makefile.  It is not
>   compatible with the linux kernel makefile style.
>
> * Using a manual flag (CONFIG_AIC7XXX_BUILD_FIRMWARE) instead of
>   automatically detecting when the firmware needs to be rebuilt.  Users
>   who set that flag by mistake but do not have libdb, lex and yacc
>   cannot compile a kernel.
>
> * Not checking that the db.h file it picked will actually compile and
>   link.
>
> * Butchering the modules_install rule to add a special case for aic7xxx
>   instead of using the same method that every other module uses.
>
> * Including endian.h in the aic7xxx driver, but endian.h is a user
>   space include.  Code that is linked into the kernel or a module
>   MUST NOT include user space headers.
>
> * Not correctly defining the dependencies between generated headers and
>   the code that includes those headers.  Generated headers require
>   explicit dependencies, the only reason it works is because aic7xxx ...
>
> * Ships generated files and overwrites them under the same name.
>   Shipping generated files is bad enough but is sometime necessary when
>   the end user might not have the tools to build the files (libdb, lex,
>   yacc).  Overwriting the shipped files under the same name is asking
>   for problem with source repositories and generating spurious diffs.
>
> All of the above problems are caused by a developer who insists on
> doing his own makefile style instead of following the kernel standards
> for makefiles.  Developers with their own standards are BAD!
>
> BTW, I have made repeated offers to rewrite the aic7xx makefiles for
> 2.4 but the aic7xxx maintainer refuses to do so.  I _will_ rewrite them
> in 2.5, as part of the kernel build 2.5 redesign.
>
> Keith Owens, kernel build maintainer.
>
> -
> 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: Coding style - a non-issue

[David S. Miller]

   From: Keith Owens <kaos@ocs.com.au>
   Date: Sat, 01 Dec 2001 12:17:03 +1100
   
   What is ugly in aic7xxx is :-

You missed:

* #undef's "current"

Re: Coding style - a non-issue

[Keith Owens]

On Sun, 02 Dec 2001 15:21:57 -0800 (PST), 
"David S. Miller" <davem@redhat.com> wrote:
>   From: Keith Owens <kaos@ocs.com.au>
>   Date: Sat, 01 Dec 2001 12:17:03 +1100
>   
>   What is ugly in aic7xxx is :-
>
>You missed:
>
>* #undef's "current"

Where?  fgrep -ir current 2.4.17-pre2/drivers/scsi/aic7xxx did not find it.

Re: Coding style - a non-issue

[Gérard Roudier]

On Mon, 3 Dec 2001, Keith Owens wrote:

> On Sun, 02 Dec 2001 15:21:57 -0800 (PST),
> "David S. Miller" <davem@redhat.com> wrote:
> >   From: Keith Owens <kaos@ocs.com.au>
> >   Date: Sat, 01 Dec 2001 12:17:03 +1100
> >
> >   What is ugly in aic7xxx is :-
> >
> >You missed:
> >
> >* #undef's "current"
>
> Where?  fgrep -ir current 2.4.17-pre2/drivers/scsi/aic7xxx did not find it.

What is ugly is "David S. Miller" ?

The 'Z' in the first name and the 'K' in the family name. :-)

  Gérard.

Re: Coding style - a non-issue

[Gérard Roudier]

On Tue, 4 Dec 2001, Gérard Roudier wrote:

>
> On Mon, 3 Dec 2001, Keith Owens wrote:
>
> > On Sun, 02 Dec 2001 15:21:57 -0800 (PST),
> > "David S. Miller" <davem@redhat.com> wrote:
> > >   From: Keith Owens <kaos@ocs.com.au>
> > >   Date: Sat, 01 Dec 2001 12:17:03 +1100
> > >
> > >   What is ugly in aic7xxx is :-
> > >
> > >You missed:
> > >
> > >* #undef's "current"
> >
> > Where?  fgrep -ir current 2.4.17-pre2/drivers/scsi/aic7xxx did not find it.
>
> What is ugly is "David S. Miller" ?
               ^^
Amusing mistake, I wanted to write 'in' instead of 'is'. :-)

>
> The 'Z' in the first name and the 'K' in the family name. :-)
>
>   Gérard.
>
>

Re: Coding style - a non-issue

[David S. Miller]

   
   On Mon, 3 Dec 2001, Keith Owens wrote:
   
   > On Sun, 02 Dec 2001 15:21:57 -0800 (PST),
   > "David S. Miller" <davem@redhat.com> wrote:
   > >   From: Keith Owens <kaos@ocs.com.au>
   > >   Date: Sat, 01 Dec 2001 12:17:03 +1100
   > >
   > >   What is ugly in aic7xxx is :-
   > >
   > >You missed:
   > >
   > >* #undef's "current"
   >
   > Where?  fgrep -ir current 2.4.17-pre2/drivers/scsi/aic7xxx did not find it.

OMFG, it's been fixed... this is amazing.  I am honestly shocked.

Re: Coding style - a non-issue

[Martin Dalecki]

Jeff Garzik wrote:
> 
> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems.  Yes, even BSD security guys do this :)
> 
> A "Top 10 ugliest Linux kernel drivers" list would probably provide
> similar motivation.

Yehh.... However some of the uglinesses results from ignorance
on behalf of the overall kernel maintainers, who don't care
to apply "cosmetic" changes to drivers, just to don't
irritate the oftes so called "maintainer". Two expierences:
ftape and mcd I'm through.... 

BTW.> ftape (for the pascal emulation) and DAC960 
(for the silly ICantReadThisCasing) 
are my personal "top ranks" in regard
of the contest for the most ugly code in the kernel...
serial.c is another one for the whole multiport support which
may be used by maybe 0.1% of the Linux users thrown on them all
and some "magic" number silliness as well...

Re: Coding style - a non-issue

[Russell King]

On Fri, Nov 30, 2001 at 06:20:40PM +0100, Martin Dalecki wrote:
> serial.c is another one for the whole multiport support which
> may be used by maybe 0.1% of the Linux users thrown on them all
> and some "magic" number silliness as well...

Magic number silliness is something that's gone with my replacement
serial drivers.  If multiport is such a problem, it can easily be
cleaned up.  I'll add that to my to do list for serial stuff.

Thanks.

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

Re: Coding style - a non-issue

[Martin Dalecki]

Russell King wrote:
> 
> On Fri, Nov 30, 2001 at 06:20:40PM +0100, Martin Dalecki wrote:
> > serial.c is another one for the whole multiport support which
> > may be used by maybe 0.1% of the Linux users thrown on them all
> > and some "magic" number silliness as well...
> 
> Magic number silliness is something that's gone with my replacement
> serial drivers.  If multiport is such a problem, it can easily be
> cleaned up.  I'll add that to my to do list for serial stuff.

Well sombeody really cares apparently! Thank's. Any pointers
where to ahve a look at it? BTW> Did you consider ther misc device
idea? (Hooking serial at to the misc device stuff).

Re: Coding style - a non-issue

[Russell King]

On Fri, Nov 30, 2001 at 06:49:01PM +0100, Martin Dalecki wrote:
> Well sombeody really cares apparently! Thank's.

Currently its a restructuring of serial.c to allow different uart type
ports to be driven without duplicating serial.c many times over.  (the
generic_serial didn't hack it either).

> Any pointers where to ahve a look at it?

I should probably put this on a web page somewhere 8)

  :pserver:cvs@pubcvs.arm.linux.org.uk:/mnt/src/cvsroot, module serial
  (no password)

> BTW> Did you consider ther misc device idea? (Hooking serial at to the
> misc device stuff).

I just caught that comment - I'll await your reply.

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

Re: Coding style - a non-issue

[Martin Dalecki]

Russell King wrote:
> 
> On Fri, Nov 30, 2001 at 06:49:01PM +0100, Martin Dalecki wrote:
> > Well sombeody really cares apparently! Thank's.
> 
> Currently its a restructuring of serial.c to allow different uart type
> ports to be driven without duplicating serial.c many times over.  (the
> generic_serial didn't hack it either).
> 
> > Any pointers where to ahve a look at it?
> 
> I should probably put this on a web page somewhere 8)
> 
>   :pserver:cvs@pubcvs.arm.linux.org.uk:/mnt/src/cvsroot, module serial
>   (no password)
> 
> > BTW> Did you consider ther misc device idea? (Hooking serial at to the
> > misc device stuff).
> 
> I just caught that comment - I'll await your reply.

I'm just right now looking at the code found above.
First of all: GREAT WORK! And then you are right a bit, I just don't
see too much code duplication between the particular drivers there.
However I still don't see the need to carrige the whole tty stuff just
to drive a mouse... but I don't see a solution right now.
I wouldn't be good to introduce a scatter heap of "micro" 
driver modules like the ALSA people did as well too..

However in serial/linux/drivers/serial/serial_clps711x.c
the following wonders me a bit:

#ifdef CONFIG_DEVFS_FS
	normal_name:		SERIAL_CLPS711X_NAME,
	callout_name:		CALLOUT_CLPS711X_NAME,
#else
	normal_name:		SERIAL_CLPS711X_NAME,
	callout_name:		CALLOUT_CLPS711X_NAME,
#endif

What is the ifdef supposed to be good for?

 
One other suggestion serial_code.c could be just serial.c or code.c
or main.c, since _xxxx.c should distinguish between particulart devices.
It was a bit clumy to find the entry-point for me...
And then we have in uart_register_driver:

	normal->open		= uart_open;
	normal->close		= uart_close;
	normal->write		= uart_write;
	normal->put_char	= uart_put_char;
	normal->flush_chars	= uart_flush_chars;
	normal->write_room	= uart_write_room;
	normal->chars_in_buffer	= uart_chars_in_buffer;
	normal->flush_buffer	= uart_flush_buffer;
	normal->ioctl		= uart_ioctl;
	normal->throttle	= uart_throttle;
	normal->unthrottle	= uart_unthrottle;
	normal->send_xchar	= uart_send_xchar;
	normal->set_termios	= uart_set_termios;
	normal->stop		= uart_stop;
	normal->start		= uart_start;
	normal->hangup		= uart_hangup;
	normal->break_ctl	= uart_break_ctl;
	normal->wait_until_sent	= uart_wait_until_sent;

And so on....

Why not do:

{
     static strcut tty_driver _normal = {
     open: uart_open,
     close: uart_close,
     ...
     };

     ...

     *normal = _normal;
}
...
for the static stuff first and only initialize the
dynamically calculated addresses dynamically later, like
the double refferences...
This would save already *quite a bit* of .text ;-).

Yeah I know I'm a bit perverse about optimizations....


You already do it for the callout device nearly this
way:

	/*
	 * The callout device is just like the normal device except for
	 * the major number and the subtype code.
	 */
	*callout		= *normal;
	callout->name		= drv->callout_name;
	callout->major		= drv->callout_major;
	callout->subtype	= SERIAL_TYPE_CALLOUT;
	callout->read_proc	= NULL;
	callout->proc_entry	= NULL;

Reagrds.

Re: Coding style - a non-issue

[Alan Cox]

> irritate the oftes so called "maintainer". Two expierences:
> ftape and mcd I'm through.... 

I timed the mcd maintainer out and tidied it anyway. I figured since it
wasnt being maintained nobody would scream too loudly - nobody has

> BTW.> ftape (for the pascal emulation) and DAC960 

ftape is an awkward one. Really the newer ftape4 wants merging into the
kernel but that should have happened a long time ago

> serial.c is another one for the whole multiport support which
> may be used by maybe 0.1% of the Linux users thrown on them all
> and some "magic" number silliness as well...

serial.c is a good example of the "ugly" that actually matters more, as is
floppy.c. Clean well formatted code that is stil opaque. 

Re: Coding style - a non-issue

[Martin Dalecki]

Alan Cox wrote:
> 
> > irritate the oftes so called "maintainer". Two expierences:
> > ftape and mcd I'm through....
> 
> I timed the mcd maintainer out and tidied it anyway. I figured since it
> wasnt being maintained nobody would scream too loudly - nobody has

Wenn sorry for the missconception I wanted to insult *you*, my expierenc
in regard to this is even older...

> > BTW.> ftape (for the pascal emulation) and DAC960
> 
> ftape is an awkward one. Really the newer ftape4 wants merging into the
> kernel but that should have happened a long time ago

It diverged too much from what's in the kernel since about already 3-4
years.
And I don't think that it's that much better in terms of implementation
style...
Fortunately all those floppy interface iomega streamers are 
physically obsolete by now. Plese notice that ftape4 is using a
different storage format, well this is due to the fact that the
ftape inside the kernel wasn't up to the corresponding standard
(QIO-80)...

> > serial.c is another one for the whole multiport support which
> > may be used by maybe 0.1% of the Linux users thrown on them all
> > and some "magic" number silliness as well...
> 
> serial.c is a good example of the "ugly" that actually matters more, as is
> floppy.c. Clean well formatted code that is stil opaque.

floppy.c is indeed one of the best compiler test cases around there.
But personally I would excuse floppy.c a bit becouse it's dealing with
a really awkward controller interface ;-).
serial.c should be hooked at the misc char device interface sooner or
later.
But somehow this never happened becouse nobody dared to care enough.

Re: Coding style - a non-issue

[Russell King]

On Fri, Nov 30, 2001 at 06:42:17PM +0100, Martin Dalecki wrote:
> serial.c should be hooked at the misc char device interface sooner or
> later.

Please explain.  Especially contentrate on justifing why serial interfaces
aren't a tty device.

Thanks.

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

Re: Coding style - a non-issue

[Martin Dalecki]

Russell King wrote:
> 
> On Fri, Nov 30, 2001 at 06:42:17PM +0100, Martin Dalecki wrote:
> > serial.c should be hooked at the misc char device interface sooner or
> > later.
> 
> Please explain.  Especially contentrate on justifing why serial interfaces
> aren't a tty device.

No problem ;-).

There is the hardware: in esp. the serial controller itself - this
belongs
to misc, becouse a mouse for example doesn't have to interpret any tty
stuff
This animal belongs to the same cage as the PS/2 variant of it.
And then there is one abstraction level above it: the tty interface -
this belongs to a line discipline.

We have this split anyway already there /dev/ttyS0 and /dev/cua0 somehow
emulated on one level.

Understood?

Re: Coding style - a non-issue

[Maciej W. Rozycki]

On Fri, 30 Nov 2001, Martin Dalecki wrote:

> > Please explain.  Especially contentrate on justifing why serial interfaces
> > aren't a tty device.
> 
> No problem ;-).
> 
> There is the hardware: in esp. the serial controller itself - this
> belongs
> to misc, becouse a mouse for example doesn't have to interpret any tty
> stuff

 The same applies to the console keyboard, which is hooked to a standard
UART on certain systems as well. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Coding style - a non-issue

[Russell King]

On Fri, Nov 30, 2001 at 07:40:29PM +0100, Maciej W. Rozycki wrote:
> The same applies to the console keyboard, which is hooked to a standard
> UART on certain systems as well. 

This particular point is up for discussion between myself and James Simmons
(and other interested parties).  We're getting there...

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

Re: Coding style - a non-issue

[antirez]

On Fri, Nov 30, 2001 at 11:47:28AM -0500, Jeff Garzik wrote:
> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems.  Yes, even BSD security guys do this :)

It's a bit different. Usually the security community uses it
when there isn't a way to fix the code (i.e. non-free code)
or when the maintaner of the code refused to fix the issue.
Also to "expose" the security problem isn't the same as
to flame.

While not a good idea, something like a long name
for a local var isn't a big problem like a completly
broken software with huge security holes used by milions of people
every day.

The quality of the code should be ensured in a different
way. If there is a standard coding-style you should either:

1) refuse to include broken code before the programmer fix it
2) fix it yourself before the inclusion

Flames aren't a good solution imho.

-- 
Salvatore Sanfilippo <antirez@invece.org>
http://www.kyuzz.org/antirez
finger antirez@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF

Re: Coding style - a non-issue

[Paul G. Allen]

antirez wrote:
> 
> On Fri, Nov 30, 2001 at 11:47:28AM -0500, Jeff Garzik wrote:
> > The security community has shown us time and again that public shaming
> > is often the only way to motivate vendors into fixing security
> > problems.  Yes, even BSD security guys do this :)
> 
> It's a bit different. Usually the security community uses it
> when there isn't a way to fix the code (i.e. non-free code)
> or when the maintaner of the code refused to fix the issue.
> Also to "expose" the security problem isn't the same as
> to flame.
> 
> While not a good idea, something like a long name
> for a local var isn't a big problem like a completly
> broken software with huge security holes used by milions of people
> every day.
> 

A variable/function name should ALWAYS be descriptive of the
variable/function purpose. If it takes a long name, so be it. At least
the next guy looking at it will know what it is for.

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[antirez]

On Fri, Nov 30, 2001 at 10:20:43AM -0800, Paul G. Allen wrote:
> antirez wrote:
> A variable/function name should ALWAYS be descriptive of the
> variable/function purpose. If it takes a long name, so be it. At least
> the next guy looking at it will know what it is for.

I agree, but descriptive != long

for (mydearcountr = 0; mydearcounter < n; mydearcounter++)

and it was just an example. Read it as "bad coding style".

-- 
Salvatore Sanfilippo <antirez@invece.org>
http://www.kyuzz.org/antirez
finger antirez@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF

Re: Coding style - a non-issue

[Paul G. Allen]

antirez wrote:
> 
> On Fri, Nov 30, 2001 at 10:20:43AM -0800, Paul G. Allen wrote:
> > antirez wrote:
> > A variable/function name should ALWAYS be descriptive of the
> > variable/function purpose. If it takes a long name, so be it. At least
> > the next guy looking at it will know what it is for.
> 
> I agree, but descriptive != long
> 
> for (mydearcountr = 0; mydearcounter < n; mydearcounter++)
> 
> and it was just an example. Read it as "bad coding style".
> 

Well if you're counting dear in the kernel, I'd say you have more
problems than your coding style. ;)

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[Jeff Garzik]

"Paul G. Allen" wrote:
> A variable/function name should ALWAYS be descriptive of the
> variable/function purpose. If it takes a long name, so be it. At least
> the next guy looking at it will know what it is for.

That's complete crap.  Human beings know and understand context, and can
use it effectively.  'idx' or 'i' or 'bh' may make perfect sense in
context.  There is absolutely no need for
JournalBHThatIsStoredAndSyncedWithSuperblock.

Kernel code like DAC960 proves that long variable names -decrease- code
readability.

	Jeff


-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: Coding style - a non-issue

[John Kodis]

On Fri, Nov 30, 2001 at 02:00:18PM -0500, Jeff Garzik wrote:

> Human beings know and understand context, and can use it
> effectively.  'idx' or 'i' or 'bh' may make perfect sense in
> context.  There is absolutely no need for
> JournalBHThatIsStoredAndSyncedWithSuperblock.

Mathematics has a rich tradition of using short variable names such as 
"pi" rather than something like "circle-circumference-to-diameter-ratio".
They keep formulas from becoming unreadably long, and have a meaning 
which is well understood in context.  While the long version may more
self-explainatory, it's the short form which is universally preferred.

-- John Kodis.

Re: Coding style - a non-issue

[Paul G. Allen]

John Kodis wrote:
> 
> On Fri, Nov 30, 2001 at 02:00:18PM -0500, Jeff Garzik wrote:
> 
> > Human beings know and understand context, and can use it
> > effectively.  'idx' or 'i' or 'bh' may make perfect sense in
> > context.  There is absolutely no need for
> > JournalBHThatIsStoredAndSyncedWithSuperblock.

JounalBH would be far better than i or idx.

> 
> Mathematics has a rich tradition of using short variable names such as
> "pi" rather than something like "circle-circumference-to-diameter-ratio".
> They keep formulas from becoming unreadably long, and have a meaning
> which is well understood in context.  While the long version may more
> self-explainatory, it's the short form which is universally preferred.
> 

While 'pi', 'e', 'theta', 'phi', etc. are universally understood, things
like 'i', 'a', and 'idx' are not. I can use these for anything I want
and even for more than one thing, and they say nothing about what they
are for. 'i', 'j', etc. are fine as loop counters and array indexes
where their meaning is apparent by context, but are _not_ fine in other
situations. You (or the person that wrote the code) may think that the
name is perfectly fine, but someone else that thinks a bit different may
not.

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[Kai Henningsen]

pgallen@randomlogic.com (Paul G. Allen)  wrote on 30.11.01 in <3C07EBB9.CF5EB85E@randomlogic.com>:

> John Kodis wrote:

> > Mathematics has a rich tradition of using short variable names such as
> > "pi" rather than something like "circle-circumference-to-diameter-ratio".
> > They keep formulas from becoming unreadably long, and have a meaning
> > which is well understood in context.  While the long version may more
> > self-explainatory, it's the short form which is universally preferred.

> While 'pi', 'e', 'theta', 'phi', etc. are universally understood, things
> like 'i', 'a', and 'idx' are not.

I'd certainly call 'i' well understood in both math and computing. In  
math, 'i' is what engineers call 'j' (i*i == -1), and in computing, 'i'  
('j', 'k', ...) is a counter for loops (some variant of int) that don't  
exceed about a screenful.

> I can use these for anything I want
> and even for more than one thing,

Of course, if you use them differently from what the convention is, *then*  
you are in trouble.

> and they say nothing about what they
> are for. 'i', 'j', etc. are fine as loop counters and array indexes
> where their meaning is apparent by context, but are _not_ fine in other
> situations. You (or the person that wrote the code) may think that the
> name is perfectly fine, but someone else that thinks a bit different may
> not.

Yup.


MfG Kai

Re: Coding style - a non-issue

[john slee]

On Fri, Nov 30, 2001 at 12:27:37PM -0800, Paul G. Allen wrote:
> While 'pi', 'e', 'theta', 'phi', etc. are universally understood, things
> like 'i', 'a', and 'idx' are not. I can use these for anything I want
> and even for more than one thing, and they say nothing about what they
> are for. 'i', 'j', etc. are fine as loop counters and array indexes
> where their meaning is apparent by context, but are _not_ fine in other

the meaning of 'i', 'j', 'k', is universal.  show me a real world
program (or programming book!) not from redmond that doesn't use these
names for loop counters.

j.

-- 
R N G G   "Well, there it goes again... And we just sit 
 I G G G   here without opposable thumbs." -- gary larson

Re: Coding style - a non-issue

[Paul G. Allen]

john slee wrote:
> 
> On Fri, Nov 30, 2001 at 12:27:37PM -0800, Paul G. Allen wrote:
> > While 'pi', 'e', 'theta', 'phi', etc. are universally understood, things
> > like 'i', 'a', and 'idx' are not. I can use these for anything I want
> > and even for more than one thing, and they say nothing about what they
> > are for. 'i', 'j', etc. are fine as loop counters and array indexes
> > where their meaning is apparent by context, but are _not_ fine in other
> 
> the meaning of 'i', 'j', 'k', is universal.  show me a real world
> program (or programming book!) not from redmond that doesn't use these
> names for loop counters.
> 

If you'd been paying attention, I discounted simple loop counters in an
early post.

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[Pavel Machek]

Hi!

> >> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> >> wankers (both individual and coprorat ones) responsible, their code and
> >> commentary on said code...
> 
> >Please, please, please, I'm begging you, please do this.  It's the only way
> >people learn quickly.  Being nice is great, but nothing works faster than 
> >a cold shower of public humiliation :-)
> 
> Cool. I can really see it. "foo inc." releases a GPL driver for Linux
> and gets publically humiliated in the "linux source code hall of
> shame". Perfect. I can hear the laughter from Redmond over here (and
> it is 12000km away).
> 
> Press release:
> 
> "If you support Linux, you may get flamed and humiliated in public for
> doing so. Don't do it."

And what? Bad driver is better than proprietary hardware, still good
driver is better than good driver.

And yes, I'd like to see that hall of shame.

								Pavel
-- 
"I do not steal MS software. It is not worth it."
                                -- Pavel Kankovsky

Re: Coding style - a non-issue

[David S. Miller]

   From: Alexander Viro <viro@math.psu.edu>
   Date: Wed, 28 Nov 2001 19:17:42 -0500 (EST)
   
   indent does _not_ solve the problem of:

Al, I think you just described the Intel e100 driver.
:-)

Re: Coding style - a non-issue

[Petko Manolov]

Alexander Viro wrote:

> 
>>Someone who cares, come up with an indentrc for the kernel code, and get it
>>into Documentation/CodingStyle

...

> indent does _not_ solve the problem of:
...


I quite liked it, applies perfectly for some people i know... :-)

Anyway, in Lindent you'll see "-psl" (--procname-start-lines) option
which contradict with what is written in CodingStyle i.e:

int my_proc(void)
{
...
}

which I personally prefer.


		Petko

Re: Coding style - a non-issue

[Matthias Andree]

On Wed, 28 Nov 2001, Alexander Viro wrote:

> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> wankers (both individual and coprorat ones) responsible, their code and
> commentary on said code...

Oh, can I vote for someone spoiling outside the Kernel? I have a
candidate for that one.

Seriously, don't waste your *p_time on that except people resist any
hints to CodingStyleIsForLameAssHackersIWantMyEDIT.COM for an extended
amount of *p_time.

-- 
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin

Re: Coding style - a non-issue

[Paul G. Allen]

Peter Waltenberg wrote:
> 
> The problem was solved years ago.
> 
> "man indent"
> 
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).
> 
> Then we can all get on with doing useful things.
> 

IMEO, there is but one source as reference for coding style: A book by
the name of "Code Complete". (Sorry, I can't remember the author and I
no longer have a copy. Maybe my Brother will chime in here and fill in
the blanks since he still has his copy.)

Outside of that, every place I have worked as a programmer, with a team
of programmers, had a style that was adhered to almost religiously. In
many cases the style closely followed "Code Complete". In the case of
the kernel, as Alan and others have mentioned, there IS a Linux kernel
coding style.

In 99% of the Linux code I have seen, the style does indeed "suck". Why?
Consider a new coder coming in for any given task. S/he knows nothing
about the kernel and needs to get up to speed quickly. S/he starts
browsing the source - the ONLY definitive explanation of what it does
and how it works - and finds:

 - Single letter variable names that aren't simple loop counters and
must ask "What the h*** are these for?"
 - No function/file comment headers explaining what the purpose of the
function/file is.
 - Very few comments at all, which is not necessarily bad except...
 - The code is not self documenting and without comments it takes an
hour to figure out what function Foo() does.
 - Opening curly braces at the end of a the first line of a large code
block making it extremely difficult to find where the code block begins
or ends.
 - Short variable/function names that someone thinks is descriptive but
really isn't.
 - Inconsistent coding style from one file to the next.
 - Other problems.

After all, the kernel must be maintained by a number of people and those
people will come and go. The only real way to keep bugs at a minimum,
efficiency at a maximum, and the learning curve for new coders
acceptable is consistent coding style and code that is easily
maintained. The things I note above are not a means to that end. Sure,
maybe Bob, the designer and coder of bobsdriver.o knows the code inside
and out without need of a single comment or descriptive
function/variable name, but what happens when Bob can no longer maintain
it? It's 10,000 lines of code, the kernel is useless without it, it
broke with kernel 2.6.0, and Joe, the new maintainer of bobsdriver.o, is
having a hell of a time figuring out what the damn thing does.

An extreme case? Maybe, but how many times does someone come in to
development and have to spend more hours than necessary trying to figure
out how things work (or are supposed to work) instead of actually
writing useful code?

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[John H. Robinson, IV]

On Fri, Nov 30, 2001 at 10:15:41AM -0800, Paul G. Allen wrote:
> 
> IMEO, there is but one source as reference for coding style: A book by
> the name of "Code Complete". (Sorry, I can't remember the author and I
> no longer have a copy. Maybe my Brother will chime in here and fill in
> the blanks since he still has his copy.)

Code Complete: A Practical Handbook of Software Construction.
Redmond, Wa.: Microsoft Press, 880 pages, 1993.
Retail price: $35.
ISBN: 1-55615-484-4.  

Steve McConnell

source: http://www.construx.com/stevemcc/cc.htm

-john

Re: Coding style - a non-issue

[Paul G. Allen]

"John H. Robinson, IV" wrote:
> 
> On Fri, Nov 30, 2001 at 10:15:41AM -0800, Paul G. Allen wrote:
> >
> > IMEO, there is but one source as reference for coding style: A book by
> > the name of "Code Complete". (Sorry, I can't remember the author and I
> > no longer have a copy. Maybe my Brother will chime in here and fill in
> > the blanks since he still has his copy.)
> 
> Code Complete: A Practical Handbook of Software Construction.
> Redmond, Wa.: Microsoft Press, 880 pages, 1993.
> Retail price: $35.
> ISBN: 1-55615-484-4.
> 

Thanks John. You beat my bro. to it. Of course, he's probably still in
bed since it's not even noon yet. :)

(Note to self: Order a new copy of the book. I should have done it last
night when I ordered 3 other programming books. :/)

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[Nestor Florez]

Book     : Code Complete
Author   : Steve McConnell
Publisher: Microsoft Press

Nestor :-)

----- Original Message -----
From: "Paul G. Allen" <pgallen@randomlogic.com>
To: "Linux kernel developer's mailing list" <linux-kernel@vger.kernel.org>;
<kplug-list@kernel-panic.org>; <kplug-lpsg@kernel-panic.org>
Sent: Friday, November 30, 2001 10:15 AM
Subject: Re: Coding style - a non-issue


> Peter Waltenberg wrote:
> >
> > The problem was solved years ago.
> >
> > "man indent"
> >
> > Someone who cares, come up with an indentrc for the kernel code, and get
it
> > into Documentation/CodingStyle
> > If the maintainers run all new code through indent with that indentrc
> > before checkin, the problem goes away.
> > The only one who'll incur any pain then is a code submitter who didn't
> > follow the rules. (Exactly the person we want to be in pain ;)).
> >
> > Then we can all get on with doing useful things.
> >
>
> IMEO, there is but one source as reference for coding style: A book by
> the name of "Code Complete". (Sorry, I can't remember the author and I
> no longer have a copy. Maybe my Brother will chime in here and fill in
> the blanks since he still has his copy.)
>
> Outside of that, every place I have worked as a programmer, with a team
> of programmers, had a style that was adhered to almost religiously. In
> many cases the style closely followed "Code Complete". In the case of
> the kernel, as Alan and others have mentioned, there IS a Linux kernel
> coding style.
>
> In 99% of the Linux code I have seen, the style does indeed "suck". Why?
> Consider a new coder coming in for any given task. S/he knows nothing
> about the kernel and needs to get up to speed quickly. S/he starts
> browsing the source - the ONLY definitive explanation of what it does
> and how it works - and finds:
>
>  - Single letter variable names that aren't simple loop counters and
> must ask "What the h*** are these for?"
>  - No function/file comment headers explaining what the purpose of the
> function/file is.
>  - Very few comments at all, which is not necessarily bad except...
>  - The code is not self documenting and without comments it takes an
> hour to figure out what function Foo() does.
>  - Opening curly braces at the end of a the first line of a large code
> block making it extremely difficult to find where the code block begins
> or ends.
>  - Short variable/function names that someone thinks is descriptive but
> really isn't.
>  - Inconsistent coding style from one file to the next.
>  - Other problems.
>
> After all, the kernel must be maintained by a number of people and those
> people will come and go. The only real way to keep bugs at a minimum,
> efficiency at a maximum, and the learning curve for new coders
> acceptable is consistent coding style and code that is easily
> maintained. The things I note above are not a means to that end. Sure,
> maybe Bob, the designer and coder of bobsdriver.o knows the code inside
> and out without need of a single comment or descriptive
> function/variable name, but what happens when Bob can no longer maintain
> it? It's 10,000 lines of code, the kernel is useless without it, it
> broke with kernel 2.6.0, and Joe, the new maintainer of bobsdriver.o, is
> having a hell of a time figuring out what the damn thing does.
>
> An extreme case? Maybe, but how many times does someone come in to
> development and have to spend more hours than necessary trying to figure
> out how things work (or are supposed to work) instead of actually
> writing useful code?
>
> PGA
> --
> Paul G. Allen
> UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
> Akamai Technologies, Inc.
> www.akamai.com

Re: Coding style - a non-issue

[Jeff Garzik]

"Paul G. Allen" wrote:
> IMEO, there is but one source as reference for coding style: A book by
> the name of "Code Complete". (Sorry, I can't remember the author and I
> no longer have a copy. Maybe my Brother will chime in here and fill in
> the blanks since he still has his copy.)

Hungarian notation???

That was developed by programmers with apparently no skill to
see/remember how a variable is defined.  IMHO in the Linux community
it's widely considered one of the worst coding styles possible.


> Outside of that, every place I have worked as a programmer, with a team
> of programmers, had a style that was adhered to almost religiously.

yes

> In 99% of the Linux code I have seen, the style does indeed "suck". Why?
> Consider a new coder coming in for any given task. S/he knows nothing
> about the kernel and needs to get up to speed quickly. S/he starts
> browsing the source - the ONLY definitive explanation of what it does
> and how it works - and finds:

99% is far and above the level of suck defined by most :)


>  - Single letter variable names that aren't simple loop counters and
> must ask "What the h*** are these for?"
>  - No function/file comment headers explaining what the purpose of the
> function/file is.
>  - Very few comments at all, which is not necessarily bad except...
>  - The code is not self documenting and without comments it takes an
> hour to figure out what function Foo() does.

We could definitely use a ton more comments... patches accepted.


>  - Opening curly braces at the end of a the first line of a large code
> block making it extremely difficult to find where the code block begins
> or ends.

use a decent editor


>  - Short variable/function names that someone thinks is descriptive but
> really isn't.

not all variable names need their purpose obvious to complete newbies. 
sometimes it takes time to understand the code's purpose, in which case
the variable names become incredibly descriptive.


> After all, the kernel must be maintained by a number of people and those
> people will come and go. The only real way to keep bugs at a minimum,
> efficiency at a maximum, and the learning curve for new coders
> acceptable is consistent coding style and code that is easily
> maintained. The things I note above are not a means to that end. Sure,
> maybe Bob, the designer and coder of bobsdriver.o knows the code inside
> and out without need of a single comment or descriptive
> function/variable name, but what happens when Bob can no longer maintain
> it? It's 10,000 lines of code, the kernel is useless without it, it
> broke with kernel 2.6.0, and Joe, the new maintainer of bobsdriver.o, is
> having a hell of a time figuring out what the damn thing does.

yes

	Jeff


-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: Coding style - a non-issue

[Paul G. Allen]

Jeff Garzik wrote:
> 
> 
> We could definitely use a ton more comments... patches accepted.
> 

I've actually thought of doing just that. :)

Alas, I'm too busy coding other things right now, so kernel stuff
(unless I need something to make the other project I'm working on
work/work better) will just have to wait. Hell, I'm even behind 2 or 3
kernel versions on the documentation I've been putting on my web site.
:(

> >  - Opening curly braces at the end of a the first line of a large code
> > block making it extremely difficult to find where the code block begins
> > or ends.
> 
> use a decent editor

A person shouldn't _need_ a decent editor to pick out the beginning/end
of a code block (or anything else for that matter). The problem is
exacerbated when such a block contains other blocks and quickly picking
out where each begins/ends becomes tiresome. I _do_ have excellent
editors, IDEs, and source code browsers and have used many different
kinds in many different jobs. They still can not replace what the human
eye and mind perceive.

> 
> >  - Short variable/function names that someone thinks is descriptive but
> > really isn't.
> 
> not all variable names need their purpose obvious to complete newbies.
> sometimes it takes time to understand the code's purpose, in which case
> the variable names become incredibly descriptive.

It should not take "time" to discover the purpose of _any_ variable or
function, or file, whether newbie or not. The point of coding is to
solve a problem, not perform an excersise in deductive or logical
reasoning before the problem (which usually involves further logical
reasoning) can be solved.

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[Jeff Garzik]

"Paul G. Allen" wrote:
> It should not take "time" to discover the purpose of _any_ variable or
> function, or file, whether newbie or not. The point of coding is to
> solve a problem, not perform an excersise in deductive or logical
> reasoning before the problem (which usually involves further logical
> reasoning) can be solved.

Part of the problem being solved by Linux kernel code is efficient long
term maintenance and efficient peer review.  Overly verbose code does
not solve these problems.

	Jeff


-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: Coding style - a non-issue

[David Weinehall]

On Fri, Nov 30, 2001 at 12:06:43PM -0800, Paul G. Allen wrote:

[snip]
> A person shouldn't _need_ a decent editor to pick out the beginning/end
> of a code block (or anything else for that matter). The problem is
> exacerbated when such a block contains other blocks and quickly picking
> out where each begins/ends becomes tiresome. I _do_ have excellent
> editors, IDEs, and source code browsers and have used many different
> kinds in many different jobs. They still can not replace what the human
> eye and mind perceive.

Uhhhm, knowing when a code block begins? Usually you'll notice this from
the indentation. It's quite hard not to notice a tabsized shift
to the right...

[snip]


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Coding style - a non-issue

[Paul G. Allen]

David Weinehall wrote:
> 
> On Fri, Nov 30, 2001 at 12:06:43PM -0800, Paul G. Allen wrote:
> 
> [snip]
> > A person shouldn't _need_ a decent editor to pick out the beginning/end
> > of a code block (or anything else for that matter). The problem is
> > exacerbated when such a block contains other blocks and quickly picking
> > out where each begins/ends becomes tiresome. I _do_ have excellent
> > editors, IDEs, and source code browsers and have used many different
> > kinds in many different jobs. They still can not replace what the human
> > eye and mind perceive.
> 
> Uhhhm, knowing when a code block begins? Usually you'll notice this from
> the indentation. It's quite hard not to notice a tabsized shift
> to the right...
> 

Whitespace can be placed almost anywhere and the program will still
compile. It can even be removed altogether. The only thing that keeps a
program legible is proper formatting. It's real damn easy to miss a
brace when the formatting is poor. And real easy to spend an hour trying
to figure out where that missing brace goes, that is after the hour you
spent figuring out that it was missing in the first place.

I guess some people Just Don't Get It. Some people just do not know how
to write maintainable code.

PGA
-- 
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Re: Coding style - a non-issue

[Tracy R Reed]

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

On Sat, Dec 01, 2001 at 01:29:14PM -0800, Paul G. Allen wrote:
> compile. It can even be removed altogether. The only thing that keeps a
> program legible is proper formatting. It's real damn easy to miss a
> brace when the formatting is poor. And real easy to spend an hour trying

And this is why Python has chosen the format that it has.

-- 
Tracy Reed      http://www.ultraviolet.org
"Every artist is a cannibal, every poet is a thief.
 They all kill their inspiration, and sing about the grief." - U2

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

Re: Coding style - a non-issue

[Mike Fedyk]

On Sat, Dec 01, 2001 at 01:29:14PM -0800, Paul G. Allen wrote:
> David Weinehall wrote:
> > 
> > On Fri, Nov 30, 2001 at 12:06:43PM -0800, Paul G. Allen wrote:
> > 
> > [snip]
> > > A person shouldn't _need_ a decent editor to pick out the beginning/end
> > > of a code block (or anything else for that matter). The problem is
> > > exacerbated when such a block contains other blocks and quickly picking
> > > out where each begins/ends becomes tiresome. I _do_ have excellent
> > > editors, IDEs, and source code browsers and have used many different
> > > kinds in many different jobs. They still can not replace what the human
> > > eye and mind perceive.
> > 
> > Uhhhm, knowing when a code block begins? Usually you'll notice this from
> > the indentation. It's quite hard not to notice a tabsized shift
> > to the right...
> > 
> 
> Whitespace can be placed almost anywhere and the program will still
> compile. It can even be removed altogether. The only thing that keeps a
> program legible is proper formatting. It's real damn easy to miss a
> brace when the formatting is poor. And real easy to spend an hour trying
> to figure out where that missing brace goes, that is after the hour you
> spent figuring out that it was missing in the first place.
>

Then when you get your hands on code like this you have two bugs to fix:

1) The origional problem you wanted to code up

2) Fix the formatting.

I suggest (yes, more work) that you run the code through the code normalizer
for that project and then look at the code produced from that.

That way, you will be able to see the code blocks in a standard way.  As you
look at the formatted code, you can program in the old indentation format.

When you're done, you have two patches.  One with the origional fix, and
another with the formatting improvements.

You'll probably want to get a concensus of what the other developers in the
project have agreed upon before you submit the formatting patch.  Much the
way this thread may turn out...

mf

Re: Coding style - a non-issue

[H. Peter Anvin]

Followup to:  <3C07D669.6C234598@mandrakesoft.com>
By author:    Jeff Garzik <jgarzik@mandrakesoft.com>
In newsgroup: linux.dev.kernel
>
> "Paul G. Allen" wrote:
> > IMEO, there is but one source as reference for coding style: A book by
> > the name of "Code Complete". (Sorry, I can't remember the author and I
> > no longer have a copy. Maybe my Brother will chime in here and fill in
> > the blanks since he still has his copy.)
> 
> Hungarian notation???
> 
> That was developed by programmers with apparently no skill to
> see/remember how a variable is defined.  IMHO in the Linux community
> it's widely considered one of the worst coding styles possible.
> 

Indeed.  What can you say for a technique which basically promotes
*reducing* abstraction and information hiding?

There is a reason why the Win64 ABI uses the same "int" and "long" as
Win32... (both are 32 bits.)  They added meaningless abstractions, and
didn't add abstractions where they needed to...

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Coding style - a non-issue

[Kai Henningsen]

hpa@zytor.com (H. Peter Anvin)  wrote on 30.11.01 in <9u8qtu$u2b$1@cesium.transmeta.com>:

> By author:    Jeff Garzik <jgarzik@mandrakesoft.com>

> > "Paul G. Allen" wrote:
> > > IMEO, there is but one source as reference for coding style: A book by
> > > the name of "Code Complete". (Sorry, I can't remember the author and I
> > > no longer have a copy. Maybe my Brother will chime in here and fill in
> > > the blanks since he still has his copy.)
> >
> > Hungarian notation???
> >
> > That was developed by programmers with apparently no skill to
> > see/remember how a variable is defined.  IMHO in the Linux community
> > it's widely considered one of the worst coding styles possible.
> >
>
> Indeed.  What can you say for a technique which basically promotes
> *reducing* abstraction and information hiding?
>
> There is a reason why the Win64 ABI uses the same "int" and "long" as
> Win32... (both are 32 bits.)  They added meaningless abstractions, and
> didn't add abstractions where they needed to...

Well, that doesn't necessarily make the idea itself completely crap just  
because the standard implementation is.

Sure, calling a variable "I point to a char! And by the way, I'm named  
Fritz" may be a bad idea, but in some situations it may well make sense to  
say that a certain variable is a container and another is a lock.

And it seems that sometimes, the kernel does just that. (pagecache_lock,  
page_list, just picking two fast examples from 2.4.0 mm)

But lpfilename is, indeed, fucking insane.


MfG Kai

Re: Coding style - a non-issue

[Andrew Morton]

Jeff Garzik wrote:
> 
> We could definitely use a ton more comments... patches accepted.
> 

Too late.  Useful comments go in during, or even before the code.

While we're on the coding style topic: ext2_new_block.

-

Re: Coding style - a non-issue

[Alexander Viro]

On Fri, 30 Nov 2001, Andrew Morton wrote:

> Jeff Garzik wrote:
> > 
> > We could definitely use a ton more comments... patches accepted.
> > 
> 
> Too late.  Useful comments go in during, or even before the code.
> 
> While we're on the coding style topic: ext2_new_block.

Yes.  I hope that new variant (see balloc.c,v) gets the thing into
better form, but then I'm obviously biased...

Re: Coding style - a non-issue

[Rik van Riel]

On Fri, 30 Nov 2001, Andrew Morton wrote:
> Jeff Garzik wrote:
> >
> > We could definitely use a ton more comments... patches accepted.
>
> Too late.  Useful comments go in during, or even before the code.

Indeed, patches with comment updates tend to get
discarded by Linus. ;(

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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

Re: Coding style - a non-issue

[Rik van Riel]

On Fri, 30 Nov 2001, Jeff Garzik wrote:
> "Paul G. Allen" wrote:
> > IMEO, there is but one source as reference for coding style: A book by
> > the name of "Code Complete". (Sorry, I can't remember the author and I
> > no longer have a copy. Maybe my Brother will chime in here and fill in
> > the blanks since he still has his copy.)
>
> Hungarian notation???
>
> That was developed by programmers with apparently no skill to
> see/remember how a variable is defined.  IMHO in the Linux community
> it's widely considered one of the worst coding styles possible.

If your functions are so large that you need hungarian
notation to figure out the type of each variable, chances
are forgetting the variable type isn't the biggest of your
problems ;)

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

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