Slashdot Mirror

Multics (Multiplexed Information and Computing Service) is a timesharing operating system begun in 1965 and used until 2000. The system was started as a joint project by MIT's Project MAC, Bell Telephone Laboratories, and General Electric Company's Large Computer Products Division. Prof. Fernando J. Corbató of MIT led the project. Bell Labs withdrew from the development effort in 1969, and in 1970 GE sold its computer business to Honeywell, which offered Multics as a commercial product and sold a few dozen systems.

It had TONS and TONS of features (look here for a list), but unfortunately it took too long to implement, and when these features were finally implemented, the resulting OS was so damn slow nobody wanted to use it. Consequently it was canned.

Fortunately for us, Dennis Richie and Ken Thompson decided to pare down some of the features and create a version of "Multics without the balls." Thus Unix was born (the name being a pun on "Multics").

And we all lived happily ever after!!

I expect that a whopping lot of people would not consider Linux, The Kernel to be terribly useful for terribly much. After all, it doesn't include:

• A shell such as zsh; note that the notion of separating OS from shell was largely due to Multics, where the command language had its commands reference programs.
• A C library as an interface to programs, such as GLIBC
• Some set of initialization controls as with init
• ... And then the whole set of "user space" stuff, including compilers, text editors, file tools, word processors, and such...
• ... And if you want to do anything graphical, you'll be using something that is recognizably "not Linux," whether you use SVGAlib or XFree86.

The question of where the OS "stops," and where "non-OS stuff" starts is incredibly unclear.

It is not an outrageous thing to argue that Linux is "just the kernel;" that certainly does represent something that is recognizably associated with Linux, and most other components such as GLIBC, X11, GNOME, KDE, GCC, and such are decidedly not specific to Linux as they are used with other OSes of whatever provenance.

It is also not an outrageous thing to think that an "operating system" might include a bunch of additional abstractions that make it useful, which could well include GLIBC, X11, GNOME, KDE, and such.

I prefer to live in the "realm of ambiguity:"

• I would consider MS-DOS to be, while rather sparse in functionality, providing little more than a CP/M program loader, along with a userspace defined by COMMAND.COM , ANSI.SYS and some other .SYS file whose name escapes me, to indeed be an "operating system."

  It is a minimal OS, to be sure; note that you need the program loader, terminal controller, and ( whatever the INIT equivalent is) to have some semblance of a functioning system.

• I'm not sure where to draw the line with Linux.
• Someone using Linux to build embedded systems might stop the line very shortly past init by implementing a custom userspace.
• Someone using Linux to deploy Internet "WebSurfing" Kiosks might consider the "OS" part of the system to include everything below a surface loosely defined by X11; the "application" side being the JavaScript and Java stuff that people might run atop Mozilla.
• On that "kiosk," if they used cfengine to clean up the system configuration every time a new user logs on, there's some ambiguity as to whether:
  • The "operating system" includes cfengine, or
  • The "operating system" includes cfengine plus the scripts used to clean up "system" stuff.

The author of the magazine article in question obviously holds to a dogma that includes some portion of the "GUI" as part of the "operating system."

I would contend that in a heterogeneous world with computer systems used for different things, there's not a good straight answer to this.

I expect that a whopping lot of people would not consider Linux, The Kernel to be terribly useful for terribly much. After all, it doesn't include:

• A shell such as zsh; note that the notion of separating OS from shell was largely due to Multics, where the command language had its commands reference programs.
• A C library as an interface to programs, such as GLIBC
• Some set of initialization controls as with init
• ... And then the whole set of "user space" stuff, including compilers, text editors, file tools, word processors, and such...
• ... And if you want to do anything graphical, you'll be using something that is recognizably "not Linux," whether you use SVGAlib or XFree86.

The question of where the OS "stops," and where "non-OS stuff" starts is incredibly unclear.

It is not an outrageous thing to argue that Linux is "just the kernel;" that certainly does represent something that is recognizably associated with Linux, and most other components such as GLIBC, X11, GNOME, KDE, GCC, and such are decidedly not specific to Linux as they are used with other OSes of whatever provenance.

It is also not an outrageous thing to think that an "operating system" might include a bunch of additional abstractions that make it useful, which could well include GLIBC, X11, GNOME, KDE, and such.

I prefer to live in the "realm of ambiguity:"

