Re: Availability of kdb

[Jamie Lokier]

Rik van Riel wrote:
 The main difference between Linux and Netware here is the
 fact that Linux has a real userland, which can touch the
 pages on its own without going through the kernel.
 
 This causes "spontaneously" dirtied or accessed pages,
 meaning that we really want to use the hardware bits ...

Of course you don't _have_ to do things that way with a real userland.
You can take page faults and update your own bits.  I think some of the
ports actually do this.

But we prefer the hardware, even though in some cases software-driven
faults give better guidance to the paging heuristics.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Rik van Riel]

On Mon, 11 Sep 2000, Jamie Lokier wrote:
 Rik van Riel wrote:
  The main difference between Linux and Netware here is the
  fact that Linux has a real userland, which can touch the
  pages on its own without going through the kernel.
  
  This causes "spontaneously" dirtied or accessed pages,
  meaning that we really want to use the hardware bits ...
 
 Of course you don't _have_ to do things that way with a real
 userland. You can take page faults and update your own bits.  I
 think some of the ports actually do this.

Meaning you have to blindly unmap pages and see if they get
faulted back in again. I believe you need to do this trick
with the VAX (and OpenBSD and NetBSD still use this method).

 But we prefer the hardware, even though in some cases
 software-driven faults give better guidance to the paging
 heuristics.

The difference is a locked cycle vs. handling a page fault.
This isn't a very hard choice to make ;)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Rik van Riel]

On Mon, 11 Sep 2000, Jamie Lokier wrote:
 Jeff V. Merkey wrote:

  In NetWare, we didn't care if the page was touched or not since we
  used our own bits in field bits 11-9 to store page specific stuff,
  like whether the page was dirty or not.
 
 Linux does actually look at both bits, but the optimisation
 still applies.  Accessed in particular -- ptes are mapped on
 page faults so you know the page is about to be accessed.

The main difference between Linux and Netware here is the
fact that Linux has a real userland, which can touch the
pages on its own without going through the kernel.

This causes "spontaneously" dirtied or accessed pages,
meaning that we really want to use the hardware bits ...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 09:46:15 -0600, 
"Jeff V. Merkey" [EMAIL PROTECTED] wrote:
Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
of software that can quickly get out of sync if it's maintained
separately from the tree -- the speed at which changes occur in Linux
would render it a very difficult project to maintain.

Bullshit.  It takes me about 30 minutes for most 2.4 kernel patches to
see if kdb needs to be changed.  A combination of a decent source
control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and
compare source branches, a little bit of Perl to standardize the patch
and tkdiff to compare the old and new patches tells me very quickly if
I need to release a new kdb patch.  If the kernel changes might have
affected kdb then I compile and test, 1-5 hours depending on the extent
of the kernel changes.  Most of the time I don't bother compiling.

The kernel debuggers that are kept up to date get used.  The ones that
are used get feedback for kernel changes which keep them up to date.
kdb has taken off precisely because it is being kept up to date with
the kernel.  And if I miss something, I know that people will tell me.

Linus' dislike of the kernel debugger concept would also
assure that it would not be considered in design decisions moving
forward, which is probably the biggest disuader in the whole debate.

Irrelevant.  Linus can change any kernel interface in the developing
kernels at any time and does.  Half the time this breaks existing
kernel code, never mind external patches.  But we manage to keep up to
date with API changes.  kdb is very low level, no I/O, restricted VFS
and SMP dependencies.  My biggest problem is gcc changes, not the
kernel.

I don't spend money on things I believe are destined to fail.  Until Linus
changes his mind, there's no point ...

Destined to fail?  Tell that to all the people downloading and using
kdb and watch them laugh.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Keith,

If you are volunteering to maintain the MANOS debugger after I hack it
into Linux, then I accept.  I'll give you an ftp and telnet account on
vger.timpanogas.org and you can run with it.

:-)

Jeff

"Jeff V. Merkey" wrote:
 
 Who pays you?
 
 Keith Owens wrote:
 
  On Mon, 11 Sep 2000 09:46:15 -0600,
  "Jeff V. Merkey" [EMAIL PROTECTED] wrote:
  Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
  of software that can quickly get out of sync if it's maintained
  separately from the tree -- the speed at which changes occur in Linux
  would render it a very difficult project to maintain.
 
  Bullshit.  It takes me about 30 minutes for most 2.4 kernel patches to
  see if kdb needs to be changed.  A combination of a decent source
  control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and
  compare source branches, a little bit of Perl to standardize the patch
  and tkdiff to compare the old and new patches tells me very quickly if
  I need to release a new kdb patch.  If the kernel changes might have
  affected kdb then I compile and test, 1-5 hours depending on the extent
  of the kernel changes.  Most of the time I don't bother compiling.
 
 Who is paying for this, BTW.  Who pays your salary?
 
 
  The kernel debuggers that are kept up to date get used.  The ones that
  are used get feedback for kernel changes which keep them up to date.
  kdb has taken off precisely because it is being kept up to date with
  the kernel.  And if I miss something, I know that people will tell me.
 
 I'm sure this is all true.  kdb was just rejected by Linus however, what
 message does that send to you?
 
 
  Linus' dislike of the kernel debugger concept would also
  assure that it would not be considered in design decisions moving
  forward, which is probably the biggest disuader in the whole debate.
 
  Irrelevant.  Linus can change any kernel interface in the developing
  kernels at any time and does.  Half the time this breaks existing
  kernel code, never mind external patches.  But we manage to keep up to
  date with API changes.  kdb is very low level, no I/O, restricted VFS
  and SMP dependencies.  My biggest problem is gcc changes, not the
  kernel.
 
  I don't spend money on things I believe are destined to fail.  Until Linus
  changes his mind, there's no point ...
 
  Destined to fail?  Tell that to all the people downloading and using
  kdb and watch them laugh.
 
 kdb is about 1/100th the size of the MANOS debugger in terms of source
 code size, and isn't a hacked in after thought like kdb.  It uses task
 gates and other tables beneath the OS that just are not there in kdb and
 that will impinge on architectural freedom for Linus.  It also uses
 nested task gates, and requires changes to the xcall layer in Linux to
 plug it in.  If Linus doesn't support the concept, it could be a lot of
 work.  I know my code, you know yours -- Linus habit of breaking things
 as he puts in new and better features that you stated aealier is true,
 so where does that leave us?
 
 Jeff
 
 
  -
  To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
  the body of a message to [EMAIL PROTECTED]
  Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 16:19:14 -0600, 
"Jeff V. Merkey" [EMAIL PROTECTED] wrote:
Who pays you?  

I used to work on kdb in my own time, for free.  Then I joined SGI and
now I get paid to work on it.  If I left SGI I would continue to work
on kdb, the original kdb developer left SGI but still contributes.

 The kernel debuggers that are kept up to date get used.  The ones that
 are used get feedback for kernel changes which keep them up to date.
 kdb has taken off precisely because it is being kept up to date with
 the kernel.  And if I miss something, I know that people will tell me.

I'm sure this is all true.  kdb was just rejected by Linus however, what
message does that send to you?

That Linus does not like kernel debuggers.  This is news?  There are
several examples of code that Linus did not like originally but enough
people wanted them and they eventually got included in the kernel.
Complaining to Linus does nothing, "show me the code".

kdb is about 1/100th the size of the MANOS debugger in terms of source
code size, and isn't a hacked in after thought like kdb.  It uses task
gates and other tables beneath the OS that just are not there in kdb and
that will impinge on architectural freedom for Linus.  It also uses
nested task gates, and requires changes to the xcall layer in Linux to
plug it in.

kdb is not a hacked in after thought.  It was designed from scratch as
a minimalist kernel debugger which coexists with the existing kernel
design.  Note "minimalist", adding kdb to a kernel has little effect on
the running kernel, the biggest impact is the symbol table (adds 20-30%
to loaded kernel size) and the last branch recording in the page fault
handler which probably slows page faulting slightly, although I have
not measured it.

kdb does a reasonable job at the binary level which is exactly what it
was designed to do.  If you have to change the kernel design to
incorporate a debugger then you seriously need to think if your
debugger design is suitable.

If Linus doesn't support the concept, it could be a lot of
work.  I know my code, you know yours -- Linus habit of breaking things
as he puts in new and better features that you stated aealier is true,
so where does that leave us?

In exactly the same position as every other kernel developer.  Nobody
promised us that kernel APIs would remain stable in development
kernels, if it breaks we fix it in the next patch.  This is the Linux
development model, everyone else lives with it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 16:24:32 -0600, 
"Jeff V. Merkey" [EMAIL PROTECTED] wrote:
Keith,

If you are volunteering to maintain the MANOS debugger after I hack it
into Linux, then I accept.  I'll give you an ftp and telnet account on
vger.timpanogas.org and you can run with it.

How on earth did you make that jump?  I maintain kdb because I like it
and it has a lot of my code in it.  MANOS is your code, you maintain
it or persuade people to help you maintain it.  Show people the code
and see if they use it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

The code is at vger.timpanogas.org.  If you want to review it, it's
there.  We are posting another MANOS kernel with full VM end of the
month.  The version Darren and I are hacking on now has the debugger
broken out as a module as a prelude to put it in Linux.  I am working on
your kdb stubs in 2.4 to put it in.  Darren is finishing the VM
subsystem.

Jeff

Keith Owens wrote:
 
 On Mon, 11 Sep 2000 16:24:32 -0600,
 "Jeff V. Merkey" [EMAIL PROTECTED] wrote:
 Keith,
 
 If you are volunteering to maintain the MANOS debugger after I hack it
 into Linux, then I accept.  I'll give you an ftp and telnet account on
 vger.timpanogas.org and you can run with it.
 
 How on earth did you make that jump?  I maintain kdb because I like it
 and it has a lot of my code in it.  MANOS is your code, you maintain
 it or persuade people to help you maintain it.  Show people the code
 and see if they use it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

"David S. Miller" wrote:

Date:Sun, 10 Sep 2000 18:14:03 -0600
From: "Jeff V. Merkey" [EMAIL PROTECTED]

Linus' apparently did not understand this, or he would have
immediately realized that double locking was always generating a
second non-cacheable memory reference for every lock being taken
and released.

 Jeff, after working together with Linus for 6 or so years myself, I
 would make a large wager that Linus understands these issues much
 better than even you.

 But then again, as previously stated, I don't take you very seriously,
 but I fear that there are a few on this list who still do.

 Later,
 David S. Miller
 [EMAIL PROTECTED]

David,

You shouldn't fault me because I worked on commercial software for so
long.  I did the hardware profiling of this stuff in 1993 -- long before
Linux was even doing SMP.I spent many sleepless nights in Building F
on the Provo campus comparing 'mov   addr, 0' and "lock bts, addr' to
see what would happen.  Long before you guys had even written your first
spinlock ..

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

"Jeff V. Merkey" wrote:

 "David S. Miller" wrote:

 Date:Sun, 10 Sep 2000 18:14:03 -0600
 From: "Jeff V. Merkey" [EMAIL PROTECTED]
 
 Linus' apparently did not understand this, or he would have
 immediately realized that double locking was always generating a
 second non-cacheable memory reference for every lock being taken
 and released.
 
  Jeff, after working together with Linus for 6 or so years myself, I
  would make a large wager that Linus understands these issues much
  better than even you.
 
  But then again, as previously stated, I don't take you very seriously,
  but I fear that there are a few on this list who still do.
 
  Later,
  David S. Miller
  [EMAIL PROTECTED]

 David,

 You shouldn't fault me because I worked on commercial software for so
 long.  I did the hardware profiling of this stuff in 1993 -- long before
 Linux was even doing SMP.I spent many sleepless nights in Building F
 on the Provo campus comparing 'mov   addr, 0' and "lock bts, addr' to
 see what would happen.  Long before you guys had even written your first
 spinlock ..

 Jeff

Also -- your loyalty is admirable -- but that's all it is.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[David S. Miller]

   Date:Sun, 10 Sep 2000 18:14:03 -0600
   From: "Jeff V. Merkey" <[EMAIL PROTECTED]>

   Linus' apparently did not understand this, or he would have
   immediately realized that double locking was always generating a
   second non-cacheable memory reference for every lock being taken
   and released.

Jeff, after working together with Linus for 6 or so years myself, I
would make a large wager that Linus understands these issues much
better than even you.

But then again, as previously stated, I don't take you very seriously,
but I fear that there are a few on this list who still do.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Alexander Viro wrote:

> On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
>
> > already there, so folks can use it on Linux for now, and I'll stick to printk()
> > and code reviews for my debugging on Linux.
>
> Jeff, does it mean that you do not use code reviews on other projects?
>
> It's not that hard to answer - just 1 bit of information. The question
> being:
> Do you use code reviews in work on MANOS?

Yes, everyone does.  But there's a class of problems, like hardware and SMP bugs,
where a debugger can help you locate a bug more quickly or profile and observe
performance issues without needing to write tons of code to instrument this type of
monitoring.  I wrote MANOS soley with code reviews, but projects earlier in my
career, I used a lot of tools, like an American Arium Logic Analyser with an Inverse
Assembler and a decent kernel debugger.  The tools gave me the ability to rapidly
master and solve problems that were related to early SMP hardware, and gave me an
understanding.

To cite a Linux specific example, let's take the issue with the memory write for a
spin_unlock().  Linus seemed to have trouble grasping why a simple  ' mov,
0' would work as opposed to a 'lock dec '  Anyone who has ever spent late
nights with an American Arium Analyzer profiling memory bus transactions on a PPro
knows that MESI will correctly propogate via the processor caches a write to a
locked location with a correct load and stor oder without any problems of locking
concurrency.  Linus' apparently did not understand this, or he would have
immediately realized that double locking was always generating a second
non-cacheable memory reference for every lock being taken and released.

There's also hidden latencies in interrupts on Intel.  I know this because I have
watched bus transactions with an analyser and seen an interrupt generate reads of
the IDE, GDT,LDT, PDE, and other tables.  NetWare had a coding error I fixed with
this tool that noone had ever even noticed or caught with a code review.  The person
writing and updating page table entries in NetWare 4.1 was clearing the accessed bit
in the PTE and did not know that the processor would assert a hidden R/M/W operation
and assert a bus lock to set this bit everytime someone cleared it -- it made
performance drop 4% from NetWare 3.X and noone knew why.  This performance problem
would have never been found without this tool.2 years of code reviews did not
find it -- an American Ariun Analyser with a kernel debugger to stop and start and
instrument the code with writing custom stubs all over the place did.

