On Wed, 26 Jul 1995, Louis-D. Dubeau wrote:
> >>>>> "JL" == Jim Lynch <jimlynch@netcom.com> writes:
>
> JL> I restate my point here (incase you missed it:) Documenting
> JL> the kernel is much more important than documenting the
> JL> configuration. (besides, as I recall from reading c.o.l.a,
> JL> someone already did a kernel config helper.)
>
> More people are likely to be confused by the configuration of Linux
> than by its internals. If you want to make Linux the most user
> friendly possible, you have to provide the simplest configuration
> interface possible.
It would be good if linux were the most user friendly possible, but I
still think kernel documentation is more important, by at least two
levels of magnitude.
> JL> Why should I bang my head against the wall reading C source
> JL> code and trying to understand it well enough to form english
> JL> language descriptions, when the authors _already_ understand
> JL> it, and could have done the job? That would be a waste of my
> JL> time, or it would be something for which I should get paid.
>
> It's like the Bible, the Coran, the Talmud, the Upanishads: you must
> read over and over until you attain enlightenment. :-) It is normal to
> feel disoriented when you first try to find your way in the code of a
> project for the first time. Eventually, you begin to see the big
> picture and you can find your way around in no time. The same is true
> in understanding the code. At first, it can take some time but you
> eventually begin to see patterns emerging.
We were on two different planets when the above exchange occured... not
that I havent been to that other one...
You're talking seeing- and knowing- chakras, while I'm talking about root
chakra. (Geez, did I _really_ say that?? English, please...) My interest
and survival issues do not depend on me understanding the kernel. I have
a moderate desire to do so, but I wanna use it and write apps (becoming
increasingly difficult with HJ changing libc around all the time...), not
write comments in order that I become enlightened. In your terms, it's
not my dharma...
(note to myself: stop discussing the kernel in terms of organized religeon)
> JL> Writing commentary is not fun as it is, without having to do
> JL> the underlying research as well. For me, writing commentary on
> JL> K&R format code is impossible, because it is impossible for me
> JL> to follow without thouroughly reformatting the code.
>
> This is a problem. You should be able to read _any_ kind of C code.
Here, we just plain don't agree. I think that if the braces do not line
up vertically, it doesn't make sense. Tabs are too big; four spaces is
enuf. (and don't try to change my mind on these points; waste of time)
> Documented code in OSes are the exception to the rule and they all use
> different coding style, beleive me.
I believe you, alright...
> Another usefull skill is being
> able to write code in any style.
I write in my style... I can read it and so can everyone else.
> If you submit code for Linux in
> Emacs formating default (2 spaces for idents), you are likely to upset
> the other developpers that will have to use your code because Linux
> code is usually formated with hard tabs.
> If you submit code formated
> with vi (hard tabs) for a project that uses Emacs default (spaces),
[it upsets others.]
That's really too bad since it comes under the category of "that's the
way it is"... but I'm not gonna be submitting diffs anytime soon, as you
may have guessed already. I just have this dream of reading a kernel
source file that's more docs than code (and not just at the top of the
file, nor even just at the top of each function, either.)