** On Sep 19, Marty Fouts scribbled:
> Gene did the instruction set architecture along with some others. I think he
> was also involved in the i/o architecture.
Marty, could you _please_ stop posting to this thread on lkml and _PLEASE_
learn how to snip messages and _DON'T_ quote everything you re
On Mon, 18 Sep 2000, Marty Fouts wrote:
> It contains a wee bit of wisdom.
be not wise in thine own eyes, yea, let other man praise thee. ;)
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 FA
Please kill this thread.
Linus has stated he does not want a kernel debugger in the standard
kernel. As the maintainer of kdb I accept that decision and will
maintain kdb outside the kernel. Any other discussion is just noise.
-
To unsubscribe from this list: send the line "unsubscribe linux-k
PROTECTED]
Subject: RE: Availability of kdb
Gene Amdahl I think...
On Mon, 18 Sep 2000, Marty Fouts wrote:
> I think that more people quote Brooks than have read him and that more
> people know him from the Mythical Man Month than from the POO.
>
> He wasn't, by the way, the princi
AIL PROTECTED]]
> Sent: Monday, September 18, 2000 3:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Availability of kdb
>
> Marty Fouts writes:
> > Here's another piece of free advice, worth less than you paid for it: in
> 25
> > years, only the computer history tr
edition of MMM is Brooks'
apology to Gries about being wrong about information hiding.
-Original Message-
From: Malcolm Beattie [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 3:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Availability of kdb
Marty Fouts writes:
> Here&
1:36 AM
To: Marty Fouts
Cc: 'Larry McVoy'; 'Linus Torvalds'; Oliver Xymoron; Daniel Phillips; Kernel
Mailing List
Subject: RE: Availability of kdb
On Sun, 17 Sep 2000, Marty Fouts wrote:
> I've probably debugged more operating systems under more varied
environments
"J. Dow" wrote:
>
> Jeff et al who might prefer a kernel debugger,
>
> One should note that when a person or critter is backed into a corner
> and pressured hard enough that he makes an "over my dead body"
> level statement more pressure is likely to solidify the position rather
> than change
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
> Marty,
>
> I think they said they could care less about kernel debuggers. Just go
> write one, use Keith's or ours or whatever, and do what you want with
> your Linux development -- Linus doesn't seem to care if you just make a
> fork of Linux or s
On Sun, Sep 17, 2000 at 08:40:33PM -0700, Larry McVoy wrote:
> On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> I'm sort of in the middle. I know BitKeeper very well, and it's actually
> a larger wad of code than the kernel if you toss out the device drivers.
> About the only thing
Marty,
I think they said they could care less about kernel debuggers. Just go
write one, use Keith's or ours or whatever, and do what you want with
your Linux development -- Linus doesn't seem to care if you just make a
fork of Linux or someone else does with a debugger for your projects.
Thes
Marty Fouts writes:
> Here's another piece of free advice, worth less than you paid for it: in 25
> years, only the computer history trivia geeks are going to remember you,
> just as only a very small handful of us now remember who wrote OS/360.
You mean like Fred Brooks who managed the developme
On Sun, 17 Sep 2000, Marty Fouts wrote:
> I've probably debugged more operating systems under more varied environments
> than nearly anyone here, having brought up a new OS, compiler, and CPU
yea yea yea, if you are so good then you should be concentrating on giving
your goodness and wisdom and e
ember 17, 2000 10:40 PM
To: Marty Fouts
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Availability of kdb
From: Marty Fouts <[EMAIL PROTECTED]>
Date:Sun, 17 Sep 2000 22:42:22 -0700
I&
From: Marty Fouts <[EMAIL PROTECTED]>
Date:Sun, 17 Sep 2000 22:42:22 -0700
I've probably debugged more operating systems under more varied
environments than nearly anyone here
Which one of them was %100 distributed where no two of the developers
were in the same building and
Larry McVoy [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 17, 2000 8:41 PM
To: Marty Fouts
Cc: 'Linus Torvalds'; Oliver Xymoron; Tigran Aivazian; Daniel Phillips;
Kernel Mailing List
Subject: Re: Availability of kdb
On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> U
m: Linus Torvalds [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 17, 2000 5:49 PM
To: Marty Fouts
Cc: Oliver Xymoron; Tigran Aivazian; Daniel Phillips; Kernel Mailing List
Subject: RE: Availability of kdb
On Sun, 17 Sep 2000, Marty Fouts wrote:
>
> Craftsmanship is in the way you approac
On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote:
> Um, for what ever it is worth, if you want to compare "power user" carpentry
> to "hand tools only" you can actually do it fairly easily on PBS in the US.
> There used to be a program done by a guy who did everything by hand. I
> love
; Daniel Phillips; Kernel Mailing List
Subject: Re: Availability of kdb
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 _techn
Linus Torvalds wrote:
> On Sun, 17 Sep 2000, Marty Fouts wrote:
> >
> > Craftsmanship is in the way you approach what you do, not in the tools you
> > use to do it. And, frankly, if you wish to artificially limit your use of
> > tools, all you are doing is hobbling yourself.
>
> You know what?
>
On Sun, 17 Sep 2000, Marty Fouts wrote:
>
> Craftsmanship is in the way you approach what you do, not in the tools you
> use to do it. And, frankly, if you wish to artificially limit your use of
> tools, all you are doing is hobbling yourself.
You know what?
Start your own kernel (or split o
On Tue, 12 Sep 2000, Jeff V. Merkey wrote:
>
> Ted,
>
> I am looking at these sources as well. One thing I went back and looked
> at was related to a comment from Mike G. I believe regarding drivers
> conflicts with int 0x13 requests potentially hosing the IDE driver. In
Hmm.. must be a diff
Ted,
I am looking at these sources as well. One thing I went back and looked
at was related to a comment from Mike G. I believe regarding drivers
conflicts with int 0x13 requests potentially hosing the IDE driver. In
MANOS, since DOS is resident underneath the OS, I instrumented the code
a lot
Date: Mon, 11 Sep 2000 17:51:20 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
I support source level in the kernel. Based on Andi Klein's review, I
have grabbed ext2utils and am looking at a minimal int 0x13 interface to
load files into memory. hardest problem here for Linux i
On Mon, 11 Sep 2000, Jeff V. Merkey 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 proj
Keith Owens wrote:
>
> 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 kd
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
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
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 cont
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
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 --
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
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, bu
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
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 hardw
One way of increasing signal to noise ratio (place in .procmailrc):
:0
* ^FROM.*jmerkey@timpanogas\.com
/dev/null
On Mon, Sep 11, 2000 at 03:53:48PM -0400, [EMAIL PROTECTED] wrote:
> On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
> Now will you stop trying to incite pointless riots and allow those
[EMAIL PROTECTED] wrote:
> Now will you stop trying to incite pointless riots and allow those of us
> who are trying to use linux-kernel as a useful means of communicating
> development issues a chance for a decent signal to noise ratio?
>
> -ben
Ben,
Read the thread before g
I'll give it some thought. Most of Linux has better paging than NetWare
already -- NetWare is pretty simple in this respect. THe process
mapping stuff in Netware (PCB's are mapped to recursively point to
themselves with a global brach table) is unique, but not as good as
what's in Linux.
:-)
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
> If you need to know if the page has been accessed, you can clear this
> bit when a page is first mapped, and when someone touches it, the
> hardware will set this bit. It set's it by doing a R/M/W operation on
We've set the accessed bit for a long ti
Jeff V. Merkey wrote:
> One of the best references that describes the bus transaction model for
> Intel in "plain english" is the Pentium Pro Processor System
> Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
> ISBN: 0-201-47953-2. It explains a very good detail how the ca
Rik van Riel wrote:
> > 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
Allright, You've convinced me. I'll do it. It will require consierable
support moving forward.
:-)
Jeff
Miles Lane wrote:
>
> On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
> >
> >
> > "Theodore Y. Ts'o" wrote:
> >
> > >
> > > If you come up with robust, easy to patch source-code-level debug
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
>
> "Theodore Y. Ts'o" wrote:
>
> >
> > If you come up with robust, easy to patch source-code-level debugger for
> > Linux, some people will use it, and some people won't. If it's better
> > than kdb, eventually it'll displace kdb as the external
> "A" == Alexander Viro <[EMAIL PROTECTED]> writes:
A> As for the "greater social good" (or world domination, for that
A> matter) - excuse me, but quite a few of us couldn't care
A> less.
Thanks for the comment, and please don't feel guilty about it, it is a
perfectly valid reas
Jamie,
I referenced a great book an an email to Rik Van Reil. It's got a great
explanation of this stuff.
:-)
Jeff
Jamie Lokier wrote:
>
> Jeff V. Merkey wrote:
> > This means it completely unnecessary to assert LOCK# for the unlock
> > case, since there are no ordering issues persay - th
Rik,
One of the best references that describes the bus transaction model for
Intel in "plain english" is the Pentium Pro Processor System
Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
ISBN: 0-201-47953-2. It explains a very good detail how the cache
controllers and MES
On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
> 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 i
Jeff V. Merkey wrote:
> This means it completely unnecessary to assert LOCK# for the unlock
> case, since there are no ordering issues persay - the other processors
> are spinning on the lock already and cannot get through.
Yes I know I left out the context. Doesn't change what I'm about to
say.
Jamie Lokier wrote:
>
> Jeff V. Merkey wrote:
> > The best info I know of is to get an analyser that plugs into the
> > processor socket (like an american arium) and enable branch trace
> > messaging to monitor the interaction between the processor and the cache
> > controllers. You get info
Lars Marowsky-Bree wrote:
> > I still don't see how processor traces will tell me what ordering
> > guarantees I can rely on across the range of processors.
>
> It will tell you when your assumptions were wrong.
Indeed. Like testing, but better.
-- Jamie
-
To unsubscribe from this list: send t
On 2000-09-11T18:11:11,
Jamie Lokier <[EMAIL PROTECTED]> said:
> I still don't see how processor traces will tell me what ordering
> guarantees I can rely on across the range of processors.
It will tell you when your assumptions were wrong.
Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED
Jeff V. Merkey wrote:
> The best info I know of is to get an analyser that plugs into the
> processor socket (like an american arium) and enable branch trace
> messaging to monitor the interaction between the processor and the cache
> controllers. You get info that's not in any Intel book just wa
The best info I know of is to get an analyser that plugs into the
processor socket (like an american arium) and enable branch trace
messaging to monitor the interaction between the processor and the cache
controllers. You get info that's not in any Intel book just watching
the thing run. Nasty
> I won't use a Linus example in the future since this seems to turn off
> some folks reason centers and they go into "attack mode".
Thanks Jeff, I heard that.
I got a lot of useful info from that 3 week long thread, but it's still
a bit confusing. A decent document from Intel or their competit
"Theodore Y. Ts'o" wrote:
>
> If you come up with robust, easy to patch source-code-level debugger for
> Linux, some people will use it, and some people won't. If it's better
> than kdb, eventually it'll displace kdb as the external kernel debugger
> of choice. As with all things, the cardi
Jamie,
I should have never brought this example up. The thread "spin_unlock()
optimization" that went on for three weeks with Intel and the whole
planet getting into the fray speaks for itself, and anyone wanting to
search the kernel archives can do so and for their own opinion. I won't
use a
Date:Sun, 10 Sep 2000 17:06:17 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
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
Gary Lawrence Murphy wrote:
> The analogy to typing hex codes or toggling code at the console is
> also apt. Unix ascended over Multix in no small part because of C,
> which drew sneers from the trad programmer of the day. Personally, I
> tend to debug intuitively based on my knowledge of code,
> > 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 perfe
On 11 Sep 2000, Gary Lawrence Murphy wrote:
> > "H" == Horst von Brand <[EMAIL PROTECTED]> writes:
>
> H> In the end, this is Linus' game. If you want to play, you'll
> H> have to pay the admission price he sets.
>
> Is it fair to ask about the purpose of Linux?
>
> The purpos
> "H" == Horst von Brand <[EMAIL PROTECTED]> writes:
H> In the end, this is Linus' game. If you want to play, you'll
H> have to pay the admission price he sets.
Is it fair to ask about the purpose of Linux?
The purpose I most often hear talks about world domination and about
havi
Jeff V. Merkey wrote:
> 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
> '
No logic analyser will tell you the subtleties of _why_ it works.
Y
On Wed, 6 Sep 2000, Linus Torvalds wrote:
>
>
> On Wed, 6 Sep 2000, Marco Colombo wrote:
> >
> > As you said, the are two kinds of reactions. I don't understand why you
> > think that the presence of a debugger will *prevent* people from doing
> > the Right Thing and "think about problems anot
[EMAIL PROTECTED] (Jeff V. Merkey) writes:
[ Jeff V. Merkey, super man ]
Huh. Once again, none of your facts is straight or correct:
>Famous double YY's of history:
>Good:
[...]
>Albert Einstein
--- cut ---
http://www.aip.org/history/einstein/einbrain.htm
Was Einstein's Brain Different?
[EMAIL PROTECTED] (Jeff V. Merkey) writes:
>They are bad because they cost people money that could be spent more
>productively in other areas due to the lengthening of the development
You still miss the point.
Most kernel developers don't give a damn about money. If you're in
kernel development
On Sun, 10 Sep 2000, Jeff V. Merkey wrote:
> 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
"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
"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 refe
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
a
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 har
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 th
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 inform
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 i
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
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
On Sun, 10 Sep 2000, J. Dow wrote:
> >
> > [ 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.
You know, Dow, if I were to
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 participat
"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 w
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_. Bu
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,
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 understand
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 u
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 completel
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
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 abo
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 comp
On Sat, 9 Sep 2000, 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.
[...]
> It's about what kind of people
[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 scientis
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 engineer
[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 livin
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 program
> 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 tool
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 m
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 t
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
> con
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
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
[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 nec
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 F
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 th
1 - 100 of 170 matches
Mail list logo