Folks who just relay on code reviews never see this level of interaction, and
conversely, do not have the understnading of hardware behavior underneath an OS to
optimize it well.  That's my case for good tools in an OS.The performance of
Linux vs. NetWare and NT in LAN environments proves this point well.

:-)

Jeff.





>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Paul Jakma]

arrgghh jeff...

On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

> One of the principal architects at Compaq called me Friday after
> reading Linus' email about not caring about commercial or support
> issues for commercialization of Linux on this topic-- his right

yes it his right. he cares about the 'goodness' of the kernel. The
commercial and support issues he doesn't care about - that's the
domain of redhat/suse/compaq/etc../etc... and timpanogas (if you so
choose).

if you need debugger -> add it to your local tree/ship with a
debugger to your customers.

> contrary to his development philosophy, so it's probably a
> complete waste of my time.
> 

linux kernel hackers do the worrying about 'goodness'

but there is *nothing* that stops commerce adding tweaks to help with
support issues! (RedHat/SuSE/etc kernels are heavily patched and
tweaked!)

> Jeff.

-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
C'est magnifique, mais ce n'est pas l'Informatique.
-- Bosquet [on seeing the IBM 4341]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Alexander Viro]

On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

> already there, so folks can use it on Linux for now, and I'll stick to printk()
> and code reviews for my debugging on Linux.

Jeff, does it mean that you do not use code reviews on other projects?

It's not that hard to answer - just 1 bit of information. The question
being:
Do you use code reviews in work on MANOS?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Nathan Paul Simons wrote:

> On Sun, Sep 10, 2000 at 12:15:31AM -0700, J. Dow wrote:
> > Properly contemplated and I wonder at the hypocrisy of using a compiler
> > or an assembler instead of carefully hand crafted bits on a blank disk.
>
> i think you miss the point.  i think that Linus is trying to say
> something along the lines of "A hacker does for love what others would not do
> for money."  Think about it; who would you rather work with: someone who is
> there because they enjoy the work, truly thrive in the environment, and is
> pleasant to be around -or- someone who does it just because they're paid, they
> "only work here" and would prefer a debugger because it means they don't have
> to think as hard.
>

One of the principal architects at Compaq called me Friday after reading Linus'
email about not caring about commercial or support issues for commercialization
of Linux on this topic-- his right -- it had the anticipated impact I would
expect, and it's rippling through the industry.  This topic on kernel debuggers
and Linux kernel development philosophy has been an unknown to a lot of folks in
the commercial software world for a long time and now Linus has made some things
very clear.

Since Linus has rejected kdb there's every indication he will reject any other
kernel debugger submissions -- also his right.  I think my time would be better
spent completing the merge of the Linux code base onto MANOS since moving the
debugger over to Linux seems to not be something Linus would adopt and it's
contrary to his development philosophy, so it's probably a complete waste of my
time.

If I get time to create a patch for Linux, I'll put it up.  kdb seems to be
already there, so folks can use it on Linux for now, and I'll stick to printk()
and code reviews for my debugging on Linux.

:-)

Jeff.



>
> --
> Nathan Paul Simons, Programmer for FSMLabs
> http://www.fsmlabs.com/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Bob Taylor]

In message <[EMAIL PROTECTED]>, Nathan Paul 
Simons writes:
> On Sun, Sep 10, 2000 at 12:15:31AM -0700, J. Dow wrote:
> > Properly contemplated and I wonder at the hypocrisy of using a compiler
> > or an assembler instead of carefully hand crafted bits on a blank disk.
> 
>   i think you miss the point.  i think that Linus is trying to say
> something along the lines of "A hacker does for love what others would not do
> for money."  Think about it; who would you rather work with: someone who is
> there because they enjoy the work, truly thrive in the environment, and is
> pleasant to be around -or- someone who does it just because they're paid, the
>y
> "only work here" and would prefer a debugger because it means they don't have
> to think as hard.

If this is what Linus *actually* means then why didn't he *say* 
so? I personally believe this is what he meant.

Bob

-- 
+---+
| Bob Taylor Email: [EMAIL PROTECTED]|
|---|
| Like the ad says, at 300 dpi you can tell she's wearing a |
| swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you   |
| can tell it's painted on. I suppose at 2400 dpi you can tell  |
| if the paint is giving her a rash. (So says Joshua R. Poulson)|
+---+


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Nathan Paul Simons]

On Sun, Sep 10, 2000 at 12:15:31AM -0700, J. Dow wrote:
> Properly contemplated and I wonder at the hypocrisy of using a compiler
> or an assembler instead of carefully hand crafted bits on a blank disk.

i think you miss the point.  i think that Linus is trying to say
something along the lines of "A hacker does for love what others would not do
for money."  Think about it; who would you rather work with: someone who is
there because they enjoy the work, truly thrive in the environment, and is
pleasant to be around -or- someone who does it just because they're paid, they
"only work here" and would prefer a debugger because it means they don't have
to think as hard.

-- 
Nathan Paul Simons, Programmer for FSMLabs
http://www.fsmlabs.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Aki M Laukkanen]

On Sun, 10 Sep 2000, Horst von Brand wrote:
> I've found more bugs by "working half crippled" (as you call it). I do
> agree with Linus that people who rely mainly on debuggers for finding and
> fixing bugs are on the whole bad programmers, I've had to deal with more

I've resisted from participating this thread but as it seems to drag forever,
what the heck (probably a bad move). Your argument has the flaw that all
programmers using debuggers are bad programmers, programmers who have
no self-discipline, no guts to actually find out what was wrong. Just as any
tool, debuggers can be abused but they should not be condemned on that basis
alone. 

On another note, I think even those bad, lazy programmers are intelligent
enough to find kdb on the net and patch it into their kernels. The mere
availability of the tools then should be enough for explosion of bad code
but has this happened? On the other hand, those people who are not
knowledgeable enough to mess with patches, system administrators or end
users have no access to the tools when they need it. For example for a 
driver author who is trying to debug a problem he can't reproduce by
himself, it would be useful to instruct the bug reporter to enter the
debugger, execute these commands and mail the results back to himself.
Debugger would simply be a tool to get wider knowledge of the kernel state
than a simple oops dump. 

Dave Miller explains his methods for finding and fixing bugs in the code
which seem logical enough but who gets to decide what's enough knowledge of
the kernel state? Currently it is oops and nothing but the oops. If taken
to its logical extreme, one could argue that oopses should be removed too.
Afterall they perform the same function as printing the register
dump and the stack backtrace in a debugger would.

-- 
D.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Horst von Brand]

"J. Dow" <[EMAIL PROTECTED]> said:

[...]

> And for my severely depreciated $0.02 I am becoming concerned
> that these guys are more concerned about some macho ideal of
> generating programs while half crippled than about having things
> work properly and maintainably no matter what gets in the way.

The problem is that yes, debuggers are useful tools. But they are _not_
general-purpose tools, very far from it. Yes, I've found my share of bugs
in programs using debuggers. But by far (I'd say by some 10 times or so)
I've found more bugs by "working half crippled" (as you call it). I do
agree with Linus that people who rely mainly on debuggers for finding and
fixing bugs are on the whole bad programmers, I've had to deal with more
than enough students working that way and just applying random symptom
fixes until the program didn't crash anymore or even did finally pass a
(very limited) set of testcases. It is rare cases where a debugger is of
real help, and for a kernel even more rare cases than in the heaven of
userland programming, where no other thread messes up your variables, and
where execution is deterministic.

Please remember that Linus' workload is staggering as it is; if you throw
in 20 times as many patches as he gets today, of which 99% are bandaids
over the symtoms of the bug, nothing at all will get done.

> Art has flaws in it that have been painted over, often two or three
> times. I grew up with a giant painting of Beethoven along side the
> dinner table. It had been presented to my step-grandfather by
> the Leipzig Symphony Orchestra. It captured the brooding artist
> wonderfully. And in humid weather you could see his third hand,
> the one the artist didn't like and painted over.

Yep. linux-1.0 is long history. There might be a few lines of it
surviving somewhere in the current kernel...

> For all the zen meditation on code I begin to wonder how many of
> the fixes really are fixes or painted over features that didn't quite
> work out. It worries me no small bit.

Check the result: Does it feel like a cobbled up mess that just happens to
work by chance? AFAIKS, the result shows that Linus' development strategy
works extremely well most of the time. You might not like parts of it, it
isn't exactly politically correct, and isn't buzzword-compliant either, but
it works.

In the end, this is Linus' game. If you want to play, you'll have to pay the
admission price he sets. As it is GPL, you could fork the kernel, add a GUI
debugger to it, and open your own shop.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Daniel Phillips]

Linus Torvalds wrote:
> 
> It's not whether you can use tools to do the work.
> 
> It's about what kind of people you get.

This makes a lot of sense.  Stop there and you are done.  But...

> ...in the end, maybe the rule to only use hand power makes sense. Not
> because hand-power is _better_. But because it brings in the kind of
> people who love to work with their hands, who love to _feel_ the wood with
> their fingers, and because of that their holes are not always perfectly
> aligned, not always at the same place. The kind of carpenter that looks at
> the grain of the wood, and allows the grain of the wood to help form the
> finished product.

This argument would make a lot more sense if we were still building
wooden airplanes.  But our wooden airplane is already built, and it
flys great.  Now we are going on to build a metal airplane which we
hope will fly higher and faster.  Yes, the old tools and techniques
still work, but they aren't necessarily well-suited to the task.

Arguing that hand tools are somehow better than power tools is... just
an argument.  It does not matter which kind of tool is better, because
both are available.  In contrast, the social engineering part does
matter - after all, would you want to attract someone to kernel
development who refused to use a tool just because it didn't come
pre-installed?  And look at the quality of the people now working on
the kernel - something has been done right.  

The result of this thread is that at least one participant (Jeff) has
been inspired to build a new-and-better kernel debugger for Linux.  If
that work comes to fruition (1) I will most happily use it and (2) the
discussion was worth it.  I don't give a rat's fuzzy behind who won
the argument.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Andrew Morton]

Michael Elizabeth Chastain wrote:
> 
> Rather than discussing what he's said, I ask: OK, if an integrated kernel
> debugger is inimical to developing more gurus, what contributions would
> Linus welcome?
> 
> More documentation, so that more people can understand more deeply?
> 
> Cleanup patches, to reduce the complexity that people have to wade through?
> Linus already seems very friendly to such patches (except when he's
> trying to push out a stable release).
> 
> More commentary with submitted patches?  Russ Nelson used to write linux
> kernel patch summaries, and so did I.  It would be a lot easier if
> the people who wrote the patches wrote that commentary, and if it
> were kept with the patches or near the patches.
> 
> A source control system so that curious people could do the equivalent of
> "cvs annotate" and figure out who wrote particular pieces?

Comments.  You know, these things:

/* Stuff goes here */

Comments communicate the design intent.  Code communicates the
implementation.  The process of finding discrepancies between these is
known as "debugging".

The process of divining the design intent from the implementation is
known as "a waste of time", and is frequently impossible because of
information loss.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Michael Elizabeth Chastain]

OK, I give in, I'll post some opinions in this advocacy-like thread.

One of the original connotations of "hacker" was someone who made
furniture with an axe.

There is a difference between a debugger and a compiler.  A compiler
never substitutes for understanding.  In fact, I gain more understanding
from reading C source code than I would from reading handcrafted machine
code or handcrafted assembly code.

Lastly, I believe Linus has said two things: (1) he prefers to work with
people who deeply understand the part of Linux that they work on, and (2)
he believes that an integrated kernel debugger would be detrimental to
(1).

Rather than discussing what he's said, I ask: OK, if an integrated kernel
debugger is inimical to developing more gurus, what contributions would
Linus welcome?

More documentation, so that more people can understand more deeply?

Cleanup patches, to reduce the complexity that people have to wade through?
Linus already seems very friendly to such patches (except when he's
trying to push out a stable release).

More commentary with submitted patches?  Russ Nelson used to write linux
kernel patch summaries, and so did I.  It would be a lot easier if
the people who wrote the patches wrote that commentary, and if it
were kept with the patches or near the patches.

A source control system so that curious people could do the equivalent of
"cvs annotate" and figure out who wrote particular pieces?

Michael Elizabeth Chastain

"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[John Alvord]

On Sun, 10 Sep 2000 00:23:43 -0700, "J. Dow" <[EMAIL PROTECTED]>
wrote:

>From: "Stephen E. Clark" <[EMAIL PROTECTED]>
>
>> Linus Torvalds wrote:
>> >
>> > On Sat, 9 Sep 2000, Oliver Xymoron wrote:
>> > >
>> > > Tools are tools. They don't make better code. They make better code easier
>> > > if used properly.
>> >
>> > I think you missed the point of my original reply completely.
>> >
>> > The _technical_ side of the tool in question is completely secondary.
>> >
>> > The social engineering side is very real, and immediate.
>> ...
>>
>> > Linus
>> >
>>
>> Then why don't we get rid of the compilers and assemblers and go back to
>> the old way of doing it
>> all - coding on the bare metal. Believe it or not at one time it was
>> done this way. Imagine where
>> we would be if everyone had said lets not invent tools to make ourselves
>> more productive.
>>
>> My $.02
>>
>> Steve Clark
>
>And for my severely depreciated $0.02 I am becoming concerned
>that these guys are more concerned about some macho ideal of
>generating programs while half crippled than about having things
>work properly and maintainably no matter what gets in the way.
>Art has flaws in it that have been painted over, often two or three
>times. I grew up with a giant painting of Beethoven along side the
>dinner table. It had been presented to my step-grandfather by
>the Leipzig Symphony Orchestra. It captured the brooding artist
>wonderfully. And in humid weather you could see his third hand,
>the one the artist didn't like and painted over.
>
>For all the zen meditation on code I begin to wonder how many of
>the fixes really are fixes or painted over features that didn't quite
>work out. It worries me no small bit.
>
> and here I thought macho didnt' fit well with people who
>used their brains. I see it is as alive and well here as on the
>streets of East LA.
>
>{O.O}

How can anyone judge that a debugger was used in development of a
patch, along with system understanding, Linux knowledge, etc? The
changed code stands along with no provenance. If it reflects a shallow
understanding, it will be rejected. If it is a deep elegant fix, that
will stand on its merits.

