From: Werner Almesberger <Werner.Almesberger@epfl.ch>
To: Michael Rothwell <rothwell@holly-springs.nc.us>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel
Date: Wed, 15 Nov 2000 00:06:10 +0100 [thread overview]
Message-ID: <20001115000610.F8753@almesberger.net> (raw)
In-Reply-To: <200011141459.IAA413471@tomcat.admin.navo.hpc.mil> <3A117311.8DC02909@holly-springs.nc.us>
In-Reply-To: <3A117311.8DC02909@holly-springs.nc.us>; from rothwell@holly-springs.nc.us on Tue, Nov 14, 2000 at 12:14:57PM -0500
Michael Rothwell wrote:
> 2) Continuous operation analogous to power & telephone services.
>
> No way. Multics could have a whole bank of memory fail and keep running.
[...]
Considering that it's very cheap nowadays to have redundancy at the
box level, designs attempting to achieve robustness at the component
level may fail to benefit from changes in the hardware market in the
last few decades. Maybe we need a Beowulf for fault tolerance ...
> 3) A wide range of system configurations, changeable without system or
> user program reorganization.
I'd say we're largely there: /proc/sys and modules give you a lot of
freedom, if properly used.
> See comments in #2. Plus, the recent two-kernel-monte, linux-from-linux
> type stuff would be especially excellent if it will allow the kernel to
> be upgraded on the fly.
Difficult, because there's no reliable (= automated) means of tracking
data structures an the semantics of internal interfaces from kernel to
kernel. Feasible for selected subsystems and with coarse granularity,
though. (E.g. modules.)
> console ACLs, etc. If there's a function, it probably needs an ACL.
Empirical evidence with VMS suggests that overly sophisticated
security mechanisms can actually decrease overall security, because
they may lead people to micro-manage security and to neglect the
overall security concept.
> 7) Support for a wide range of applications.
>
> Well... anything wih source or compiled for the Linux ABI. A
> microkernel-type architecture with servers would provide a lot more of
> this. See QNX, NT, Mach.
Hmm, I don't think you want to say this :)
> 9) The ability to evolve the system with changes in technology and in
> user aspirations.
That's perhaps the most important point. The computing environment
has changed a lot. Take for example Google's PC farm and compare
this with the mainframe approach one would have chosen twenty or
thirty years ago. Mainframes are still the right answer for some
problems, but their role in the solution may be very different from
the days when they were the only solution, and all of the solution.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-14 23:36 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-14 14:59 Advanced Linux Kernel/Enterprise Linux Kernel Jesse Pollard
2000-11-14 15:47 ` David Weinehall
2000-11-14 17:14 ` Michael Rothwell
2000-11-14 16:20 ` Mike Dresser
2000-11-14 17:27 ` Michael Rothwell
2000-11-14 17:32 ` Michael Rothwell
2000-11-14 16:25 ` Richard B. Johnson
2000-11-14 17:29 ` Michael Rothwell
2000-11-14 16:38 ` Mark Hahn
2000-11-14 19:23 ` spam
2000-11-14 16:41 ` Richard B. Johnson
2000-11-14 17:06 ` Michael Meissner
2000-11-14 17:59 ` Richard B. Johnson
2000-11-14 17:51 ` Buddha Buck
2000-11-14 18:10 ` Michael Rothwell
2000-11-14 18:00 ` Richard B. Johnson
2000-11-15 0:31 ` Gerhard Mack
2000-11-14 20:08 ` Alexander Viro
2000-11-14 16:57 ` David Relson
2000-11-14 18:17 ` Rik van Riel
2000-11-14 19:15 ` spam
2000-11-14 16:53 ` David Relson
2000-11-14 17:06 ` Andrea Arcangeli
2000-11-14 17:55 ` Andreas Dilger
2000-11-14 18:35 ` Christoph Hellwig
2000-11-14 23:06 ` Werner Almesberger [this message]
2000-11-15 4:25 ` Albert D. Cahalan
2000-11-17 22:10 ` Daniel Phillips
2000-11-18 0:58 ` Eric W. Biederman
2000-11-18 20:13 ` Daniel Phillips
2000-11-18 16:40 ` Pavel Machek
2000-11-19 20:37 ` Daniel Phillips
2000-11-20 13:34 ` Pavel Machek
2000-11-14 17:34 ` Andrea Arcangeli
-- strict thread matches above, loose matches on Subject: below --
2000-11-17 5:28 Bernd Eckenfels
2000-11-15 4:19 Marty Fouts
2000-11-14 18:20 Marty Fouts
2000-11-14 18:18 Marty Fouts
2000-11-14 18:10 Marty Fouts
2000-11-14 19:43 ` Steve VanDevender
2000-11-15 1:13 ` Leo Mauro
2000-11-14 18:06 Marty Fouts
2000-11-14 18:03 Marty Fouts
2000-11-08 20:31 [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI) richardj_moore
2000-11-13 21:56 ` Advanced Linux Kernel/Enterprise Linux Kernel Josue Emmanuel Amaro
2000-11-14 7:49 ` Lars Marowsky-Bree
2000-11-14 18:33 ` lamont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20001115000610.F8753@almesberger.net \
--to=werner.almesberger@epfl.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=rothwell@holly-springs.nc.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox