Hacker News Reader

Comment by shrubble | Hacker News Reader

The goal was a reliable secure OS (achieved) that unfortunately was not very portable.

Also: written in a high level language (uncommon at the time), uniform structures and models for things like memory and IO, and many more laid out in the original Multics papers.

If Multics had been treated as a research project rather than being a plan to invent a ton of new stuff and build a system that would be deployed in volume, everybody would be singing its praises today.

> If Multics had been treated as a research project rather than being a plan to invent a ton of new stuff and build a system that would be deployed in volume, everybody would be singing its praises today.

I wonder if Multics had to be pitched to funders as "a plan to invent a ton of new stuff and build a system that would be deployed in volume" to obtain the level of funding needed for it to prove out its precepts. As a research project, it might not have had the impact that it did upon modern OS theory, design and implementation.

Even today, there is an incredibly strong averse reaction by funding agents to the software notion of "build one to throw away".

That was back in the early 60s, funded by ARPA as part of Project MAC. The “customers” were the kinds of people who cared about the rainbow books (hint: all government), though the science was open.

ARPA (later DARPA) funded a lot of things that were built under contract, not just pure research.

Most of project MAC was pure research and a lot of it is still fundamental and influential today.

Indeed. Porting it to an architecture that wasn't 36 bits wide would be a major undertaking. From my minimal reading of the source, PL/1 (or, perhaps, the dialect of it which was used on Multics?) lacks a real equivalent to C's typedef, and as a result you have explicitly sized types like "fixed bin(35)" and "bit(18)" and the like all over the place in the source.

Beyond that, it was, as Germany described their WW1 alliance with Austria-Hungary, “chained to a corpse”. The GE 645 was essentially a IBM 7090 derivative bolted to a very advanced MMU. The successor implementations were heavily bound by (a) antediluvian architecture and (b) increasingly limited corporate resources to supercharge something increasingly farther away from the mainstream.

Reply on news.ycombinator.com