• I would consider MS-DOS to be, while rather sparse in functionality, providing little more than a CP/M program loader, along with a userspace defined by COMMAND.COM , ANSI.SYS and some other .SYS file whose name escapes me, to indeed be an "operating system."

  It is a minimal OS, to be sure; note that you need the program loader, terminal controller, and ( whatever the INIT equivalent is) to have some semblance of a functioning system.

• I'm not sure where to draw the line with Linux.
• Someone using Linux to build embedded systems might stop the line very shortly past init by implementing a custom userspace.
• Someone using Linux to deploy Internet "WebSurfing" Kiosks might consider the "OS" part of the system to include everything below a surface loosely defined by X11; the "application" side being the JavaScript and Java stuff that people might run atop Mozilla.
• On that "kiosk," if they used cfengine to clean up the system configuration every time a new user logs on, there's some ambiguity as to whether:
  • The "operating system" includes cfengine, or
  • The "operating system" includes cfengine plus the scripts used to clean up "system" stuff.

The author of the magazine article in question obviously holds to a dogma that includes some portion of the "GUI" as part of the "operating system."

I would contend that in a heterogeneous world with computer systems used for different things, there's not a good straight answer to this.

Multics also had special kernel features for hot-swapping just about everything - again except the microkernel (called "hardcode") itself. But if your microkernel is small enough and enough well designed, replacing device drivers and other kernel parts becomes less of a problem.

I attended a presentation he made at Purdue on Monday, 7/24/00 to the PLUG (Purdue Linux Users Group). He gave an hour presentation and dealt with an hour of formal questions and more than an hour of one-on-one questions. Several things struck me about his presentation:

1) In the hour presentation, he spent 40 minutes talking about Unix history. Sadly, he was wrong about lots of little things, such as Unix was designed to be a time-sharing system -- NOT. I would have hoped for 10 minutes of history and 50 minutes of NOW.

2) In the remaining 20 minutes, he described NOW. It sounded much like Athena and especially Plan-9. It is problematic that Plan-9 solved many of his problems and took 10 years to do that while they have far less time than that. He was "not familier" with MIT Oxygen

3) NOW's time-line seemed unrealistic. NOW's lack of core PhD class CS problem solvers was notably missing. NOW's goals (given the time line) should have been aggresively well defined and yet "we're looking at that" was often an answer.

4) He was factually incorrect about the features of Plan-9. If he'd even read and absorbed Plan 9 from Bell Labs he'd have been in better shape.

5) The company is missing a definitive business plan. It shows already and they're barely off the ground.

6) The office location they've selected in Indianapolis, is one of, if not the most expensive locations in the entire city. This means their venture capital burn rate will be extremely high. Within 5 minutes of that location there are places that cost 25% of that location.

7) The presentation was an un-abashed hunt for warm bodies that know something about Unix (Indianapolis is a nice place, but far from a hot-bed of computing -- Unix or otherwise).

So I came away with the feeling that they'd not done their homework before they started. Further that their venture capitalists said, "Linux is hot, who is available? Ian? oh good. Let's give him buckets of money and see if he can do 'stuff'."

In the end, they're destined to fail. They have a poor grasp of Linux pre-history (Multics & Unix real history) and lack good technical management to judge wisely how to spend their finite amount of money.

Too bad. NOW as a concept doesn't seem like a clunker as little as we were told about it.

something to do with grading the possible transmission of information in such subtle ways as someone replying to an email or not replying to an email (ie: regardless of the content of the message, this accounts for one bit of unpredictable information)

Sounds like a story about "covert channels"; I don't know to which story your professor was referring, but here's one story about covert channels from the multicians.org site.

something to do with grading the possible transmission of information in such subtle ways as someone replying to an email or not replying to an email (ie: regardless of the content of the message, this accounts for one bit of unpredictable information)

Sounds like a story about "covert channels"; I don't know to which story your professor was referring, but here's one story about covert channels from the multicians.org site.

You can't compare DOS to Unix well, as Unix influenced DOS... When MS added subdirectories to DOS they boasted they were going to add more Unix features to DOS (anyone have that announcement in your files?).

__________

I found this story http://www.multicians.org/security.html amusing, particulary how the password "encryption" in an early version of MULTICS turned out to depend on a compiler bug.

He's talking about mapping memory to files, not files to memory.