john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Stephen E. Clark" <[EMAIL PROTECTED]>

> Linus Torvalds wrote:
> >
> > On Sat, 9 Sep 2000, Oliver Xymoron wrote:
> > >
> > > Tools are tools. They don't make better code. They make better code easier
> > > if used properly.
> >
> > I think you missed the point of my original reply completely.
> >
> > The _technical_ side of the tool in question is completely secondary.
> >
> > The social engineering side is very real, and immediate.
> ...
>
> > Linus
> >
>
> Then why don't we get rid of the compilers and assemblers and go back to
> the old way of doing it
> all - coding on the bare metal. Believe it or not at one time it was
> done this way. Imagine where
> we would be if everyone had said lets not invent tools to make ourselves
> more productive.
>
> My $.02
>
> Steve Clark

And for my severely depreciated $0.02 I am becoming concerned
that these guys are more concerned about some macho ideal of
generating programs while half crippled than about having things
work properly and maintainably no matter what gets in the way.
Art has flaws in it that have been painted over, often two or three
times. I grew up with a giant painting of Beethoven along side the
dinner table. It had been presented to my step-grandfather by
the Leipzig Symphony Orchestra. It captured the brooding artist
wonderfully. And in humid weather you could see his third hand,
the one the artist didn't like and painted over.

For all the zen meditation on code I begin to wonder how many of
the fixes really are fixes or painted over features that didn't quite
work out. It worries me no small bit.

 and here I thought macho didnt' fit well with people who
used their brains. I see it is as alive and well here as on the
streets of East LA.

{O.O}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Linus Torvalds" <[EMAIL PROTECTED]>
> Yes, using a power-drill and other tools makes a lot of carpentry easier.
> To the point that a lot of carpenters don't even use their hands much any
> more. Almost all the "carpentry" today is 99% automated, and sure, it
> works wonderfuly - especially as you in carpentry cannot do it any other
> way if you want to mass-produce stuff.
> 
> But take a moment to look at it the other way. 
> 
> If you want to find the true carpenters today, what do you do? Not just "a
> carpenter". But THE carpenter.
> 
> I'm saying that maybe you put up a carpentry shop where everything is
> lovingly hand-crafted and tools are not considered to be the most
> important part - or even necessarily good. And yes, some people
> (carpenters in every sense of the word) will be frustrated. They can't use
> the power-lathe that they are used to. It doesn't suit them. They _know_
> that they are missing something.
> 
> But in the end, maybe the rule to only use hand power makes sense. Not
> because hand-power is _better_. But because it brings in the kind of
> people who love to work with their hands, who love to _feel_ the wood with
> their fingers, and because of that their holes are not always perfectly
> aligned, not always at the same place. The kind of carpenter that looks at
> the grain of the wood, and allows the grain of the wood to help form the
> finished product.
> 
> The kind of carpenter who, in a word, is more than _just_ a carpenter.
> 
>   [ Insert a silent minute to contemplate the beaty of the world here. ]

Properly contemplated and I wonder at the hypocrisy of using a compiler
or an assembler instead of carefully hand crafted bits on a blank disk.

{o.o}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Linus Torvalds" [EMAIL PROTECTED]
 Yes, using a power-drill and other tools makes a lot of carpentry easier.
 To the point that a lot of carpenters don't even use their hands much any
 more. Almost all the "carpentry" today is 99% automated, and sure, it
 works wonderfuly - especially as you in carpentry cannot do it any other
 way if you want to mass-produce stuff.
 
 But take a moment to look at it the other way. 
 
 If you want to find the true carpenters today, what do you do? Not just "a
 carpenter". But THE carpenter.
 
 I'm saying that maybe you put up a carpentry shop where everything is
 lovingly hand-crafted and tools are not considered to be the most
 important part - or even necessarily good. And yes, some people
 (carpenters in every sense of the word) will be frustrated. They can't use
 the power-lathe that they are used to. It doesn't suit them. They _know_
 that they are missing something.
 
 But in the end, maybe the rule to only use hand power makes sense. Not
 because hand-power is _better_. But because it brings in the kind of
 people who love to work with their hands, who love to _feel_ the wood with
 their fingers, and because of that their holes are not always perfectly
 aligned, not always at the same place. The kind of carpenter that looks at
 the grain of the wood, and allows the grain of the wood to help form the
 finished product.
 
 The kind of carpenter who, in a word, is more than _just_ a carpenter.
 
   [ Insert a silent minute to contemplate the beaty of the world here. ]

Properly contemplated and I wonder at the hypocrisy of using a compiler
or an assembler instead of carefully hand crafted bits on a blank disk.

{o.o}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Stephen E. Clark" [EMAIL PROTECTED]

 Linus Torvalds wrote:
 
  On Sat, 9 Sep 2000, Oliver Xymoron wrote:
  
   Tools are tools. They don't make better code. They make better code easier
   if used properly.
 
  I think you missed the point of my original reply completely.
 
  The _technical_ side of the tool in question is completely secondary.
 
  The social engineering side is very real, and immediate.
 ...

  Linus
 

 Then why don't we get rid of the compilers and assemblers and go back to
 the old way of doing it
 all - coding on the bare metal. Believe it or not at one time it was
 done this way. Imagine where
 we would be if everyone had said lets not invent tools to make ourselves
 more productive.

 My $.02

 Steve Clark

And for my severely depreciated $0.02 I am becoming concerned
that these guys are more concerned about some macho ideal of
generating programs while half crippled than about having things
work properly and maintainably no matter what gets in the way.
Art has flaws in it that have been painted over, often two or three
times. I grew up with a giant painting of Beethoven along side the
dinner table. It had been presented to my step-grandfather by
the Leipzig Symphony Orchestra. It captured the brooding artist
wonderfully. And in humid weather you could see his third hand,
the one the artist didn't like and painted over.

For all the zen meditation on code I begin to wonder how many of
the fixes really are fixes or painted over features that didn't quite
work out. It worries me no small bit.

sigh and here I thought macho didnt' fit well with people who
used their brains. I see it is as alive and well here as on the
streets of East LA.

{O.O}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[John Alvord]

On Sun, 10 Sep 2000 00:23:43 -0700, "J. Dow" [EMAIL PROTECTED]
wrote:

From: "Stephen E. Clark" [EMAIL PROTECTED]

 Linus Torvalds wrote:
 
  On Sat, 9 Sep 2000, Oliver Xymoron wrote:
  
   Tools are tools. They don't make better code. They make better code easier
   if used properly.
 
  I think you missed the point of my original reply completely.
 
  The _technical_ side of the tool in question is completely secondary.
 
  The social engineering side is very real, and immediate.
 ...

  Linus
 

 Then why don't we get rid of the compilers and assemblers and go back to
 the old way of doing it
 all - coding on the bare metal. Believe it or not at one time it was
 done this way. Imagine where
 we would be if everyone had said lets not invent tools to make ourselves
 more productive.

 My $.02

 Steve Clark

And for my severely depreciated $0.02 I am becoming concerned
that these guys are more concerned about some macho ideal of
generating programs while half crippled than about having things
work properly and maintainably no matter what gets in the way.
Art has flaws in it that have been painted over, often two or three
times. I grew up with a giant painting of Beethoven along side the
dinner table. It had been presented to my step-grandfather by
the Leipzig Symphony Orchestra. It captured the brooding artist
wonderfully. And in humid weather you could see his third hand,
the one the artist didn't like and painted over.

For all the zen meditation on code I begin to wonder how many of
the fixes really are fixes or painted over features that didn't quite
work out. It worries me no small bit.

sigh and here I thought macho didnt' fit well with people who
used their brains. I see it is as alive and well here as on the
streets of East LA.

{O.O}

How can anyone judge that a debugger was used in development of a
patch, along with system understanding, Linux knowledge, etc? The
changed code stands along with no provenance. If it reflects a shallow
understanding, it will be rejected. If it is a deep elegant fix, that
will stand on its merits.

john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Andrew Morton]

Michael Elizabeth Chastain wrote:
 
 Rather than discussing what he's said, I ask: OK, if an integrated kernel
 debugger is inimical to developing more gurus, what contributions would
 Linus welcome?
 
 More documentation, so that more people can understand more deeply?
 
 Cleanup patches, to reduce the complexity that people have to wade through?
 Linus already seems very friendly to such patches (except when he's
 trying to push out a stable release).
 
 More commentary with submitted patches?  Russ Nelson used to write linux
 kernel patch summaries, and so did I.  It would be a lot easier if
 the people who wrote the patches wrote that commentary, and if it
 were kept with the patches or near the patches.
 
 A source control system so that curious people could do the equivalent of
 "cvs annotate" and figure out who wrote particular pieces?

Comments.  You know, these things:

/* Stuff goes here */

Comments communicate the design intent.  Code communicates the
implementation.  The process of finding discrepancies between these is
known as "debugging".

The process of divining the design intent from the implementation is
known as "a waste of time", and is frequently impossible because of
information loss.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Daniel Phillips]

Linus Torvalds wrote:
 
 It's not whether you can use tools to do the work.
 
 It's about what kind of people you get.

This makes a lot of sense.  Stop there and you are done.  But...

 ...in the end, maybe the rule to only use hand power makes sense. Not
 because hand-power is _better_. But because it brings in the kind of
 people who love to work with their hands, who love to _feel_ the wood with
 their fingers, and because of that their holes are not always perfectly
 aligned, not always at the same place. The kind of carpenter that looks at
 the grain of the wood, and allows the grain of the wood to help form the
 finished product.

This argument would make a lot more sense if we were still building
wooden airplanes.  But our wooden airplane is already built, and it
flys great.  Now we are going on to build a metal airplane which we
hope will fly higher and faster.  Yes, the old tools and techniques
still work, but they aren't necessarily well-suited to the task.

Arguing that hand tools are somehow better than power tools is... just
an argument.  It does not matter which kind of tool is better, because
both are available.  In contrast, the social engineering part does
matter - after all, would you want to attract someone to kernel
development who refused to use a tool just because it didn't come
pre-installed?  And look at the quality of the people now working on
the kernel - something has been done right.  

The result of this thread is that at least one participant (Jeff) has
been inspired to build a new-and-better kernel debugger for Linux.  If
that work comes to fruition (1) I will most happily use it and (2) the
discussion was worth it.  I don't give a rat's fuzzy behind who won
the argument.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Horst von Brand]

"J. Dow" [EMAIL PROTECTED] said:

[...]

 And for my severely depreciated $0.02 I am becoming concerned
 that these guys are more concerned about some macho ideal of
 generating programs while half crippled than about having things
 work properly and maintainably no matter what gets in the way.

The problem is that yes, debuggers are useful tools. But they are _not_
general-purpose tools, very far from it. Yes, I've found my share of bugs
in programs using debuggers. But by far (I'd say by some 10 times or so)
I've found more bugs by "working half crippled" (as you call it). I do
agree with Linus that people who rely mainly on debuggers for finding and
fixing bugs are on the whole bad programmers, I've had to deal with more
than enough students working that way and just applying random symptom
fixes until the program didn't crash anymore or even did finally pass a
(very limited) set of testcases. It is rare cases where a debugger is of
real help, and for a kernel even more rare cases than in the heaven of
userland programming, where no other thread messes up your variables, and
where execution is deterministic.

Please remember that Linus' workload is staggering as it is; if you throw
in 20 times as many patches as he gets today, of which 99% are bandaids
over the symtoms of the bug, nothing at all will get done.

 Art has flaws in it that have been painted over, often two or three
 times. I grew up with a giant painting of Beethoven along side the
 dinner table. It had been presented to my step-grandfather by
 the Leipzig Symphony Orchestra. It captured the brooding artist
 wonderfully. And in humid weather you could see his third hand,
 the one the artist didn't like and painted over.

Yep. linux-1.0 is long history. There might be a few lines of it
surviving somewhere in the current kernel...

 For all the zen meditation on code I begin to wonder how many of
 the fixes really are fixes or painted over features that didn't quite
 work out. It worries me no small bit.

Check the result: Does it feel like a cobbled up mess that just happens to
work by chance? AFAIKS, the result shows that Linus' development strategy
works extremely well most of the time. You might not like parts of it, it
isn't exactly politically correct, and isn't buzzword-compliant either, but
it works.

In the end, this is Linus' game. If you want to play, you'll have to pay the
admission price he sets. As it is GPL, you could fork the kernel, add a GUI
debugger to it, and open your own shop.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Aki M Laukkanen]

On Sun, 10 Sep 2000, Horst von Brand wrote:
 I've found more bugs by "working half crippled" (as you call it). I do
 agree with Linus that people who rely mainly on debuggers for finding and
 fixing bugs are on the whole bad programmers, I've had to deal with more

I've resisted from participating this thread but as it seems to drag forever,
what the heck (probably a bad move). Your argument has the flaw that all
programmers using debuggers are bad programmers, programmers who have
no self-discipline, no guts to actually find out what was wrong. Just as any
tool, debuggers can be abused but they should not be condemned on that basis
alone. 

On another note, I think even those bad, lazy programmers are intelligent
enough to find kdb on the net and patch it into their kernels. The mere
availability of the tools then should be enough for explosion of bad code
but has this happened? On the other hand, those people who are not
knowledgeable enough to mess with patches, system administrators or end
users have no access to the tools when they need it. For example for a 
driver author who is trying to debug a problem he can't reproduce by
himself, it would be useful to instruct the bug reporter to enter the
debugger, execute these commands and mail the results back to himself.
Debugger would simply be a tool to get wider knowledge of the kernel state
than a simple oops dump. 

Dave Miller explains his methods for finding and fixing bugs in the code
which seem logical enough but who gets to decide what's enough knowledge of
the kernel state? Currently it is oops and nothing but the oops. If taken
to its logical extreme, one could argue that oopses should be removed too.
Afterall they perform the same function as printing the register
dump and the stack backtrace in a debugger would.

-- 
D.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Bob Taylor]

In message [EMAIL PROTECTED], Nathan Paul 
Simons writes:
 On Sun, Sep 10, 2000 at 12:15:31AM -0700, J. Dow wrote:
  Properly contemplated and I wonder at the hypocrisy of using a compiler
  or an assembler instead of carefully hand crafted bits on a blank disk.
 
   i think you miss the point.  i think that Linus is trying to say
 something along the lines of "A hacker does for love what others would not do
 for money."  Think about it; who would you rather work with: someone who is
 there because they enjoy the work, truly thrive in the environment, and is
 pleasant to be around -or- someone who does it just because they're paid, the
