Why Some Dead OSes Still Matter (2007) [pdf]
usenix.org
usenix.org
Worthy of mention are: ITS (http://victor.se/bjorn/its/, https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste...) This was the original hacker system, developed and used at the AI Lab at MIT.
Genera (https://en.wikipedia.org/wiki/Genera_%28operating_system%29) and the other Lisp Machine OSes.
EROS (http://eros-os.org/eros.html), a more modern research system.
Also worthy of mention are the various mainframe operating systems, particularly MCP (Burroughs) and VME/B (ICL).
These are all quite different to both the present day operating systems, and in many ways they were better. If all people know about are Unix-like systems (and the not too different Microsoft Windows), there will be far fewer ideas for how to improve them, never mind improving upon them.
http://www.symbolics-dks.com/Genera-why-1.htm
Modern stuff caught up to quite a few of these. However, we still don't have a platform where (a) entire system from kernel to apps is in same language, (b) apps can use any code in system for their benefit, and (c) any problem anywhere can be debugged by loading up relevant source and current running state. I thought (b) was cool but (c) would be a godsend for troubleshooting.
Brings new (old?) meaning to "full-stack developer." ;)
UNIX and Windows (VMS) are fundamentally different on just about every level. (Some more recent notes: https://groups.google.com/forum/#!topic/framework-benchmarks...)
The differences between the other systems I mentioned (ITS, Genera, EROS) and Unix are even more striking.
We can't go back now and replace UNIX because we've too much invested in it and there's work to be done.
I remember in the 90s how awesome it seemed to get a *nix system for free with a book.
Around 1996 they made a pivot. They invested heavily to recreate themselves as a company who sold services based on Windows NT. This was a desperate move, but it worked - by the late 90s they had reinvented themselves as a services business. One of the stories of the late 90s was the way that IBM had reinvented themselves.
Then, shrewdly, they invested heavily in Linux. At a time, FreeBSD was still a much better platform. But Linux had the GPL behind it. The GPL forces people to release changes. This sabotaged the commercial software market, which IBM had already lost. IBM could continue to charge for services and retain their hardware monopoly. This has hurt competitors who had strong footholds in software but who who were less strong in services (Sun, Oracle).
Well, it locked up the PS/2 hardware with patents, so nobody could clone it. So non-PS/2 hardware was a lot cheaper, because there were a hundred companies trying to sell it. But that cheaper hardware didn't run OS/2 (at least initially).
But when Microsoft was able to keep pace (more or less) with Windows, nobody wanted the PS/2, because Windows on commodity hardware was good enough, and less expensive.
> Well, it locked up the PS/2 hardware with patents, so nobody could clone it.
The "IBM Compatible" was already well-established though. PS2 architecture plays were an attempt for them to get relevant again, and it didn't work. The main technology that they had was EISA, and there wasn't much edge from having that. > cheaper hardware didn't run OS/2
I don't think that's quite right. A mate had a PS2 that was bundled with OS/2 4 in 1996. We found that the OS/2 install disks that were bundled with his PS2 wouldn't install to other systems. But I never had trouble getting shrinkwrapped os/2 running on commodity ISA or VESA bus hardware - 2.0, 2.1, 3, 4. I ran it as my main desktop for five years. You did have a poor experience if you didn't have a well-supported video card, and almost nothing was well-supported.Which appears just to be the same old idea of UNIX and mainframes revamped in new package, stuck in C and in a kernel model that has hardly changed.
EDIT: To clarify.
Many use GNU/Linux in the same way as they would be using UNIX SYSTEM V, there is hardly any change.
Add to it that besides new filesystems, adoption of mainframe virtualization and sandboxes concepts, there is hardly anything new happening in OS research in regards to Linux.
What I currently care about is OS research that tries to mimick the Xerox PARC experiences, use of micro-kernels, use of safe systems programming languages and so forth.
Better in other OS that are already researching alternative systems programming languages.
Unikernels are just the logical continuation of exokernels, except designed to run under a bare metal hypervisor. Though still excellent to see libOS taken to its limits, I find the task of actually turning a full workstation operating system into a secure multi-tenant distributed cluster system to be more versatile, as you could then tailor it to both general-purpose and special tasks, libOS being firmly in the latter - deploying applications.
Singularity was great, though it seems to have stagnated.
The compilation of .NET to native code on Windows Phone 8.x with MDIL, and its successor .NET Native, can be traced back to Bartok. The Singularity's AOT compiler toolchain for Sing#.
Microsoft research then went on to Drawbridge, Midori (still classified) and now IronClad.
Then as programming languages that grew out of it there the M# which was mentioned around two years ago and not much more, and Dafny being used by IronClad.
Why? When was the last time there was a Linux crash due to it not using a "safe" language? How many people did it effect? Is Linux actually measurably any the worse for using an "unsafe" language?
Would Linux be measurably any better for use of a micro-kernel?
Is anybody going to spend the man-decades (or man-centuries) necessary to re-write Linux using micro-kernels or safe languages, just to wind up at the same level of functionality? No. Ain't nobody got time for that.
So unless you can point to concrete, measurable benefits that are going to come from switching to micro-kernels or Rust or whatever, Linux is going to continue on its way. (I agree that the advantages of micro-kernels are a valid research subject. But you need more than Tannenbaum's "that's the right way to do it". You need a compelling reason where it can do something that people care about that Linux can't do, or where it can do it with much fewer resources (either hardware or programmers), or something of that sort. Merely 10% improvement, say, isn't going to cut it, because you'd have to re-write all of Linux to get that improvement, and it's not worth it.)
The demand for microkernel-like features is there, and Linux will progressively be refactored into a hybrid kernel with a standard set of "servers" you plug on top to augment it (systemd appears to be taking the role of the servers in question). Whether this architecture will end up desirable or an awkward worst-of-both-worlds combination remains unclear.
Micro-kernels are used in many embedded scenarios nowadays. Even your phone or car infotainment system might be running one, e.g. L4, QNX.
GNU/Linux being a UNIX clone will never change. Using a micro-kernel or any other language instead of C simply doesn't work out in UNIX culture.
That's being very objective. Technical merits can only get you so far. One should never be too attached to them.
The Plan 9 team was initially led by Rob Pike, Ken Thompson, Dave Presotto and Phil Winterbottom, with support from Dennis Ritchie as head of the Computing Techniques Research Department. Over the years, many notable developers have contributed to the project including Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup and Bruce Ellis. [Wikipedia]
https://en.wikipedia.org/wiki/Haiku_(operating_system)
It's linked from the wikipedia BeOS page but not prominently...
In September 2005, ACCESS acquired PalmSource, the owner of the Palm OS and BeOS. The company has used these assets and expertise to create the Access Linux Platform, an open-source Linux-based platform for smartphones and other mobile devices [Wikipedia]
https://users.cs.jmu.edu/abzugcx/public/Student-Produced-Ter...
CTOS was Plan 9 of mainframe world. Unisys killed it for a reason. Imagine LISP-like macros and debugger at assembler level. https://en.wikipedia.org/wiki/CTOS
Genode Architecture (very active development) http://genode.org/documentation/general-overview/
Architectural overview of QNX (commercially available) http://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pd...
MorphOS continues Amiga tradition of being lightweight, ultra-responsive, and beautiful http://www.morphos-team.net/
I wouldn't mind a Burroughs on a Chip today given details below http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
IBM's System/38 was way more secure, reliable, future-proof and consistent than UNIX's design. i432 was also radical. https://homes.cs.washington.edu/~levy/capabook/index.html
OpenVMS was so reliable admins sometimes forgot how to reboot it. Cluster uptime up to 17 years. What's cloud uptime again? ;) Fairly future-proof software, too. http://h71000.www7.hp.com/openvms/20th/vmsbook.pdf
Worried about embedded security? Try a highly-assured, real-time, pen-tested Ada runtime. http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA340370&Location=U...
Use, debug, and modify the app down to running OS for developer productivity? Sign me up! http://www.symbolics-dks.com/Genera-why-1.htm
PSOS's layering and abstraction were used in highly-secure systems such as LOCK, GEMSOS, and VAX Security Kernel. Also used object storage to avoid filesystem in TCB. https://www.acsac.org/2003/papers/classic-neumann.pdf
Flex Machine had Go-like source code, capability-security, garbage collection, and cross-language VM. https://en.wikipedia.org/wiki/Flex_machine
Microsoft's VerveOS mathematically verified down to assembler. Relevant to meme: Nucleus copied/improved General Electric's firmware design. http://research.microsoft.com/pubs/122884/pldi117-yang.pdf
Trying to secure VMM's? Learn from the masters. http://www.cse.psu.edu/~trj1/cse543-f06/papers/vax_vmm.pdf
Trying to secure GUI's in VM's, etc? Learn from the masters. https://www.acsac.org/2005/papers/54.pdf
Trying to do robust networking? Learn from the masters. http://eros-os.org/papers/usenix-net-2004.ps
Trying to have a secure filesystem? Learn from a good one. https://www.usenix.org/legacy/event/atc11/tech/slides/weinho...
You're looking for the Unisys SCAMP[1] in a Unisys Micro-A. It's a single chip implementation of the A-series mainframe architecture running MCP packaged in a "desktop"(ish) package. Very nifty. These days Unisys will sell you what amounts to an A-series emulator running on a Xeon. For a lot of money.
[1] Not SC/MP. Different chip.
http://www.cpushack.com/2015/04/18/the-forgotten-ones-unisys...
There was a YouTube ad for them, too, that showed the processor and memory took up little space. Good job on that. The pricing was around $25,000 for people wanting to play with it. That was nice. Unfortunately, and predictably, they've moved onto x86 with firmware emulation:
http://www.pcworld.com/article/2364600/unisys-phasing-out-de...
Not sure if that's a mainframe box or not. Has a nice case that reminds me of Alienware. Anyway, now MCP runs on Libra's which are $900,000 entry-level. Wasn't crap on eBay for the older stuff. (sighs)
I'd be concerned about buying one given the complexity of mainframes. I tried to acquire an old AS/400 to play with only to find that there were a myriad of strangely-named options that probably weren't options. I surely found all for sale. It take an expert, though, to know what to buy, how to put it together, and so on. Unless I wanted to sift through encyclopedias. Is acquiring Unisys Micro-A's etc like that where I'd definitely need an expert rather than just the documentation?
As to purchasing one, since it was designed from the start to be an "all-in-one" product for a relatively non-technical crowd, I image as long as all the hardware worked, you'd have a working system and would only need to learn MCP (complicated, but for which there is excellent doco and people who currently use it for help). However, if anything didn't work or failed later (especially the disk), you probably have an interesting paperweight. There aren't exactly a bunch of spares or OS install tapes running around.
That said, I've never seen a Micro-A for sale on eBay or otherwise, and only know one person that has one. By comparison, the P/370, P/390 and other IBM-mainframe-card-in-a-PC show up a couple of times a year one place or another, though I've never seen one go cheap.
Re: AS/400: Oh, yeah...glad I never got bit by that bug. It's crazy trying to understand various piece parts of that ecosystem. Bonus: as I understand, the software licenses for an AS/400 are not transferable.
"Bonus: as I understand, the software licenses for an AS/400 are not transferable."
I especially appreciate that. Expired icing on an already rotten cake in terms of a deal for the inexperienced buyer. ;)
The UX is just quite odd and looks old - making it themeable would certainly have made it more appealing to my younger self.
Your alternative doesn't work. Qt in particular is a platform that goes out of its way to obscure the underlying platform. You could probably use GTK in a 9er way. Still, it wouldn't make sense for applications - the apps written on GTK for unix or windows don't stick close to the everything-is-a-file approach. They are monolithic and beige.
Winning users to Plan9 is particularly difficult because part of the vision is about creating a network, rather than a computer. From this, it follows that it doesn't make sense to have sshd run on it. I think the community made a mistake here. If they'd offered a sshd entrypoint, it would have offered a path-to-adoption for new users coming from a unix background. On the path they've taken, there's a high barrier to entry to anyone wanting to do work with it in a non-pure way. If it had ssh, you could sneak it into enterprise. That's not practical for plan9 in its its current form.
Not to mention the fact that ssh has existed for plan 9 for as long as there has been ssh. Plan 9 is older than ssh. Plan 9 also supported rsh and all the other awful unix communications protocols. They never gained popularity with plan 9 users because superior alternatives existed, which made better use of the OS abilities.
> plan 9 to do unix things, and there is no benefit to that
No - there is. Lots of benefit. Often when I'm thinking about approaches to an IPC problem, I'll go to the plan9 manuals and find an approach that is much more evolved than what's in Stevens. It's not hard to sell people on 9p.Unix people are attracted to plan9. But it'd be nice to be able to learn rc in isolation, without having to deal with the cog/overload of the window manager and the unfamiliar editors. And then gradually move your tool chain over to 9p.
Once they were established they'd branch out towards the other awesome stuff.
> Trying to gain any benefit of the plan 9 architecture
> by crippling it with an overengineered telex emulator
> is missing the point entirely.
Baby steps. > Not to mention the fact that ssh has existed for
> plan 9 for as long as there has been ssh
Really? How do you set up a ssh server on plan9?No, because rc "lacks" features unix users are used to, such as command history. The reason rc does not have this sort of thing is because it's unnecessary thanks to rio. Without rio, rc is not a useful interactive shell. Without using rc interactively, why bother using it instead of perl or python? It's just another programming language at that point.
> Really? How do you set up a ssh server on plan9?
sshserve(1) (see ssh1(1)) for sshv1, and sshsession(1) (see ssh2(1)) for sshv2.
> No, because rc "lacks" features unix users are used to, such as command history.
Hmm. You're right.The general problem remains. It's difficult to build momentum in a platform that operates as an all-or-nothing proposition. 9p might offer a way in though.