Hacker News Reader

Comment by omginternets | Hacker News Reader

While entertaining, I'm left with the following question: if not UNIX, then what?

Are there any successful non-UNIX-y OSes that are worth checking out?

I may embarrass myself here, but I was under the impression that BSD, Plan 9, Solaris and HP-UX were all UNIX-y ...

Basically only two paradigms survived the 90s. The Unix way (via Linux, BSD, Darwin) and the VMS way (via Windows NT). Everything else is either ultra-niche, dying, a mainframe so ancient and terrifying nobody will go near it, or only of marginal historical import.

Bear in mind that when this book was written, the average desktop PC was running MS-DOS, and possibly Windows 3.1 if it was new and powerful enough.

What UNIX is being compared to is the other mainframe OSes of the 1980s, from DEC's VAX/VMS to IBM's OS/360 and OS/400

Seems like a good summary. Let's not forget that microkernels and RTOS's dominate embedded.

http://www.cs.vu.nl//~ast/reliable-os/

Microkernels are also favored in the safety- and security-critical niches in high-assurance systems. Although niche, it's tens to hundreds of millions of dollars in activity over the past decade. Seemed worth adding as a surviving paradigm given that. One of more successful ones below.

http://www.ghs.com/products/safety_critical/integrity-do-178...

The Xerox way also influenced Windows, OS X, iOS and Android and to certain extent ChromeOS.

In regards to IDEs, frameworks, programming languages culture.

There's a good book about this, called 'Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age'

http://a.co/9Gp3tQ7

I googled "the VMS way" an got this: https://youtu.be/96LQ9_jiwQ4

Very 90's, but I think this is what I was actually looking for ;) https://en.wikipedia.org/wiki/OpenVMS

still worth checking out? or just worth checking out?

The coherency of VMS (and the VAX platform) is quite amazing -

Coherent command line interfaces, API's, documentation, hardware, and software, even down to coherent part numbering made by a single company, from small workstations up to larger scale minis, and nearly transparent clustering.

I mention VAX specifically, since by the time Alpha arrived, DEC was competing in a much different environment, and was subsequently merged, etc etc etc.

IBM and other mainframe-ey OS's, though definately arcane, have some amazing facilities (parallel sysplex.. multi architecture systems that are completely redundant and hot-swappable) and capabilities since the late 60s/70s which are only now being caught upto in crude and hackish form at the present time with commmercial PC servers.

BeOS had some cool concepts.

I've installed and played around with VMS on an emulator and even on my own VaxStation, but never used it in a production environment. I'm sure real world usage left a lot to be desired, but my impressions are that VMS as a product was well-rounded, feels complete as if there aren't a lot of loose ends. In contrast to the unix philosophy, VMS feels DESIGNED, as if the people working on it had a coherent idea of the way the entire system was supposed to work and its components interroperated. The documentation is superb. Linux distro maintainers would do good to revisit VMS docs from time to time to see how its done.

The versioning filesystem is something I've waited for since I first used VMS (1991) and discovered such a thing existed. Though to be fair recent Windows and OSX versions have something like it, it's not the same.

"VMS feels DESIGNED"

It was. This is one of the reasons outside of its legendary reliability that I keep bringing it up. It's a cathedral where most things fit. There was cruft to deal with. Overall, the pieces work very well together as the teams had a coherent vision for how they wanted the system to work. It also integrates solutions to problems such as distributed locking and node failures that other systems dump on the app developers.

Not to mention I never got these testimonials or personal experiences when I started with UNIX...

http://h41379.www4.hpe.com/openvms/30th/t_guestbook.html

Which emulator did you use? Simh?

I used Simh Vax, but I've also used Charon-VAX in the past when they were allowing free usage of the software (I don't know the current situation). Charon was quite fast at the time on the hardware I had in maybe 2008 or so. But I've used Simh recently and it's plenty fast enough on modern hardware.

Not OP but I recently installed OpenVMS 7.3 on Simh following this guide [1], (ignoring the building Simh part) and it works like a charm.