y
 "only work here" and would prefer a debugger because it means they don't have
 to think as hard.

If this is what Linus *actually* means then why didn't he *say* 
so? I personally believe this is what he meant.

Bob

-- 
+---+
| Bob Taylor Email: [EMAIL PROTECTED]|
|---|
| Like the ad says, at 300 dpi you can tell she's wearing a |
| swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you   |
| can tell it's painted on. I suppose at 2400 dpi you can tell  |
| if the paint is giving her a rash. (So says Joshua R. Poulson)|
+---+


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Nathan Paul Simons wrote:

 On Sun, Sep 10, 2000 at 12:15:31AM -0700, J. Dow wrote:
  Properly contemplated and I wonder at the hypocrisy of using a compiler
  or an assembler instead of carefully hand crafted bits on a blank disk.

 i think you miss the point.  i think that Linus is trying to say
 something along the lines of "A hacker does for love what others would not do
 for money."  Think about it; who would you rather work with: someone who is
 there because they enjoy the work, truly thrive in the environment, and is
 pleasant to be around -or- someone who does it just because they're paid, they
 "only work here" and would prefer a debugger because it means they don't have
 to think as hard.


One of the principal architects at Compaq called me Friday after reading Linus'
email about not caring about commercial or support issues for commercialization
of Linux on this topic-- his right -- it had the anticipated impact I would
expect, and it's rippling through the industry.  This topic on kernel debuggers
and Linux kernel development philosophy has been an unknown to a lot of folks in
the commercial software world for a long time and now Linus has made some things
very clear.

Since Linus has rejected kdb there's every indication he will reject any other
kernel debugger submissions -- also his right.  I think my time would be better
spent completing the merge of the Linux code base onto MANOS since moving the
debugger over to Linux seems to not be something Linus would adopt and it's
contrary to his development philosophy, so it's probably a complete waste of my
time.

If I get time to create a patch for Linux, I'll put it up.  kdb seems to be
already there, so folks can use it on Linux for now, and I'll stick to printk()
and code reviews for my debugging on Linux.

:-)

Jeff.




 --
 Nathan Paul Simons, Programmer for FSMLabs
 http://www.fsmlabs.com/
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Alexander Viro]

On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

 already there, so folks can use it on Linux for now, and I'll stick to printk()
 and code reviews for my debugging on Linux.

Jeff, does it mean that you do not use code reviews on other projects?

It's not that hard to answer - just 1 bit of information. The question
being:
Do you use code reviews in work on MANOS?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Paul Jakma]

arrgghh jeff...

On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

 One of the principal architects at Compaq called me Friday after
 reading Linus' email about not caring about commercial or support
 issues for commercialization of Linux on this topic-- his right

yes it his right. he cares about the 'goodness' of the kernel. The
commercial and support issues he doesn't care about - that's the
domain of redhat/suse/compaq/etc../etc... and timpanogas (if you so
choose).

if you need debugger - add it to your local tree/ship with a
debugger to your customers.

 contrary to his development philosophy, so it's probably a
 complete waste of my time.
 

linux kernel hackers do the worrying about 'goodness'

but there is *nothing* that stops commerce adding tweaks to help with
support issues! (RedHat/SuSE/etc kernels are heavily patched and
tweaked!)

 Jeff.

-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
C'est magnifique, mais ce n'est pas l'Informatique.
-- Bosquet [on seeing the IBM 4341]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Alexander Viro wrote:

 On Sun, 10 Sep 2000, Jeff V. Merkey wrote:

  already there, so folks can use it on Linux for now, and I'll stick to printk()
  and code reviews for my debugging on Linux.

 Jeff, does it mean that you do not use code reviews on other projects?

 It's not that hard to answer - just 1 bit of information. The question
 being:
 Do you use code reviews in work on MANOS?

Yes, everyone does.  But there's a class of problems, like hardware and SMP bugs,
where a debugger can help you locate a bug more quickly or profile and observe
performance issues without needing to write tons of code to instrument this type of
monitoring.  I wrote MANOS soley with code reviews, but projects earlier in my
career, I used a lot of tools, like an American Arium Logic Analyser with an Inverse
Assembler and a decent kernel debugger.  The tools gave me the ability to rapidly
master and solve problems that were related to early SMP hardware, and gave me an
understanding.

To cite a Linux specific example, let's take the issue with the memory write for a
spin_unlock().  Linus seemed to have trouble grasping why a simple  ' movaddr,
0' would work as opposed to a 'lock dec addr.'  Anyone who has ever spent late
nights with an American Arium Analyzer profiling memory bus transactions on a PPro
knows that MESI will correctly propogate via the processor caches a write to a
locked location with a correct load and stor oder without any problems of locking
concurrency.  Linus' apparently did not understand this, or he would have
immediately realized that double locking was always generating a second
non-cacheable memory reference for every lock being taken and released.

There's also hidden latencies in interrupts on Intel.  I know this because I have
watched bus transactions with an analyser and seen an interrupt generate reads of
the IDE, GDT,LDT, PDE, and other tables.  NetWare had a coding error I fixed with
this tool that noone had ever even noticed or caught with a code review.  The person
writing and updating page table entries in NetWare 4.1 was clearing the accessed bit
in the PTE and did not know that the processor would assert a hidden R/M/W operation
and assert a bus lock to set this bit everytime someone cleared it -- it made
performance drop 4% from NetWare 3.X and noone knew why.  This performance problem
would have never been found without this tool.2 years of code reviews did not
find it -- an American Ariun Analyser with a kernel debugger to stop and start and
instrument the code with writing custom stubs all over the place did.

Folks who just relay on code reviews never see this level of interaction, and
conversely, do not have the understnading of hardware behavior underneath an OS to
optimize it well.  That's my case for good tools in an OS.The performance of
Linux vs. NetWare and NT in LAN environments proves this point well.

:-)

Jeff.







 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[David S. Miller]

   Date:Sun, 10 Sep 2000 18:14:03 -0600
   From: "Jeff V. Merkey" [EMAIL PROTECTED]

   Linus' apparently did not understand this, or he would have
   immediately realized that double locking was always generating a
   second non-cacheable memory reference for every lock being taken
   and released.

Jeff, after working together with Linus for 6 or so years myself, I
would make a large wager that Linus understands these issues much
better than even you.

But then again, as previously stated, I don't take you very seriously,
but I fear that there are a few on this list who still do.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Linus Torvalds wrote:

> 
> I think you missed the point of my original reply completely.
> 
> The _technical_ side of the tool in question is completely secondary.
> 
> The social engineering side is very real, and immediate.
> 
> It's not whether you can use tools to do the work.
> 
> It's about what kind of people you get.
>

Linus,

I think everyone respects your opinion here, but it's the difference
between a paintbrush and a spray can.  Some artists paint with a camel
hair brush, some paint with a spray can (like an air  brush artist does)
-- graffitti artists are even more crude, and use a spray can and a
concrete wall.  

Putting in kdb or anything else as a config option for "make config"
won't matter one way or the other relative to the development or
"weeding out" of kernel developers.  After all, you may want someone
around who looks up at the sky every once and a while for asteroids
heading towards earth.   

One thing that will happen if you do this is that Linux kernel evolution
will explode, since the debugger will act a lot like ultra-violet
radiation, and cause myriad Linux mutations to appear rapidly.  Darwinsm
relies on two principals to work - random mutations, and environmental
pressure.  Your analogy describes only one side -- encironmental
pressure, while on the other you are limiting the process of mutation.  

If you require that all Linux kernel work be "aryan" (not meant to
offend anyone in Germany), and all Linux code must have blue eyes and
blonde hair, this process will not promote the other side of the
equation, since the process of mutation is in essence halted.  Breeding
with dogs and horses over centuries has proven this.  Pure bred dogs
suffer from a long list of genetic maladies due to in-breeding and
line-breeding, such a abiotrophy, ataxia, and other problems.

:-)

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Stephen E. Clark]

Linus Torvalds wrote:
> 
> On Sat, 9 Sep 2000, Oliver Xymoron wrote:
> >
> > Tools are tools. They don't make better code. They make better code easier
> > if used properly.
> 
> I think you missed the point of my original reply completely.
> 
> The _technical_ side of the tool in question is completely secondary.
> 
> The social engineering side is very real, and immediate.
...

> Linus
> 

Then why don't we get rid of the compilers and assemblers and go back to
the old way of doing it
all - coding on the bare metal. Believe it or not at one time it was
done this way. Imagine where
we would be if everyone had said lets not invent tools to make ourselves
more productive.

My $.02

Steve Clark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Oliver Xymoron]

[reposted for the benefit of anyone wondering what Linus was replying to]

On Sat, 9 Sep 2000, Oliver Xymoron wrote:

> On Sat, 9 Sep 2000, Linus Torvalds wrote:
> 
> > I use revision control at work. We use CVS on steroids - CVS with a lo tof
> > the extensions available, and with a "mad scientists helper" program
> > called "igor".
> [...]
> > And with a chip that _includes_ a compiler, we have some debuggers that I
> > don't think exist anywhere else on the planet. Which turns out very useful
> > when the first version of the silicon doesn't actually act the way we
> > thought it would ;)
> 
> I figured as much on both counts, actually - I was mostly razzing you.
>  
> > So I've seen both. And I still don't think they make for better code. They
> > sometimes make for more expedient release schedules. Which is not the same
> > thing at all.
> 
> I think the only one who's argued from the release schedule POV is Jeff
> Merkey. The rest are arguing that debuggers are sometimes useful tools[1].
> 
> Tools are tools. They don't make better code. They make better code easier
> if used properly. Companies are using drills and lathes and table saws and
> power sanders to produce furniture that doesn't compare to antiques made
> with hand tools[2]. Does this mean we should make everything by hand? No,
> it just means we need to be focused on craftsmanship rather than cost.
> I think the current development culture already has that focus.
> 
> Fact is, the kernel debugging tools are, just like drivers, best
> maintained with the kernel proper. 
> 
> Either DM or AV referred to K's _Practice of Programming_ (p118) in
> defense of the avoiding debugger argument. If you have it handy, give that
> chapter a read. They devote pretty much their entire chapter on debugging
> to the printf school and most of the book lines up with your code quality
> philosophy but they still conclude that "a debugger can be of enormous
> value, however, and you should certainly include one in your debugging
> toolkit.."
> 
> [1] Compare TM's core debuggers to the usefulness of something like IKD
> for early work on a new port.
> 
> [2] Note that you're only looking at the antiques that were built well
> enough to be around for comparison.
> 
> --
>  "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 
> 
> 

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Linus Torvalds]

On Sat, 9 Sep 2000, Oliver Xymoron wrote:
> 
> Tools are tools. They don't make better code. They make better code easier
> if used properly.

I think you missed the point of my original reply completely.

The _technical_ side of the tool in question is completely secondary.

The social engineering side is very real, and immediate.

It's not whether you can use tools to do the work.

It's about what kind of people you get.

You were the one who brought up the power drill analogy. I'll take it, and
run with it, and maybe you can see _my_ point by me taking your analogy
and running with it.

Yes, using a power-drill and other tools makes a lot of carpentry easier.
To the point that a lot of carpenters don't even use their hands much any
more. Almost all the "carpentry" today is 99% automated, and sure, it
works wonderfuly - especially as you in carpentry cannot do it any other
way if you want to mass-produce stuff.

But take a moment to look at it the other way. 

If you want to find the true carpenters today, what do you do? Not just "a
carpenter". But THE carpenter.

I'm saying that maybe you put up a carpentry shop where everything is
lovingly hand-crafted and tools are not considered to be the most
important part - or even necessarily good. And yes, some people
(carpenters in every sense of the word) will be frustrated. They can't use
the power-lathe that they are used to. It doesn't suit them. They _know_
that they are missing something.

But in the end, maybe the rule to only use hand power makes sense. Not
because hand-power is _better_. But because it brings in the kind of
people who love to work with their hands, who love to _feel_ the wood with
their fingers, and because of that their holes are not always perfectly
aligned, not always at the same place. The kind of carpenter that looks at
the grain of the wood, and allows the grain of the wood to help form the
finished product.

The kind of carpenter who, in a word, is more than _just_ a carpenter.

  [ Insert a silent minute to contemplate the beaty of the world here. ]

Go back and read my original reply to this thread.

Really _understand_ the notion of two kinds of people. 

And think about what kind of people you'd like to work with.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 06.09.00 in 
<[EMAIL PROTECTED]>:

> On Wed, 6 Sep 2000, Tigran Aivazian wrote:
> >
> > very nice monologue, thanks. It would be great to know Linus' opinion. I
> > mean, I knew Linus' opinion of some years' ago but perhaps it changed? He
> > is a living being and not some set of rules written in stone so perhaps
> > current stability/highquality of kdb suggests to Linus that it may be
> > (just maybe) acceptable into official tree?
>
> I don't like debuggers. Never have, probably never will. I use gdb all the
> time, but I tend to use it not as a debugger, but as a disassembler on
> steroids that you can program.
>
> None of the arguments for a kernel debugger has touched me in the least.
> And trust me, over the years I've heard quite a lot of them. In the end,
> they tend to boil down to basically:
>
>  - it would be so much easier to do development, and we'd be able to add
>new things faster.

That's never been my argument. My argument has always been "it's far  
easier to *understand* tough bugs with a debugger".

BTDTGTTS. *Easy* bugs don't *need* a debugger to fix.

Tough bug: a place where reality doesn't match your understanding.

In which case, you often need to go exploring. Which is roughly 100 times  
as fast with a debugger compared to, say, printk. (Think about it. You get  
a new idea what to look at, you insert a new printk, you recompile, you  
reboot, you re-trigger the bug. Whereas if you're running a debugger, you  
just examine a different piece of memory.)

Often you look at various different places before you finally locate the  
one that's giving you the missing clue.

> And quite frankly, I don't care. I don't think kernel development should
> be "easy". I do not condone single-stepping through code to find the bug.
> I do not think that extra visibility into the system is necessarily a good
> thing.

Well, it's pretty certainly never a *bad* thing.

> To me, it's not a bug, it's a feature. Not only is it documented, but it's
> _good_, so it obviously cannot be a bug.

