Slashdot Mirror

Interesting to read about events from a bygone era.

I used Multics, but I thought it prioritised the tasks by how thick the cards were.

I guess that explains the slow response I got - I mostly used Multics from an IBM 2741, so I didn't have any cards.

It's also a lot like old-fashioned drum memory.

I think what people really want is MULTICS. http://www.multicians.org/general.html
I mean, who wants a workstation sitting on their desktop that has real computing power when they can have a dumb terminal??

...I once worked at IBM, and they hired me, they said, because I knew Latin. I would submit that Latin is to IBM as Swahili is to Vermont...

Oh I don't know; Latin has a famous role in computing as well...

(although in my case my memories from those years of classical languages are long since gone....but the modern spoken languages I have to use every day are easily at hand. I guess the same could be said for my memories PL/1 though...long since evaporated).

Totally OT, but your comment reminded me of this. A great piece of history from the Multics group about an error code that never was meant to see the light of day, yet, through circumstances, did show up once during an upgrade.

so was Multics written in assembly

Yes, at least initially.

That's simply incorrect. PL/I was chosen as the implementation language for MULTICS well before the first line of code was written. It was never written in assembly language. If you'd like to know some facts, consider reading a bit about the history of MULTICS.

The idea of the first portable operating system escaping the editors of this article is unforgivable.

Oddly enough, this is mostly true. Even though MULTICS was written in a high level language from the beginning, it wasn't very portable. It required a fairly heavy duty memory-management unit that most of the machines at the time simply didn't provide. It was a bit like a current x86 in protected mode, but in reverse. The x86 takes a virtual address and translates with with the paging unit to a linear address, then the segmentation unit (theoretically) does another translation on that to give a physical address. MULTICS required an MMU that took a segment-style address and translated it to a linear address, then a paging unit that translated that to a paged address.

Very few memory management units (then or now) provide that capability, and without it, MULTICS is pretty much dead in the water.

Is that you, Charles Babbage? :-D

A good exhibit mentions Multics... and not just as the father of unix.

Async work is very annoying when the whole system is one state machine.

Hence, large-scale async work is often based on every data transfer between modules being sent along with a PULSE or READY signal. Of course, every module has to be designed so that its output is ready when it propagates the pulse... otherwise there's bogus output into the next module. Basically, one module having the propagation delay timed incorrectly can kill the whole system. BUT, with fast logic, your system will simply run as fast as the hardware can handle...

Commercial async processors have been around for AGES -- but modern logic IC-based processors are rarely build and sold on a large scale, being mostly experimental designs.

There was email long before there were networks. http://www.multicians.org/thvv/mail-history.html describes early email on Multics, between multiple users time-sharing one mainframe.

So Vista may ship with a credible protection model, only 40 years after the party? I heard Windows described as the biggest beta test in history, but is it also the biggest and slowest game of catch-up?

EMACS used to stand for Editor Macros.

Because when it was first released (by the end of the 70s), EMACS was in fact a TECO macros package, result of the unification of several TECO macro packages such as TMACS and TECMACS.