[1] https://www.wherry.com/gadgets/retrocomputing/vax-simh.html

What's the easiest way to get OpenVMS these days?

The official site is here:

http://www.openvmshobbyist.com/news.php

You can sign up as a hobbyist here:

http://plato.ccsscorp.com/hobbyist_registration.php

someone will email you in the next day or so with a license installer and the URLs to download the software.

Also they have the Alpha version of OpenVMS available.

I put the post below together for anyone wondering what UNIX alternatives existed with what superior attributes:

https://news.ycombinator.com/item?id=10957020

"Successful" was mostly social and economic factors rather than technical. The most successful in mass market are the OpenVMS variant called Windows, an OS building a GUI platform on a UNIX/Mach hybrid, UNIX OS's such as Linux, and an OS building a user-space platform on Linux. UNIX's and BSD-licensed code allowed companies to save money & increase adoption building on existing code/ecosystem that had tons of momentum. Mainframe OS's are still going pulling in huge revenues, including MCP via Unisys (Burroughs renamed post-merger). IBM i's succeeded AS/400 that succeeded modern System/38. Microkernels and mainframe VM's got reinvented as modern clouds with VM's or containers. Legacy continues even if original products mostly died out.

I think the important thing to accept is just because something is the best option we have, doesn't mean it couldn't be significantly improved -- I feel each of bash, vim and Emacs fall into this category, in their own way.

They all are, but this book dates from a time when Unix had nothing like the absolute dominance of paradigm it does now. True, by the early-mid 90s, the Unix model had effectively won - but there remained a very large number of people with fond memories of other platforms, many of which did at least some things better than any contemporary or even modern Unix.

>there remained a very large number of people with fond memories of other platforms, many of which did at least some things better than any contemporary or even modern Unix.

Yeah, that's what I'm curious about. Could you name names? :)

I still miss things from AmigaOS (still being developed, but ultra-niche; with "clones" in the form of AROS - which is open source - and MorphOS).

Things like ubiquituous scriptability of apps via Arexx (the language is awful, but you don't need to use the language much to call the APIs), heavy multi-threading throughout the OS, datatypes (new image format? drop a library in the right directory and every application that knows how to load images via datatypes can load it; same for text/documents, sound etc.), assigns (think of it a bit like $PATH, but not limited to a single variable, and enforced OS-level, so e.g. C: in AmigaOS works roughly like $PATH, but by default there's also LIBS: for libraries, T: for temporary storage, CLIPS: for the clipboard, and by convention people tend to have e.g. WORK: pointing wherever you want your project data - you can define your own, and redefine them at will, and they can refer to eachother, so e.g. your "C:" may refer to System:C and Work:C (at the same time), and either System: or Work: or both can be either partitions or labels assigned to removable media (in which case the OS may ask you to insert the right disk if you reference it - it can reference a specific disk rather than just the drive), or to another assign).

Or workspaces as an OS-level construct (Screens) that applications can open, close and manipulate, either for "private" use for just its own windows or by opening public screens that can be used to combine windows from multiple applications.

Or third party standards like XPK, which lets any application transparently support file compression - similar to datatypes you can drop in a library forany compression algorithms and all the apps gains support for it (there are several similar standards for e.g. archivers, disk images etc.).

Current mainstream OS's still feel very backwards in many ways after being used to those things.

