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 Kern
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
could
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, th
Actually, you have the sequence of events slightly out of order. AT&T,
specifically Bell Labs, was one of the participants in the program that
would develop Multics. AT&T 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
de
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 busin
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, Nove
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 'r
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 of
"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 classes
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
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 bus
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 b
still 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
t that, IMHO, gives 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]
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
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
h
ah, but not everyone 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
>
>
>
&g
w.nolo.com/product/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
.
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 a
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 befo
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 sear
> -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 f
> -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 on
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 f
> -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
essage-
> 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
> st
> -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
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
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&
ou: mistakes like that that get by are
nearly impossible to catch.
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:
, 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. Work
hard on having fun, the rest will sort itself out.
Marty (as silly as ever)
-Original Message-
Fro
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
loved to watch it, especially the parts where he cut himself badly becaus
problem really becomes simply the run-time replacement 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
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 ca
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 kernel
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
which
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 PROTECT
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 (possib
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 rig
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 [mailto:[EM
46 matches
Mail list logo