The "modern" Emacs, as an independant program (and not a bunch of TECO macros) built upon Lisp, came a few years later, taking inspiration from Multics Emacs and EINE (Eine Is Not Emacs) and ZWEI (Zwei Was Eine Initially) which opened the way for Emacs being written in Lisp (you should read the Multics Emacs article BTW, it's extremely interresting). GNU Emacs "a we know it" was first released with v13.0 in 1985.

Hey they didn't make that up for the movie...

http://www.multicians.org/cookie.html

CTSS was written by a team of MIT Computation Center programmers led by Prof. Fernando J. Corbató, known to everybody as Corby.

How about humour in other languages?? For example, the famous Latin quote in Multics: http://www.multicians.org/hodie-natus-est.html

Only more than thirty years after it was industry standard... Another M$ innovation, I see.

I think you mean "welcome to the 1960's and Multics".

Multics was the first to have hierarchial directories.

+5, Informative. For those curious about Multics, see multicians.org.

What stops all this? A real, heretofore unknown high-level security model, that actually says "The email program can access stored email data, preferences, and can talk to the network on this port, to these hosts" ...

The mail system (your excerpted example) did not use this privilege model until 1970 though, so you could sorta claim it was unknown until 35 years ago (and the IM support took another four years!).

Otherwise your points are legit.

What stops all this? A real, heretofore unknown high-level security model, that actually says "The email program can access stored email data, preferences, and can talk to the network on this port, to these hosts" ...

The mail system (your excerpted example) did not use this privilege model until 1970 though, so you could sorta claim it was unknown until 35 years ago (and the IM support took another four years!).

Otherwise your points are legit.

Dude, ever heard of VM/370

or maybe Multics

or, more obscure but even earlier Atlas

Dude, ever heard of VM/370

or maybe Multics

or, more obscure but even earlier Atlas

Hear Hear!

cynical side notes:
There is no technical reason why I should not be able to walk into compusa, ask for a computer that by design doesn`t "get viruses" and not get laughed at. The orange book described what a secure computer system should look like, multics shows what a secure OS and computer system look like in reality... and they did so thirty f$%#ing years ago! (Also the morris worm was in 88) There is only one conclusion possible, everyone who can fix these problems once and for all has been abducted by aliens for twenty years now and noone noticed... or whatever. Their excuse better be good!

The fact that noone goes into compusa to ask for a computer that does not spend most of its time spreading worms and ddos might also be a small factor. This is ofcourse not going to change until the raporting on computer security moves on from spreading symantec FUD to doing real reviews of the stuff on the market. This would interfere with the megahurts/marchitecture "benchmarks" though...

To be fair this rapport isn`t all bad. It has the usual vaguely defined growing graphs, percentages only, no absolute numerbs and everything "Source: Symantec coorporation". You wont find those in honeynet and SANS data and analysis. Being ductape salesmen the symantecs of this world need their FUD...

However to the end the rapport has some real data from what looks like an impressive honeynet. You will have to go through the usual "number of rapported vulnerabilities" graphs comparing mozilla and internet explorer first though.

The Multics approach wouldn't have worked in all the environments UNIX thrives (look at NetBSD!) It would be just as "accurate" to say that Plan 9 is a "slapdash clone" of UNIX.

Yeah, it was like reading a chinese edition of a Noam Chomsky book on semiotics as translated by the author of the Celestial Emporium of Benevolent Knowledge, who's name is most likely the chinese equivalent of Monty Cantsin.

I have found that this program helps me. I keep scrolling through until I find one that strikes my fancy.

Java Password Generator

What I really wish they'd do next is what IBM pioneered [...]every byte of data -- including every byte on every disc drive -- had a unique address. I thought that was a groundbreaking idea at the time.

Well, in a way, you're absolutely right. The very first thing you have to realize before you even do a preliminary security screening/threat assement is that security is always a trade-off. That's the major point that most managers fail to understand.

Basically, there are three elements that you need to balance: security, usability and costs (there a re also lot of other relevant factors like existing infrastructre, resistance to change, scalability, etc. that make real security work, ie. more breaking out the pen test kit and print a report, so damn expensive).

There is no such thing as a 100% secure system. That's the common wisdom and that's true. But you can design a 98% secure system. The only problem is that this system will require a huge overhead and be so cumbersome that your employees will spend most of their time doing anything but actual work. That way they'll either avoid it and use something else (ie. something less secure and more usuable), if given the choice. Or they'll be largely unproductive, which in turn means you'll have to spend a lot of money to even keep things running. Which of course means you'll not be able to compete (that's one of the reasons a lot of secure systems are designed for government use only because they government doesn't really have to compete or be efficient).

Multics implemented usuable security exceptionally well. You could get the job done in a timely but relatively secure manner. For some more information about user centered security check out this paper or "Multics Security Evaluation: Vulnerability Analysis" by Karger & Schell (1974). The latter is available online too.

It's really a shame there's no "Open Multics". I wouldn't really run it in a secure production envionment but I'd sure like to have my own Multics machine.

I had always assumed that obfuscation was a magic fix that I could apply if necessary.

Let me get this straight: the author recommends that 'honest' developers obfuscate their code?

I've read programs that I thought were obfuscated, but later found out were just poorly written. Other times I've run into programmers who, tin hats firmly affixed, went to great lengths to make sure no one learned their Merlinesque techniques for getting the most out of BASIC.

In context, the author seems to be talking about obfuscating object code. Yikes! What's the opposite of debugging? Buggery?

Encrypting object code to make it harder to reverse engineer is a giant waste of time. Here are more productive ways to spend the the same amount of energy:

• Making your programs work better
• Asking other people to look over your code for bugs
• Commenting the source so you (and others) can find bugs better
• Replying to 'frist p0sts' on Slashdot

In fact, I can't think of many worse wastes of time than making a compiled program hard to understand.

namely that having a single file that's too big to be memory-mapped just wouldn't have happened then (I assume)

Not exactly - that's why multisegment files were implemented.

In that case, though, the restriction was that a single segment could be no larger than a megabyte (18-bit segment offset, word addressing, 4 9-bit bytes per word), not a limit on the size of the entire address space (12 bits of segment number, as I remember, gives a total address space of 4GB, although some of that was taken up by the kernel^H^H^H^H^H^Hhardcore supervisor and various bits of code you'd probably have mapped into the address space of your process ("process",singular - one per login session, typically).

The MIT 6180, in 1973, had 15 150MB disks, according to the page on the MIT Multics systems in the Multics site history, for a grand total of 2.25GB. (Main memory was 384K 36-bit works, or about 1.5MB.)

namely that having a single file that's too big to be memory-mapped just wouldn't have happened then (I assume)

Not exactly - that's why multisegment files were implemented.

In that case, though, the restriction was that a single segment could be no larger than a megabyte (18-bit segment offset, word addressing, 4 9-bit bytes per word), not a limit on the size of the entire address space (12 bits of segment number, as I remember, gives a total address space of 4GB, although some of that was taken up by the kernel^H^H^H^H^H^Hhardcore supervisor and various bits of code you'd probably have mapped into the address space of your process ("process",singular - one per login session, typically).

The MIT 6180, in 1973, had 15 150MB disks, according to the page on the MIT Multics systems in the Multics site history, for a grand total of 2.25GB. (Main memory was 384K 36-bit works, or about 1.5MB.)

You can't access the disk and RAM the same way because 32 bits aren't enough; just ask the HURD people with their 2 GB (maximum) partitions.

That didn't stop Multics - you didn't assign every single segment in the system its own virtual address range, a process had to initiate a segment to get it mapped into the process' address space. Initiating a segment is, in UN*Xy terms, sort of like opening the file, mmapping it into your address, and then closing the descriptor - you can only access it by using the pointer you get back from the initiate operation. (The equivalents of read and write worked by copying from or to the mapped region.)

The first version of what came to be called CTSS ran in 1961 on an IBM 709. See here for more info:

http://www.multicians.org/thvv/7094.html

I've been writing code or managing projects since 1969. I worked on Multics which was used for multi-level security at the Pentagon http://www.multicians.org/history.html#tag7.4.

They did not, and could not, trust us.

I've never seen a security conscious customer just blindly accept any code from anyone.

Another point worth to be noted is that, under Un*x, the DLL Hell is a non-issue, as we've had libraries versioning since day 1. So, I might as well install multiple versions of a library, and yet do not have the need to recompile an application.

Unix versioning is based on sym links. Given that it doesn't look like sym links came into play until somewhere around SVR 3.2 which seems to have come from 4.2BSD (I base the "come from" on a diagram on page 5 of The Design & Implementation of the 4.3BSD Unix OS), and Linux didn't get them until .95.

Now, I don't know what your definition of "since day 1" is but if it's 14 years (First Edition released in 1969, 4.2BSD released in 1983) then you're absolutely correct.

I'd also point you to the fact that Unix didn't have passwords on day one. They were added later. So much for security can't be added on, it's gotta be designed in. Not that you claimed that they did but it's an example of where Unix came from.

You see when Unix was designed it was a stripped down Multics. Multics was too big, too bulky, too much operating system with too many features. But if you look at the features of Multics we all have them on our desktops (and Unix systems). So Unix barely had anything from day 1. You wouldn't want to use day 1 unix today. Oh, maybe you'd find some level of nostalgia in it - it'd be like whipping out a Pong console - but you wouldn't ever make it your desktop, let alone attempt to install multiple versions of software on it.

Sorry, I thought you were referring to the original ring zero from Multics. Unlike modern systems which are split (with hardware support) into user and supervisor modes, Multics had 8 rings, which allowed all kinds of happy jailing. If modern OSes had this kind of control, you'd be able to do something like having your web server run in a privileged mode that lets it read public_html directories as root but write only as its own user, which is nice when you're philosophically opposed to running your web server as root (and you should be) but you want to deny directory listings to local filesystem users without locking out the web server. This is quite useful when on a very large server where some users don't really trust other users (they shouldn't have to) and would like to be able to enforce .htaccess permissions, but you have to hack a modern OS to pieces to make something like that go. Yes, it's possible to do this with ACLs, but those are OS level, and letting applications enforce capabilities (as Apache does with .htaccess files) is a nice thing to be able to do. My point is, doing this on a modern OS isn't pretty, and experience tells me that pretty is a necessary condition for security.

"e-macs too; a different bastard"

Oh, nobody cares about Lisp.

I have written many small routines in Lisp only to have to scrap them because when it came time to debug the programs I couldn't follow my own logic.

PS - did you know that you can script AutoCAD in Visual Basic? It's been available now for several years.

PPS - Bernard Greenberg wrote a very beautiful paper on Multics Emacs that was published in the Proceedings of the 1980 Lisp Conference. A much larger, mostly technical paper is available on-line, but it doesn't have the same usage stories. RMS recounts the secretaries story in a speech given at ILC 2002. It seems that Multics Emacs had a large impression on the development of GNU Emacs. From this (and another document that he authored) I think that Bernard Greenberg deserves a lot of credit for originating the modern Lisp programming style.

Almost sounds like Multics error message...

Linux cannot at this point compete in terms of feature and performance with most other operating systems *currently available (*note: of course it's lightyears ahead of the Hurd).

However, it may still attract plenty of attention and publicity by strategically displaying booth babes and mascots as their more modern competitors commonly do, such as BSD and Multics. For example, Linux Asia could use this appropriate mascot more often and hopefully they won't go the way of UnitedLinux.

VM for the 360/370 was derived from their experimental CP-40 and CP-67, which did really strange things with the memory map hardware in the 360/40 eventually 360/67 ... and demonstrated that the MMU should be standard in future models. CMS, the Conversational (originally Cambridge) Monitor System, was the primary user component to load into the virtual machines created by VM. Before it became VM/SP, the bundle was VM/CMS. Marketing tried to kill VM/CMS a few times, but the user community SHARES kept it alive until marketing reallized it was gold. Many early adopters were universities, some of whome had their own lightweight variant OS's loaded in a VM, which combined lightweight user support of TSO with capabilities of CMS.

I am unclear as to whether CP/67 and VM were as derivative of the MIT 7094 CTSS as CMS was. CMS's derivation from CTSS may be the academic confusion in the oritinal comment on this; or perhaps that the first "customer" was also MIT related (Lincoln Labs). See also Project MAC history.

VM for the 360/370 was derived from their experimental CP-40 and CP-67, which did really strange things with the memory map hardware in the 360/40 eventually 360/67 ... and demonstrated that the MMU should be standard in future models. CMS, the Conversational (originally Cambridge) Monitor System, was the primary user component to load into the virtual machines created by VM. Before it became VM/SP, the bundle was VM/CMS. Marketing tried to kill VM/CMS a few times, but the user community SHARES kept it alive until marketing reallized it was gold. Many early adopters were universities, some of whome had their own lightweight variant OS's loaded in a VM, which combined lightweight user support of TSO with capabilities of CMS.

I am unclear as to whether CP/67 and VM were as derivative of the MIT 7094 CTSS as CMS was. CMS's derivation from CTSS may be the academic confusion in the oritinal comment on this; or perhaps that the first "customer" was also MIT related (Lincoln Labs). See also Project MAC history.

Oopsie, I forgot the html tags. Don't worry, no tubgirl here!!

Multics

Asianux

But there's something remarkably adept about this computer that makes it so functional. We originally used AppleWorks on it, which was a typical Works suite. Then we used MultiScribe, which was a MacWrite clone (fonts that printed beautifully to an Apple ImageWriter). Then we bought PublishIt! 2 for the thing that gave us desktop publishing. And then we were pushing it; PublishIt! 2 was slow.

But I had to hook up my //e the other day to check some serial hardware, and while I was at it I took a trip down memory lane. Things that I thought were slow 10 years ago were pretty damn fast by today's standards! A 1 MHz //e, fast! To launch MultiScribe, you had to startup the //e with the floppy in the drive, wait for it to ask you to flip the floppy over (insert disk 2), and then hit return for it to continue. I used to think that took forever. It turns out that's faster than OS X booting up on my G4, and I think faster than Illustrator 10 or Photoshop starting up. And honestly, nobody uses the features that Microsoft Word has over the features that MultiScribe has.

For those who aren't familiar, the //e's spec'd as (mine's an original, but the later ones shipped as) 128 K of RAM at 1 MHz. You can expand the RAM quite a bit, add a hard drive, add networking, add a Postscript Laserwriter, and honestly expand anything you can think of (that's what the 'e' stands for), but they're generally expected to be used as I said, and perhaps with a mouse. BTW, the //e had 15 character file names with Macintosh-style type and creator meta-data (no 3-character extensions like DOS to determine file types); it was quite a shock when my Dad bought a powerful 8 MHz 286 for his business and it was so... archaic :)

We can do a whole lot more work with a whole lot less CPU power; the //e is a testimony to that. Compare the original Palms to the Windows CE devices. The first Palms were great! They were instant sellers because they served a useful purpose; not because they had a bazillion features. OS X is nice and all, but most of the CPU time and RAM isn't spent doing much. I'm looking at getting more RAM (I have 768, I'm thinking of popping in a 512MB dimm) just because I do hit the max every so often. Software developers have grown accustomed to growing hardware requirements, and it's really a shame.

When my older brother did CS in University, his computer lab consisted of 16 MHz Sun workstations and he did quite a bit of assembly programming over a few courses. He had to write controller software for a robot arm in assembly. When I did computer science at a different University (I started in 96), we had 300 MHz UltraSparcs, did most of our stuff in C, and I had one course in assembly where we didn't actually execute the code on hardware. The new students to CS do everything in Java; compare that (garbage collection) to programming a robot arm in assembly. (FYI, I'm all for garbage collection as a programming practice, but they don't teach you calculus in university because it's useful. They teach it to you because it makes your brain hurt).

While it's absolutely fantastic that Apple went from the Copland/Gershwin route to Mach/BSD, they did lose a bit in the process; one of the features of Copland's NuKernel was that it ran within 1 MB of RAM. Holy crap. That's what happens when you write stuff from scratch and start over. Multics is generally considered a failure but it did actually ship. Most people don't know what it was, and just think "it was too complex to even exist." Here's a quick rundown of its features,

• Convenient remote terminal use
• A wide range of system configurations, changeable without system or user program reorganization
• Contin

yes... but SCO should know, then, about good ol' multics.

You are a liar, a fraud, and a thief.

You are a liar (if in nothing else) in deliberately misquoting Bruce Perens' analysis of the memory allocation routines which SGI contributed to Linux. Bruce Perens clearly did not say (as you claim he did) that we had allowed '...Unix System V code that "didn't belong in Linux" to end up in the Linux kernel' (my emphasis). He nowhere agreed that this was System V code.

You are a fraud in that you you claim that these routines are your company's property. They are not property, and they are not yours. They aren't yours, they weren't SGI's, they weren't AT&T's. You cannot inherit from others that which they do not own.

Algorithms for allocating memory have been developed over a period of over half a century by software developers studying and improving on one another's code. No implementation of these algorithms exists in isolation; none is fresh hewn from virgin intellectual territory. Improvements are incremental and have largely developed in an open and collegiate environment. Linux may, indeed, have learned some things from UNIX[tm]; but UNIX in its turn got the algorithms from MULTICS, TRIPOS, CPL and others lost even further in the mists of time. You cannot simply stop this process at an arbitrary point and say 'now this is property'. It is not property, it's a commons, a commons tilled and tended by many hands, to bring it to the state it is today.

And so, Sir, lastly, I say you are a thief. You are a thief in that you seek to enclose commons, to deprive the community of the rightful fruits of its labours over many decades, to make property what is not, never was, and never could be property. To steal our work and sell it back to us.

Sincerely

Simon Brooke

This is a terrible slashdot article, no hype, no good in-jokes, no mindless "____ is the next big thing".

Next you'll expect slashdot readers to actually learn something about the history of computing, and the basics of computer science, and information technology.

Resource Limits
Multics supported spending limits per user and per project. When a user or project exceeded its limits, users could not log in, and logged-in users whose limit expired were logged out by the answering service. Prices in "dollars" were set for interactive (per shift) and absentee (per queue) virtual CPU usage and memory usage, terminal connect time, terminal I/O, I/O daemon usage by queue, and attached device usage time by device type. A project administrator could set limits on individual users' spending in the PDT, per shift or overall. (from the glossary at multicians.org)

UNIX = Commercial way of thinking and doing business from a software standpoint, extended to the hardware aspect (by tieing the commercial, closed software to certain hardware). The old way, it is no doubt dying.

Unix started as a way to run a non-vender-supported OS on cheap PDP-11s. Unix eventually became highly commercialized and proprietized, but it started life as a hobbyist project (of sorts).

You can't learn lessons from the past if you get your facts wrong.

Multics did not die when Bell labs pulled out early in its development. It continued to grow, became a commercial product, sold hundreds of millions of dollars of hardware (back when that was a lot of money), and was finally killed by the French in 1986. Systems remained in use until October 2000.

see http://www.multicians.org/myths.html for more on this and other incorrect ideas about Multics.

Although your comments seem authoritative and knowledgeable, your facts are fuzzy and wrong. Unix was derived from Multics, but Multics at the point was dead. AT&T had abandoned the project altogether. That's when Dennis Ritchie developed Unix.

Completely incorrect. AT&T withdrew from Multics in 1969, before a single Multics system had been shipped. In fact, after that point, development continued, and the first systems went into production use four months after Bell Labs' withdrawal. Honeywell (who acquired GE's computer business in 1970) continued to sell and develop Multics systems well into the 1970s, and Multics was not officially cancelled until 1985. See here for more info.

Since Ritchie helped to develop Multics for AT&T, how can anybody say that he ripped off Multics. Is like saying I'm stealing part of my car to use in my other car. If it's mine, it's not stealing.

Right, he was the only one, and all those people at GE and MIT contributed nothing? The facts are simple: in 1969, Systems at Bell Labs were running Multics, and Ritchie and others had access to the source code and knowledge of its internal workings. This code was copyrighted and the property of the three parties involved in development. Bell Labs left the project, and a scant few months later Unix was up and running, developed by many of the same people. If there was any leakage of copyrighted code, or ideas considered to be trade secrets of the Multics project, then Unix was clearly founded on IP theft. And it is clear that the existence of a much cheaper workalike (AT&T basically gave away Unix licenses to universities, etc. in the 70s because the government wouldn't let them sell it competitively) did much to undermine Multics as it struggled to gain acceptance in the same time frame as Unix became popular. Its the same lesson the recording industry has learned: You can't compete with cheap pirated copies of your own product. But piracy is embedded into the culture of Unix, so no business model based on sale of Unix-like operating systems can practically survive.