Further more, you get a new application on floppy. The disk is named FOOAPP. The application can then request data files such as FOOAPP:data1.dat and FOOAPP:data2.dat. If the program is running and you remove the floppy, no issue. When the program tries to open FOOAPP:data3.dat, the operating system will then ask you to insert disk FOOAPP (and there's no having to dismiss the alert box or anything---the system will detect the inserted disk and dismiss the alert box automatically).

Later, when you get a harddrive (or decide you like the app and want to continue using it), you can copy it to the harddrive (wherever you want) and add an assign "FOOAPP=MY_APPS:new/fooapp" and the application will still work just fine.

It's still something I miss.

There were lots of attention to details like that... I still hope AROS will get to the point where I can use it more. The big challenge is SMP and memory protection; without it a lot of software gets really hard to port (a lot of essential OSS software depends on fork()). It's in the works, though, so maybe one day...

Assigns sound a bit similar to how Plan9 handles the "everything is a file" thing

Lisp machines turn up pretty frequently in this context, and I understand why - some of their capabilities still haven't been replicated anywhere else, nor are they likely to be, and that's a real loss; in particular, there is a great deal to be said for a model in which changing the behavior of the running system, right down to the microcode, can be as simple as writing up the changes you want and evaluating them. No compile step, no restart, no nothing - you just point at something and say "do this instead from now on". If you like it, save it and hang it off the boot process; if you don't, reverting the change is as easy as evaluating what you replaced; if you discover you've broken the running environment, you can usually fix it without a reboot, and in extremis a (fast!) reboot cures all such ills.

About as close as you can get and stay relevant to the modern world is Emacs, which, while a lot of fun, I gather from those with real Lisp-M experience isn't really all that close. And it says something, I think, that the next former Lisp-M user I meet who has a bad word to say about that platform will be the first one.

In general, the book does these systems more justice than I can, and it's a fun read in general. I recommend it quite highly - in those areas it covers where I have experience of my own, I found little with which to disagree and much with which to laugh.

Live modifications of OS code sounds like a recipe for disaster. Unless you are an expert that codes himself an OS before breakfast

Bear in mind that LispMs had well-designed tools for supporting this kind of development. For example, they had version control that tracked all changes everywhere at all times, even changes that were not saved in any file.

Also bear in mind that they were designed by programmers for programmers. They were not intended for the general public.

> they had version control that tracked all changes everywhere at all times, even changes that were not saved in any file.

No. The file system did auto-versioning, so you could generally recover recent history of a file, but there was nothing that "tracked all changes everywhere".

Well, ZMacs (the editor) did have unbounded 'undo' functionality, and you could even select a function and undo changes to that particular function, even if those weren't the most recent changes to the file. Maybe that's what you have in mind.

Thanks for the correction. I'm probably conflating features of ZMACS undo with features of Interlisp's Masterscope.

It's not something one would probably use every day, or without due care. But it is something you can. And, as I said before, unless you take explicit steps to persist the change across boots, one flick of the big red switch and it's gone.

Very interesting, thanks. Why do you suppose Lisp-M isn't more widely used?

They were expensive. Sun workstations that cost five figures were cheap compared to LispMs.

Their UI was powerful and efficient, but not easy to learn. They were designed by programmers for programmers. Their UI assumed that you were willing to invest nontrivial time and effort learning a broad palette of specialized tools.

Their system design made some pretty different assumptions about how they were going to be used, and the environment they would be used in. For example, LispMs didn't have any kind of security or memory protection. They were wide open systems.

If you would have wanted a comparable Lisp experience on a SUN workstation (large bitmap screen, large disk, software, ...) the actual price difference wasn't that much. But there were a lot of underpowered and slow SUNS, which were cheaper. But then you would better not use Allegro CL, Lucid CL or LispWorks on those. 16 or even 24 MB RAM were simply not enough and GC was fighting with the virtual memory pager...

The big cost driver at that time was memory and peripherals like disks.

The lab I worked for had slow SUN SPARCs. The idea was that you would net boot them and they would get their software from a main server. Relatively cheap. But it turned out a bit slow and clunky. People then often used their office Macs for software development, with Macintosh Common Lisp.

True, but the point is that there weren't any really cheap LispMs until it was too late to matter.

Besides which, a system that was so much designed for programmers was probably never going to command a very big market.

There was never a really cheap Lispm. The 'cheap' ones were a Mac II + TI microexplorer or the Mac II + MacIvory. But developer workstations were always expensive - Lispm or not - or underpowered.

What was also expensive was the software. I got a KEE license on a used machine I was given. I think it cost $50k. Similar Symbolics extensions for their OS could be extremely expensive. The graphics suite did cost several 10k per module (paint, model, render, tools, ...).

> a system that was so much designed for programmers was probably never going to command a very big market

Well, they could not live from developers alone. They were also looking for end users. Some of the machines were thought as delivery machines, cheaper and with less resources. There were also tools like 'firewall', which were supposed to keep users from getting in contact with the development environment (like debugger, ...).

Actually Symbolics also targeted high-end endusers, both with hardware and with software. They had to go beyond government developers - to be able to sell machines/software. There were applications that were kind of development centric, like the iCAD cad system - where one could program 3d models via Flavors extensions. But one huge area for Symbolics was the graphics market. 2d, 2.5d animation, 3d animation, paint/model/render. Much of that was used without programming. The graphics suite was mostly targeted at graphics professionals, often doing 3d visualizations for TV, cinema and games. Many TV stations had their logos animated on Symbolics machines.

https://www.youtube.com/watch?v=V4HXPJtym2Q

https://www.youtube.com/watch?v=f4Lo0IfUSPk

Early:

http://lispm.de/symbolics-3/symbolics-3.html

Later high-end hardware/software for accelerated graphics: http://lispm.de/symbolics-1/symbolics-1.html

Thus the UI had to be usable for non-programmers doing graphics work.

https://www.youtube.com/watch?v=gV5obrYaogU

It's a fair observation that you could build end-usery UIs on a LispM. The default UI was pretty programmery, but then that's true of pretty much all computers at the time they were being introduced.

I guess a more important factor is that PCs were cheap enough to create a market for friendlier UIs, and LispMs weren't.

> It's a fair observation that you could build end-usery UIs on a LispM.

Texas instruments ran the Interface Builder on their Lisp Machine, which was demoed to Steve Jobs and which then was developed into the NeXTstep interface builder.

> I guess a more important factor is that PCs were cheap enough to create a market for friendlier UIs, and LispMs weren't.

The higher-end commercial applications on the Lispm were kind of user friendly. Using something like the font editor or a graphics editor was not difficult. There was a problem that during its lifetime much of the UI landscape was under development - both in look&feel and APIs. There were even UIs on the Lispm that looked similar to Mac apps (like Plexi, a neural network toolkit).

Symbolics' Dynamic Windows GUI had some polish, which came from being used in some applications and it had seen some substantial investment in development. Where this investment was not done, applications lacked polish and remained experiments, demos, sketches, research prototypes, ...

TI also developed a more conventional UI toolkit for their Lispm.

> I guess a more important factor is that PCs were cheap enough to create a market for friendlier UIs, and LispMs weren't.

The market was small - I would guess that around 10000 machines were sold. Additionally the software was not portable to other platforms. CLIM was thought to support that - with some applications using it - but that was bound to commercial Lisp systems, some of them expensive... Generally I think the Lispm impact on other UI systems wasn't that great.

Was there anything preventing the development of a less hacker-focused UI, save lack of reason to do so?

There is a price list for Lisp machines in this archived Symbolics presentation made in 1986, page 14: http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/h...

Lisp machines were expensive, the early ones at least took a very long time to boot, and I think there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge. They're still extraordinarily cool machines.

> there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge

I'd be interested to hear this expanded upon.

Old-fashioned Lisp and Smalltalk systems presented a programming model in which the language process is your running program, but it doesn't yet know how to do the right thing. Your job is to interactively teach it how to be your application. This you do by teaching it one little piece at a time until it is transformed into the application you want.

This process is facilitated by the ability to at any point save the state of the process for later resumption. These saved states are called "heaps" or "images" or "worlds". Start up one of them and you are more or less instantly returned to the last state you were in when the process was last running.

LispMs extended this model to the entire machine.

There are advantages and disadvantages. The advantages are legion, and they can enormously accelerate development in the hands of someone comfortable with that mode of working.

There are two main types of disadvantage. One is that, since you are interactively modifying a live, running system, if you make a mistake, the mistake becomes part of the running system. If you save the image with that mistake in it, it becomes part of the system in future sessions, too.

The second problem is that it becomes troublesome to separate your application from the scaffolding that you've used to build it. To take a very simple example, suppose you construct a few simple data structures for testing purposes. Those test structures then become part of the running system, and there is a risk that your application will inadvertently come to depend on their values, leading to obscure bugs if they change or if the application is deployed without them.

There are reasonably straightforward ways to deal with both classes of problem, and properly-designed Lisp and Smalltalk systems include tools that help solve these problems, but it's appropriate to acknowledge them as problems.

I like old-fashioned Lisp and Smalltalk systems, and I like image-based development. I prefer the programming model in which I am teaching the process to be my application, and I'm much more productive in such an environment than in the now more-mainstream, model where programming is more like building something from a blueprint than it is like teaching something to behave the way I want.

But that doesn't mean I don't acknowledge the problems of image-based development. They exist. They are solvable, but they do exist.

> very long time to boot

Actually a typical Symbolics 3600 didn't boot much longer than a SUN... my NXP1000 Lisp Machine boots in three minutes from a very large image.

i'm not trying to be fussy, but we would boot the 3670 overnight when the GC stopped being able to catch up with itself. because as i recall it took a couple hours

A full GC could take easily take half an hour on a machine with large virtual memory.

Booting then was much faster.

OpenVMS: distributed locking (we're barely catching up with it, in 2017!) -- see e.g. http://download.oracle.com/otndocs/products/rdb/pdf/rdbtf05_... , filesystem versioning (we still have nothing like it, and applications like ClearCase (very poorly) try to implement their own over filesystems that don't support it). ASTs (see https://en.wikipedia.org/wiki/Asynchronous_System_Trap ) are also great, but I think something akin to them exists in Windows.

See Show Stopper!: The Breakneck Race to Create Windows NT by Zachary. Gives you an idea what the Unix landscape was like, and how primitive Windows was when Dave Culter's team from Digital began building NT (after the VMS at Digital), which became Windows XP (when Windows stopped crashing every hour).

Much of what we assume every OS does today was cutting edge development in 1990.

Yeah everyone seems to rag on C for being ancient. They don't realize that, in 1990, writing a kernel in C was an huge improvement over assembly language! And it still is today -- there's really no other option.

If your only other choice is assembly language, then C starts to look really good. You don't complain about weird function interfaces, because at least you have functions!

The original NT graphics code was in newfangled C++. The books goes into detail on the time lost teaching the team C++, and that they should have stuck with C. ;)

Nitpick: NT became Windows 2000, and that's where Windows stopped crashing every hour. XP came next, and was where the 2000/NT line entirely superseded the 95/98/Me line, whereupon there was much rejoicing.

Amiga OS, BeOS

And consequently, HaikuOS

Well, Haiku is mostly POSIX, so I'd say it's mostly UNIX. It's more than that however, and the graphical subsystem is awesome. But I'd say it's unix.

Having a POSIX API doesn't imply a UNIX architecture.

ITS is often mentioned and I suppose PR1MOS (which was descended from ITS)

I'm familiar with ITS, but haven't heard this before, and am highly skeptical of any connexion with PRIMOS. The Wikipedia article on PRIMOS says "Legend has it that the unusual choice of FORTRAN for the OS programming language had to do with its history. Allegedly, the founders of Prime had worked for Honeywell on a NASA project. However, Honeywell at that time was uninterested in minicomputers, so they left and founded Prime, taking the code with them." ITS was written at the MIT AI Lab in MIDAS assembly language.

It seems more likely that PRIMOS would have been influenced by Multics.

- Temple OS. Very simple OS but has interesting innovations. http://www.codersnotes.com/notes/a-constructive-look-at-temp...

- Amiga OS / Morph OS

- Menuet OS / Kolibri OS. minimalistic and 100% written in Assembly.

A lot of the Unix Haters Handbook is comparing it to proprietary mainframes of the time.

There are lots of non-Unix operating systems that were never successful. But they are still an important, if forgotten, source of ideas: BeOS, RiscOS, OS/2, Pick Operating System.

Reply on news.ycombinator.com