Slashdot Mirror


48-Year-Old Multics Operating System Resurrected (multicians.org)

"The seminal operating system Multics has been reborn," writes Slashdot reader doon386: The last native Multics system was shut down in 2000. After more than a dozen years in hibernation a simulator for the Honeywell DPS-8/M CPU was finally realized and, consequently, Multics found new life... Along with the simulator an accompanying new release of Multics -- MR12.6 -- has been created and made available. MR12.6 contains many bug and Y2K fixes and allows Multics to run in a post-Y2K, internet-enabled world.
Besides supporting dates in the 21st century, it offers mail and send_message functionality, and can even simulate tape and disk I/O. (And yes, someone has already installed Multics on a Raspberry Pi.) Version 1.0 of the simulator was released Saturday, and Multicians.org is offering a complete QuickStart installation package with software, compilers, install scripts, and several initial projects (including SysDaemon, SysAdmin, and Daemon). Plus there's also useful Wiki documents about how to get started, noting that Multics emulation runs on Linux, macOS, Windows, and Raspian systems.

The original submission points out that "This revival of Multics allows hobbyists, researchers and students the chance to experience first hand the system that inspired UNIX."

94 comments

  1. What can we do with it? by Frosty+Piss · · Score: 1

    Is this purely an educational thing at this point, or is there any other uses?

    --
    If you want news from today, you have to come back tomorrow.
    1. Re:What can we do with it? by Gay+Boner+Sex · · Score: 4, Interesting

      History. Read. Learn from the past. General concepts and themes do not change.

      Multics didn't have many "problems," or at least many more than other systems of the time. (the IBM TSS/360, in 1967, turned out to be too slow for supporting more than one user concurrently, and of course OS/360 was plagued with bugs and performance problems). There is a common myth that Multics "failed," but in fact the system was first described in 1965, released in the early 1970s, and lasted until 2000 (Salus himself said, "With Multics they tried to have a much more versatile and flexible operating system, and it failed miserably."). However, the lifespan, in particular the thirteen years after development ceased in which installations continued to use it, doesn't suggest failure. It's certainly true that AT&T management decided that the project wasn't relevant to them, and that's sufficient for Unix history.

      Bam!

    2. Re:What can we do with it? by ArchieBunker · · Score: 1

      Where did you read that the 360 was so slow it could only handle one user?

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    3. Re:What can we do with it? by Gay+Boner+Sex · · Score: 4, Informative

      Where did I read?

      Market research at Digital by walking up to someone ELSE'S mainframe and waiting for it to do another "load in the washing machine" before it would even think about giving you the time of day and sniff your card stack.

    4. Re:What can we do with it? by udin · · Score: 3, Interesting

      The 360 wasn't particularly slow--the time-sharing operating system TSS/360 was initially a mess (so was OS/360--at first--see Brooks,"The Mythical Man Month") and I don't recall that they improved the TSS to where it was usable. There was a project in (as I recall) the IBM lab in Cambridge MA that did an interesting and credible virtual machine OS for the 360 (I vaguely recall it was for a middling level 360) that was developed because the "official" time-sharing system TSS/360 was such a mess.

      --
      udin
    5. Re:What can we do with it? by udin · · Score: 1

      Multics suffered due to its scale--ultimately time-sharing on minicomputers became much more cost-effective compared to Multics. The cost of the hardware it ran on limited its market. Its niche disappeared. OSes like Unix could run on small computers in small companies and big computers (or lots of small computers) in big companies. It also suffered slow development due to tackling new hardware, a new (and complex, bloated) programming language, PL/I, and several new architectural concepts in one project. That it didn't out-and-out collapse with this combination is a miracle, in itself.

      --
      udin
    6. Re:What can we do with it? by Anonymous Coward · · Score: 0

      "Plus there's also useful Wiki documents about how to get started, noting that Multics emulation runs on Linux, macOS, Windows, and Raspian systems."
      It may be Multics, but by now, it is hardly uniques.

      Captcha: hamlet
      Dammit, now I have to do some research. Though this be madness, yet there is method in it.

    7. Re: What can we do with it? by Anonymous Coward · · Score: 0

      Ah, but fucking a Vax system with some mill oil...now that's a good fuck. Never fucked a Multics setup before, maybe I'll have to try it!

    8. Re: What can we do with it? by Anonymous Coward · · Score: 0

      So does everyone on Slashdot go into their server room and fuck the oldest computer in there? Thought it was just me, what a relief!

    9. Re:What can we do with it? by Anonymous Coward · · Score: 0

      Pretty much anything that can replace Windows should be used.

    10. Re:What can we do with it? by Anonymous Coward · · Score: 0

      thank you, Gay Boner Sex, for that insightful first-hand anecdote

    11. Re:What can we do with it? by Anonymous Coward · · Score: 0

      There was a project in (as I recall) the IBM lab in Cambridge MA that did an interesting and credible virtual machine OS for the 360 (I vaguely recall it was for a middling level 360)

      You mean the z/VM OS? IMHO, the only System/360 machine it supported was model 360/67, and it was a rather high-end machine.

    12. Re:What can we do with it? by PolygamousRanchKid+ · · Score: 4, Funny

      Where did you read that the 360 was so slow it could only handle one user?

      This rumor originated in Dr. Gene Amdahl's lesser known history of the IBM mainframe titled, "The Apocryphal Man Mouth," which examined the contradictory cognitive dissonance of software project managers who think that they are running a development process, when, in fact, they are simply running their own mouths. The book is filled with the taller tales of the seminal computer industry, like the instance of Professor Forman Acton of referring to the inventors of that new-fangled language, collectively as, "The FORTRAN Boys."

      Apparently, a disgruntled IBM customer complained about about the one user design limitation of OS/360, and asked the IBM sales rep when an upgrade to more than one user would be available. The IBM sales rep pulled out a little plastic case containing resistors, uttered some bizarre incantation like, "Bad Booze Rots Our Young Girls But Vodka Goes Well", and enumerated the prices of the resistors, and how many users each one would support. One cold solder joint later, and the IBM customer was a happy camper.

      There was also something in there about Oliver North nearly starting World War Three, because he was forced to use IBM's OrifaceVision/2, which was like their PROFS Professional Office System for mainframes, but it was much more secure, because it was based on OS/2, which meant it never ran or was used at all, and you can't get any more secure than something that just doesn't work . . .

      . . . oh, and speaking about IBM SAA AD/Cycle, don't mention that, unless you say "Mary Hartman! Mary Hartman" three times to a mirror, and conclude it with that Islamic curling Eight-ender cry, "Allah Hu Almaraq!", ("God is Gravy!"),

      . . . and . . .

      --
      Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
    13. Re:What can we do with it? by OolimPhon · · Score: 2

      As I recall, most Multics (Multicii? Multicesses?) ran at University shops all over the western world. They had a big requirement for multi-user access in a way that most businesses didn't - at the time.

      What killed Multics was the Personal Computer - why be forced to use a terminal to access a mainframe somewhere else in the world, and over 300 baud if you were lucky, when you could have your own processing power right under your desk?

      The original minicomputers, like PDP, VAX and Wang, were all small timesharing computers whose operating systems owed a lot to Multics (and subsequently Unix). PCs brought a whole change of emphasis.

    14. Re:What can we do with it? by Anne+Thwacks · · Score: 3, Interesting
      Multics didn't have many "problems,"

      I am not so sure about that. In 1973, I repeatedly brought down the system by running a Fortran program in which I declared an array names ARRAY. I cant remember whether this was illegal or not, ARRAY may have been a reserved word, but in the context of Fortran 4, that could have depended on where it was used.

      I would not have complained if I got a printout with an error message - probably "SYNTAX ERROR AT OR NEAR LINE 1 COLUMN 1". Instead the entire OS would crash! This happened several times a day for several days before anyone realised it was me. It was then possible to figure out what I had done wrong only by deliberately crashing a few more times! I am sure that, over a 6 month period, I had few days without a system crash. I may not have been the cause of most of them.

      In mitigation, none of my BASIC programs crashed bringing down the whole system. (But they were only concerned with gathering data from users. The Fortran stuff was solving Maxwell's wave equations).

      Yes, I did ask for a PDP8 instead. I don't know how the costs would have compared. What I do know, is my employers made a colossal amount of money from that software, while I was paid £11 per week for 6 months. After it was written, an apprentice could do in 30 minutes what had previously taken a degree level physicist 3 months - and not only get the right answer, but prove that he had, before gold plated parts were manufactured to the resulting spec. Then, if there were manufacturing errors, predict whether the resulting predict would still be in spec over a wide range of parameters, requiring only a single 30 minute lab test to confirm my predictions, rather than 6 months field tests at the top of a 30 metre mast IN A FIELD WITH COWS or on the top of a war ship at sea - and other scenarios where failure was rather expensive.

      OK, so computers cost $1M in those days - the payback could be many times that - per month. (But even then, engineers were treated like shit).

      --
      Sent from my ASR33 using ASCII
    15. Re:What can we do with it? by Anonymous Coward · · Score: 0

      Very simple explanation; you are a girl and girl will poison you thus OS:
      https://slashdot.org/comments....

      -cremier
      Visit me website and click on amazon link! https://www.cdreimer.com/slash...

    16. Re: What can we do with it? by Anonymous Coward · · Score: 0

      newer systems cant handle my big tool so yes.
      -creimer
      Support Me! https://www.cdreimer.com/slash...

    17. Re: What can we do with it? by Anonymous Coward · · Score: 0

      I love to fuck old Apple systems whilst rubbing my nipples and moaning "Woz"

    18. Re:What can we do with it? by Antique+Geekmeister · · Score: 1

      I used it myself. Your analysis is correct. It was also prone to oversubscription. Students and computer scientists were programming it with the beginnings of "object oriented programming" with languages like LISP, and taught to use self-reference and recursion as part of their philosophically preferred approach rather than as resource expensive tools to use only when needed. The result was _profoundly_ expensive in system resources: calling a function is a much more expensive operation at the kernel level than running a loop. It led to code with no reporting on its current state and no well defined checkpoints, because that was handlined inside of another recursively called function which was actively discouraged from looking inside. The failures of recursion to terminate led to runaway resource consumption by many different less skilled programmers. Given the age of Multics, there was little resource management: the servers became extremely overwhelmed when homework was due on student systems, and when projects were due for business or research use.

      UNIX learned many lessons from Multics: more effective multi-tasking and resource control were some of the more important lessons.

    19. Re: What can we do with it? by K.+S.+Kyosuke · · Score: 1

      calling a function is a much more expensive operation at the kernel level than running a loop

      Clearly they needed The Sussman their God.

      --
      Ezekiel 23:20
    20. Re:What can we do with it? by Bing+Tsher+E · · Score: 1

      and over 300 baud if you were lucky,

      "110 baud should be enough for everybody." - Bill Gates, while in Jr. High School and sitting in front of an ASR-33.

    21. Re:What can we do with it? by davecb · · Score: 1

      Read up on how they did single-level store, whcih caused memory and the file system to behave a lot like one another. Then ask yourself about running Linux programs out of a persistant memory filesystem.

      --
      davecb@spamcop.net
    22. Re:What can we do with it? by unixisc · · Score: 1

      Unix was supposed to be a simplified version of Multics, so it would be interesting to see what the original Multics was capable of, and in what ways would upgrades of Unix have occured had Multics developed on parallel tracks

    23. Re: What can we do with it? by Anonymous Coward · · Score: 0

      I love to fuck old Apple systems whilst rubbing my nipples and moaning "Woz"

      I keep the special sauce out of my Apple ][ by wiring the case to the mains live wire. Passing case rapers get a surprise. Kills their boner permanently.

    24. Re:What can we do with it? by Anonymous Coward · · Score: 0

      Yes, CP/67 was on the 360/67, but before that there was CP/40, and experimental hypervisor on much smaller 360/40 - a one-off that proved it could be done.

    25. Re:What can we do with it? by Anonymous Coward · · Score: 0

      Some corrections: 360/67 supported perhaps a few dozen users on CP/67, and later VM/370 supported hundreds. PROFS came much later, was only on mainframe, on VM/370 and its children. It never ran anywhere else. I figure you're joking, but somebody might stop before the last sentence and not realize that :)

    26. Re:What can we do with it? by angel'o'sphere · · Score: 1

      You don't need the kernel to call a function.
      And inside of the kernel, function calls have the same cost as outside.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    27. Re:What can we do with it? by bobmunck3990 · · Score: 1

      CP-67/CMS, at the IBM Cambridge Scientific Center at 545 Tech Square. Also in that building was the MIT Multics project and the early days of the MIT AI Lab. CP-67 ran on the /360 mod 67 and later on quite a few of the /370 mainframes. It was written mostly in System/360 Assembler, and later in IBM's double-secret language PL/S.

      I taught a graduate course at Brown on the internals of TSS/360, CP-67, and Multics in the early 1970s. One year the class project was to replace the paging and tasking support of CP-67. We also did a nice little hack that gave CP-67 users virtual disks that were actually implemented as virtual memory pages. Prior to that the smallest virtual disk was a megabyte, and we only had 240 MB of real disk storage, but this allowed disks as small as 4K, which meant we could give Brown students accounts.

      I've often said that Multics was a vast improvement on all of its successors, including UNIX, Linux , Mach, and maybe even NeXTSTEP.

    28. Re:What can we do with it? by Antique+Geekmeister · · Score: 1

      You cannot allocate the space to save the state from which a function is called, nor allocate new space to copy in specified function with space for its local variables, without access to the kernel. Nor can you read the end state of the called function and return its generated information or status to the working environment or connect its results to other programs without kernel level functions. It's true that many libraries efectively abstract away this operation at the library level, including libc or glibc themselves. It's also true that I have, on occasion, appalled colleagues by insisting on looking beneath a layer of abstraction to note the resource issues at a separate layer.

      Learning to actually _look_ at the underlying cost and behavior of software at its lowest levels was a lesson I learned using Multics. I'm afraid it cost me popularity with some of my colleagues, but it was vital to protecting performance and avoiding errors on such a constrained operating system and on such resource constrained hardware shared by a working group.

    29. Re:What can we do with it? by jimtheowl · · Score: 1

      Education has been known to be useful. I don't understand why there is an "or" in your statement.

    30. Re:What can we do with it? by angel'o'sphere · · Score: 1

      You cannot allocate the space to save the state from which a function is called, nor allocate new space to copy in specified function with space for its local variables, without access to the kernel
      That is utterly wrong.
      The magic is called a stack. And every processor has build in instructions for function calls.
      No kernel needed at all, kernels have nothing to do with funvtion calls.
      Instead of having a fancy name, I suggest to read a book, or simply dissassemble a fibonacci function or something similar trivial.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    31. Re:What can we do with it? by Anonymous Coward · · Score: 0

      At the University of British Columbia, in the early 1970s, we had TSS/360 running under CMS on a 360/67 and later a 370/168, if I recall correctly. I think we were supporting around 30 simultaneous users and hundreds of connected terminals at that time. Seemed to work pretty well. As an academic user, I didn't notice any significant number of system crashes. Occasionally, I had exclusive use of the system, with special permission, because I used so much virtual memory and CPU cycles that other users were unable to do anything useful. So, yes, it had limitations, but, for more normal academic use (compiling and running student projects, less compute-intensive and less memory-intensive research projects) it worked fine, However, we did have two IBM engineers (IBM employees) on-site to keep it all running smoothly.

    32. Re:What can we do with it? by Anonymous Coward · · Score: 0

      Further to the above comment about TSS/360 at the University of British Columbia, I believe we replaced it with TSO in 1971 or 1972. If I recall correctly, both were available on the same machine for a while during the transition.

    33. Re:What can we do with it? by Antique+Geekmeister · · Score: 1

      Sigh. Thank you, it's been a long week. My apologies for hitting the wrong layer.

  2. no systemd ;) by TheGratefulNet · · Score: 4, Funny

    maybe its worth looking into..

    --

    --
    "It is now safe to switch off your computer."
    1. Re:no systemd ;) by Anonymous Coward · · Score: 0

      I'm sure it'll be infected with the systemd rootkit soon.

      --sf

    2. Re:no systemd ;) by phantomfive · · Score: 1

      How do they handle parallel boot?

      --
      "First they came for the slanderers and i said nothing."
    3. Re:no systemd ;) by invictusvoyd · · Score: 1

      Its the year of the Multics desktop ! .

    4. Re:no systemd ;) by K.+S.+Kyosuke · · Score: 1

      Coming tomorrow: New systemd release with Multics support!

      --
      Ezekiel 23:20
  3. Wonder if my account still works? by sk999 · · Score: 5, Interesting

    I had a Multics account way back - used it solve problem sets in Physical Chemistry. It would be cool to resurrect my account, but I don't remember the password. Is there a password reset function?

    1. Re:Wonder if my account still works? by OolimPhon · · Score: 5, Funny

      Is there a password reset function?

      Yes, but your email address has to have UUCP bangs in it :)

  4. Unix = Castrated Multics by Anonymous Coward · · Score: 0

    Obligatory quote.

    From what I remember of it, it had much better security features than Unix, for example.

  5. Still by ArchieBunker · · Score: 3, Informative

    a more capable operating system than HURD.

    --
    Only the State obtains its revenue by coercion. - Murray Rothbard
  6. I used it at MIT in the early 80s. by www.sorehands.com · · Score: 4, Informative

    I was a project administrator on Multics for my students at MIT. It was a little too powerful for students, but I was able to lock it down. Once I had access to the source code for the basic subsystem (in PL/1) I was able to make it much easier to use. But it was still command line based.

    A command line, emails, and troff. Who needed anything else?

    1. Re:I used it at MIT in the early 80s. by Anonymous Coward · · Score: 0

      emacs and the kitchen sink. On second thought, forget the sink...

      --sf

    2. Re:I used it at MIT in the early 80s. by Anonymous Coward · · Score: 0

      Who needed anything else?

      What about Lynx?

      (On that note, sometimes I find myself tempted to disable images and videos on Chrome...)

    3. Re:I used it at MIT in the early 80s. by Anonymous Coward · · Score: 0

      troff being from bell labs notably after they left the multics project.

    4. Re:I used it at MIT in the early 80s. by Anonymous Coward · · Score: 0

      Well, now you have the chance to port it to a proper operating system. </snark>

    5. Re:I used it at MIT in the early 80s. by freeze128 · · Score: 1

      There was no World Wide Web in the early 80's, so no need of Lynx.

    6. Re:I used it at MIT in the early 80s. by DaiyuHurst · · Score: 2

      Who needed anything else?

      What about Lynx?

      (On that note, sometimes I find myself tempted to disable images and videos on Chrome...)

      Lynx, the text-mode web browser? No. No real network access yet. The front-end processor emulation turns TELNET connections into what Multics thinks are serial ports. We don't have a TCP/IP network stack. The NSA didn't pass that along to the archivists. We have most of an older ARPAnet (NCP) stack, and I think, a full X.25 stack. Email currently works only between users of a given system. But we are planning to resurrect bang-path so we can exchange email with the outside world. This is mostly all outside the emulator though, it's part of our ongoing development of Multics itself. I think once we do that, we'll also have a rudimentary web server in the form of Bjorn Victor's 'httpd' written in MACLISP for ITS. *Then* we could port Lynx. We do have a working C compiler!

    7. Re:I used it at MIT in the early 80s. by Lorens · · Score: 1

      Well, without the web, I would definitely want inn and trn.

  7. Can they port it to a soldering iron? by Anonymous Coward · · Score: 0

    It's not resurrected, till you emulate it on a soldering iron microcontroller:

    http://hackaday.com/2017/07/07/tetris-on-a-soldering-iron/

    You'll probably need to add delay loops to make it run Multics realistically.

    1. Re:Can they port it to a soldering iron? by Anne+Thwacks · · Score: 1
      You'll probably need to add delay loops to make it run Multics realistically.

      No need for a loop:

      sleep(1, "day")

      should do fine if used sufficiently liberally.

      --
      Sent from my ASR33 using ASCII
  8. It's not the end! by Gravis+Zero · · Score: 3, Interesting

    Considering that processor was likely made with the three micrometer lithographic process, it's quite possible to make the processor in a homemade lab using maskless lithography. Hell, you could even make it NMOS if you wanted. So yeah, emulation isn't the end, it's just another waypoint in bringing old technology back to life.

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:It's not the end! by phantomfive · · Score: 1

      Wow, I never thought about that. Do people do that??

      --
      "First they came for the slanderers and i said nothing."
    2. Re:It's not the end! by Anonymous Coward · · Score: 0

      I'm not sure that those who do this are really people :)

    3. Re:It's not the end! by Anonymous Coward · · Score: 0

      Sounds like a pursuit for people that have clones of people.

    4. Re:It's not the end! by Anne+Thwacks · · Score: 1
      Considering that processor was likely made with the three micrometer lithographic process,

      Not even close. It dates from before 1970. It was built with discrete components. I doubt it used printed circuit boards, but if it did, the process would have been closer to 3mm minimum feature size. The adder (as in hardware used to implement "add" assembler instruction) would have been a 15" square board, or more likely, a crate of 10 smaller wire-wrapped boards. The CPU would have been more than 4 off 42U racks. Compared to this, a CDC6600 (several years later) was a supercomputer. They were room sized (room - as in sports hall).

      --
      Sent from my ASR33 using ASCII
    5. Re:It's not the end! by LWATCDR · · Score: 1

      Why bother? Just use and FPGA to clone it.
      The real project at this point IMHO is getting gcc and glibc running on it. I doubt many users will want write software in PL/1 for it.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    6. Re:It's not the end! by Anonymous Coward · · Score: 0

      Think you dropped a zero there - it would have used 30 micrometer lithography as the 3 micrometer (near infrared) didn't exist until 1980 when the 8088 chip was released by Intel. Yes some foundries were already working towards that (Intel - IBM/Motorola) but the writing wasn't on the wall yet.

      I've actually considered the idea of stepping back to a 30 micrometer process and working from that to see how much we've missed with the new low nanometer designs. Is it possible to take the latest AMD Ryzen and actually build it on a larger scale? How does it perform? One thing is we don't have to use the current sockets so start fresh with what we've learned about CPU and motherboard designs over the last 30 years.

    7. Re:It's not the end! by Anonymous Coward · · Score: 1

      My first thought was whether it'd be interesting to implement the machine with an FPGA or something, since emulating 36 bit registers on 32 bit has got to hurt performance (and 64 bit everything is just brute force and ignorance). But seeing how far you can push homemade lithography might actually be quite interesting, if maybe several steps up on the difficulty ladder.

      What sort of budget does one need for this?

    8. Re:It's not the end! by Gravis+Zero · · Score: 1

      It's a work in progress. The chemistry is doable (it's been shown and proven) but people (including me) are actually working to design and build cheap "high resolution" lithographic systems. One micrometer lithography is easily within reach. Higher resolution is possible but getting a laser with the wavelengths shorter than 400nm on the cheap may be a challenge.

      --
      Anons need not reply. Questions end with a question mark.
    9. Re:It's not the end! by phantomfive · · Score: 1

      Wow, that's cool! I would think that getting any laser with sub millimeter precision would be tough or expensive.

      --
      "First they came for the slanderers and i said nothing."
    10. Re:It's not the end! by Anonymous Coward · · Score: 0

      Printed circuits date back to World War II, and were in common use in the 1960s. 74xxx series transistor-transistor bipolar logic (TTL) chips date back to the 1960s. Resistor-transistor logic (RTL) chips date back to the early 1960s. The 74181 four-bit adder is in the 1972 Signetics catalog. Nine 74181s form a 36-bit adder. 74xxx dual-inline packages (DIP) had pins on 2.54mm centers and 1mm PCB features were common. --Peter Traneus Anderson

    11. Re:It's not the end! by Anonymous Coward · · Score: 0

      You don't happen to be with this bunch, do you?

  9. Not impressed by Anonymous Coward · · Score: 0

    The abacus came around much earlier, can do bianry, legedary reliablity, never crashes.

    1. Re:Not impressed by Opportunist · · Score: 1

      Well, it does actually crash from time to time, depending on the amount of stuff on your desk, your eagerness to make room, its position and your general clumsiness, but so far the worst that happened to me was a full reset of the thing.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  10. Multics by Tom · · Score: 4, Interesting

    The original submission points out that "This revival of Multics allows hobbyists, researchers and students the chance to experience first hand the system that inspired UNIX."

    More importantly: To take some of the things that Multics did better and port them to Unix-like systems. Much of the secure system design, for example, was dumped from early Unix systems and was then later glued back on in pieces.

    --
    Assorted stuff I do sometimes: Lemuria.org
    1. Re:Multics by tlhIngan · · Score: 4, Informative

      More importantly: To take some of the things that Multics did better and port them to Unix-like systems. Much of the secure system design, for example, was dumped from early Unix systems and was then later glued back on in pieces.

      Basically Multics gave way to the rise in minicomputers who could not handle such a heavy OS, so the developers created Unix ("Multics without balls" - a play on Eunuchs). One thing they did was if there was every a problem, you called panic(). Aka, the kernel panic on Unix. Much simpler and much lighter than trying to recover (though modern Linux is pretty hard to panic() without failing hardware - it has enough built-in self checks that in general it'll handle misbehaving kernel drivers).

      There's also historical interest - don't you want to see what the predecessor to Unix and C was? Unix was popular because it was a lightweight OS at the time that was multiuser and multiprocessing, a change from CP/M and DOS. It's why people run emulators of the Apollo Guidance Computer with the original software. It's neat, it's interesting.

    2. Re:Multics by squiggleslash · · Score: 2

      Also worth pointing out - and I'm not expressing any views on Multics myself here - while it's technically correct that Unix was "inspired" by Multics, it was inspired as in "You're doing it all wrong! THIS is how you should write an operating system." Ken Thompson and Dennis Richie felt Multics was far too complex and reliant upon unusual hardware. Multics was also one of the more serious attempts to create proto-cloud computing - the concept was that people wouldn't own computers, they'd just pay AT&T for an account and a connection to a computer AT&T would own - plus, you know, per minute fees, per CPU cycle fees, per kilobyte fees, etc. How much this played into the design - beyond obvious issues like security - I can't comment upon, but I do know it meant the design wasn't dependent upon concepts like "Really should run on conventional computer designs."

      As I understand it, there's very, very, very, little resemblance between the two beyond what you'd expect between two operating systems that shared some designers.

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:Multics by davecb · · Score: 2

      The Honeywell salesforce of the day weren't quite sure how to sell a big timesharing system, and referred to Multics as "a machine big enough for everyone in Boston". They were very much into selling "one computer per company" instead, and flogged GCOS to all sorts of unsuspecting companies, including the University of Waterloo. The wouldn't have had a clue about how to sell one computer per person

      --
      davecb@spamcop.net
    4. Re:Multics by Samantha+Wright · · Score: 1

      Time to undo some mod points, because this comment is too good to pass up! I've been a student of Multics lore for a few years—it was way before my time—and the answer is that the obsession with this was beyond amazing. The MIT site would regularly split their system into two while doing debugging, removing IO controllers and CPUs from the main system (without shutting it down) until they had enough hardware set aside to bring up another instance of the OS, still sharing disk drives. They also a per-resource-usage billing system, that could price processing time and I/O as needed. It's much more meticulous accounting than what you'd see on a modern PBS-based cluster, or even Amazon Web Services. Most users would see an account balance upon logging in, and I believe some of the logs at the dps8m site, from when they were getting the emulator up and running, have balance numbers scattered throughout them. These are key features that distinguish Multics from other operating systems—there are lots of posts in this thread that mention Multics being distinctive, but none of them seem to actually touch on any details besides fault recovery.

      The vision was called computing as a utility, and the Project MAC team wanted Multics machines to be as reliable and ubiquitous as electricity or telephone service. Alas, the clusters we have today are far more limited in accessibility and rarely have worthy access protections (I could, for example, ssh into a random node on my university's cluster and bring it to a halt with a forkbomb, messing up any jobs running on it), and to even approach the kind of scaling and subdivision Multics supported, we have to resort to networks of numerous discrete computers rather than a single, unified OS.

      --
      Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
  11. Multics = masturbation by Hognoxious · · Score: 1

    Using Multics is rather like masturbation; it's fun for a while, but ultimately it doesn't produce anything.
    --
    E.A. Blair

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  12. is it on purpose? by AndyKron · · Score: 1

    Will it run my smart phone without crashing? I need something to run my phone that doesn't crash. Is there anything anywhere that won't crash, or is crashing a design feature intentionally put into software?

    1. Re:is it on purpose? by Anne+Thwacks · · Score: 1

      If you don't like crashes, Multics is not for you. (See my previous post).

      --
      Sent from my ASR33 using ASCII
    2. Re:is it on purpose? by DaiyuHurst · · Score: 1

      If you don't like crashes, Multics is not for you. (See my previous post).

      We really don't have much trouble there; I've had a Multics up for three months, another team member, nearly a year. Then again, we haven't have hundreds of stoned college kids banging away at it.

    3. Re:is it on purpose? by DaiyuHurst · · Score: 1

      Will it run my smart phone without crashing? I need something to run my phone that doesn't crash. Is there anything anywhere that won't crash, or is crashing a design feature intentionally put into software?

      Software crashes because the people who pay for software development are more interested in having it NOW than they are in having it RIGHT. Screw Agile.

    4. Re:is it on purpose? by davecb · · Score: 1

      It was quite easy to crash a process: Multics itself was way harder to crash. It was substantially more resiliant than GCOS, which ran on almost-identical hardware. Hi-Multics.ARPA was usually up for months, between occasional maintenance reboots.

      --dave (DRBrown.TSDC@Hi-Multics.ARPA) c-b

      --
      davecb@spamcop.net
  13. Endian-ness by Anonymous Coward · · Score: 0

    Is it big endian, little endian, or bellend-ian?

    1. Re:Endian-ness by DaiyuHurst · · Score: 2

      Is it big endian, little endian, or bellend-ian?

      Lol@bellendian. The GE635, GE645, Honeywell 6180, and Honeywell/Bull DPS8/m were all big endian machines. The emulator is endian-flexible.

  14. There's a joke in there somewhere by darthsilun · · Score: 1

    About HURD.

  15. VMS + 1 = WNT by tepples · · Score: 1

    As I understand it, there's very, very, very, little resemblance between the two beyond what you'd expect between two operating systems that shared some designers.

    Such as how the NT kernel resembles VMS in several key ways.

  16. Other OSes? by tbuskey · · Score: 1

    I wonder if it could run https://en.wikipedia.org/wiki/...?
    I was a sysop for DTSS on a DPS-8 for awhile. DTSS had pipes which inspired them in Unix.

  17. Re:Things like this... by DaiyuHurst · · Score: 1

    Yuck. Eggs are not food. Eggs are food ingredient. Like for mayonnaise.

  18. Influence on Unix by nuckfuts · · Score: 3, Informative

    From here...

    The design and features of Multics greatly influenced the Unix operating system, which was originally written by two Multics programmers, Ken Thompson and Dennis Ritchie. Superficial influence of Multics on Unix is evident in many areas, including the naming of some commands. But the internal design philosophy was quite different, focusing on keeping the system small and simple, and so correcting some deficiencies of Multics because of its high resource demands on the limited computer hardware of the time.

    The name Unix (originally Unics) is itself a pun on Multics. The U in Unix is rumored to stand for uniplexed as opposed to the multiplexed of Multics, further underscoring the designers' rejections of Multics' complexity in favor of a more straightforward and workable approach for smaller computers. (Garfinkel and Abelson[18] cite an alternative origin: Peter Neumann at Bell Labs, watching a demonstration of the prototype, suggested the name/pun UNICS (pronounced "Eunuchs"), as a "castrated Multics", although Dennis Ritchie is claimed to have denied this.)

    Ken Thompson, in a transcribed 2007 interview with Peter Seibel[20] refers to Multics as "...overdesigned and overbuilt and over everything. It was close to unusable. They (i.e., Massachusetts Institute of Technology) still claim it’s a monstrous success, but it just clearly wasn't." He admits, however, that "the things that I liked enough (about Multics) to actually take were the hierarchical file system and the shell—a separate process that you can replace with some other process."

  19. Much Love by DaiyuHurst · · Score: 1

    Based on the comments here, I can't wait for this story to be taken up at TheRegister.

    1. Re:Much Love by doon386 · · Score: 1

      We're making the big-time Dai, eh? H

  20. inspired UNIX being shitty by Anonymous Coward · · Score: 0

    I had to use it in college. It was unnecessarily complicated.

  21. M.U.T.I.C.S. by Darkness+Of+Course · · Score: 1

    Massive
    Unusable
    Tables
    In
    Core
    Seriously

    Okay the last I just winged it, but that was the standard definition of Multics for(;;).
    Since it wasn't posted, I did my duty for history. And tables. In Core.

    1. Re:M.U.T.I.C.S. by Anonymous Coward · · Score: 0

      I learned it as Many Unnecessarily Large Tables In Core Simultaneously

  22. A hugely influential failure by Shirley+Marquez · · Score: 1

    The biggest problem with Multics was GE/Honeywell/Bull, the succession of companies that made the computers that it ran on. None of them were much good at either building or marketing mainframe computers.

    So yes, Multics was a commercial failure; the number of Multics systems that were sold was small. But in terms of moving the computing and OS state of the art forward, it was a huge success. Many important concepts were invented or popularized by Multics, including memory mapped file I/O, multi-level file system hierarchies, and hardware protection rings. Security was a major focus in the design of Multics, which led to it being adopted by the military and other security-conscious customers.