Er, um, yes. I stand corrected.
-Original Message-
From: Steve VanDevender [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 14, 2000 11:44 AM
To: Marty Fouts
Cc: '[EMAIL PROTECTED]'; Michael Rothwell; Linux kernel
Subject: RE: Advanced Linux Kernel/Enterprise Linux Kernel
Marty
I would agree that Multics probably wouldn't qualify as a platform for
enterprise computing these days, but it is interesting to examine the 9
stated goals, and see how they relate to enterprise computing. They are
applicable goals, although they certainly don't qualify as the only set, and
Dick Johnson wrote:
> The original DEC was "given" to W. M. Ritchie and his staff in
> "Department 58213". He wanted to use it for games. To do so, required
> him to write some sort of OS, which became Unix.
A typo, I assume. That's D(ennis) Ritchie.
> As I said, when Multics was designed,
Actually, you have the sequence of events slightly out of order. AT,
specifically Bell Labs, was one of the participants in the program that
would develop Multics. AT opted out of the program, for various reasons,
but it continued apace. The PDP-8 of fame was one that, according to
Thompson,
Sorry, wrong answer, but thanks for playing. Multics was not abandoned as
unusable, and was, in fact, widely used, sometimes in what would now be
called "mission critical" applications, for a long time. While Honeywell
finally stopped supporting Multics sometime in the 90s, I was surprised and
Sorry, wrong answer, but thanks for playing.
When Multics was developed, (early 60s,) DEC equipment wasn't even
interesting to much of an audience. The original equipment Multics ran on
was build by one of the "seven dwarf" computer companies, (GE) which was
soon to get out of the computer
Sorry, wrong answer, but thanks for playing.
When Multics was developed, (early 60s,) DEC equipment wasn't even
interesting to much of an audience. The original equipment Multics ran on
was build by one of the "seven dwarf" computer companies, (GE) which was
soon to get out of the computer
Sorry, wrong answer, but thanks for playing. Multics was not abandoned as
unusable, and was, in fact, widely used, sometimes in what would now be
called "mission critical" applications, for a long time. While Honeywell
finally stopped supporting Multics sometime in the 90s, I was surprised and
Actually, you have the sequence of events slightly out of order. ATT,
specifically Bell Labs, was one of the participants in the program that
would develop Multics. ATT opted out of the program, for various reasons,
but it continued apace. The PDP-8 of fame was one that, according to
Thompson,
Dick Johnson wrote:
The original DEC was "given" to W. M. Ritchie and his staff in
"Department 58213". He wanted to use it for games. To do so, required
him to write some sort of OS, which became Unix.
A typo, I assume. That's D(ennis) Ritchie.
As I said, when Multics was designed, the
I would agree that Multics probably wouldn't qualify as a platform for
enterprise computing these days, but it is interesting to examine the 9
stated goals, and see how they relate to enterprise computing. They are
applicable goals, although they certainly don't qualify as the only set, and
Er, um, yes. I stand corrected.
-Original Message-
From: Steve VanDevender [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 14, 2000 11:44 AM
To: Marty Fouts
Cc: '[EMAIL PROTECTED]'; Michael Rothwell; Linux kernel
Subject: RE: Advanced Linux Kernel/Enterprise Linux Kernel
Marty
There's been a bunch of related work done at the Oregon Graduate Institute
by Calton Pu and others. See
http://www.cse.ogi.edu/DISC/projects/synthetix/publications.html for a list
of papers.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday,
There is a variation of #2 that is often good enough, based on some research
work done at (among other places) the Oregon Graduate Center. I don't have
the references handy, but you might want to look for papers on "sandboxing"
authored there.
The basic idea is similar to the one used by many
There is a variation of #2 that is often good enough, based on some research
work done at (among other places) the Oregon Graduate Center. I don't have
the references handy, but you might want to look for papers on "sandboxing"
authored there.
The basic idea is similar to the one used by many
There's been a bunch of related work done at the Oregon Graduate Institute
by Calton Pu and others. See
http://www.cse.ogi.edu/DISC/projects/synthetix/publications.html for a list
of papers.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday,
If I understand the SGI compiler's history correctly, it's more than "some
code." (I would guess that it would be 70-80% of the volume of a compiler,
as Pro64 appears to only share the front end with gcc, the entire backend is
from scratch.) IA64 is architecturally very different than the sort
"microkernel" is an unfortunate term. Once upon a time it had a reasonably
well understood technical meaning and then Cutler claimed that NT had a
'microkernel' design and the FUD set in. In the literature I'm familiar
with, (not counting marketing hype,) 'micokernel means two distinct
"microkernel" is an unfortunate term. Once upon a time it had a reasonably
well understood technical meaning and then Cutler claimed that NT had a
'microkernel' design and the FUD set in. In the literature I'm familiar
with, (not counting marketing hype,) 'micokernel means two distinct
FWIW, 'message passing' is the wrong answer to the question 'how do I
separate the components of a kernel into distinct modules for ' but
that's because it's tied to the Accent ancestry of the Mach style
"microkernel".
One of the few things we did get right in Brevix was the idea of an
interface
FWIW, 'message passing' is the wrong answer to the question 'how do I
separate the components of a kernel into distinct modules for mumble' but
that's because it's tied to the Accent ancestry of the Mach style
"microkernel".
One of the few things we did get right in Brevix was the idea of an
I prefer Peter Salus' wording, myself: The difference between theory and
practice is always larger in practice than in theory.
-
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/
I prefer Peter Salus' wording, myself: The difference between theory and
practice is always larger in practice than in theory.
-
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/
> -Original Message-
> From: Matti Aarnio [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 19, 2000 1:26 PM
> To: [EMAIL PROTECTED]
> Subject: [ADMIN] some list related topics ..
[snip]
>
> 3) some ISP systems yield 500 series errors with text:
> "system is temporarily
-Original Message-
From: Matti Aarnio [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 19, 2000 1:26 PM
To: [EMAIL PROTECTED]
Subject: [ADMIN] some list related topics ..
[snip]
3) some ISP systems yield 500 series errors with text:
"system is temporarily busy"
There are some details in error in this document, and the discussion of
cache-coherence might be expanded or dropped altogether, rather than hinted
at. I've sent a long note to the author with "diffs' for a next edition.
Thanks for pointing it out, I know of several situations in which it will
There are some details in error in this document, and the discussion of
cache-coherence might be expanded or dropped altogether, rather than hinted
at. I've sent a long note to the author with "diffs' for a next edition.
Thanks for pointing it out, I know of several situations in which it will
point out bogosities
when they come up?
-Original Message-
From: Tigran Aivazian [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 16, 2000 1:05 AM
To: Marty Fouts
Cc: 'Jeff V. Merkey'; [EMAIL PROTECTED]
Subject: RE: [Criticism] On the discussion about C++ modules
On Mon, 16 Oct 2000, Marty
ives every
appearance of being nonsense.
But I do agree that discussions of C++ belong off list.
Marty
-Original Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 16, 2000 12:44 AM
To: Marty Fouts
Cc: [EMAIL PROTECTED]
Subject: Re: [Criticism] On the discussi
Um? Huh? This seems like mumbo-jumbo to me. With the exception of those
parts of the kernel that actually manipulate the hardware as hardware, --
which is a surprisingly small part of the kernel, even of the parts of the
kernel that look like what they do is manipulate the hardware as hardware
Um? Huh? This seems like mumbo-jumbo to me. With the exception of those
parts of the kernel that actually manipulate the hardware as hardware, --
which is a surprisingly small part of the kernel, even of the parts of the
kernel that look like what they do is manipulate the hardware as hardware
point out bogosities
when they come up?
-Original Message-
From: Tigran Aivazian [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 16, 2000 1:05 AM
To: Marty Fouts
Cc: 'Jeff V. Merkey'; [EMAIL PROTECTED]
Subject: RE: [Criticism] On the discussion about C++ modules
On Mon, 16 Oct 2000, Marty
As several people are sure to remind me, the Linux Kernel mailing list is
not the right forum for a discussion on language choice and the impact on
kernel development, but as this is not the first time I've followed this
class of argument, I'd like to make a couple of general observations that I
As several people are sure to remind me, the Linux Kernel mailing list is
not the right forum for a discussion on language choice and the impact on
kernel development, but as this is not the first time I've followed this
class of argument, I'd like to make a couple of general observations that I
on this mailing list
is.
> -Original Message-
> From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 06, 2000 3:40 PM
> To: Marty Fouts
> Cc: 'jesse'; [EMAIL PROTECTED]
> Subject: Re: Tux 2 patents
>
>
>
>
> Marty Fouts wrote:
&g
uct/pct.html?t=0023003202000)
-Original Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 2:35 PM
To: Marty Fouts
Cc: 'jesse'; [EMAIL PROTECTED]
Subject: Re: Tux 2 patents
I've filed lots of patents in my day Marty -- this is correct. I have
two patent la
.
Marty
-Original Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 11:52 AM
To: Marty Fouts
Cc: 'jesse'; [EMAIL PROTECTED]
Subject: Re: Tux 2 patents
And you only get the year of protection **IF** you have filed a
provisional patent application
Please be careful with attributions. I did not write the paragraph
attributed to me below, which contains information I believe is incorrect.
-Original Message-
From: Daniel Phillips
[mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 12:24 PM
To: Marty Fouts; [EMAIL PROTECTED
IANAL; this is not legal advice.
The 'one year' you are referring to is from 'disclosure', not from released
product. "disclosure" in this case is a legal term-of-art. Further, there
is a difference between US and European Union patent law, in that, IIRC, EU
law requires patent application
IANAL; this is not legal advice.
The 'one year' you are referring to is from 'disclosure', not from released
product. "disclosure" in this case is a legal term-of-art. Further, there
is a difference between US and European Union patent law, in that, IIRC, EU
law requires patent application
Please be careful with attributions. I did not write the paragraph
attributed to me below, which contains information I believe is incorrect.
-Original Message-
From: Daniel Phillips
[mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 12:24 PM
To: Marty Fouts; [EMAIL PROTECTED
.
Marty
-Original Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 11:52 AM
To: Marty Fouts
Cc: 'jesse'; [EMAIL PROTECTED]
Subject: Re: Tux 2 patents
And you only get the year of protection **IF** you have filed a
provisional patent application
0003202000)
-Original Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 2:35 PM
To: Marty Fouts
Cc: 'jesse'; [EMAIL PROTECTED]
Subject: Re: Tux 2 patents
I've filed lots of patents in my day Marty -- this is correct. I have
two patent lawyers on st
on this mailing list
is.
-Original Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 3:40 PM
To: Marty Fouts
Cc: 'jesse'; [EMAIL PROTECTED]
Subject: Re: Tux 2 patents
Marty Fouts wrote:
I don't do pissing matches, Jeff, and won't
IANAL
That said, I would refer anyone interested in 'prior art' in patents to
http://www.ipmall.fplc.edu/ipcorner/bp98/welch.htm
especially the brief discussion on what 'prior art' is to the patent office.
Also, for those who believe that similar concepts will void patents, I would
suggest a
> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 29, 2000 2:08 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Anyone working on multi-threaded core
> -Original Message-
> From: Igmar Palsenberg [mailto:[EMAIL PROTECTED]]
[snip]
>
> Maybe I'm totally stupid, but I think you need to sync the
> threads so that
> the're in the same state. And I don't think it's that simple.
>
> Or I'm talking totally nonsense here :)
>
I think
I suspect that this discussion belongs off-list, because it apparently comes
up frequently.
But an observation from a Linux-Kernel "outsider":
Multilanguage developement (meaning using more than one language in the
product) makes any product harder to develop. Because Linux is in C
originally
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 29, 2000 3:39 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Linux kernel modules development in C++
>
>
> But but but.. wasn't the very first C++ compilers really just
> a preprocessor
; From: Daniel Phillips [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 29, 2000 1:16 AM
> To: Marty Fouts
> Subject: Re: Linux kernel modules development in C++
>
>
> Marty Fouts wrote:
> > IMO, it was worse even than that. C++ itself hadn't
> stablized as a languag
: Daniel Phillips [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 29, 2000 1:16 AM
To: Marty Fouts
Subject: Re: Linux kernel modules development in C++
Marty Fouts wrote:
IMO, it was worse even than that. C++ itself hadn't
stablized as a language
to the point where it would have been wise
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 29, 2000 3:39 AM
To: [EMAIL PROTECTED]
Subject: RE: Linux kernel modules development in C++
But but but.. wasn't the very first C++ compilers really just
a preprocessor into
I suspect that this discussion belongs off-list, because it apparently comes
up frequently.
But an observation from a Linux-Kernel "outsider":
Multilanguage developement (meaning using more than one language in the
product) makes any product harder to develop. Because Linux is in C
originally
-Original Message-
From: Igmar Palsenberg [mailto:[EMAIL PROTECTED]]
[snip]
Maybe I'm totally stupid, but I think you need to sync the
threads so that
the're in the same state. And I don't think it's that simple.
Or I'm talking totally nonsense here :)
I think one needs
-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 29, 2000 2:08 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Anyone working on multi-threaded core files
> -Original Message-
> From: Horst von Brand [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 28, 2000 1:45 PM
[snip]
> When Linux started, there was _no_ decent freeware C++
> compiler around.
IMO, it was worse even than that. C++ itself hadn't stablized as a language
to the
-Original Message-
From: Horst von Brand [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 28, 2000 1:45 PM
[snip]
When Linux started, there was _no_ decent freeware C++
compiler around.
IMO, it was worse even than that. C++ itself hadn't stablized as a language
to the
Gene did the instruction set architecture along with some others. I think he
was also involved in the i/o architecture.
-Original Message-
From: Joel Jaeggli [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 4:59 PM
To: Marty Fouts
Cc: 'Malcolm Beattie'; [EMAIL PROTECTED
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's another pi
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
> than nearly anyone here,
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've pr
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
than nearly anyone here, having
Gene did the instruction set architecture along with some others. I think he
was also involved in the i/o architecture.
-Original Message-
From: Joel Jaeggli [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 4:59 PM
To: Marty Fouts
Cc: 'Malcolm Beattie'; [EMAIL PROTECTED
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've probably debugged
.
Basically, I use a debugger when I realize that I've developed a perception
block and I want to validate my perception against reality. Computing is,
after all, an empirical science.
Marty
-Original Message-
From: Larry McVoy [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 17, 200
ou,
just as only a very small handful of us now remember who wrote OS/360. Work
hard on having fun, the rest will sort itself out.
Marty (as silly as ever)
-Original Message-
From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 17, 2000 5:49 PM
To: Marty Fouts
Cc: Oliv
ou,
just as only a very small handful of us now remember who wrote OS/360. Work
hard on having fun, the rest will sort itself out.
Marty (as silly as ever)
-Original Message-
From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 17, 2000 5:49 PM
To: Marty Fouts
Cc: Oliv
eplacement of algorithms
based on system size.
Marty
-Original Message-
From: Jesse Noller [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 07, 2000 2:46 PM
To: Marty Fouts; [EMAIL PROTECTED]
Subject: RE: Scalability Efforts
But would it be possible to apply a sort of "Linux S
FWIW, large system scalability, especially NUMA is not tractable with a 'one
size (algorithm) fits all' approach, and can be a significant test of the
degree of modularity in your system. Different relative costs of access to
the different levels of the memory hierarchy and different models of
FWIW, large system scalability, especially NUMA is not tractable with a 'one
size (algorithm) fits all' approach, and can be a significant test of the
degree of modularity in your system. Different relative costs of access to
the different levels of the memory hierarchy and different models of
None of my arguments for kernel debuggers add up to "add new things faster".
If you want to be able to add new things faster than you need to radically
restructure systems and your implementation process to better accommodate
modularization; a different process altogether.
My arguments for
I have been involved in the freely-distributable software community since
1975. (Yes, Virginia, it predates the Free Software Foundation, and, in
fact, can be traced back to the '50s.) Freely-distributable software has
some advantages, but I didn't see then and I don't see now any path by
Isn't it time to offer the platitude about working smarter rather than
harder?
Nah, probably not.
Marty
-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 06, 2000 2:20 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL
Isn't it time to offer the platitude about working smarter rather than
harder?
Nah, probably not.
Marty
-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 06, 2000 2:20 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL
None of my arguments for kernel debuggers add up to "add new things faster".
If you want to be able to add new things faster than you need to radically
restructure systems and your implementation process to better accommodate
modularization; a different process altogether.
My arguments for
I've debugged quiet a few operating systems on a very wide range of hardware
over 25 years using a very wide range of tools and techniques, sometimes
even having to use logic analysers. I've also watched this discussion for a
while. IMHO, y'all have conflated two quiet different processes
FWIW, although this is an interesting theory, in my experience, having a
good kernel debugger allows me *more* time to think clearly, rather than
less. YMMV.
IMHO, the division of labor between man and computer should be that each
does what they are best at. In the case of debugging, this means
just an aside on asynchronous i/o: concurrency by asychronous I/O actually
predates concurrency via thread-like models, and goes back to the earliest
OS-precursors. Early work on thread-like concurrency models were, in part,
a response to the difficulties inherent in getting asynchronous I/O
I'm confused. Threads are harder than *what* to get right?
If you need concurrency, you need concurrency, and any existing model is
hard. Besides, at some level, all of the concurrency models come down to a
variant on threads, anyway.
-Original Message-
From: Alexander Viro
I'm confused. Threads are harder than *what* to get right?
If you need concurrency, you need concurrency, and any existing model is
hard. Besides, at some level, all of the concurrency models come down to a
variant on threads, anyway.
-Original Message-
From: Alexander Viro
just an aside on asynchronous i/o: concurrency by asychronous I/O actually
predates concurrency via thread-like models, and goes back to the earliest
OS-precursors. Early work on thread-like concurrency models were, in part,
a response to the difficulties inherent in getting asynchronous I/O
81 matches
Mail list logo
