Re: Advanced Linux Kernel/Enterprise Linux Kernel
Hi! > > > Actually, I was planning on doing on putting in a hack to do something > > > like that: calculate a checksum after every buffer data update and check > > > it after write completion, to make sure nothing scribbled in the buffer > > > in the interim. This would also pick up some bad memory problems. > > > > You might want to take look to a patch with crc loop option. > > > > It does verify during read, not during write; but that's even better because > > that way you pick up problems in IO subsystem, too. > > You would have to store the checksums on the filesystem then, or use a I store checksums in separate partition. > verify-after-write. What I was talking about is a > verify-the-buffer-didn't get scribbled. I'd then trust the hardware to > report a write failure. Note that if something scribbles on your buffer > between the time you put good data on it and when it gets transfered to > disk, you can verify perfectly and still have a hosed filesystem. Actually, I have 50% chance detecting that corruption. If it happens between application and loop, I detect nothing. If it happens between loop and disk, I catch it. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Hi! Actually, I was planning on doing on putting in a hack to do something like that: calculate a checksum after every buffer data update and check it after write completion, to make sure nothing scribbled in the buffer in the interim. This would also pick up some bad memory problems. You might want to take look to a patch with crc loop option. It does verify during read, not during write; but that's even better because that way you pick up problems in IO subsystem, too. You would have to store the checksums on the filesystem then, or use a I store checksums in separate partition. verify-after-write. What I was talking about is a verify-the-buffer-didn't get scribbled. I'd then trust the hardware to report a write failure. Note that if something scribbles on your buffer between the time you put good data on it and when it gets transfered to disk, you can verify perfectly and still have a hosed filesystem. Actually, I have 50% chance detecting that corruption. If it happens between application and loop, I detect nothing. If it happens between loop and disk, I catch it. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Pavel Machek wrote: > > Actually, I was planning on doing on putting in a hack to do something > > like that: calculate a checksum after every buffer data update and check > > it after write completion, to make sure nothing scribbled in the buffer > > in the interim. This would also pick up some bad memory problems. > > You might want to take look to a patch with crc loop option. > > It does verify during read, not during write; but that's even better because > that way you pick up problems in IO subsystem, too. You would have to store the checksums on the filesystem then, or use a verify-after-write. What I was talking about is a verify-the-buffer-didn't get scribbled. I'd then trust the hardware to report a write failure. Note that if something scribbles on your buffer between the time you put good data on it and when it gets transfered to disk, you can verify perfectly and still have a hosed filesystem. It was pointed out that you can't really do what I'm suggesting for mmaped file data, and there's some truth to that - but certainly the interval between when ->writepage gets called and when the actual buffer write happens can be secured in this way. Doing this only for metadata is also a good idea because then the overhead would be close to nil and the basic fs integrity would be protected. -- 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: Advanced Linux Kernel/Enterprise Linux Kernel
Hi! > > book, Ext2 throws safety to the wind to achieve speed. This also ties > > into Linux' convoluted VM system, and is shot in the foot by NFS. We > > would need minimally a journaled filesystem and a clean VM design, > > probably with a unified cache (no separate buffer, directory entry and > > page caches). The Tux2 Phase Trees look to be a good step in the > > direction as well, in terms of FS reliability. The filesystem would have > > to do checksums on every block. > > Actually, I was planning on doing on putting in a hack to do something > like that: calculate a checksum after every buffer data update and check > it after write completion, to make sure nothing scribbled in the buffer > in the interim. This would also pick up some bad memory problems. You might want to take look to a patch with crc loop option. It does verify during read, not during write; but that's even better because that way you pick up problems in IO subsystem, too. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Hi! book, Ext2 throws safety to the wind to achieve speed. This also ties into Linux' convoluted VM system, and is shot in the foot by NFS. We would need minimally a journaled filesystem and a clean VM design, probably with a unified cache (no separate buffer, directory entry and page caches). The Tux2 Phase Trees look to be a good step in the direction as well, in terms of FS reliability. The filesystem would have to do checksums on every block. Actually, I was planning on doing on putting in a hack to do something like that: calculate a checksum after every buffer data update and check it after write completion, to make sure nothing scribbled in the buffer in the interim. This would also pick up some bad memory problems. You might want to take look to a patch with crc loop option. It does verify during read, not during write; but that's even better because that way you pick up problems in IO subsystem, too. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Pavel Machek wrote: Actually, I was planning on doing on putting in a hack to do something like that: calculate a checksum after every buffer data update and check it after write completion, to make sure nothing scribbled in the buffer in the interim. This would also pick up some bad memory problems. You might want to take look to a patch with crc loop option. It does verify during read, not during write; but that's even better because that way you pick up problems in IO subsystem, too. You would have to store the checksums on the filesystem then, or use a verify-after-write. What I was talking about is a verify-the-buffer-didn't get scribbled. I'd then trust the hardware to report a write failure. Note that if something scribbles on your buffer between the time you put good data on it and when it gets transfered to disk, you can verify perfectly and still have a hosed filesystem. It was pointed out that you can't really do what I'm suggesting for mmaped file data, and there's some truth to that - but certainly the interval between when -writepage gets called and when the actual buffer write happens can be secured in this way. Doing this only for metadata is also a good idea because then the overhead would be close to nil and the basic fs integrity would be protected. -- 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: Advanced Linux Kernel/Enterprise Linux Kernel
"Eric W. Biederman" wrote: > > Daniel Phillips <[EMAIL PROTECTED]> writes: > > > Actually, I was planning on doing on putting in a hack to do something > > like that: calculate a checksum after every buffer data update and check > > it after write completion, to make sure nothing scribbled in the buffer > > in the interim. This would also pick up some bad memory problems. > > Be very careful that this just applies to metadata. For normal data > this is a valid case. Weird but valid. I'm not sure what you mean. With the exception of mmap'd files, the filesystem (or VFS) controls every transfer onto a buffer so... what does that leave? -- 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: Advanced Linux Kernel/Enterprise Linux Kernel
"Eric W. Biederman" wrote: Daniel Phillips [EMAIL PROTECTED] writes: Actually, I was planning on doing on putting in a hack to do something like that: calculate a checksum after every buffer data update and check it after write completion, to make sure nothing scribbled in the buffer in the interim. This would also pick up some bad memory problems. Be very careful that this just applies to metadata. For normal data this is a valid case. Weird but valid. I'm not sure what you mean. With the exception of mmap'd files, the filesystem (or VFS) controls every transfer onto a buffer so... what does that leave? -- 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: Advanced Linux Kernel/Enterprise Linux Kernel
In article <[EMAIL PROTECTED]> you wrote: > But also scalability: 2TB is a problem for me in some cases, 32bit just don't > cut it all the time - but I need to circumvent the storage problem even on a > 32bit system. And adding disks to the system while running is desireable. Why do you run 32bit Systems in the First Place? This can solve a lot of flaky PC Hardware Issues, too... (also it does not help in Hotplug PCI and CPU). Greetings Bernd - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Daniel Phillips <[EMAIL PROTECTED]> writes: > Actually, I was planning on doing on putting in a hack to do something > like that: calculate a checksum after every buffer data update and check > it after write completion, to make sure nothing scribbled in the buffer > in the interim. This would also pick up some bad memory problems. Be very careful that this just applies to metadata. For normal data this is a valid case. Weird but valid. Eric - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell wrote: > 4) A high reliability internal file system. > > Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems > book, Ext2 throws safety to the wind to achieve speed. This also ties > into Linux' convoluted VM system, and is shot in the foot by NFS. We > would need minimally a journaled filesystem and a clean VM design, > probably with a unified cache (no separate buffer, directory entry and > page caches). The Tux2 Phase Trees look to be a good step in the > direction as well, in terms of FS reliability. The filesystem would have > to do checksums on every block. Actually, I was planning on doing on putting in a hack to do something like that: calculate a checksum after every buffer data update and check it after write completion, to make sure nothing scribbled in the buffer in the interim. This would also pick up some bad memory problems. > Some type of mirroring/clustering would > be good. And the ability to grow filesystems online, and replace disks > online, would be key. If your disks are getting old, you may want to > pre-emptively replace them with faster, newer, larger ones with more > MTBF left. This is all coming, but as you say, it's not quite here yet. -- 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: Advanced Linux Kernel/Enterprise Linux Kernel
Daniel Phillips [EMAIL PROTECTED] writes: Actually, I was planning on doing on putting in a hack to do something like that: calculate a checksum after every buffer data update and check it after write completion, to make sure nothing scribbled in the buffer in the interim. This would also pick up some bad memory problems. Be very careful that this just applies to metadata. For normal data this is a valid case. Weird but valid. Eric - 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: Advanced Linux Kernel/Enterprise Linux Kernel
In article [EMAIL PROTECTED] you wrote: But also scalability: 2TB is a problem for me in some cases, 32bit just don't cut it all the time - but I need to circumvent the storage problem even on a 32bit system. And adding disks to the system while running is desireable. Why do you run 32bit Systems in the First Place? This can solve a lot of flaky PC Hardware Issues, too... (also it does not help in Hotplug PCI and CPU). Greetings Bernd - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell writes: > 1) Convenient remote terminal use. > > Telnet, ssh, X windows, rsh, vnc, "screen," ethernet, > serial, etc. I think we have this one. Nope: /dev/audio, /dev/cdrom, /dev/floppy, fonts, etc. Also one would want a local window manager for performance, but this tends to interfere with starting apps on the other system. > 4) A high reliability internal file system. Now we want it distributed, with version control, with mirroring onto N of M machines and migration toward usage... > 5) Support for selective information sharing. > > Linux has a rather poor security model -- the Unix one. > It needs ACLs no only on filesystem objects, but on other > OS features as well; such as the ability to use network > interfaces, packet types, display ACLs, console ACLs, etc. It would have been nice to have just put 2 entries right in the inode years ago. With the KISS method, we'd be using ACLs right now. Even just a list of UIDs that would share permission bits with the file's GID would be very useful. I just want to share a file with one other person! - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 Fouts writes: > 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, happened to be available and unused. The original system on which UNIX development started was not a PDP-8, but a PDP-7. The earliest UNIX was also written in assembler. Thompson and Ritchie developed C as a higher-level implementation language during the process of porting UNIX from the PDP-7 to the PDP-11. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tuesday 14 November 2000 03:43 pm, Steve VanDevender wrote: >Marty Fouts writes: > > 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, happened to be > > available and unused. > >The original system on which UNIX development started was not a > PDP-8, but a PDP-7. The earliest UNIX was also written in > assembler. Thompson and Ritchie developed C as a higher-level > implementation language during the process of porting UNIX from the > PDP-7 to the PDP-11. I haven't seen anybody point at this URL http://cm.bell-labs.com/cm/cs/who/dmr/hist.html where you can read about early Unix story from the horse's mouth himself. The paper is 20 years old, but still full of very tasty tidbits. Browse around and you'll find many more interesting goodies. In particular, if you want to know the story of how C came to be, as told by its creator, try this URL http://cm.bell-labs.com/cm/cs/who/dmr/chist.html Take it from somebody who has been hacking all sorts of Unix and Unix-like kernels for the last 25 years: Those who don't know Unix history are doomed to reimplement it badly. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote: > On Tue, 14 Nov 2000, Michael Rothwell wrote: > > > "Richard B. Johnson" wrote: > > > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > > > the bullshit. > > > > Funny, I got those off the "Multics FAQ" page. > > > > -M > > > > > History is being rewritten. When Multics was being developed by AT, > it was found to be unusable on the DEC. It was a PDP-8, so the > story is told. General Electric got the first contract to make > a machine specifically designed for Multics and development > continued. > > 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. > > As I said, when Multics was designed, the only criteria as to > get it to work on a DEC. It didn't. To use this development as > an example of "enterprise computing" is absurd and belies its > well documented history. But .. but... but they said so on slashdot. That must make it true. ;) -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 [EMAIL PROTECTED] / /_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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote:
> On Tue, 14 Nov 2000, Michael Rothwell wrote:
>
> > "Richard B. Johnson" wrote:
> > > Multics??? [..] way too many persons on this list who know the history of
> > > Unix to try this BS.
> >
> > So, you're saying their nine goals were bullshit? Multics had a lot of
> > problems. But it did a lot of ground-breaking. Perhaps you should reply
> > to the nine goals, or the general topic of "Enterpriseness," rather than
> > merely express your irrelevant hatred for Multics.
> >
>
> Relating some "nine goals of 'Enterprise Computing'" to Multics is
> the bullshit. When Multics was being developed, the singular goal
> was to make an operating system that worked on DEC Equipment without
> having to use DEC software. The emphasis was on trying to make it
> work period.
WTF are you smoking? Multics never ran on DEC hardware. Moreover, your
ideas about UNIX history ("modified Multics bootloader" bit) are, well,
interesting. Porting from GE to PDP-7... Besides, the thing
had wildly different fs usage model - "everything is mmaped segment" vs.
UNIX "everything is stream of characters".
-
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: Advanced Linux Kernel/Enterprise Linux Kernel
Marty Fouts writes: > 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, happened to be available and unused. The original system on which UNIX development started was not a PDP-8, but a PDP-7. The earliest UNIX was also written in assembler. Thompson and Ritchie developed C as a higher-level implementation language during the process of porting UNIX from the PDP-7 to the PDP-11. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Mark Hahn wrote: > Linux is a good Unix. if adding "enterpriseness" means violating its > Unixness, then yes, the goals are bullshit. in particular, the kind > of extensive, kernel-based auditing and accounting some people talk about, > as well as the complete evisceration of the Unix design for security, > would make Linux no Unix at all. that would be very bad, and indeed Multics > is a fine example of the kind of history we should not repeat. Are you one of those people who say X11 sucks? And whole idea of a neworked gui sucks? Like ones who threaten to rewrite entire gui without planning, in OpenGL and use the rest of the energy tarishing X? Well, if it is done, probably you won't have to compile those extensions in anyway, so what's the whining about? Enterprise level features will let linux run on Mainframes not in pitiful x86 emulation mode, with hot swappable hardware. Just like raid. Would you say RAID sucks a** and weighs down linux, because it is an enterprise feature? By the tone of your voice it seems so. I am for a concious featurism, add features as long as others are stable and fixed(not in MS way) pavel - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote: > On Tue, 14 Nov 2000, Michael Rothwell wrote: > > > One historically significant "Enterprise" OS is Multics. It had nine > > major goals. Perhaps we should think about how Linux measures up to > > these 1965 goals for "Enterprise Computing." > > > 2 > Multics??? No way. It was abandoned as unusable and part of the > kernel code, basically the boot loader, was modified to become > part of Unix. > > You have way too many persons on this list who know the history of > Unix to try this BS. Perhaps this is a call for forking off linux into other project, It is not unreasonable, if goals of one do not match with the other. =) However the guy said that goals are applicable to linux, he did not say rewrite linux to be multics... Pavel. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
In article <[EMAIL PROTECTED]> you wrote: > 2) Continuous operation analogous to power & telephone services. > No way. Multics could have a whole bank of memory fail and keep running. > You could add CPUs, memory and IO devices while it was running without > interrupting users' work. Of course, a lot of this cannot be > accomplished due to the brain-dead hardware designs (especially PC) > prevalent today. However, Linux does not have any support for this type > of facility. I recently saw a patch to let Linux use partially bad > memory. This is a step in the right direction. The ability to scale the > system while on-line is extremely valuable. Motorola has announced Linux Systems with a Hot-Plug CPU - but this seems to be more a hardware then a software feature. > 4) A high reliability internal file system. > Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems > book, Ext2 throws safety to the wind to achieve speed. No. Shure, you don't have all the nice features of log structured or journaled filesystem, but ext2 is pretty reliable for a traditional fs. (I'd like to see if the multics fs was better, do you have a pointer?) > This also ties > into Linux' convoluted VM system, and is shot in the foot by NFS. We > would need minimally a journaled filesystem and a clean VM design, > probably with a unified cache (no separate buffer, directory entry and > page caches). The dcache is not a disk cache. It caches directory lookups, it is neither something VM related nor does it inpact reliability. The buffercache seems pretty dead in the near future - filesystems are going towards putting metadata in the page cache. (See Al Viro's ext2 patches) > The Tux2 Phase Trees look to be a good step in the > direction as well, in terms of FS reliability. > The filesystem would have to do checksums on every block. The filesystem? This does not belong into the filesystem. An ecc personality for md might be a much better idea ... > Some type of mirroring/clustering would be good. Mirroring does _not_ belong into the fs layer, it belongs into LVM, software -, or if you want a really reliable system, hardware raid. > And the ability to grow filesystems online, and replace disks > online, would be key. If your disks are getting old, you may want to > pre-emptively replace them with faster, newer, larger ones with more > MTBF left. Why don't you use LVM? > 5) Support for selective information sharing. > Linux has a rather poor security model -- the Unix one. It needs ACLs no > only on filesystem objects, but on other OS features as well; such as > the ability to use network interfaces, packet types, display ACLs, > console ACLs, etc. If there's a function, it probably needs an ACL. ACLs are not really interesting. They are like good-old file rights with some nice new features and much more complicated. You want MACs and Capabilities (the latter are implemented in Linux). > 6) Hierarchical structures of information for system administration and > decentralization of user activities. > See #5. Linux really does not support delgation of authority well. > There's one user who can reconfigure/admin the system: root. No, there is not. There is a capability for each job (or a group of jobs). The root user is just UNIX-Legacy. (ok, ok nearly every system has one - but the Linux security model doesn't really need it). > 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. Shure. NT supports win32, win16, dos and recompiled UNIX binaries. QNX supports QNX and now Linux binaries. Thanks to the personality architecture I can (and do) run UnixWare, OpenServer, etc binaries under Linux. And I can use dosemu, wine, etc ... Christoph -- Always remember that you are unique. Just like everyone else. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
if you look at the kstat structure under solaris, there's a lot of info there that'd be good to be able to pull out of the linux kernel. that would slow down the kernel a little, lead to some 'bloat' that linus abhors and such, but its good to have that information for monitoring and debugging problems. it'd also be nice to have hooks built in to monitor errors in the disk subsystem and ideally warn of impending failures as much as possible -- that might be better done in userspace. and pretty much you want all error messages from different subsystems to be monitored and appropriate action taken. ideally all error messages from the kernel and device drivers should be standardized and HA software can then monitor them and take appropriate actions when it sees one that indicates failure. sun is currently in the process of documenting all the kernel error messages from what i understand. those are the kinds of things that give IT managers and sysadmins warm fuzzy feelings about solaris. On Mon, 13 Nov 2000, Josue Emmanuel Amaro wrote: > This subject came up in the Generalized Kernel Hooks Interface thread, since it > is an area of interest to me I wanted to continue that conversation. > > While I do not think it would be productive to enter a discussion whether there > is a need to fork the kernel to add features that would be beneficial to > mission/business critical applications, I am curious as to what are the features > that people consider important to have. By mission critical I mean systems that > if not functional bring a business to a halt, while by business critical I mean > systems that affect a division of a business. > > Another problem is how people define Enterprise Systems. Many base it on the > definitions that go back to S390 systems, others in the context of the 24/7 > nature of the internet. That would also be a healthy discussion to have. > > At Oracle we are primarily interested on I/O subsystem features and memory > management. (For anyone that knows anything about Oracle this should not come > as a surprise, although I am pretty sure that any database vendor/developer > would be interested on those features as well.) > > Regards, > > -- > === > Josue Emmanuel Amaro [EMAIL PROTECTED] > Linux Products Manager > Intel and Linux Technologies Group > === > > > - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 well be expanded given what has been learned in the 35 years since. Marty -Original Message- From: Buddha Buck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 9:52 AM To: Michael Rothwell; [EMAIL PROTECTED] Cc: Linux kernel Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel At 01:10 PM 11/14/00 -0500, Michael Rothwell wrote: >"Richard B. Johnson" wrote: > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > > the bullshit. > >Funny, I got those off the "Multics FAQ" page. It may be reasonable to question them as "goals of 'Enterprise Computing'". I found, on http://www.multicians.org/general.html, a list of those same nine goals, introduced by the sentence "As described in the 1965 paper Introduction and Overview of the Multics System by Corbató and Vyssotsky, there were nine major goals for Multics:" While those were the goals of Multics, it is not at all clear that Multics would classify these days as a platform for "Enterprise Computing". I'll note that the word "enterprise" does not appear in either the general FAQ page I cited, nor in the linked article it cites. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 only criteria as to > get it to work on a DEC. It didn't. To use this development as > an example of "enterprise computing" is absurd and belies its > well documented history. How odd then, that Corbato's '65 paper specifically describes it as a research effort on a GE system, and both Ritchie and Thompson have written to similar effect and Glasser et al wrote In the late spring and early summer of 1964 it became obvious that greater facility in the computing system was required if time-sharing techniques were to move from the state of an interesting pilot experiment into that of a useful prototype for remote access computer systems. Investigation proved computers that were immediately available could not be adapted readily to meet the difficult set of requirements time-sharing places on any machine. However, there was one system that appeared to be extendible into what was desired. This machine was the General Electric 635. Multics grew out of research into the design of timesharing systems at MIT, and is from the same family of systems as ITS. It had a long and interesting history and was supported by Honeywell into the 90s. There were several other interesting OSes developed in that time frame, such as SDS's CP/V for the Sigma series, but most of them were not described in the literature and so are long forgotten. Marty - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote: > On Tue, 14 Nov 2000, Michael Rothwell wrote: > > > One historically significant "Enterprise" OS is Multics. It had nine > > major goals. Perhaps we should think about how Linux measures up to > > these 1965 goals for "Enterprise Computing." > > > > Multics??? No way. It was abandoned as unusable and part of the > kernel code, basically the boot loader, was modified to become > part of Unix. "take a look at the goals Multics had" != "please reimplement Multics" Flaming is ok, but you should really read the WHOLE email before replying, otherwise you might end up with a flame that isn't relevant at all to the email it supposedly is a reply to... 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: Advanced Linux Kernel/Enterprise Linux Kernel
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, happened to be available and unused. -Original Message- From: Richard B. Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 10:01 AM To: Michael Rothwell Cc: Linux kernel Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel On Tue, 14 Nov 2000, Michael Rothwell wrote: > "Richard B. Johnson" wrote: > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > > the bullshit. > > Funny, I got those off the "Multics FAQ" page. > > -M > History is being rewritten. When Multics was being developed by AT, it was found to be unusable on the DEC. It was a PDP-8, so the story is told. General Electric got the first contract to make a machine specifically designed for Multics and development continued. 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. As I said, when Multics was designed, the only criteria as to get it to work on a DEC. It didn't. To use this development as an example of "enterprise computing" is absurd and belies its well documented history. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 delighted to find that there are still Multics systems running. There may be many people on this list who know the history of Unix, but from this thread, I'm thinking that perhaps there is some confusion between the history and the mythology. Perhaps we could get AT, Lucent, or whomever owns the copyright these days, to reprint the "Unix" issue of the Bell Systems Journal. Marty -Original Message- From: Richard B. Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 8:26 AM To: Michael Rothwell Cc: Linux kernel Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel On Tue, 14 Nov 2000, Michael Rothwell wrote: > One historically significant "Enterprise" OS is Multics. It had nine > major goals. Perhaps we should think about how Linux measures up to > these 1965 goals for "Enterprise Computing." > Multics??? No way. It was abandoned as unusable and part of the kernel code, basically the boot loader, was modified to become part of Unix. You have way too many persons on this list who know the history of Unix to try this BS. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 business altogether. I would suggest Organick's book, if I could recall the title. Marty -Original Message- From: Richard B. Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 8:42 AM To: Michael Rothwell Cc: Linux kernel Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel On Tue, 14 Nov 2000, Michael Rothwell wrote: > "Richard B. Johnson" wrote: > > Multics??? [..] way too many persons on this list who know the history of > > Unix to try this BS. > > So, you're saying their nine goals were bullshit? Multics had a lot of > problems. But it did a lot of ground-breaking. Perhaps you should reply > to the nine goals, or the general topic of "Enterpriseness," rather than > merely express your irrelevant hatred for Multics. > Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. When Multics was being developed, the singular goal was to make an operating system that worked on DEC Equipment without having to use DEC software. The emphasis was on trying to make it work period. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Michael Rothwell wrote: > "Richard B. Johnson" wrote: > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > > the bullshit. > > Funny, I got those off the "Multics FAQ" page. > > -M > History is being rewritten. When Multics was being developed by AT, it was found to be unusable on the DEC. It was a PDP-8, so the story is told. General Electric got the first contract to make a machine specifically designed for Multics and development continued. 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. As I said, when Multics was designed, the only criteria as to get it to work on a DEC. It didn't. To use this development as an example of "enterprise computing" is absurd and belies its well documented history. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Michael Meissner wrote: > On Tue, Nov 14, 2000 at 11:41:33AM -0500, Richard B. Johnson wrote: > > On Tue, 14 Nov 2000, Michael Rothwell wrote: > > > > > "Richard B. Johnson" wrote: > > > > Multics??? [..] way too many persons on this list who know the history of > > > > Unix to try this BS. > > > > > > So, you're saying their nine goals were bullshit? Multics had a lot of > > > problems. But it did a lot of ground-breaking. Perhaps you should reply > > > to the nine goals, or the general topic of "Enterpriseness," rather than > > > merely express your irrelevant hatred for Multics. > > > > > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > > the bullshit. When Multics was being developed, the singular goal > > was to make an operating system that worked on DEC Equipment without > > having to use DEC software. The emphasis was on trying to make it > > work period. > > Ummm, the way I parse the above statement, you are saying that Multics was > developed to work on DEC equipment without having to use DEC software. Maybe > we are inhabiting parallel universes, but I'm pretty sure that in my universe, > Multics ran first on GE computers, and then on Honeywell computers when > Honeywell bought the division from GE. Note, DEC did bid for the Multics > contract but was turned down. Maybe you are thinking of Tenex or UNIX? > > The original machine was a GE-645, which was a segmented, virtual memory system > using 36 bit words. The operating system and system software was written in > PL/1. Bell Labs had bought a GE-645 and was one of the three development > partners (along with GE and MIT) until they withdrew in April 1969. You might > want to browse: > No parallel universe. When Multics was being developed by AT, it was found to be unusable on the DEC. It was a PDP-8, so the story is told. General Electric got the first contract to make a machine specifically designed for Multics and development continued. 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. As I said, when Multics was designed, the only criteria as to get it to work on a DEC. It didn't. To use this development as an example of "enterprise computing" is absurd and belies its well documented history. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell writes: > 4) A high reliability internal file system. > > Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems > book, Ext2 throws safety to the wind to achieve speed. This also ties > into Linux' convoluted VM system, and is shot in the foot by NFS. We > would need minimally a journaled filesystem and a clean VM design, > probably with a unified cache (no separate buffer, directory entry and > page caches). The Tux2 Phase Trees look to be a good step in the > direction as well, in terms of FS reliability. Ext3 is doing pretty well... > The filesystem would have > to do checksums on every block. Some type of mirroring/clustering would > be good. And the ability to grow filesystems online, and replace disks > online, would be key. If your disks are getting old, you may want to > pre-emptively replace them with faster, newer, larger ones with more > MTBF left. You can always do this in the hardware - no reason to do it in software. If you are using RAID 5, and you wanted to take the performance hit you could always calculate the checksums for each stripe on read to detect errors. You may even be able to add a second parity disk to do ECC on the disk data. As for online resizing, you can do this with ext2 for a long time with my ext2online patches/tools. LVM lets you migrate between disks online. You need hardware support (available) to do hot-swap disks - SCSI works, but I don't think the IDE code is ready for hot-swap yet. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: Advanced Linux Kernel/Enterprise Linux Kernel
At 01:10 PM 11/14/00 -0500, Michael Rothwell wrote: >"Richard B. Johnson" wrote: > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > > the bullshit. > >Funny, I got those off the "Multics FAQ" page. It may be reasonable to question them as "goals of 'Enterprise Computing'". I found, on http://www.multicians.org/general.html, a list of those same nine goals, introduced by the sentence "As described in the 1965 paper Introduction and Overview of the Multics System by Corbató and Vyssotsky, there were nine major goals for Multics:" While those were the goals of Multics, it is not at all clear that Multics would classify these days as a platform for "Enterprise Computing". I'll note that the word "enterprise" does not appear in either the general FAQ page I cited, nor in the linked article it cites. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 08:59:49AM -0600, Jesse Pollard wrote: >I (meaning me) would like the ability to audit every system call. (yes, >this is horrendous, if everything is logged, but I want to be able to >choose how much is logged at the source of the data, rather than at >the destination. That would reduce the total data flood to what is >manageable or desired. Yes, you really need to control the logging at the source of the data. To do that we need to use to use self modifying tricks as dprobes and GKHI does to provide "fast unregistered hooks". o with dprobes the hooks will be _absolutely_ zero cost if they're unregistered but they're very costly (basically enter/exit kernel for every hook) when they're registered (so they're ok if your auditing doesn't happen all the time). dprobe hooks also binds you to a certain binary image (not a generic interface stable across different kernel binaries) o GKHI provides fast unregistered hooks too, if implemented with 5 nops as suggested they will cost around 3 cycles when they're unregistered, and they will provide good performance also when they're registered (no enter/exit kernel as dprobes needs to do) and you can control them via userspace without being dependent on binary offsets (just like with every other hook we have in kernel just now but with the difference that our current hooks aren't self modifying so they adds branches also when they're unregistered so they're bad for usages like syscall auditing). However bloating every syscall with tons of GKHI hooks isn't possible either or it will become a performance problem too eventually. It depends what you need exactly. I'd say one GKHI hook per syscall shouldn't have measurable impact on performance. Andrea - 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: Advanced Linux Kernel/Enterprise Linux Kernel
"Richard B. Johnson" wrote: > Relating some "nine goals of 'Enterprise Computing'" to Multics is > the bullshit. Funny, I got those off the "Multics FAQ" page. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 12:14:57PM -0500, Michael Rothwell wrote: > Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems > book, Ext2 throws safety to the wind to achieve speed. This also ties What safety problems bdflush/kupdated have? (if something they lacks in performance since they works on a global dirty list while it should be per queue dirty list to take the I/O pipeline full on all disks) > [..] And the ability to grow filesystems online, [..] This is provided in linux for ages by LVM+reiserfs also in 2.2.x. Any filesystem with inode map and not dependent on disk offsets to find stuff (exept the superblock of course) can do the grow almost trivially and online, the shrink is some more complicated instead. Andrea - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 11:41:33AM -0500, Richard B. Johnson wrote: > On Tue, 14 Nov 2000, Michael Rothwell wrote: > > > "Richard B. Johnson" wrote: > > > Multics??? [..] way too many persons on this list who know the history of > > > Unix to try this BS. > > > > So, you're saying their nine goals were bullshit? Multics had a lot of > > problems. But it did a lot of ground-breaking. Perhaps you should reply > > to the nine goals, or the general topic of "Enterpriseness," rather than > > merely express your irrelevant hatred for Multics. > > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > the bullshit. When Multics was being developed, the singular goal > was to make an operating system that worked on DEC Equipment without > having to use DEC software. The emphasis was on trying to make it > work period. Ummm, the way I parse the above statement, you are saying that Multics was developed to work on DEC equipment without having to use DEC software. Maybe we are inhabiting parallel universes, but I'm pretty sure that in my universe, Multics ran first on GE computers, and then on Honeywell computers when Honeywell bought the division from GE. Note, DEC did bid for the Multics contract but was turned down. Maybe you are thinking of Tenex or UNIX? The original machine was a GE-645, which was a segmented, virtual memory system using 36 bit words. The operating system and system software was written in PL/1. Bell Labs had bought a GE-645 and was one of the three development partners (along with GE and MIT) until they withdrew in April 1969. You might want to browse: http://www.multicians.org/ for more of the history of Multics. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
At 11:41 AM 11/14/00, Richard B. Johnson wrote: >On Tue, 14 Nov 2000, Michael Rothwell wrote: > > > "Richard B. Johnson" wrote: > > > Multics??? [..] way too many persons on this list who know the > history of > > > Unix to try this BS. > > > > So, you're saying their nine goals were bullshit? Multics had a lot of > > problems. But it did a lot of ground-breaking. Perhaps you should reply > > to the nine goals, or the general topic of "Enterpriseness," rather than > > merely express your irrelevant hatred for Multics. > > > >Relating some "nine goals of 'Enterprise Computing'" to Multics is >the bullshit. When Multics was being developed, the singular goal >was to make an operating system that worked on DEC Equipment without >having to use DEC software. The emphasis was on trying to make it >work period. DEC? Try GE, specifically the GE-645 (if my memory hasn't lost any bits). Speaking of Multics, the last Multics system was just recently decomissioned. I think 35 years is a very impressive lifetime for a computer system. Linux, now at age 9, only has 26 years to go. David David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] 514 W. Keech Ave. www.osagesoftware.com Ann Arbor, MI 48103 voice: 734.821.8800fax: 734.821.8800 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
At 11:20 AM 11/14/00, Mike Dresser wrote: >Michael Rothwell wrote: > > > Just some thoughts from 35 years ago. Please add your $0.02. > >What's that $0.02 worth after 35 years of inflation? > >=) I'd say inflation has been easily 12x since then. So $0.02 is now worth $0.25, i.e. the 2 cents of yesteryear is now 2 bits :-) David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] 514 W. Keech Ave. www.osagesoftware.com Ann Arbor, MI 48103 voice: 734.821.8800fax: 734.821.8800 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Michael Rothwell wrote: > "Richard B. Johnson" wrote: > > Multics??? [..] way too many persons on this list who know the history of > > Unix to try this BS. > > So, you're saying their nine goals were bullshit? Multics had a lot of > problems. But it did a lot of ground-breaking. Perhaps you should reply > to the nine goals, or the general topic of "Enterpriseness," rather than > merely express your irrelevant hatred for Multics. > Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. When Multics was being developed, the singular goal was to make an operating system that worked on DEC Equipment without having to use DEC software. The emphasis was on trying to make it work period. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
> > Multics??? [..] way too many persons on this list who know the history of > > Unix to try this BS. > > So, you're saying their nine goals were bullshit? Multics had a lot of > problems. But it did a lot of ground-breaking. Perhaps you should reply > to the nine goals, or the general topic of "Enterpriseness," rather than > merely express your irrelevant hatred for Multics. Linux is a good Unix. if adding "enterpriseness" means violating its Unixness, then yes, the goals are bullshit. in particular, the kind of extensive, kernel-based auditing and accounting some people talk about, as well as the complete evisceration of the Unix design for security, would make Linux no Unix at all. that would be very bad, and indeed Multics is a fine example of the kind of history we should not repeat. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell wrote: > > Mike Dresser wrote: > > > What's that $0.02 worth after 35 years of inflation? > > About $6 Sorry.. six times a much... not six dollars. Which means $0.02 circa 1965 is 'worth' $0.12 today, given an average annual devaluation of the currency of 5.2% since 1965. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
"Richard B. Johnson" wrote: > Multics??? [..] way too many persons on this list who know the history of > Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Mike Dresser wrote: > What's that $0.02 worth after 35 years of inflation? About $6 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Michael Rothwell wrote: > One historically significant "Enterprise" OS is Multics. It had nine > major goals. Perhaps we should think about how Linux measures up to > these 1965 goals for "Enterprise Computing." > Multics??? No way. It was abandoned as unusable and part of the kernel code, basically the boot loader, was modified to become part of Unix. You have way too many persons on this list who know the history of Unix to try this BS. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell wrote: > Just some thoughts from 35 years ago. Please add your $0.02. What's that $0.02 worth after 35 years of inflation? =) - 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: Advanced Linux Kernel/Enterprise Linux Kernel
One historically significant "Enterprise" OS is Multics. It had nine major goals. Perhaps we should think about how Linux measures up to these 1965 goals for "Enterprise Computing." 1) Convenient remote terminal use. Telnet, ssh, X windows, rsh, vnc, "screen," ethernet, serial, etc. I think we have this one. 2) Continuous operation analogous to power & telephone services. No way. Multics could have a whole bank of memory fail and keep running. You could add CPUs, memory and IO devices while it was running without interrupting users' work. Of course, a lot of this cannot be accomplished due to the brain-dead hardware designs (especially PC) prevalent today. However, Linux does not have any support for this type of facility. I recently saw a patch to let Linux use partially bad memory. This is a step in the right direction. The ability to scale the system while on-line is extremely valuable. 3) A wide range of system configurations, changeable without system or user program reorganization. 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. If it could save state and have the new kernel take over, that would rock. On a smaller scale, allowing this for modules would be good. This would allow the upgrade of nic drivers, etc. The GKHI would also be invaluable if it would allow the replacement/augmentation of certain other subsystems on the fly -- such as the scheduler, VFS, etc. 4) A high reliability internal file system. Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems book, Ext2 throws safety to the wind to achieve speed. This also ties into Linux' convoluted VM system, and is shot in the foot by NFS. We would need minimally a journaled filesystem and a clean VM design, probably with a unified cache (no separate buffer, directory entry and page caches). The Tux2 Phase Trees look to be a good step in the direction as well, in terms of FS reliability. The filesystem would have to do checksums on every block. Some type of mirroring/clustering would be good. And the ability to grow filesystems online, and replace disks online, would be key. If your disks are getting old, you may want to pre-emptively replace them with faster, newer, larger ones with more MTBF left. 5) Support for selective information sharing. Linux has a rather poor security model -- the Unix one. It needs ACLs no only on filesystem objects, but on other OS features as well; such as the ability to use network interfaces, packet types, display ACLs, console ACLs, etc. If there's a function, it probably needs an ACL. 6) Hierarchical structures of information for system administration and decentralization of user activities. See #5. Linux really does not support delgation of authority well. There's one user who can reconfigure/admin the system: root. Tools like sudo only make you root for a moment, and don't inherently limit you to that one activity. ACLs on most if not all system attributes and objects would go a long way towards decentralized but safe administration. 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. 8) Support for multiple programming environments & human interfaces. Many languages are supported by Linux. This is good. Linux has two humnan interfaces: CLI and X Windows guis. I'm not sure what could be added, except for voice input. 9) The ability to evolve the system with changes in technology and in user aspirations. Ties ties into #2 and #3and #5. Otherwise, rewrites of the Linux kernel and userspace accomplish this. Unfortunately, that requires taking the system, or minimally its applications, down. Just some thoughts from 35 years ago. Please add your $0.02. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 08:59:49AM -0600, Jesse Pollard wrote: [snip] > 4. Unauthorized access to, modification to, or damage to the >effectiveness of the system should be possible (the ideal...). >All security related events should be audited and logged. Uhmmm, there should be some kind of negation above, shouldn't it?! [snip] /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: Advanced Linux Kernel/Enterprise Linux Kernel
Josue Emmanuel Amaro <[EMAIL PROTECTED]>: > This subject came up in the Generalized Kernel Hooks Interface thread, since it > is an area of interest to me I wanted to continue that conversation. > > While I do not think it would be productive to enter a discussion whether there > is a need to fork the kernel to add features that would be beneficial to > mission/business critical applications, I am curious as to what are the features > that people consider important to have. By mission critical I mean systems that > if not functional bring a business to a halt, while by business critical I mean > systems that affect a division of a business. > > Another problem is how people define Enterprise Systems. Many base it on the > definitions that go back to S390 systems, others in the context of the 24/7 > nature of the internet. That would also be a healthy discussion to have. > > At Oracle we are primarily interested on I/O subsystem features and memory > management. (For anyone that knows anything about Oracle this should not come > as a surprise, although I am pretty sure that any database vendor/developer > would be interested on those features as well.) I reformatted/phrased your questions above to allow for separate answers: Q1. How do you define Enterprise Systems? Many base it on the definitions that go back to S390 systems, others in the context of the 24/7 nature of the internet. 1. The system should be available 24 hours a day, 7 days a week, 52 weeks a year :-), with time off for scheduled down time for maintenance and upgrades. 2. It should be possible to take down a node of a cluster without affecting the effectiveness of the other nodes. There is an expeced higher load on the remaining nodes during the time the node is missing. 3. It should be possible to add nodes to a cluster without affecting the effectiveness of the other nodes. 4. Unauthorized access to, modification to, or damage to the effectiveness of the system should be possible (the ideal...). All security related events should be audited and logged. Q2. I am curious as to what are the features that people consider important to have. By mission critical I mean systems that if not functional bring a business to a halt, while by business critical I mean systems that affect a division of a business. 1. Secure - Multi-level security (with compartmentalization) is needed to be able to detect unauthorized attempts to modify the system. There should be no all powerfull user. System updates should require three different authorizations (security, administrator, and auditor) to take effect when the system is on-line. All bets are off, of course, if the system is taken offline for such modifications - at that point, the administrator would be able to make any changes. The security administrator should validate the system in some manner. The system should not be able to be brought online without being validated. IPSec to provide controled encryption between hosts. Inclusion of CIPSO style extensions to allow for labeled network support. Virtical integration to include user identification tags as well. I would like to be able to identify the remote user, with confidence in that identity established by the confidence in the host, which is in turn established by IPSec. I (meaning me) would like the ability to audit every system call. (yes, this is horrendous, if everything is logged, but I want to be able to choose how much is logged at the source of the data, rather than at the destination. That would reduce the total data flood to what is manageable or desired. I realize that this is extreme - but in some environments this degree of control is necessary. It should be possible to downgrade this level of control to the point that is required for other environments. 2. Allow for full accounting of user resources - memory, cpu, disk, IO. 3. It should not be possible for a user to exceed the resource quotas established for the user. This control should be flexible enough to allow for exceeding some quotas if additional resources are available, but unused. (I'm considering memory resources and CPU time here. The user should be able to exceed memory quota, but with the understanding that the users processes will be trimmed down to the users quota limit if needed for other users. 4. Batch jobs, using a more common definition of batch than that used by the "batch" utility - job queues, with batch controled limits, job checkpointing/restart, resource allocation controls... Batch jobs should be able to migrate to other nodes/systems (as long as all other required resources are available ... This is HARD to do :-). 5. Allow for multiple scheduling types, preferably concurrently, but changable at runtime. Some real time, mostly batch and interactive.
Re: Advanced Linux Kernel/Enterprise Linux Kernel
On 2000-11-13T13:56:16, Josue Emmanuel Amaro <[EMAIL PROTECTED]> said: Good morning Josue, I hope your certification matrix hasn't driven you mad yet ;-) > While I do not think it would be productive to enter a discussion whether > there is a need to fork the kernel to add features that would be beneficial > to mission/business critical applications, I am curious as to what are the > features that people consider important to have. This is in fact the valuable subpart of the discussion. Working for SuSE on High Availability, especially in the "enterprise" segment: Here, referring to systems running databases (mostly Oracle, surprise), ERP-Systems, but also providing services (NFS, Samba, firewalls) in such an environment. I personally need features which allow me to keep on running, shut down as gracefully as possible if an error occurs, and if an error occured, diagnose it out in the field. This means: ECC memory, hotpluggable everything, proper error handling and reporting in the kernel. Yes, christmas and easter do occur on the same day in the real world, unfortunately. This can best be summarised as "robustness". If an error occured, I need to be able to fully diagnose it without having to reproduce it - no, I do not wish to reproduce the error by crashing my critical server on purpose, nor is "The error appears to have gone away, we have no clue what it was" an acceptable answer. (kdb, LKCD, Oopsing to the network etc: And they must be part of the default kernel as far as possible, so they stay in sync and get widespread testing) But also scalability: 2TB is a problem for me in some cases, 32bit just don't cut it all the time - but I need to circumvent the storage problem even on a 32bit system. And adding disks to the system while running is desireable. Cluster awareness, again mostly referring to storage: Yes, there is more than one system accessing my SCSI bus, my FCAL RAID, and the error handling should be architected in a way that they do not start reset wars. The LVM should safeguard against multiple nodes changing the metadata. (Ok, this can be solved in userspace too) LVM must be transactional, so a crash on a node doesn't corrupt the data. Basically, the talks in Miami (The Second Annual Linux Storage Management Workshop) gave a great overview of everything I need. And: I need all of this as Open Source. Period. No binary kernel modules do me any good and I will pointedly ignore them. Oh, and by the way - if any hot kernel hacker, not yet working on this full time feels inspired to make this happen, contact me. Or any other Linux company, as long as the job gets done. We'll be glad to make you a fulltime kernel slave^Whacker! ;-) > Another problem is how people define Enterprise Systems. Many base it on the > definitions that go back to S390 systems, others in the context of the 24/7 > nature of the internet. That would also be a healthy discussion to have. _ 24/7 * 99.99% mission/business critical services with "medium to high" load. 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: Advanced Linux Kernel/Enterprise Linux Kernel
On 2000-11-13T13:56:16, Josue Emmanuel Amaro [EMAIL PROTECTED] said: Good morning Josue, I hope your certification matrix hasn't driven you mad yet ;-) While I do not think it would be productive to enter a discussion whether there is a need to fork the kernel to add features that would be beneficial to mission/business critical applications, I am curious as to what are the features that people consider important to have. This is in fact the valuable subpart of the discussion. Working for SuSE on High Availability, especially in the "enterprise" segment: Here, referring to systems running databases (mostly Oracle, surprise), ERP-Systems, but also providing services (NFS, Samba, firewalls) in such an environment. I personally need features which allow me to keep on running, shut down as gracefully as possible if an error occurs, and if an error occured, diagnose it out in the field. This means: ECC memory, hotpluggable everything, proper error handling and reporting in the kernel. Yes, christmas and easter do occur on the same day in the real world, unfortunately. This can best be summarised as "robustness". If an error occured, I need to be able to fully diagnose it without having to reproduce it - no, I do not wish to reproduce the error by crashing my critical server on purpose, nor is "The error appears to have gone away, we have no clue what it was" an acceptable answer. (kdb, LKCD, Oopsing to the network etc: And they must be part of the default kernel as far as possible, so they stay in sync and get widespread testing) But also scalability: 2TB is a problem for me in some cases, 32bit just don't cut it all the time - but I need to circumvent the storage problem even on a 32bit system. And adding disks to the system while running is desireable. Cluster awareness, again mostly referring to storage: Yes, there is more than one system accessing my SCSI bus, my FCAL RAID, and the error handling should be architected in a way that they do not start reset wars. The LVM should safeguard against multiple nodes changing the metadata. (Ok, this can be solved in userspace too) LVM must be transactional, so a crash on a node doesn't corrupt the data. Basically, the talks in Miami (The Second Annual Linux Storage Management Workshop) gave a great overview of everything I need. And: I need all of this as Open Source. Period. No binary kernel modules do me any good and I will pointedly ignore them. Oh, and by the way - if any hot kernel hacker, not yet working on this full time feels inspired to make this happen, contact me. Or any other Linux company, as long as the job gets done. We'll be glad to make you a fulltime kernel slave^Whacker! ;-) Another problem is how people define Enterprise Systems. Many base it on the definitions that go back to S390 systems, others in the context of the 24/7 nature of the internet. That would also be a healthy discussion to have. _ 24/7 * 99.99% mission/business critical services with "medium to high" load. 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 08:59:49AM -0600, Jesse Pollard wrote: [snip] 4. Unauthorized access to, modification to, or damage to the effectiveness of the system should be possible (the ideal...). All security related events should be audited and logged. Uhmmm, there should be some kind of negation above, shouldn't it?! [snip] /David Weinehall _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / - 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: Advanced Linux Kernel/Enterprise Linux Kernel
One historically significant "Enterprise" OS is Multics. It had nine major goals. Perhaps we should think about how Linux measures up to these 1965 goals for "Enterprise Computing." 1) Convenient remote terminal use. Telnet, ssh, X windows, rsh, vnc, "screen," ethernet, serial, etc. I think we have this one. 2) Continuous operation analogous to power telephone services. No way. Multics could have a whole bank of memory fail and keep running. You could add CPUs, memory and IO devices while it was running without interrupting users' work. Of course, a lot of this cannot be accomplished due to the brain-dead hardware designs (especially PC) prevalent today. However, Linux does not have any support for this type of facility. I recently saw a patch to let Linux use partially bad memory. This is a step in the right direction. The ability to scale the system while on-line is extremely valuable. 3) A wide range of system configurations, changeable without system or user program reorganization. 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. If it could save state and have the new kernel take over, that would rock. On a smaller scale, allowing this for modules would be good. This would allow the upgrade of nic drivers, etc. The GKHI would also be invaluable if it would allow the replacement/augmentation of certain other subsystems on the fly -- such as the scheduler, VFS, etc. 4) A high reliability internal file system. Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems book, Ext2 throws safety to the wind to achieve speed. This also ties into Linux' convoluted VM system, and is shot in the foot by NFS. We would need minimally a journaled filesystem and a clean VM design, probably with a unified cache (no separate buffer, directory entry and page caches). The Tux2 Phase Trees look to be a good step in the direction as well, in terms of FS reliability. The filesystem would have to do checksums on every block. Some type of mirroring/clustering would be good. And the ability to grow filesystems online, and replace disks online, would be key. If your disks are getting old, you may want to pre-emptively replace them with faster, newer, larger ones with more MTBF left. 5) Support for selective information sharing. Linux has a rather poor security model -- the Unix one. It needs ACLs no only on filesystem objects, but on other OS features as well; such as the ability to use network interfaces, packet types, display ACLs, console ACLs, etc. If there's a function, it probably needs an ACL. 6) Hierarchical structures of information for system administration and decentralization of user activities. See #5. Linux really does not support delgation of authority well. There's one user who can reconfigure/admin the system: root. Tools like sudo only make you root for a moment, and don't inherently limit you to that one activity. ACLs on most if not all system attributes and objects would go a long way towards decentralized but safe administration. 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. 8) Support for multiple programming environments human interfaces. Many languages are supported by Linux. This is good. Linux has two humnan interfaces: CLI and X Windows guis. I'm not sure what could be added, except for voice input. 9) The ability to evolve the system with changes in technology and in user aspirations. Ties ties into #2 and #3and #5. Otherwise, rewrites of the Linux kernel and userspace accomplish this. Unfortunately, that requires taking the system, or minimally its applications, down. Just some thoughts from 35 years ago. Please add your $0.02. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell wrote: Just some thoughts from 35 years ago. Please add your $0.02. What's that $0.02 worth after 35 years of inflation? =) - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Michael Rothwell wrote: One historically significant "Enterprise" OS is Multics. It had nine major goals. Perhaps we should think about how Linux measures up to these 1965 goals for "Enterprise Computing." Multics??? No way. It was abandoned as unusable and part of the kernel code, basically the boot loader, was modified to become part of Unix. You have way too many persons on this list who know the history of Unix to try this BS. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Mike Dresser wrote: What's that $0.02 worth after 35 years of inflation? About $6 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
"Richard B. Johnson" wrote: Multics??? [..] way too many persons on this list who know the history of Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell wrote: Mike Dresser wrote: What's that $0.02 worth after 35 years of inflation? About $6 Sorry.. six times a much... not six dollars. Which means $0.02 circa 1965 is 'worth' $0.12 today, given an average annual devaluation of the currency of 5.2% since 1965. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Multics??? [..] way too many persons on this list who know the history of Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. Linux is a good Unix. if adding "enterpriseness" means violating its Unixness, then yes, the goals are bullshit. in particular, the kind of extensive, kernel-based auditing and accounting some people talk about, as well as the complete evisceration of the Unix design for security, would make Linux no Unix at all. that would be very bad, and indeed Multics is a fine example of the kind of history we should not repeat. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Multics??? [..] way too many persons on this list who know the history of Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. When Multics was being developed, the singular goal was to make an operating system that worked on DEC Equipment without having to use DEC software. The emphasis was on trying to make it work period. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
At 11:20 AM 11/14/00, Mike Dresser wrote: Michael Rothwell wrote: Just some thoughts from 35 years ago. Please add your $0.02. What's that $0.02 worth after 35 years of inflation? =) I'd say inflation has been easily 12x since then. So $0.02 is now worth $0.25, i.e. the 2 cents of yesteryear is now 2 bits :-) David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] 514 W. Keech Ave. www.osagesoftware.com Ann Arbor, MI 48103 voice: 734.821.8800fax: 734.821.8800 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
At 11:41 AM 11/14/00, Richard B. Johnson wrote: On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Multics??? [..] way too many persons on this list who know the history of Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. When Multics was being developed, the singular goal was to make an operating system that worked on DEC Equipment without having to use DEC software. The emphasis was on trying to make it work period. DEC? Try GE, specifically the GE-645 (if my memory hasn't lost any bits). Speaking of Multics, the last Multics system was just recently decomissioned. I think 35 years is a very impressive lifetime for a computer system. Linux, now at age 9, only has 26 years to go. David David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] 514 W. Keech Ave. www.osagesoftware.com Ann Arbor, MI 48103 voice: 734.821.8800fax: 734.821.8800 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 11:41:33AM -0500, Richard B. Johnson wrote: On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Multics??? [..] way too many persons on this list who know the history of Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. When Multics was being developed, the singular goal was to make an operating system that worked on DEC Equipment without having to use DEC software. The emphasis was on trying to make it work period. Ummm, the way I parse the above statement, you are saying that Multics was developed to work on DEC equipment without having to use DEC software. Maybe we are inhabiting parallel universes, but I'm pretty sure that in my universe, Multics ran first on GE computers, and then on Honeywell computers when Honeywell bought the division from GE. Note, DEC did bid for the Multics contract but was turned down. Maybe you are thinking of Tenex or UNIX? The original machine was a GE-645, which was a segmented, virtual memory system using 36 bit words. The operating system and system software was written in PL/1. Bell Labs had bought a GE-645 and was one of the three development partners (along with GE and MIT) until they withdrew in April 1969. You might want to browse: http://www.multicians.org/ for more of the history of Multics. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 12:14:57PM -0500, Michael Rothwell wrote: Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems book, Ext2 throws safety to the wind to achieve speed. This also ties What safety problems bdflush/kupdated have? (if something they lacks in performance since they works on a global dirty list while it should be per queue dirty list to take the I/O pipeline full on all disks) [..] And the ability to grow filesystems online, [..] This is provided in linux for ages by LVM+reiserfs also in 2.2.x. Any filesystem with inode map and not dependent on disk offsets to find stuff (exept the superblock of course) can do the grow almost trivially and online, the shrink is some more complicated instead. Andrea - 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: Advanced Linux Kernel/Enterprise Linux Kernel
"Richard B. Johnson" wrote: Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. Funny, I got those off the "Multics FAQ" page. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 08:59:49AM -0600, Jesse Pollard wrote: I (meaning me) would like the ability to audit every system call. (yes, this is horrendous, if everything is logged, but I want to be able to choose how much is logged at the source of the data, rather than at the destination. That would reduce the total data flood to what is manageable or desired. Yes, you really need to control the logging at the source of the data. To do that we need to use to use self modifying tricks as dprobes and GKHI does to provide "fast unregistered hooks". o with dprobes the hooks will be _absolutely_ zero cost if they're unregistered but they're very costly (basically enter/exit kernel for every hook) when they're registered (so they're ok if your auditing doesn't happen all the time). dprobe hooks also binds you to a certain binary image (not a generic interface stable across different kernel binaries) o GKHI provides fast unregistered hooks too, if implemented with 5 nops as suggested they will cost around 3 cycles when they're unregistered, and they will provide good performance also when they're registered (no enter/exit kernel as dprobes needs to do) and you can control them via userspace without being dependent on binary offsets (just like with every other hook we have in kernel just now but with the difference that our current hooks aren't self modifying so they adds branches also when they're unregistered so they're bad for usages like syscall auditing). However bloating every syscall with tons of GKHI hooks isn't possible either or it will become a performance problem too eventually. It depends what you need exactly. I'd say one GKHI hook per syscall shouldn't have measurable impact on performance. Andrea - 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: Advanced Linux Kernel/Enterprise Linux Kernel
At 01:10 PM 11/14/00 -0500, Michael Rothwell wrote: "Richard B. Johnson" wrote: Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. Funny, I got those off the "Multics FAQ" page. It may be reasonable to question them as "goals of 'Enterprise Computing'". I found, on http://www.multicians.org/general.html, a list of those same nine goals, introduced by the sentence "As described in the 1965 paper Introduction and Overview of the Multics System by Corbató and Vyssotsky, there were nine major goals for Multics:" While those were the goals of Multics, it is not at all clear that Multics would classify these days as a platform for "Enterprise Computing". I'll note that the word "enterprise" does not appear in either the general FAQ page I cited, nor in the linked article it cites. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell writes: 4) A high reliability internal file system. Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems book, Ext2 throws safety to the wind to achieve speed. This also ties into Linux' convoluted VM system, and is shot in the foot by NFS. We would need minimally a journaled filesystem and a clean VM design, probably with a unified cache (no separate buffer, directory entry and page caches). The Tux2 Phase Trees look to be a good step in the direction as well, in terms of FS reliability. Ext3 is doing pretty well... The filesystem would have to do checksums on every block. Some type of mirroring/clustering would be good. And the ability to grow filesystems online, and replace disks online, would be key. If your disks are getting old, you may want to pre-emptively replace them with faster, newer, larger ones with more MTBF left. You can always do this in the hardware - no reason to do it in software. If you are using RAID 5, and you wanted to take the performance hit you could always calculate the checksums for each stripe on read to detect errors. You may even be able to add a second parity disk to do ECC on the disk data. As for online resizing, you can do this with ext2 for a long time with my ext2online patches/tools. LVM lets you migrate between disks online. You need hardware support (available) to do hot-swap disks - SCSI works, but I don't think the IDE code is ready for hot-swap yet. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Michael Meissner wrote: On Tue, Nov 14, 2000 at 11:41:33AM -0500, Richard B. Johnson wrote: On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Multics??? [..] way too many persons on this list who know the history of Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. When Multics was being developed, the singular goal was to make an operating system that worked on DEC Equipment without having to use DEC software. The emphasis was on trying to make it work period. Ummm, the way I parse the above statement, you are saying that Multics was developed to work on DEC equipment without having to use DEC software. Maybe we are inhabiting parallel universes, but I'm pretty sure that in my universe, Multics ran first on GE computers, and then on Honeywell computers when Honeywell bought the division from GE. Note, DEC did bid for the Multics contract but was turned down. Maybe you are thinking of Tenex or UNIX? The original machine was a GE-645, which was a segmented, virtual memory system using 36 bit words. The operating system and system software was written in PL/1. Bell Labs had bought a GE-645 and was one of the three development partners (along with GE and MIT) until they withdrew in April 1969. You might want to browse: No parallel universe. When Multics was being developed by ATT, it was found to be unusable on the DEC. It was a PDP-8, so the story is told. General Electric got the first contract to make a machine specifically designed for Multics and development continued. 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. As I said, when Multics was designed, the only criteria as to get it to work on a DEC. It didn't. To use this development as an example of "enterprise computing" is absurd and belies its well documented history. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. Funny, I got those off the "Multics FAQ" page. -M History is being rewritten. When Multics was being developed by ATT, it was found to be unusable on the DEC. It was a PDP-8, so the story is told. General Electric got the first contract to make a machine specifically designed for Multics and development continued. 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. As I said, when Multics was designed, the only criteria as to get it to work on a DEC. It didn't. To use this development as an example of "enterprise computing" is absurd and belies its well documented history. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 business altogether. I would suggest Organick's book, if I could recall the title. Marty -Original Message- From: Richard B. Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 8:42 AM To: Michael Rothwell Cc: Linux kernel Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Multics??? [..] way too many persons on this list who know the history of Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. When Multics was being developed, the singular goal was to make an operating system that worked on DEC Equipment without having to use DEC software. The emphasis was on trying to make it work period. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 delighted to find that there are still Multics systems running. There may be many people on this list who know the history of Unix, but from this thread, I'm thinking that perhaps there is some confusion between the history and the mythology. Perhaps we could get ATT, Lucent, or whomever owns the copyright these days, to reprint the "Unix" issue of the Bell Systems Journal. Marty -Original Message- From: Richard B. Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 8:26 AM To: Michael Rothwell Cc: Linux kernel Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel On Tue, 14 Nov 2000, Michael Rothwell wrote: One historically significant "Enterprise" OS is Multics. It had nine major goals. Perhaps we should think about how Linux measures up to these 1965 goals for "Enterprise Computing." Multics??? No way. It was abandoned as unusable and part of the kernel code, basically the boot loader, was modified to become part of Unix. You have way too many persons on this list who know the history of Unix to try this BS. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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, happened to be available and unused. -Original Message- From: Richard B. Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 10:01 AM To: Michael Rothwell Cc: Linux kernel Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. Funny, I got those off the "Multics FAQ" page. -M History is being rewritten. When Multics was being developed by ATT, it was found to be unusable on the DEC. It was a PDP-8, so the story is told. General Electric got the first contract to make a machine specifically designed for Multics and development continued. 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. As I said, when Multics was designed, the only criteria as to get it to work on a DEC. It didn't. To use this development as an example of "enterprise computing" is absurd and belies its well documented history. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote: On Tue, 14 Nov 2000, Michael Rothwell wrote: One historically significant "Enterprise" OS is Multics. It had nine major goals. Perhaps we should think about how Linux measures up to these 1965 goals for "Enterprise Computing." Multics??? No way. It was abandoned as unusable and part of the kernel code, basically the boot loader, was modified to become part of Unix. "take a look at the goals Multics had" != "please reimplement Multics" Flaming is ok, but you should really read the WHOLE email before replying, otherwise you might end up with a flame that isn't relevant at all to the email it supposedly is a reply to... 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 only criteria as to get it to work on a DEC. It didn't. To use this development as an example of "enterprise computing" is absurd and belies its well documented history. How odd then, that Corbato's '65 paper specifically describes it as a research effort on a GE system, and both Ritchie and Thompson have written to similar effect and Glasser et al wrote In the late spring and early summer of 1964 it became obvious that greater facility in the computing system was required if time-sharing techniques were to move from the state of an interesting pilot experiment into that of a useful prototype for remote access computer systems. Investigation proved computers that were immediately available could not be adapted readily to meet the difficult set of requirements time-sharing places on any machine. However, there was one system that appeared to be extendible into what was desired. This machine was the General Electric 635. Multics grew out of research into the design of timesharing systems at MIT, and is from the same family of systems as ITS. It had a long and interesting history and was supported by Honeywell into the 90s. There were several other interesting OSes developed in that time frame, such as SDS's CP/V for the Sigma series, but most of them were not described in the literature and so are long forgotten. Marty - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 well be expanded given what has been learned in the 35 years since. Marty -Original Message- From: Buddha Buck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 14, 2000 9:52 AM To: Michael Rothwell; [EMAIL PROTECTED] Cc: Linux kernel Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel At 01:10 PM 11/14/00 -0500, Michael Rothwell wrote: "Richard B. Johnson" wrote: Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. Funny, I got those off the "Multics FAQ" page. It may be reasonable to question them as "goals of 'Enterprise Computing'". I found, on http://www.multicians.org/general.html, a list of those same nine goals, introduced by the sentence "As described in the 1965 paper Introduction and Overview of the Multics System by Corbató and Vyssotsky, there were nine major goals for Multics:" While those were the goals of Multics, it is not at all clear that Multics would classify these days as a platform for "Enterprise Computing". I'll note that the word "enterprise" does not appear in either the general FAQ page I cited, nor in the linked article it cites. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
if you look at the kstat structure under solaris, there's a lot of info there that'd be good to be able to pull out of the linux kernel. that would slow down the kernel a little, lead to some 'bloat' that linus abhors and such, but its good to have that information for monitoring and debugging problems. it'd also be nice to have hooks built in to monitor errors in the disk subsystem and ideally warn of impending failures as much as possible -- that might be better done in userspace. and pretty much you want all error messages from different subsystems to be monitored and appropriate action taken. ideally all error messages from the kernel and device drivers should be standardized and HA software can then monitor them and take appropriate actions when it sees one that indicates failure. sun is currently in the process of documenting all the kernel error messages from what i understand. those are the kinds of things that give IT managers and sysadmins warm fuzzy feelings about solaris. On Mon, 13 Nov 2000, Josue Emmanuel Amaro wrote: This subject came up in the Generalized Kernel Hooks Interface thread, since it is an area of interest to me I wanted to continue that conversation. While I do not think it would be productive to enter a discussion whether there is a need to fork the kernel to add features that would be beneficial to mission/business critical applications, I am curious as to what are the features that people consider important to have. By mission critical I mean systems that if not functional bring a business to a halt, while by business critical I mean systems that affect a division of a business. Another problem is how people define Enterprise Systems. Many base it on the definitions that go back to S390 systems, others in the context of the 24/7 nature of the internet. That would also be a healthy discussion to have. At Oracle we are primarily interested on I/O subsystem features and memory management. (For anyone that knows anything about Oracle this should not come as a surprise, although I am pretty sure that any database vendor/developer would be interested on those features as well.) Regards, -- === Josue Emmanuel Amaro [EMAIL PROTECTED] Linux Products Manager Intel and Linux Technologies Group === - 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: Advanced Linux Kernel/Enterprise Linux Kernel
In article [EMAIL PROTECTED] you wrote: 2) Continuous operation analogous to power telephone services. No way. Multics could have a whole bank of memory fail and keep running. You could add CPUs, memory and IO devices while it was running without interrupting users' work. Of course, a lot of this cannot be accomplished due to the brain-dead hardware designs (especially PC) prevalent today. However, Linux does not have any support for this type of facility. I recently saw a patch to let Linux use partially bad memory. This is a step in the right direction. The ability to scale the system while on-line is extremely valuable. Motorola has announced Linux Systems with a Hot-Plug CPU - but this seems to be more a hardware then a software feature. 4) A high reliability internal file system. Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems book, Ext2 throws safety to the wind to achieve speed. No. Shure, you don't have all the nice features of log structured or journaled filesystem, but ext2 is pretty reliable for a traditional fs. (I'd like to see if the multics fs was better, do you have a pointer?) This also ties into Linux' convoluted VM system, and is shot in the foot by NFS. We would need minimally a journaled filesystem and a clean VM design, probably with a unified cache (no separate buffer, directory entry and page caches). The dcache is not a disk cache. It caches directory lookups, it is neither something VM related nor does it inpact reliability. The buffercache seems pretty dead in the near future - filesystems are going towards putting metadata in the page cache. (See Al Viro's ext2 patches) The Tux2 Phase Trees look to be a good step in the direction as well, in terms of FS reliability. The filesystem would have to do checksums on every block. The filesystem? This does not belong into the filesystem. An ecc personality for md might be a much better idea ... Some type of mirroring/clustering would be good. Mirroring does _not_ belong into the fs layer, it belongs into LVM, software -, or if you want a really reliable system, hardware raid. And the ability to grow filesystems online, and replace disks online, would be key. If your disks are getting old, you may want to pre-emptively replace them with faster, newer, larger ones with more MTBF left. Why don't you use LVM? 5) Support for selective information sharing. Linux has a rather poor security model -- the Unix one. It needs ACLs no only on filesystem objects, but on other OS features as well; such as the ability to use network interfaces, packet types, display ACLs, console ACLs, etc. If there's a function, it probably needs an ACL. ACLs are not really interesting. They are like good-old file rights with some nice new features and much more complicated. You want MACs and Capabilities (the latter are implemented in Linux). 6) Hierarchical structures of information for system administration and decentralization of user activities. See #5. Linux really does not support delgation of authority well. There's one user who can reconfigure/admin the system: root. No, there is not. There is a capability for each job (or a group of jobs). The root user is just UNIX-Legacy. (ok, ok nearly every system has one - but the Linux security model doesn't really need it). 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. Shure. NT supports win32, win16, dos and recompiled UNIX binaries. QNX supports QNX and now Linux binaries. Thanks to the personality architecture I can (and do) run UnixWare, OpenServer, etc binaries under Linux. And I can use dosemu, wine, etc ... Christoph -- Always remember that you are unique. Just like everyone else. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote: On Tue, 14 Nov 2000, Michael Rothwell wrote: One historically significant "Enterprise" OS is Multics. It had nine major goals. Perhaps we should think about how Linux measures up to these 1965 goals for "Enterprise Computing." 2 Multics??? No way. It was abandoned as unusable and part of the kernel code, basically the boot loader, was modified to become part of Unix. You have way too many persons on this list who know the history of Unix to try this BS. Perhaps this is a call for forking off linux into other project, It is not unreasonable, if goals of one do not match with the other. =) However the guy said that goals are applicable to linux, he did not say rewrite linux to be multics... Pavel. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Mark Hahn wrote: Linux is a good Unix. if adding "enterpriseness" means violating its Unixness, then yes, the goals are bullshit. in particular, the kind of extensive, kernel-based auditing and accounting some people talk about, as well as the complete evisceration of the Unix design for security, would make Linux no Unix at all. that would be very bad, and indeed Multics is a fine example of the kind of history we should not repeat. Are you one of those people who say X11 sucks? And whole idea of a neworked gui sucks? Like ones who threaten to rewrite entire gui without planning, in OpenGL and use the rest of the energy tarishing X? Well, if it is done, probably you won't have to compile those extensions in anyway, so what's the whining about? Enterprise level features will let linux run on Mainframes not in pitiful x86 emulation mode, with hot swappable hardware. Just like raid. Would you say RAID sucks a** and weighs down linux, because it is an enterprise feature? By the tone of your voice it seems so. I am for a concious featurism, add features as long as others are stable and fixed(not in MS way) pavel - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Marty Fouts writes: 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, happened to be available and unused. The original system on which UNIX development started was not a PDP-8, but a PDP-7. The earliest UNIX was also written in assembler. Thompson and Ritchie developed C as a higher-level implementation language during the process of porting UNIX from the PDP-7 to the PDP-11. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote:
On Tue, 14 Nov 2000, Michael Rothwell wrote:
"Richard B. Johnson" wrote:
Multics??? [..] way too many persons on this list who know the history of
Unix to try this BS.
So, you're saying their nine goals were bullshit? Multics had a lot of
problems. But it did a lot of ground-breaking. Perhaps you should reply
to the nine goals, or the general topic of "Enterpriseness," rather than
merely express your irrelevant hatred for Multics.
Relating some "nine goals of 'Enterprise Computing'" to Multics is
the bullshit. When Multics was being developed, the singular goal
was to make an operating system that worked on DEC Equipment without
having to use DEC software. The emphasis was on trying to make it
work period.
WTF are you smoking? Multics never ran on DEC hardware. Moreover, your
ideas about UNIX history ("modified Multics bootloader" bit) are, well,
interesting. Porting from GE to PDP-7... shudder Besides, the thing
had wildly different fs usage model - "everything is mmaped segment" vs.
UNIX "everything is stream of characters".
-
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: Advanced Linux Kernel/Enterprise Linux Kernel
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 [EMAIL PROTECTED] / /_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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote: On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. Funny, I got those off the "Multics FAQ" page. -M History is being rewritten. When Multics was being developed by ATT, it was found to be unusable on the DEC. It was a PDP-8, so the story is told. General Electric got the first contract to make a machine specifically designed for Multics and development continued. 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. As I said, when Multics was designed, the only criteria as to get it to work on a DEC. It didn't. To use this development as an example of "enterprise computing" is absurd and belies its well documented history. SARCASM But .. but... but they said so on slashdot. That must make it true. ;) /SARCASM -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
On Tuesday 14 November 2000 03:43 pm, Steve VanDevender wrote: Marty Fouts writes: 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, happened to be available and unused. The original system on which UNIX development started was not a PDP-8, but a PDP-7. The earliest UNIX was also written in assembler. Thompson and Ritchie developed C as a higher-level implementation language during the process of porting UNIX from the PDP-7 to the PDP-11. I haven't seen anybody point at this URL http://cm.bell-labs.com/cm/cs/who/dmr/hist.html where you can read about early Unix story from the horse's mouth himself. The paper is 20 years old, but still full of very tasty tidbits. Browse around and you'll find many more interesting goodies. In particular, if you want to know the story of how C came to be, as told by its creator, try this URL http://cm.bell-labs.com/cm/cs/who/dmr/chist.html Take it from somebody who has been hacking all sorts of Unix and Unix-like kernels for the last 25 years: Those who don't know Unix history are doomed to reimplement it badly. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
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 Fouts writes: 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, happened to be available and unused. The original system on which UNIX development started was not a PDP-8, but a PDP-7. The earliest UNIX was also written in assembler. Thompson and Ritchie developed C as a higher-level implementation language during the process of porting UNIX from the PDP-7 to the PDP-11. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell writes: 1) Convenient remote terminal use. Telnet, ssh, X windows, rsh, vnc, "screen," ethernet, serial, etc. I think we have this one. Nope: /dev/audio, /dev/cdrom, /dev/floppy, fonts, etc. Also one would want a local window manager for performance, but this tends to interfere with starting apps on the other system. 4) A high reliability internal file system. Now we want it distributed, with version control, with mirroring onto N of M machines and migration toward usage... 5) Support for selective information sharing. Linux has a rather poor security model -- the Unix one. It needs ACLs no only on filesystem objects, but on other OS features as well; such as the ability to use network interfaces, packet types, display ACLs, console ACLs, etc. It would have been nice to have just put 2 entries right in the inode years ago. With the KISS method, we'd be using ACLs right now. Even just a list of UIDs that would share permission bits with the file's GID would be very useful. I just want to share a file with one other person! - 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/