Sorry, you haven't shown it's good either. All the claims about it weeding  
out poor techniques I've seen lacked any serious support.

There's one thing that can make for debugger abuse (but in fact can abuse  
any other debugging technique just as well): management pressure.

But "management pressure" does not seem to apply to Linux kernel  
development in any meaningful way. Everybody wo looks even remotely like a  
Linux kernel development manager (such as the Messiers Torvalds, Cox,  
Miller, and so on) already understands about good and bad bugfixes, and  
how "we must get this out to the customer or lose $$$" is a bad argument.

>  My biggest job is to say
> "no" to new features, not trying to find them.

So, if someone with a debugger creates a bad patch, nobody is forcing you  
to accept that patch.

> Oh. And sure, when things crash and you fsck and you didn't even get a
> clue about what went wrong, you get frustrated. Tough. There are two kinds
> of reactions to that: you start being careful, or you start whining about
> a kernel debugger.

I don't even see that a debugger makes all that much difference in *that*  
scenario. When you have a bug that corrupts the fs, how is a debugger  
magically going to remove that corruption?!

What it can do is make you understand what's going on faster. And that  
*is* a good thing. Always.

> Quite frankly, I'd rather weed out the people who don't start being
> careful early rather than late. That sounds callous, and by God, it _is_
> callous. But it's not the kind of "if you can't stand the heat, get out
> the the kitchen" kind of remark that some people take it for. No, it's
> something much more deeper: I'd rather not work with people who aren't
> careful. It's darwinism in software development.

Except that "careful" doesn't seem even remotely relevant to the question.  
I certainly don't see how a debugger lets you be less careful.

> I'm a bastard. I have absolutely no clue why people can ever think
> otherwise. Yet they do. People think I'm a nice guy, and the fact is that
> I'm a scheming, conniving bastard who doesn't care for any hurt feelings
> or lost hours of work if it just results in what I consider to be a better
> system.

But it doesn't. I'm pretty convinced that in this point, you're entirely  
barking up the wrong tree.

> I happen to believe that not having a kernel debugger forces people to
> think about their problem on a different level than with a debugger. I

I happen to believe that this is just plain wrong.

> think that without a debugger, you don't get into that mindset where you
> know how it behaves, and then you fix it from there. Without a debugger,
> you tend to think about problems another way. You want to understand
> things on a different _level_.

Maybe you do - I certainly don't.

In fact, it's often been exactly the other way around for me. With a  
working debugger, I can 

Re: Availability of kdb

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 06.09.00 in 
[EMAIL PROTECTED]:

 On Wed, 6 Sep 2000, Tigran Aivazian wrote:
 
  very nice monologue, thanks. It would be great to know Linus' opinion. I
  mean, I knew Linus' opinion of some years' ago but perhaps it changed? He
  is a living being and not some set of rules written in stone so perhaps
  current stability/highquality of kdb suggests to Linus that it may be
  (just maybe) acceptable into official tree?

 I don't like debuggers. Never have, probably never will. I use gdb all the
 time, but I tend to use it not as a debugger, but as a disassembler on
 steroids that you can program.

 None of the arguments for a kernel debugger has touched me in the least.
 And trust me, over the years I've heard quite a lot of them. In the end,
 they tend to boil down to basically:

  - it would be so much easier to do development, and we'd be able to add
new things faster.

That's never been my argument. My argument has always been "it's far  
easier to *understand* tough bugs with a debugger".

BTDTGTTS. *Easy* bugs don't *need* a debugger to fix.

Tough bug: a place where reality doesn't match your understanding.

In which case, you often need to go exploring. Which is roughly 100 times  
as fast with a debugger compared to, say, printk. (Think about it. You get  
a new idea what to look at, you insert a new printk, you recompile, you  
reboot, you re-trigger the bug. Whereas if you're running a debugger, you  
just examine a different piece of memory.)

Often you look at various different places before you finally locate the  
one that's giving you the missing clue.

 And quite frankly, I don't care. I don't think kernel development should
 be "easy". I do not condone single-stepping through code to find the bug.
 I do not think that extra visibility into the system is necessarily a good
 thing.

Well, it's pretty certainly never a *bad* thing.

 To me, it's not a bug, it's a feature. Not only is it documented, but it's
 _good_, so it obviously cannot be a bug.

Sorry, you haven't shown it's good either. All the claims about it weeding  
out poor techniques I've seen lacked any serious support.

There's one thing that can make for debugger abuse (but in fact can abuse  
any other debugging technique just as well): management pressure.

But "management pressure" does not seem to apply to Linux kernel  
development in any meaningful way. Everybody wo looks even remotely like a  
Linux kernel development manager (such as the Messiers Torvalds, Cox,  
Miller, and so on) already understands about good and bad bugfixes, and  
how "we must get this out to the customer or lose $$$" is a bad argument.

  My biggest job is to say
 "no" to new features, not trying to find them.

So, if someone with a debugger creates a bad patch, nobody is forcing you  
to accept that patch.

 Oh. And sure, when things crash and you fsck and you didn't even get a
 clue about what went wrong, you get frustrated. Tough. There are two kinds
 of reactions to that: you start being careful, or you start whining about
 a kernel debugger.

I don't even see that a debugger makes all that much difference in *that*  
scenario. When you have a bug that corrupts the fs, how is a debugger  
magically going to remove that corruption?!

What it can do is make you understand what's going on faster. And that  
*is* a good thing. Always.

 Quite frankly, I'd rather weed out the people who don't start being
 careful early rather than late. That sounds callous, and by God, it _is_
 callous. But it's not the kind of "if you can't stand the heat, get out
 the the kitchen" kind of remark that some people take it for. No, it's
 something much more deeper: I'd rather not work with people who aren't
 careful. It's darwinism in software development.

Except that "careful" doesn't seem even remotely relevant to the question.  
I certainly don't see how a debugger lets you be less careful.

 I'm a bastard. I have absolutely no clue why people can ever think
 otherwise. Yet they do. People think I'm a nice guy, and the fact is that
 I'm a scheming, conniving bastard who doesn't care for any hurt feelings
 or lost hours of work if it just results in what I consider to be a better
 system.

But it doesn't. I'm pretty convinced that in this point, you're entirely  
barking up the wrong tree.

 I happen to believe that not having a kernel debugger forces people to
 think about their problem on a different level than with a debugger. I

I happen to believe that this is just plain wrong.

 think that without a debugger, you don't get into that mindset where you
 know how it behaves, and then you fix it from there. Without a debugger,
 you tend to think about problems another way. You want to understand
 things on a different _level_.

Maybe you do - I certainly don't.

In fact, it's often been exactly the other way around for me. With a  
working debugger, I can understand exactly what's happening, and can write  
a 

Re: Availability of kdb

[Linus Torvalds]

On Sat, 9 Sep 2000, Oliver Xymoron wrote:
 
 Tools are tools. They don't make better code. They make better code easier
 if used properly.

I think you missed the point of my original reply completely.

The _technical_ side of the tool in question is completely secondary.

The social engineering side is very real, and immediate.

It's not whether you can use tools to do the work.

It's about what kind of people you get.

You were the one who brought up the power drill analogy. I'll take it, and
run with it, and maybe you can see _my_ point by me taking your analogy
and running with it.

Yes, using a power-drill and other tools makes a lot of carpentry easier.
To the point that a lot of carpenters don't even use their hands much any
more. Almost all the "carpentry" today is 99% automated, and sure, it
works wonderfuly - especially as you in carpentry cannot do it any other
way if you want to mass-produce stuff.

But take a moment to look at it the other way. 

If you want to find the true carpenters today, what do you do? Not just "a
carpenter". But THE carpenter.

I'm saying that maybe you put up a carpentry shop where everything is
lovingly hand-crafted and tools are not considered to be the most
important part - or even necessarily good. And yes, some people
(carpenters in every sense of the word) will be frustrated. They can't use
the power-lathe that they are used to. It doesn't suit them. They _know_
that they are missing something.

But in the end, maybe the rule to only use hand power makes sense. Not
because hand-power is _better_. But because it brings in the kind of
people who love to work with their hands, who love to _feel_ the wood with
their fingers, and because of that their holes are not always perfectly
aligned, not always at the same place. The kind of carpenter that looks at
the grain of the wood, and allows the grain of the wood to help form the
finished product.

The kind of carpenter who, in a word, is more than _just_ a carpenter.

  [ Insert a silent minute to contemplate the beaty of the world here. ]

Go back and read my original reply to this thread.

Really _understand_ the notion of two kinds of people. 

And think about what kind of people you'd like to work with.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Oliver Xymoron]

[reposted for the benefit of anyone wondering what Linus was replying to]

On Sat, 9 Sep 2000, Oliver Xymoron wrote:

 On Sat, 9 Sep 2000, Linus Torvalds wrote:
 
  I use revision control at work. We use CVS on steroids - CVS with a lo tof
  the extensions available, and with a "mad scientists helper" program
  called "igor".
 [...]
  And with a chip that _includes_ a compiler, we have some debuggers that I
  don't think exist anywhere else on the planet. Which turns out very useful
  when the first version of the silicon doesn't actually act the way we
  thought it would ;)
 
 I figured as much on both counts, actually - I was mostly razzing you.
  
  So I've seen both. And I still don't think they make for better code. They
  sometimes make for more expedient release schedules. Which is not the same
  thing at all.
 
 I think the only one who's argued from the release schedule POV is Jeff
 Merkey. The rest are arguing that debuggers are sometimes useful tools[1].
 
 Tools are tools. They don't make better code. They make better code easier
 if used properly. Companies are using drills and lathes and table saws and
 power sanders to produce furniture that doesn't compare to antiques made
 with hand tools[2]. Does this mean we should make everything by hand? No,
 it just means we need to be focused on craftsmanship rather than cost.
 I think the current development culture already has that focus.
 
 Fact is, the kernel debugging tools are, just like drivers, best
 maintained with the kernel proper. 
 
 Either DM or AV referred to KP's _Practice of Programming_ (p118) in
 defense of the avoiding debugger argument. If you have it handy, give that
 chapter a read. They devote pretty much their entire chapter on debugging
 to the printf school and most of the book lines up with your code quality
 philosophy but they still conclude that "a debugger can be of enormous
 value, however, and you should certainly include one in your debugging
 toolkit.."
 
 [1] Compare TM's core debuggers to the usefulness of something like IKD
 for early work on a new port.
 
 [2] Note that you're only looking at the antiques that were built well
 enough to be around for comparison.
 
 --
  "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 
 
 

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Stephen E. Clark]

Linus Torvalds wrote:
 
 On Sat, 9 Sep 2000, Oliver Xymoron wrote:
 
  Tools are tools. They don't make better code. They make better code easier
  if used properly.
 
 I think you missed the point of my original reply completely.
 
 The _technical_ side of the tool in question is completely secondary.
 
 The social engineering side is very real, and immediate.
...

 Linus
 

Then why don't we get rid of the compilers and assemblers and go back to
the old way of doing it
all - coding on the bare metal. Believe it or not at one time it was
done this way. Imagine where
we would be if everyone had said lets not invent tools to make ourselves
more productive.

My $.02

Steve Clark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Oliver Xymoron]

On Wed, 6 Sep 2000, Linus Torvalds wrote:

> Apparently, if you follow the arguments, not having a kernel debugger
> leads to various maladies:
>  - you crash when something goes wrong, and you fsck and it takes forever
>and you get frustrated.
>  - people have given up on Linux kernel programming because it's too hard
>and too time-consuming
>  - it takes longer to create new features.
> 
> And nobody has explained to me why these are _bad_ things.

There are those, but there are others, most of which are so obvious[1]
we're not mentioning them, assuming you're familiar with them too. I
usually eschew debuggers as well, but I'm beginning to suspect that you've
spent so much of your programming life immersed in the kernel that you
haven't used a debugger enough to know what sorts of things it's actually
good for. Not all the world's a nail, but there are times when the bigger
hammer approach is the right one.

One of these days you should give revision control a try too. Not to
mention bug tracking. :P

[1] eg I've found many a compiler bug in 5 minutes of single stepping that
days of eyeballing source and adding printfs failed to discover. 

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Michael Elizabeth Chastain]

> There are people today that refuse to use computers for writeing,
> and they have good arguments, ...

Harken back to David Miller, who wrote about occupying his hands
with something to keep them the hell off the keyboard while he is
meditating on a screen full of code.

One of my debugging tools is a printer.  I print out bunches of
source code and trace files and then I go to a room *without* any
computers in it and I read for a while.

And I still write a lot of source code with pen and paper.

Michael Elizabeth Chastain

"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Patrick J. LoPresti]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> Sure. I just don't see many end-users single-stepping through
> interrupt handlers etc.
> 
> But yes, there probably are a few.

I think you would be surprised, and I speak as someone who has found
and fixed race conditions in your kernel.

There are more Linux users who are competent with x86 hardware and SMP
issues than there are Linux developers.  A *lot* more.

When these technically savvy users have a problem, they want to
diagnose it as best they can and then hand it off to a kernel expert
to analyse and to fix.  They wish they had the time to understand the
kernel deeply and come up with the "right" solution, but they don't;
and the expert can do the job ten times faster anyway.

If you give us better diagnostic tools, your kernel *will* improve
faster.  Whether this benefit outweighs the cost is, of course, up to
you.

 - Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Andrew Scott]

On 6 Sep 2000, at 14:03, Linus Torvalds wrote:

> In article <[EMAIL PROTECTED]>,

> >Linus Torvalds wrote:
> 
> Think of rabbits. And think of how the wolf helps them in the end. Not
> by being nice, no. But the rabbits breed, and they are better for having
> to worry a bit.

No matter how much they think about it, or how smart they are, 
they'll alway be food for wolves unless they develop the ability to 
use tools. It isn't smarts and thinking, though they certainly help, 
it's the ability to make and use tools that does it.  

There are all kinds of tools. In many cases you don't need to use 
them. War and Peace was written with a pen. There are people today 
that refuse to use computers for writeing, and they have good 
arguments, but if Tolstoy was born today, he'd probably use a Word 
processor, and he'd probably have written a sequel! It probably 
wouldn't have been the same book, though, and this is not to say it 
would be any better or worse. At least one writer that I'm aware of, 
output slowed considerably when he switched to a word processor 
because it became so easy to edit, that he spent much more time 
tweaking his work.

Most of the people who write and don't use a word processing 'tool' 
are people who didn't grow up with them.

Linux is really just a hobby for a few people. The sort of people who 
insist on climbing cliffs without safety gear. This is ok. It's your 
hobby, but I think that people should understand that it _is_ a hobby.



--Mailed via Pegasus 3.12 & Mercury 1.44---
[EMAIL PROTECTED]Fax (617)373-2942
Andrew Scott   Tel (617)373-5278   _
Northeastern University--138 Meserve Hall / \   /
College of Arts & Sciences-Deans Office  / \ \ /
Boston, Ma. 02115   /   \_/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Chris Meadors]

Now that is what I want on a t-shirt.  ;)

On Thu, 7 Sep 2000, Peter Samuelson wrote:

> [Now, centuries-old theological arguments may well be of supreme
> importance in some ways -- an undeniably subjective and personal
> judgment -- but in terms of Linux kernel development they are usually
> considered even more off-topic than the latest clever AC quote.]

-- 
Two penguins were walking on an iceburg.  The first one said to the
second, "you look like you are wearing a tuxedo."  The second one said,
"I might be..."
  --David Lynch, Twin Peaks

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Patrick J. LoPresti]

Linus Torvalds [EMAIL PROTECTED] writes:

 Sure. I just don't see many end-users single-stepping through
 interrupt handlers etc.
 
 But yes, there probably are a few.

I think you would be surprised, and I speak as someone who has found
and fixed race conditions in your kernel.

There are more Linux users who are competent with x86 hardware and SMP
issues than there are Linux developers.  A *lot* more.

When these technically savvy users have a problem, they want to
diagnose it as best they can and then hand it off to a kernel expert
to analyse and to fix.  They wish they had the time to understand the
kernel deeply and come up with the "right" solution, but they don't;
and the expert can do the job ten times faster anyway.

If you give us better diagnostic tools, your kernel *will* improve
faster.  Whether this benefit outweighs the cost is, of course, up to
you.

 - Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Michael Elizabeth Chastain]

 There are people today that refuse to use computers for writeing,
 and they have good arguments, ...

Harken back to David Miller, who wrote about occupying his hands
with something to keep them the hell off the keyboard while he is
meditating on a screen full of code.

One of my debugging tools is a printer.  I print out bunches of
source code and trace files and then I go to a room *without* any
computers in it and I read for a while.

And I still write a lot of source code with pen and paper.

Michael Elizabeth Chastain
mailto:[EMAIL PROTECTED]
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[J. Dow]

Timur,
> Well, if it really is just his hobby, then he shouldn't be chanting the "World
> Domination" mantra.  Either Linux belongs to Linus, in which case it's
> irrelevant outside his personal world, or it is a tool for all computer users.
> If Linus really doesn't care who uses his OS, then he should not be
encouraging
> community participation, and he shouldn't be accepting speaking engagements at
> major conventions where business users attend to decide whether Linux is for
> them or not.

Shh, you're not supposed to notice that man behind the curtain
over there that your annoying little doggy found.

{^_-}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

From: "Horst von Brand" <[EMAIL PROTECTED]>

> "J. Dow" <[EMAIL PROTECTED]> said:
> 
> [...]
> 
> > The point is that WITH a debugger you have to take that step as well.
> > A person without the self discipline to do that is still a child and should
> > not be in this business. The debugger gives you a better picture of what
> > is actually happening. If that leverage is considered to be a bad thing
> > I am surprised and dismayed. A bloody LOT of personal experience 
> > and technological bloody noses suggests it is a very good thing.
> 
> This is true as long as the debugger hooks have no (or very minimal) impact
> on the instrumented system. Impossible (or very nearly so) in the case of a
> massively parallel program like the kernel. Where it is possible it has
> been done, in general. General hooks into the distributed subsystems inside
> the kernel are only a bit easier to maintain than the instrumented code,
> and they impact its performance, stability and readability.

Oh bat doodoo. In the first place you use a debug build with the debugger
built in for debugging. You run a real build without the debugger for
production. In the second place since you have the sense to do the
aforementioned good practice you keep in mind that there are interactions
involved to indicate whether the problem goes away or not and how the
problem manifestation changes with the debugger present. In the third
place if you are reduced to printk you can have even worse timing issues
than with a well constructed debugger.

If you have that well constructed debugger you have a patch to install it.
If there is a "make debugged" and "make nondebugged" command in
the kernel Makefile and the debugger is not patched in for most people
until they issue the "make debugged" command you have exactly what
you have now with the addition of a debugger for which there is a huge
incentive to maintain it.

Heck, run up proposed patches in the debugger, confirm your desk
analysis of what they do, THEN install the patches into the kernel
formally. (And for Ghu's sake make it a source level debugger if you
want it to work right.)

> You did not build a logic analyzer and circuit simulator into each and
> every transmitter you built, did you?

I built in the test points these tools attached to in each and every module
of each and every radio. Except obviously the simulator was used before
hand to predict circuit performance. If you design for proper testpoints
there is little or no affect on operation and a great improvement in ease
of maintenance and tuneup.

> I've used debuggers too, and do so sometimes to check on stuff I write when
> I'm truly stumped, but in general I stay away from them. I (try to) write
> stuff in modular, cleanly separate parts with (I hope) well understood
> interactions. That makes isolating bugs easy enough without a detailed
> step-by-step following of the program, at least most of the time. Debuggers
> _can_ be useful, no question about that. But you can also waste a huge
> amount of time with them. They just give you _one_ very narrow picture of
> what is going on, and that picture is from a quite useless perspective most
> of the time.

That design approach plus a good debugger can reach the finished line
of clean completed and debugged (to the same level) code quicker than
without the good debugger. The times I have most loved the debugger are
when the code generated is very different from the code laid down either
due to a typo I continually overlooked (I am human  -  I think) or a compiler
bug. Sometimes it actually adds time to development if I didn't NEED to run
that debugger based verification that what I intended is what appeared.
(Sadly I don't quite have the self-discipline to make that run EVERY time
and even worse sometimes I have not had the debugger to work with.)
So far I have noticed that the debuggers catch a wider range of issues
than the desk analysis.

{^_^}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Peter Samuelson]

  [Tigran]
> > I like this one even better:
> > 
> > "Little children, keep yourselves from idols" -- St John, Ist century.

[rgooch]
> Hm. Does that apply also to all the statues of saints, the virgin
> mother and all those crosses with Jesus that you find in churches,
> hanging off people's necks and in some places on every street corner?

Why, yes it does, IMO.  In fact ... [snaps fingers] you appear to have
rediscovered a centuries-old argument, and the single biggest problem
many of us Protestants have with Roman Catholic doctrine & practice.

[Now, centuries-old theological arguments may well be of supreme
importance in some ways -- an undeniably subjective and personal
judgment -- but in terms of Linux kernel development they are usually
considered even more off-topic than the latest clever AC quote.]

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Michal Jaegermann]

Jamie Lokier wrote:
> World Domination is my hobby too :-)

Now, that is THE T-shirt!  What should be added?  A flock of penguins
in an attack mode. :-)

  --mj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[lamont]

On Thu, 7 Sep 2000, Alexander Viro wrote:
> On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
> > scale in the end.  We'll either see forking, see another OS like FreeBSD
> > fill the void, or (worst case) Solaris.
> 
> Somehow I doubt that arguments from marketshare/field circus/etc. peppered
> with threats of coprorat world turning to Solaris, etc. will win you much
> love from FreeBSD core team.

First of all I'm not trying to threaten anyone.  Second of all, I'm not
trying to affect FreeBSD at all.  I'm pointing out there's a
void.  FreeBSD could fill that void.  Or they could choose not to.

> I _really_ doubt that they will make any
> effect on the development decisions. You see, these guys are bastards
> too - comes with the territory. So are NetBSD and OpenBSD folks - try to
> speak to Theo that way and you will realize that Linus _is_ a nice guy,
> after all.

I've gotten into flamewars with Theo on comp.security.unix before.  You
don't need to explain that to me either.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Ingo Molnar wrote:
> 
> On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
> 
> > [...] Hardware problems require a debugger or logic analyzer to fix.
> > [...]
> 
> 'kernel problems need a kernel debugger to fix'. How wrong.

It says "hardware problems" not "kernel problems".  read it again.

:-)

Jeff

> 
> Ingo
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Ingo Molnar]

On Wed, 6 Sep 2000, Jeff V. Merkey wrote:

> [...] Hardware problems require a debugger or logic analyzer to fix.
> [...]

'kernel problems need a kernel debugger to fix'. How wrong.

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Jamie Lokier]

Timur Tabi wrote:
> Well, if it really is just his hobby, then he shouldn't be chanting
> the "World Domination" mantra.

Why not?  World Domination is my hobby too :-)

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Timur Tabi]

** Reply to message from "J. Dow" <[EMAIL PROTECTED]> on Thu, 7 Sep 2000
02:50:37 -0700


> Aw, Tigran, give the kid his hobby, OK? We can try to bang some
> sense into his head and suggest ways his hobby could offer more
> satisfaction from good results achieved and make it more fun for
> the rest of us. But this IS his model train setup we're playing on. So
> in the final analysis he gets to choose the means of train control we
> use and everything else, as well.

Well, if it really is just his hobby, then he shouldn't be chanting the "World
Domination" mantra.  Either Linux belongs to Linus, in which case it's
irrelevant outside his personal world, or it is a tool for all computer users.
If Linus really doesn't care who uses his OS, then he should not be encouraging
community participation, and he shouldn't be accepting speaking engagements at
major conventions where business users attend to decide whether Linux is for
them or not.


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Richard Gooch]

Tigran Aivazian writes:
> On Thu, 7 Sep 2000, George Anzinger wrote:
> > I like this one better:
> > 
> > "And I'm right.  I'm always right, but in this case I'm just a bit more
> > right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
> > 
> 
> I like this one even better:
> 
> "Little children, keep yourselves from idols" -- St John, Ist century.

Hm. Does that apply also to all the statues of saints, the virgin
mother and all those crosses with Jesus that you find in churches,
hanging off people's necks and in some places on every street corner?

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[the end?] RE: Availability of kdb

[Mike Galbraith]

On Thu, 7 Sep 2000, Mike Jagdis wrote:

> > Q: Then why isn't kdb in the kernel?
> > A: Uh...
> 
> More to the point, why don't the people that want a kernel
> debugger maintain kdb and simply drop in the patch when they
> need it? If Jeff releases his debugger will anyone care enough
> to maintain it? Less talk, more action methinks :-).

Hmm.. my name is on the to line, so I guess that this is directed
at me too?

I have _no problem_ with Linus not liking/integrating KDB.  I only
suggested that it _could_ improve bug report quality and encourage
folks to try to solve problems if it were integrated.  I also pointed
out that debuggers are readily available for those who want them.

Now (having gotten the last word in) let's stop talking about something
that's _not going to happen_ and chase down bugs so 2.4 _can_ happen :)

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Chris Ricker]

On Wed, 6 Sep 2000, Jeff V. Merkey wrote:

> I have no axe to grind, but I do have a different view.  I'm the 1 in 30
> million men born with an extra Y chromosone (a double YY), so you are
> pertially right there.  DOuble YY males have a different brain structure
> -- the lymbic system in my brain is so electrically active, it qualifies
> as a third brain.  Normal humans have two brains, left and right.  Like
> most double YY's I have three, left, right, lymbic.  Fortunately for me,
> my frontal lobes are normal and do not exhibit the wiring problems that
> afflict 60% of double YY's, such as an uncontrollable urge to take an
> axe and chop someone to pieces because they pissed me off.  



Not that any of this has anything to do with Linux kernel development, but
you really should do a bit more background reading on 47,XYY.  Incidence is
much, much higher than you claim.  Frequency estimates vary slightly with
the study, of course, but it's usually somewhere around 1 in 1000 live male
births (1 in 843 reported in Birth Defects 26:209-223, for example, and
similar results in Prenatal Diagnosis 17:363-368.  The *lowest* frequency
I've ever seen reported was ~ 1/1250).

Similarly, no scientific study I've ever seen has substantiated any of that
nonsense about "lymbic wiring" or three brains. [1] There's a very small
correlation between 47,XYY and: tallness, slightly reduced IQ,
hyperactivity, ADD, and learning disabilities.  AFAIK, there's no
demonstrated physiological difference between 46,XY males (ie, "normal") and
47,XYY; average testosterone levels are the same in both, for example (AACE
report, 1998).  If you actually know of scientific studies substantiating
the above claim of a physiological difference in the brain or any other
physiological differences, I'd really appreciate references.  Ditto for the
list of individuals you claim had 47,XYY -- the only "famous" person I know
of with any connection to the condition was Richard Speck, who falsely
claimed to be 47,XYY in an attempt to get leniency for his murders.  I'm
curious about your references because it's a condition which is quite
common, but which is very rarely diagnosed precisely because it usually has
no effect

Sorry about responding to this on linux-kernel instead of privately, but
47,XYY is a condition for which most popular "knowledge" is both wrong, and
quite persistent in its popularity and acceptance; furthermore, this
incorrect "knowledge" is often detrimental to those with the condition (ie,
Psychological Bulletin 78:209-233).  Historically, it was popularly thought
that 47,XYY was a condition leading to hyperaggression, criminal behavior,
etc., and so those with 47,XYY were often treated accordingly.  The
scientific reality is far more boring; most males with 47,XYY -- like most
males with 46,XY -- are as normal as males ever are, and should be treated
accordingly ;-).

later,
chris

[1] I suspect you're conflating two very different conditions, Klinefelter
syndrome (47,XXY) and 47,XYY.  Some studies (ie, J Neurol Neurosurg
Psychiatry 66:628-32) have demonstrated neurological differences for
subjects with Klinefelter syndrome, but they have simultaneously
demonstrated that neurological structures in 47,XYY subjects are no
different than in age-matched 46,XY controls.

-- 
Chris Ricker   [EMAIL PROTECTED]
  [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Horst von Brand]

"J. Dow" <[EMAIL PROTECTED]> said:

[...]

> The point is that WITH a debugger you have to take that step as well.
> A person without the self discipline to do that is still a child and should
> not be in this business. The debugger gives you a better picture of what
> is actually happening. If that leverage is considered to be a bad thing
> I am surprised and dismayed. A bloody LOT of personal experience 
> and technological bloody noses suggests it is a very good thing.