To what is he referring when he says "mapping memory to files", and how is this different from "mapping files to memory" (except in the order of the two words relative to "mapping" and "to")? (Or did he just decide to use the words in the reverse order in which they tend to be used when talking about mmap(), in which case we're both talking about the same thing....)

In Multics, you initiated a segment, which caused a file to appear in your address space; this is, to some extent, similar to opening a file and mmap()ing it, or doing the appropriate Win32 voodoo dance to get something to hand to MapViewOfFile() and then doing so.

(See the definition of "initiate":

Said of a segment. Also "to make a segment known" (to a process). To make the supervisor call (or as a side-effect of dynamic linking) that associates a segment number with a file in the file system by making an entry in a process's KST. From that point on, references to that segment number become references to that segment, the fundamental illusion of the Multics Virtual Memory. On Multics, instead of opening files, a user initiates segments, and all the rest is magic [BSG].

in the "i" section of the Glossary on the Multicians.org site.)

I.e., they both involve taking a file name (pathname in UNIX or Win32; pathname, or segment name to be searched for in a path, in Multics) and, after making various calls to low-layer OS code, eventually getting a pointer that can be dereferenced, causing page faults that are satisfied by fetching data from the file, and possibly allowing stores through that pointer, with dirty pages pushed back to the file.

Unfortunately the referenced Multics link seems to be /.-ed. But it brings up a subject that's been on my mind lately; the Linux scheduling algorithm. Anyone have any links to a discussion of it? (Other than the code!) I've noticed, with RH 6.0 at least, that Linux seems a lot more "clunky" in its response when it gets a bit loaded. Much more so that Solaris or FreeBSD. But I've not looked at scheduling algorithms since reading The Design of the Unix Operating System by Maurice Bach very, very many years ago.

Multics (MULTiplexed Interactive Computer System) was a Bell Labs project...

That's not entirely accurate. From the Multicians web site:

Multics (Multiplexed Information and Computing Service) is a timesharing operating system begun in 1965 and still in use today. The system was started as a joint project by MIT's Project MAC, Bell Telephone Laboratories, and General Electric Company's Large Computer Products Division. Prof. Fernando J. Corbató of MIT led the project. Bell Labs withdrew from the development effort in 1969, and in 1970 GE sold its computer business to Honeywell, which offered Multics as a commercial product and sold a few dozen systems.

Thank goodness we don't see this kind of insane bloat in UNIX systems

Additional Names

Thank goodness we don't see this kind of insane bloat in UNIX systems

Additional Names

Ah yes, the UNIX and "Open Source"(TM) misinformation campaign rolls forward.

... Whereas the predecessor to UNIX, Multics, a large project with heaps of developers failed miserably and never produced a working system. ...

From http://www.multicians.org/history.html
"6. Commercial announcement (1/73)"
It must not of been a working system.

You probably also think that UNIX was the first OS not written in assembler.

From http://www.tuxedo.org/~esr/j argon/html/entry/Unix.html
... The turning point in Unix's history came when it was reimplemented almost entirely in C during 1972-1974, making it the first source-portable OS. ...

From http://www.oreilly.com /catalog/opensources/book/raymond.html
... Thompson and Ritchie were among the first to realize that hardware and compiler technology had become good enough that an entire operating system could be written in C, and by 1974 the whole environment had been successfully ported to several machines of different types. This had never been done before, and the implications were enormous. ...

From http://www.multicians.org/general.html #tag13
...
1.3.3. High-level language implementation

Multics was implemented in the PL/I language, which was then a new proposal by IBM. Only a small part of the operating system was implemented in assembly language. This was a radical idea at the time. ...

Ah yes, the UNIX and "Open Source"(TM) misinformation campaign rolls forward.

... Whereas the predecessor to UNIX, Multics, a large project with heaps of developers failed miserably and never produced a working system. ...

From http://www.multicians.org/history.html
"6. Commercial announcement (1/73)"
It must not of been a working system.

You probably also think that UNIX was the first OS not written in assembler.

From http://www.tuxedo.org/~esr/j argon/html/entry/Unix.html
... The turning point in Unix's history came when it was reimplemented almost entirely in C during 1972-1974, making it the first source-portable OS. ...

From http://www.oreilly.com /catalog/opensources/book/raymond.html
... Thompson and Ritchie were among the first to realize that hardware and compiler technology had become good enough that an entire operating system could be written in C, and by 1974 the whole environment had been successfully ported to several machines of different types. This had never been done before, and the implications were enormous. ...

From http://www.multicians.org/general.html #tag13
...
1.3.3. High-level language implementation

Multics was implemented in the PL/I language, which was then a new proposal by IBM. Only a small part of the operating system was implemented in assembly language. This was a radical idea at the time. ...

Why is Unix called Unix if there are so many different Unixes (Or is it unixae).

Because, at the time it came out, there weren't that many different ones (although I hae the impresssion the various bits of AT&T using it for various internal purposes started creating different variants for their own projects fairly soon after they started getting it from Bell Labs).

(I'm not sure whether any Bell Labs person has officially said that "UNIX" was a pun on "Multics" or not.)

It should be called Multix

...except that a name that sounds very much like that was already taken (take a look at said page; it's the home page for a site that discusses an interesting operating system).

(I don't remember whether anybody from Bell Labs officially stated that "UNIX" was a pun on "Multics" or not.)

Two examples:
Part of the Multics operating system was written, using 60s technology, that is, mostly a pencil, paper, and competent mind. It was, essentially, the VM/buffer cache manager. It had one, count it, one bug, and that was due to the programmer being misinformed about the API he was calling. Read the story, told properly, at this link.

The BBC Micro was an 8-bit microcomputer produced by Acorn. It had, like most others at the time, BASIC supplied in ROM. It was a very good BASIC, much better than many others at the time (and a lot better than that written by Mr Gates and Mr Allen). The author, Roger Wilson, wrote it in about 3 months (all in assembler, of course), as scheduled. He was then expected to proceed to testing and debugging, but stated this was not necessary as he had written it to be correct. It was, pretty much. It had about 2 minor bugs.

So, it can be done. You can even do it under commercial pressure.

Nicolai

I'm sorry, but `my' definition is the standard, accepted definition of an operating system in computer science.

Funny, when I was in school, I seem to remember people including more than just kernel-mode code - in particular, one operating system partially developed at the school where I went, namely Multics, had very little code running in "kernel mode" (called "master mode" on the GE 6xx machines and their Honeywell successors) - most of it ran in "slave mode", with some running in "ring 0" (no, this was not an x86 processor, so "ring 0" was not equivalent to master mode - even in ring 0 you couldn't execute the instructions to e.g. start an I/O operation), some running in "ring 1", and some running in "ring 4", which was the ring in which user-written code mainly ran.

Please show some hard evidence that your definition is "the standard, accepted definition of an operating system in computer science".

TENEX? Multics? That was back in NCP days--the ARPANET didn't use TCP/IP until the mid-'80s.

I'd have thought they still had TENEX and Multics machines on the ARPANET then. Multics, at least, wasn't, I think, as lively as it was in the '70's, so maybe they had them, but its networking stuff wasn't cutting-edge. Perhaps the same was true of TENEX/TOPS-20. (When did Digital shoot the 10's/20's in the head?)

( Tom Van Vleck's Multics Web site claims that TCP/IP was introduced in the late '70's, but, given that RFC 791 says "September 1981" on the cover, he's off by a bit, I think.)

but the first full implementation was done at Berkeley and incorporated into the Berkeley Standard Distibution for VAX and then PDP-11

I'd heard that BBN had a stack for BSD before the 4.1aBSD stack, and that the BSD stack was derived from it, with a lot of changes by Bill Joy; I don't know if that's the case, though.

(I also vaguely remember hearing of older stacks for UNIX, but those may have been NCP stacks.)

(Gee, I wonder if your appearance here will further surprise the guy who was surprised to see me show up on Slashdot; this article seems to have brought out the old folks, for some reason. :-))

TENEX? Multics? That was back in NCP days--the ARPANET didn't use TCP/IP until the mid-'80s.

I'd have thought they still had TENEX and Multics machines on the ARPANET then. Multics, at least, wasn't, I think, as lively as it was in the '70's, so maybe they had them, but its networking stuff wasn't cutting-edge. Perhaps the same was true of TENEX/TOPS-20. (When did Digital shoot the 10's/20's in the head?)

( Tom Van Vleck's Multics Web site claims that TCP/IP was introduced in the late '70's, but, given that RFC 791 says "September 1981" on the cover, he's off by a bit, I think.)

but the first full implementation was done at Berkeley and incorporated into the Berkeley Standard Distibution for VAX and then PDP-11

I'd heard that BBN had a stack for BSD before the 4.1aBSD stack, and that the BSD stack was derived from it, with a lot of changes by Bill Joy; I don't know if that's the case, though.

(I also vaguely remember hearing of older stacks for UNIX, but those may have been NCP stacks.)

(Gee, I wonder if your appearance here will further surprise the guy who was surprised to see me show up on Slashdot; this article seems to have brought out the old folks, for some reason. :-))