This is true as long as the debugger hooks have no (or very minimal) impact
on the instrumented system. Impossible (or very nearly so) in the case of a
massively parallel program like the kernel. Where it is possible it has
been done, in general. General hooks into the distributed subsystems inside
the kernel are only a bit easier to maintain than the instrumented code,
and they impact its performance, stability and readability.

You did not build a logic analyzer and circuit simulator into each and
every transmitter you built, did you?

I've used debuggers too, and do so sometimes to check on stuff I write when
I'm truly stumped, but in general I stay away from them. I (try to) write
stuff in modular, cleanly separate parts with (I hope) well understood
interactions. That makes isolating bugs easy enough without a detailed
step-by-step following of the program, at least most of the time. Debuggers
_can_ be useful, no question about that. But you can also waste a huge
amount of time with them. They just give you _one_ very narrow picture of
what is going on, and that picture is from a quite useless perspective most
of the time.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jesse C Cronce]

[EMAIL PROTECTED] wrote:
> 
> On 6 Sep 2000, Linus Torvalds wrote:
> > In article <[EMAIL PROTECTED]>,
> > Jeff V. Merkey <[EMAIL PROTECTED]> wrote:

> I guarantee you that IT managers and CTOs do not share your enthusiasm for
> slow, correct coding when faced with their business being down, their
> revenue stream being interrupted and their stock options losing value.
> If you ignore those concerns then you may find that wolf at your door as
> IT managers choose other operating systems (e.g. FreeBSD, Solaris), kernel
> developers choose other operating systems to work on (e.g. FreeBSD), and
> Linux companies start going under.
> 



Which is exactly why there should NOT be a debugger. Some guy in a suit
doesn't give a rat's batoot whether the code his programmers put out is
correct or not. The guy calling the shots may not even KNOW the
correctness
of said code. All he cares about is that the project his people just
spent
the past x amt of time and y amt of  should be, or 
(more probably) HAS to be done within a week, and the only thing between
him and a big, fat holiday bonus is some out of the way feature in the 
kernel that hardly gets used. His people use a debugger, see that
certain 
conditions lead to the behavior that makes his program work, make those 
conditions always true, and submit a patch without ever thinking about
the 
long ranging effects. If said patch is 
incorrect, it will probably be rejected. The fact is however, it's only 
PROBABLY. The linux masters catch most patch bugs, but when linux starts 
to REALLY take off, one patch a day will turn into five, ten, etc. and
the
gurus are still (barely, but still) short of super-human, make mistakes, 
and bugs will get introduced into the kernel. 

Fact is, linux is gaining in popularity because CORRECTNESS guides 
development, not money. When correctness falls to the way side, and
profits
take the reigns, linux will turn into a free . A 
debugger allows a bad coder to disguise their bad code as good code more 
easily.

Jesse C Cronce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Mike Porter]

On Wed, 6 Sep 2000, Dan Hollis wrote:

> On Wed, 6 Sep 2000, Alan Cox wrote:
> > For things like driver debugging its the only way to work. Hardware simply does
> > not work like the manual says and no amount of Zen contemplation will ever 
> > make you at one with a 3c905B ethernet card. 
> 
> This is probably the best argument for a kernel debugger.
> 
> Adding debug code (printk, if/then/BUG() etc) to track down a driver bug
> sometimes changes behaviour enough to turn it into a heisenbug. In these
> cases a kernel debugger is the best way to swat it.

I've found the opposite more times than not.  The debugger leaves
too many zeroes around, leading to code that doesn't fail when run
under the debugger.

Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Igmar Palsenberg]

On Thu, 7 Sep 2000, David Woodhouse wrote:

> 
> [EMAIL PROTECTED] said:
> >  Which Linux companies are profitable?  **NONE**.

That's a statement with balls, which I would really see with some
numbers..



Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Peter Steiner]

Gregory Maxwell <[EMAIL PROTECTED]> wrote:

>If this is your primary argument for a kernel debugger, a 'crash dump tool
>with extra controls', then why not just cleanly implement a 'crash dump
>tool with extra controls'.

What about an enhanced printk tool that virtually inserts conditional
printk's into the kernel without the need to recompile the kernel?
Logpoints, conditions and what to print could be set with a usermode
tool. And there should be an emergency stop keycombination that clears
all logpoints. That's all.

Activating logging should be as easy as feeding an email into the
usermode tool. And a second tool could automatically prepare an email
with the results.

Peter
-- 
  _   x___   [EMAIL PROTECTED] (Peter Steiner)
 / \_/_\_ /,--' Linux User #55148 (http://counter.li.org/)
 \/>'//
   \_/ perl -e'while(<>){s/=\n//g;s/=([\dA-F]{2})/chr(hex($1))/eg;print;}'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[J. Dow]

> On Thu, 7 Sep 2000, George Anzinger wrote:
> 
> > Chris Wedgwood wrote:
> > > 
> > > On Wed, Sep 06, 2000 at 12:52:29PM -0700, Linus Torvalds wrote:
> > > 
> > > [... words of wisdom removed for brevity ...]
> > > 
> > >  I'm a bastard, and proud of it!
> > > 
> > > Linus
> > > 
> > > Anyone else think copyleft could make a shirt from this?
> > 
> > I like this one better:
> > 
> > "And I'm right.  I'm always right, but in this case I'm just a bit more
> > right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
> > 
> 
> I like this one even better:
> 
> "Little children, keep yourselves from idols" -- St John, Ist century.
> 
> Regards,
> Tigran

Aw, Tigran, give the kid his hobby, OK? We can try to bang some
sense into his head and suggest ways his hobby could offer more
satisfaction from good results achieved and make it more fun for
the rest of us. But this IS his model train setup we're playing on. So
in the final analysis he gets to choose the means of train control we
use and everything else, as well.

{^_-}


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Daniel Phillips]

Christer Weinigel wrote:
> 
> [[EMAIL PROTECTED]] wrote:
>
> >I'm really kind of surprised that companies like SuSE, VA and RedHat
> >haven't started talking about forking the kernel already.  Those companies
> >are serving the administrators and managers whose needs you are openly
> >admitting that you are not concerned with.  For those companies the
> >present state of affairs isn't sustainable.
> 
> If you haven't noticed, they already do.  The kernel shipped from
> RedHat has quite a few patches applied that arent in Linus' tree.
> There's nothing stopping them from doing the same thing with
> the KGDB or IKD patch.

Yes, for example I doubt Mandrake would need much encouragement to
start doing that - it's just one more way to get a little bit out in
front of the pack.  This will be fine for stable kernels in shipping
distributions, IOW, for newbies, the unwashed masses, and the just
plain lazy.

For the unstable tree I can pick up the SGI patch from time to time. 
When I go so far out on the bleeding edge that SGI hasn't updated the
patch yet I'll just bare my hairy chest and wrestle those bugs into
submission with my bare hands like a man

To tell the truth it's what I've been doing anyway, except for the
part about the hairy chest. :-)

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Mike Jagdis]

> Q: Then why isn't kdb in the kernel?
> A: Uh...

More to the point, why don't the people that want a kernel
debugger maintain kdb and simply drop in the patch when they
need it? If Jeff releases his debugger will anyone care enough
to maintain it? Less talk, more action methinks :-).

Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Daniel Phillips]

Gregory Maxwell wrote:
> 
> On Wed, 6 Sep 2000, Alan Cox wrote:
> 
> > > Ehh? And exactly _how_ would a debugger help it.
> > >
> > > Especially as Alan quoted an example of a driver bug that didn't get fixed
> > > for several months because the maintainer didn't have the hardware.
> > >
> > > What would a debugger have done?
> >
> > Let the end user give me essential answers on what was happening at the failure
> > point. Think of it as a crash dump tool with extra controls
> [snip]
> 
> If this is your primary argument for a kernel debugger, a 'crash dump tool
> with extra controls', then why not just cleanly implement a 'crash dump
> tool with extra controls'.

Where did he say 'primary argument'?

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Tigran Aivazian]

On Thu, 7 Sep 2000, George Anzinger wrote:

> Chris Wedgwood wrote:
> > 
> > On Wed, Sep 06, 2000 at 12:52:29PM -0700, Linus Torvalds wrote:
> > 
> > [... words of wisdom removed for brevity ...]
> > 
> >  I'm a bastard, and proud of it!
> > 
> > Linus
> > 
> > Anyone else think copyleft could make a shirt from this?
> 
> I like this one better:
> 
> "And I'm right.  I'm always right, but in this case I'm just a bit more
> right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
> 

I like this one even better:

"Little children, keep yourselves from idols" -- St John, Ist century.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[George Anzinger]

Chris Wedgwood wrote:
> 
> On Wed, Sep 06, 2000 at 12:52:29PM -0700, Linus Torvalds wrote:
> 
> [... words of wisdom removed for brevity ...]
> 
>  I'm a bastard, and proud of it!
> 
> Linus
> 
> Anyone else think copyleft could make a shirt from this?

I like this one better:

"And I'm right.  I'm always right, but in this case I'm just a bit more
right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[David Woodhouse]

[EMAIL PROTECTED] said:
>  Which Linux companies are profitable?  **NONE**.   The only people
> making money are hardware vendors and it's a model like SUN's, where
> you get a free "machine driver" with every system you buy.   

And nobody has explained to me why these are _bad_ things.

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Alexander Viro]

On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:

> scale in the end.  We'll either see forking, see another OS like FreeBSD
> fill the void, or (worst case) Solaris.

Somehow I doubt that arguments from marketshare/field circus/etc. peppered
with threats of coprorat world turning to Solaris, etc. will win you much
love from FreeBSD core team. I _really_ doubt that they will make any
effect on the development decisions. You see, these guys are bastards
too - comes with the territory. So are NetBSD and OpenBSD folks - try to
speak to Theo that way and you will realize that Linus _is_ a nice guy,
after all.

Could we please avoid bringing the moldy corpse of UniForum on l-k? Let
it rot in purgatory, where it belongs. There are valid arguments for and
against kernel dubuggers, but Wall Street and viability of someone's
business models have nothing to them.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Alexander Viro]

On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:

 scale in the end.  We'll either see forking, see another OS like FreeBSD
 fill the void, or (worst case) Solaris.

Somehow I doubt that arguments from marketshare/field circus/etc. peppered
with threats of coprorat world turning to Solaris, etc. will win you much
love from FreeBSD core team. I _really_ doubt that they will make any
effect on the development decisions. You see, these guys are bastards
too - comes with the territory. So are NetBSD and OpenBSD folks - try to
speak to Theo that way and you will realize that Linus _is_ a nice guy,
after all.

Could we please avoid bringing the moldy corpse of UniForum on l-k? Let
it rot in purgatory, where it belongs. There are valid arguments for and
against kernel dubuggers, but Wall Street and viability of someone's
business models have nothing to them.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[George Anzinger]

Chris Wedgwood wrote:
 
 On Wed, Sep 06, 2000 at 12:52:29PM -0700, Linus Torvalds wrote:
 
 [... words of wisdom removed for brevity ...]
 
  I'm a bastard, and proud of it!
 
 Linus
 
 Anyone else think copyleft could make a shirt from this?

I like this one better:

"And I'm right.  I'm always right, but in this case I'm just a bit more
right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Availability of kdb

[Mike Jagdis]

 Q: Then why isn't kdb in the kernel?
 A: Uh...

More to the point, why don't the people that want a kernel
debugger maintain kdb and simply drop in the patch when they
need it? If Jeff releases his debugger will anyone care enough
to maintain it? Less talk, more action methinks :-).

Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Daniel Phillips]

Christer Weinigel wrote:
 
 [[EMAIL PROTECTED]] wrote:

 I'm really kind of surprised that companies like SuSE, VA and RedHat
 haven't started talking about forking the kernel already.  Those companies
 are serving the administrators and managers whose needs you are openly
 admitting that you are not concerned with.  For those companies the
 present state of affairs isn't sustainable.
 
 If you haven't noticed, they already do.  The kernel shipped from
 RedHat has quite a few patches applied that arent in Linus' tree.
 There's nothing stopping them from doing the same thing with
 the KGDB or IKD patch.

Yes, for example I doubt Mandrake would need much encouragement to
start doing that - it's just one more way to get a little bit out in
front of the pack.  This will be fine for stable kernels in shipping
distributions, IOW, for newbies, the unwashed masses, and the just
plain lazy.

For the unstable tree I can pick up the SGI patch from time to time. 
When I go so far out on the bleeding edge that SGI hasn't updated the
patch yet I'll just bare my hairy chest and wrestle those bugs into
submission with my bare hands like a man

To tell the truth it's what I've been doing anyway, except for the
part about the hairy chest. :-)

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[J. Dow]

 On Thu, 7 Sep 2000, George Anzinger wrote:
 
  Chris Wedgwood wrote:
   
   On Wed, Sep 06, 2000 at 12:52:29PM -0700, Linus Torvalds wrote:
   
   [... words of wisdom removed for brevity ...]
   
    I'm a bastard, and proud of it!
   
   Linus
   
   Anyone else think copyleft could make a shirt from this?
  
  I like this one better:
  
  "And I'm right.  I'm always right, but in this case I'm just a bit more
  right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
  
 
 I like this one even better:
 
 "Little children, keep yourselves from idols" -- St John, Ist century.
 
 Regards,
 Tigran

Aw, Tigran, give the kid his hobby, OK? We can try to bang some
sense into his head and suggest ways his hobby could offer more
satisfaction from good results achieved and make it more fun for
the rest of us. But this IS his model train setup we're playing on. So
in the final analysis he gets to choose the means of train control we
use and everything else, as well.

{^_-}


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Mike Porter]

On Wed, 6 Sep 2000, Dan Hollis wrote:

 On Wed, 6 Sep 2000, Alan Cox wrote:
  For things like driver debugging its the only way to work. Hardware simply does
  not work like the manual says and no amount of Zen contemplation will ever 
  make you at one with a 3c905B ethernet card. 
 
 This is probably the best argument for a kernel debugger.
 
 Adding debug code (printk, if/then/BUG() etc) to track down a driver bug
 sometimes changes behaviour enough to turn it into a heisenbug. In these
 cases a kernel debugger is the best way to swat it.

I've found the opposite more times than not.  The debugger leaves
too many zeroes around, leading to code that doesn't fail when run
under the debugger.

Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Richard Gooch]

Tigran Aivazian writes:
 On Thu, 7 Sep 2000, George Anzinger wrote:
  I like this one better:
  
  "And I'm right.  I'm always right, but in this case I'm just a bit more
  right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000.
  
 
 I like this one even better:
 
 "Little children, keep yourselves from idols" -- St John, Ist century.

Hm. Does that apply also to all the statues of saints, the virgin
mother and all those crosses with Jesus that you find in churches,
hanging off people's necks and in some places on every street corner?

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Jamie Lokier]

Timur Tabi wrote:
 Well, if it really is just his hobby, then he shouldn't be chanting
 the "World Domination" mantra.

Why not?  World Domination is my hobby too :-)

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Ingo Molnar wrote:
 
 On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
 
  [...] Hardware problems require a debugger or logic analyzer to fix.
  [...]
 
 'kernel problems need a kernel debugger to fix'. How wrong.

It says "hardware problems" not "kernel problems".  read it again.

:-)

Jeff

 
 Ingo
 
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[lamont]

On Thu, 7 Sep 2000, Alexander Viro wrote:
 On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
  scale in the end.  We'll either see forking, see another OS like FreeBSD
  fill the void, or (worst case) Solaris.
 
 Somehow I doubt that arguments from marketshare/field circus/etc. peppered
 with threats of coprorat world turning to Solaris, etc. will win you much
 love from FreeBSD core team.

First of all I'm not trying to threaten anyone.  Second of all, I'm not
trying to affect FreeBSD at all.  I'm pointing out there's a
void.  FreeBSD could fill that void.  Or they could choose not to.

 I _really_ doubt that they will make any
 effect on the development decisions. You see, these guys are bastards
 too - comes with the territory. So are NetBSD and OpenBSD folks - try to
 speak to Theo that way and you will realize that Linus _is_ a nice guy,
 after all.

I've gotten into flamewars with Theo on comp.security.unix before.  You
don't need to explain that to me either.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Michal Jaegermann]

Jamie Lokier wrote:
 World Domination is my hobby too :-)

Now, that is THE T-shirt!  What should be added?  A flock of penguins
in an attack mode. :-)

  --mj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[Peter Samuelson]

  [Tigran]
  I like this one even better:
  
  "Little children, keep yourselves from idols" -- St John, Ist century.

[rgooch]
 Hm. Does that apply also to all the statues of saints, the virgin
 mother and all those crosses with Jesus that you find in churches,
 hanging off people's necks and in some places on every street corner?

Why, yes it does, IMO.  In fact ... [snaps fingers] you appear to have
rediscovered a centuries-old argument, and the single biggest problem
many of us Protestants have with Roman Catholic doctrine  practice.

[Now, centuries-old theological arguments may well be of supreme
importance in some ways -- an undeniably subjective and personal
judgment -- but in terms of Linux kernel development they are usually
considered even more off-topic than the latest clever AC quote.]

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: Availability of kdb

[J. Dow]

Timur,
 Well, if it really is just his hobby, then he shouldn't be chanting the "World
 Domination" mantra.  Either Linux belongs to Linus, in which case it's
 irrelevant outside his personal world, or it is a tool for all computer users.
 If Linus really doesn't care who uses his OS, then he should not be
encouraging
 community participation, and he shouldn't be accepting speaking engagements at
 major conventions where business users attend to decide whether Linux is for
 them or not.

Shh, you're not supposed to notice that man behind the curtain
over there that your annoying little doggy found.

{^_-}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Mike Galbraith]

On Wed, 6 Sep 2000, Daniel Phillips wrote:

> Mike Galbraith wrote:
> > 
> > On Wed, 6 Sep 2000, Damien Miller wrote:
> > 
> > > Tools like a KDB would make the kernel a lot more accessible to the
> > > time-poor.
> > 
> > Kdb is available to all.  I think it should be _integrated_ mostly
> > because of the (potential) improvement in bug report quality.
> 
> Well, yes and no.  As maintained by SGI, kdb is up to date:
> ftp://oss.sgi.com/www/projects/kdb/download/ix86/kdb-v1.3-2.4.0-test8-pre4.gz
> 
> As maintained in the official ikd package, kdb is unusuably out of
> date, at least for me:
> ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/ikd/v2.4/2.4.0-test2-ikd2.bz2

It's the same kdb.  (I do need to re-sync with Andrea though, memleak
has been busted and fixed since way back then)  It happens the other
way around too.. sometimes ikd patches are against a more recent kernel
than the standalone kdb patch.

-Mike

In any case, if the official release ikd is ever too old for anyone
(ikd is maintenance intensive.  Andrea wouldn't get any work done if
he released for every pre-patch), drop a line via private mail and
I'll extract/send what I'm running. #include  ;-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Lars Marowsky-Bree]

On 2000-09-06T12:52:29,
   Linus Torvalds <[EMAIL PROTECTED]> said:

I do agree with your assessment.

Except for a single point:

> And quite frankly, for most of the real problems (as opposed to the stupid
> bugs - of which there are many, as the latest crap with "truncate()" has
> shown us) a debugger doesn't much help. And the real problems are what I
> worry about. The rest is just details. It will get fixed eventually. 

I want these to get fixed _soon_. Not later. I want fixing these to be made as
easy as possible, because they are annoying and don't have to be, because the
"simple" problems are easier spotted with a debugger.

If a real problem gets spotted easier and fixed correctly, all the better. If
some people are able to better understand the code and what it does with a
debugger, all the better.

The community peer review will weed out incorrect patches. I doubt there will
be too many of them or that people will suddenly start patch bombing l-k with
crap because a debugger has been added.

Hell, if a debugger only supplies a single clue to make people go "Duh, I was
looking in the entirely wrong direction, better get to understand how the
networking code works instead of hunting it in the VM layer", it is well worth
it.

I don't need quick and shallow fixes any more than you do. I want the code to
stabilize, and do The Right Thing(tm). For all "fixes" which lead to clumsy,
harder to understand code - see figure 1.

For those fixes which can be spotted because we can easily get a consistent
view of what happened on the system the time it crashed - no more "What
processes were you running, try disabling  and see if it persists" -, debugger output which makes you go "Duh, I
have a typo there", I _do_ care for a debugger.

> I do realize that others disagree. And I'm not your Mom. You can use a
> kernel debugger if you want to, and I won't give you the cold shoulder
> because you have "sullied" yourself. But I'm not going to help you use
> one, and I wuld frankly prefer people not to use kernel debuggers that
> much. So I don't make it part of the standard distribution, and if the
> existing debuggers aren't very well known I won't shed a tear over it.
> 
> Because I'm a bastard, and proud of it!
> 
>   Linus

This makes for a good Think Geek shirt, and I will personally buy one and try
to get it signed by Alan.

But for trying to shepherd a project the size of the Linux, I do think it is
the wrong attitude if taken to the extremes. Not trying to make it easier for
the masses to provide better QA data, or even fix the stupid errors
themselves, so that the core team can focus on the real hard bugs and design
issues, I call that wrong.

Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>
Development HA

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[lamont]

On Wed, 6 Sep 2000, Gregory Maxwell wrote:
> On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
> > If you'd read what I wrote in it's entirety, you'd know that I'm very well
> > aware of this perspective.
> 
> I read it. I just didn't agree with the level of importance I felt you
> were assigning to corporate use.

Well, what I'm trying to do is raise the issue.  If it seems like I'm
trying to make it overly important there's probably some miscommunication
going on.  
 
> I think it's obvious you understand what Linus wrote. I think you
> misunderstand the design focus of the Linux kernel.

I think I understand the design focus as well.  Like you said a bit later
its focused on creating a very solid underlying structure.  Maybe you're
right that in the long-run Linux will win the race by having the solid
structure with all the features layered properly on top of it.  OTOH if
Linux doesn't deliver the features soon, perhaps interest will go
elsewhere so something which doesn't have a perfect platform but is more
usable for those who need those features.  Like I said, its an interesting
experiment, we'll see who is right in the end...
 
> > Perhaps to put a better spin on things what I should state is that I
> > understand what Linus is trying to do, and I'm merely pointing out that
> > he's really not filling the gap of supplying an IT-friendly open source
> > OS.
> 
> I don't believe he ever stated that he wanted to do that.

I never stated that I believed that Linus wanted to do that.  Lots of
people seem to think that he's doing this though.  I'm just pointing out
that he's not.

> > I don't know why this viewpoint creates such hostile responses from some
> > people.  I'm pointing out that Linux is not everything for everyone.  
> > Heresy.
> 
> I certainly hope you didn't see my response as hostile. It certainly wasn't
> intended to be that way.

Actually yours wasn't at all.  Some of the e-mail I'm getting privately
hasn't quite been as polite though, and I was still doing a bit of a slow
burn...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Mark Hahn]

> your email inundation by one. Er, why's the list setup without
> a reply-to the list?)

lists that add "reply-to: list" degenerate to chat rooms.
so this is social-engineering, just like the lack of builtin kernel debugger.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Horst von Brand]

<[EMAIL PROTECTED]> said:

[...]

> It cuts the other way as well though.  If it is prohibitively hard and
> difficult to get fixes out for bugs in the Linux kernel, then companies
> will tend to choose other operating systems to run their applications on.

So what? I have been running Linux from long before the craze started, and
I suspect I'll be doing so long after it dies down (if it does).

In any case, in Linux (and OS software in general) I find it is much easier
to get bugs fixed than with closed alternatives. The hard problem is to
find bugs to fix... there are so few ;-)

[...]

> I'm really kind of surprised that companies like SuSE, VA and RedHat
> haven't started talking about forking the kernel already.  Those companies
> are serving the administrators and managers whose needs you are openly
> admitting that you are not concerned with.  For those companies the
> present state of affairs isn't sustainable.  

The people at the helm of those companies seem to think otherwise. And I
suspect they know a bit more about their respective states of affairs than
you do. 

In a way they have forked the kernel (mildly) already, just look at the
patches they apply to the kernels they ship. But none of them can match the
manpower of the full kernel hacker community, so they know they have to
stay in synch with the official kernel in general terms.

> And I don't ask you to care about it.  I guess my point is just that the
> linux kernel is an experiment in what happens when you ditch the managers
> and administrators and business-types and try to write a major software
> project entirely driven by developers.  I will place a friendly wager that
> the experiment will show that not all the needs of those people are as
> dismissable as many software developers seem to think.

Linux is doing fine, thank you.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Gregory Maxwell]

On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:

> If you'd read what I wrote in it's entirety, you'd know that I'm very well
> aware of this perspective.

I read it. I just didn't agree with the level of importance I felt you
were assigning to corporate use.

> I don't need to have the volumes of idiocy
> which come out of some management pointed out to me.

Good.

> At the same time my
> entire point was that I think there's some valid business concerns that
> they have /after/ removing all the crap, and that I wouldn't be surprised
> if the market went against linux and in favor of other operating systems
> that addressed them.

They should use what is best for them.

> And if you think I don't understand what Linux wrote you are very wrong.  

I think it's obvious you understand what Linus wrote. I think you
misunderstand the design focus of the Linux kernel.

> Perhaps to put a better spin on things what I should state is that I
> understand what Linus is trying to do, and I'm merely pointing out that
> he's really not filling the gap of supplying an IT-friendly open source
> OS.

I don't believe he ever stated that he wanted to do that.

>  He's providing an OS for developers.  Cool.  Fine.  No worries.  But

It would be more accurately to say that he's creating a GPLed Unix
compatible kernel which utilizes the best (in his unhumble
opinion) available technologies while remaining reasonably compatible. The
strongest development direction appears to be towards long-term
sustainability and stability (vs short term) and a focus on features that
are usable today (vs experimental stuff).

> that does leave a void, in my opinion.  Perhaps disributions adding
> patches to the kernel will fill this void, but I tend to think it wont
> scale in the end.  We'll either see forking, see another OS like FreeBSD
> fill the void, or (worst case) Solaris.

None of those are necessarily bad things.

I think Linuses design decisions will pay off in the long run. When the
race has no ending line, who cares if you have a slower start.

> I don't know why this viewpoint creates such hostile responses from some
> people.  I'm pointing out that Linux is not everything for everyone.  
> Heresy.

I certainly hope you didn't see my response as hostile. It certainly wasn't
intended to be that way.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

> Or, to misquote Feynman (another cantankorous bastard, but proud of it):
> 
> "Look at the problem. Think really hard. And write the correct code."

In a smallish voice I note that the debugger helps you look at the problem.
It is your X-Ray vision.

{o.o}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[J. Dow]

Quoth Linus
> Apparently, if you follow the arguments, not having a kernel debugger
> leads to various maladies:
>  - you crash when something goes wrong, and you fsck and it takes forever
>and you get frustrated.
>  - people have given up on Linux kernel programming because it's too hard
>and too time-consuming
>  - it takes longer to create new features.

Quoth an unrepentant jdow.
 Nice men of straw there. I note you properly demolished them.


> It's partly "source vs binary", but it's more than that. It's not that you
> have to look at the sources (of course you have to - and any good debugger
> will make that _easy_). It's that you have to look at the level _above_
> sources. At the meaning of things. Without a debugger, you basically have
> to go the next step: understand what the program does. Not just that
> particular line.

The point is that WITH a debugger you have to take that step as well.
A person without the self discipline to do that is still a child and should
not be in this business. The debugger gives you a better picture of what
is actually happening. If that leverage is considered to be a bad thing
I am surprised and dismayed. A bloody LOT of personal experience 
and technological bloody noses suggests it is a very good thing.

> And quite frankly, for most of the real problems (as opposed to the stupid
> bugs - of which there are many, as the latest crap with "truncate()" has
> shown us) a debugger doesn't much help. And the real problems are what I
> worry about. The rest is just details. It will get fixed eventually. 

Is somebody saying that a debugger is the key to heaven? I certainly
am not. It is the platform at the top of the ladder that holds your paint
bucket so that you don't have to climb up and down the ladder of your
understanding quite so often. It also beats you over the head with
facts when your head has it wrong. And I must admit that is a painful
hit direct to the ego. {^_-}

> Because I'm a bastard, and proud of it!

And I am an older bitch and proud of it. I've whupped bigger boys than
you.

{^,-}At least I ended on some humor.
(And I even arranged that you only see the list copy reducing
your email inundation by one. Er, why's the list setup without
a reply-to the list?)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/