Live data from Hacker News

A Requiem for a Dying Operating System (1994)

user.eng.umd.edu

161–170 of 286 posts

Re: A Requiem for a Dying Operating System (1994)

#161
post #119

Earlier quoted context omitted.

Why so? Imagine the WSL will eventually molding into an LSW. The end-user experience needn't be affected apart from the more technical power-users.

Because frankly I think the Linux Desktop as it exists is incompatible with a good personal computing platform. I have rambled on at quite some length about this elsewhere on HN. Were Windows to become just another cobbled-together leaky abstraction of a desktop on top of Linux, it would suffer from all of the same problems.

How much have you worked directly with the WinAPIs? Because oh lord.

I imagine it'd be more holistic and maybe not so similar to current desktop distros. No X11 for sure, but not sure if it'd even be wayland.

May not even be Linux - BSD seems more likely of the two, especially considering licenses. Remember that Apple did the same transition with OS X (which has roots in BSD).

Re: A Requiem for a Dying Operating System (1994)

#162
VMS had the "sound the fire alarm and leave the building" attitude towards exceptional events that Windows NT has. That's why you used to see the "Blue Screen of Death" on Windows all the time, but they changed it in the early days of Win 8, when they realized you were violating the human rights of tablet users, even laptop users, and suddenly changed it so the system would reboot, reopen your windows, and pretend it didn't happen.

The flip side is UNIX which tries to pretend things are OK even when they are strange. For instance, you might fill the disk with a log file, then 'rm' the log file and note that the disk is still full. The file is still taking up space on the disk, even though it is invisible. The space isn't released until that process closes the file or gets killed.

Contrast that to VMS which, given an impossible situation, will do nothing. (as in "not do anything") Recovering from a "full disk" on UNIX is usually routine, but on VMS you will probably be recovering from tape or calling the factory for support.

This guy

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

(the year after that album was released) got mad because a midwestern state university student had a "non-traditional" student spamming hundreds of USENET newsgroups. The university couldn't throttle the spammer because he'd had already won a "free speech" lawsuit against the university newspaper.

The antagonist saw this as an existential threat to the net one Friday night and went Ender Wiggen on his ass.

He thought he'd fill the disk quota on the spammer's account on the VAX/VMS system so the spammer couldn't log in and delete his received email -- an excellent implementation of quotas meant you could usually get the victim running to 'mommy' (the sysadmin) for help.

The antagonist used ftp-to-email gateway servers to vastly amplify the attack and confuse people about the origin. At the last minute he found a way to get the ftp-to-email gateway servers to send email commands to each other in a cascading way.

The target campus went down in about 30 minutes, and, logged into the VT-100 terminal in his dorm room, the antagonist realized that he'd miscalculated and the attack was possibly 20,000 times larger than planned.

The target campus didn't come back until Tuesday evening, probably the disk was full for the whole VMS Cluster.

The spam stopped. They never proved anything, but a few days they shoved an empty SUNtape into the antagonist's hand that allegedly held the files from his account at his campus central computer center account -- just "being a jackass on social media" was a good enough reason.

About a decade after that incident, I had "the same thing" happen to an email server running Linux on this box

https://en.wikipedia.org/wiki/Cobalt_Qube

during the 'Love Letter' virus crisis. I had email accounts getting millions of emails a day on that badly underpowered machine, a beta-test model with a 2% slow real-time clock.

In 15 minutes I had the email server shut down, the disk full condition cleared, logs working correctly again.

I brought up qmail and did not like what I saw in "top" so I shut it down. I wrote a uniq|bash|awk script that picked out virus-sending ip addresses from the logs and piped the bash script into bash to block them at the firewall.

I brought qmail up and it was good, good enough to go to bed. By the next morning the viral load was serious so I automated the firewall script, installed an anti-virus scanner, etc.

In wartime, VAX/VMS gives up the fight but UNIX soldiers on.

Re: A Requiem for a Dying Operating System (1994)

#163
post #14

Earlier quoted context omitted.

The back story to this is that the DIGITAL Command Language (more or less the equivalent of an Unix shell), with its excellent filesystem-level features and the environment around it (e.g. the well-written and extremely thorough documentation) was very much light-years ahead of anything you could get on most Unix environments at the time. Going back to the Unix shell felt a bit like a step back. FWIW, there are plent…

Ah yes! Documentation for VMS and the whole shebang of layered products. Until this day, in my book, the absolute gold standard when it comes to documentation. Having the arguably best tools suite to develop (LSE, Debugger, what have you) also didn't hurt. I still believe it the best operating system I ever worked with. Ironically the article describes quite precisely why DEC failed. Most of the company had a viscera…

>Most of the company had a visceral hate of anything Unix and anybody involved with anything that even smelled faintly of Unix was a second class citizen.

Reminds me of ye olde UNIX-Hater's Handbook[0]

0:http://web.mit.edu/~simsong/www/ugh.pdf

Re: A Requiem for a Dying Operating System (1994)

#164
post #138

> Unix seems to consist largely of arcanae which be learnt only by taking instruction direct from a priesthood who seem largely to be stuck in the anal-retentive stage. Tell that to linux nerds who encourage people on forums to install arch from scratch if they want to learn about how computers work.

> install arch from scratch if they want to learn about how computers work

15 years ago it was "install gentoo to learn how computers work" but all it really teaches you is how the gentoo/arch install procedure works, or, more likely, how to type in commands from a HOWTO one after another.

Re: A Requiem for a Dying Operating System (1994)

#165

Earlier quoted context omitted.

> but largely (functionally) indistinguishable from a UNIX machine when accessing it via teletype (glass or otherwise). I disagree. I first sat down at a VMS terminal in a library in North Carolina when the OPAC broke and dropped me back to a prompt. I knew Linux passably well at that point but had never used VMS before. I typed ls, tried dir, that worked, and finally tried help. In half an hour I was investigating t…

I just tried 'help' on a linux system. It is absolute garbage.

One of my first tasks as a systems programmer for the Schlumberger corporation in 1986 was to rewrite the VMS help command for use on SunOS. As it turns out, my rewritten version ran nearly twice as fast as the VMS version on VMS.

That design (a nested heirarchy of help topics/subtopics, with some navigation hacks to make getting around easier) was quite good.

But then came hypertext in the form of the web, and at that point, the "help" command just looks like crap.

Re: A Requiem for a Dying Operating System (1994)

#166

Earlier quoted context omitted.

I just tried 'help' on a linux system. It is absolute garbage.

That's because 'help' on most Linux-based systems is actually a shell builtin which explains other shell builtin commands. This, in turn, is related to the fact that Linux-based systems are flexible - you could use a totally different shell which does not even have the _help_ builtin - while VMS was a comprehensive single-sourced top-down controlled system. Both have their strengths and weaknesses, the fact that you…

help on VMS wasn't a builtin. It was a system-provided program, with data files that could be accessed via other software.

Re: A Requiem for a Dying Operating System (1994)

#167
post #4

Earlier quoted context omitted.

> largely (functionally) indistinguishable from a UNIX machine Although they were functionally similar, there were some practical considerations... I will say that path names in unix were a simple and elegant , compared to what VMS used. I recall VMS paths were something like [foo.bar.bletch]something.txt At the time this was a little cumbersome, but looking back it is much worse.

That's a cosmetic difference. The real difference is when you try to work out whether your binaries are (supposed to be) in /bin, /usr/local/bin, /sbin, etc, whether settings for a specific application and/or daemon are in $config or $.cfg or $.conf or $.cf or $d_config or .ssh and .bshrc in your personal directory, and where your web server and mail logs are. Because they might be in /var/log - or equally they might…

And then there was DECnet ....

Re: A Requiem for a Dying Operating System (1994)

#168
post #4

Earlier quoted context omitted.

> largely (functionally) indistinguishable from a UNIX machine Although they were functionally similar, there were some practical considerations... I will say that path names in unix were a simple and elegant , compared to what VMS used. I recall VMS paths were something like [foo.bar.bletch]something.txt At the time this was a little cumbersome, but looking back it is much worse.

That's a cosmetic difference. The real difference is when you try to work out whether your binaries are (supposed to be) in /bin, /usr/local/bin, /sbin, etc, whether settings for a specific application and/or daemon are in $config or $.cfg or $.conf or $.cf or $d_config or .ssh and .bshrc in your personal directory, and where your web server and mail logs are. Because they might be in /var/log - or equally they might…

It's not a cosmetic difference. Unix has a single-rooted filesystem. VMS did not (like DOS). That doesn't invalidate your complaints about file naming and location, but it isn't a cosmetic difference.

Re: A Requiem for a Dying Operating System (1994)

#169
post #94

Earlier quoted context omitted.

I remember getting new Sun workstations at that time and part of the fun of getting new Suns was taking the boxes of printed documentation that came with them and slotting them into the supplied ring folders. Later on they would ship the Adobe red/blue/green PostScript books with OpenWindows.

A full set of Vax documentation was at least the size of the Vax. I still have my 3 volume copy of HPUX's man page. Including the famous bug for tunefs which is still current in FreeBSD (talk about slack in addressing the real issues!): "You can tune a file system, but you cannot tune a fish." https://www.freebsd.org/cgi/man.cgi?query=tunefs&sektion=8#e...

The docset was large, but it was not as large as a VAX.

I had to learn VMS in a hurry in the last two months of 1986. I had the full binder set on a shelf in my toilet (Cambridge, UK). You could not have put a VAX in there :)

Re: A Requiem for a Dying Operating System (1994)

#170

"Anyway, have you ever tried to use man? It's fine as long as you know what you are looking for. How would you ever find out the name of command given just the function you wanted to execute? You can't. " One of my gripes with UNIX systems is how opaque they are

PowerShell takes the UNIX philosophy, cranks it up to 11, and makes commands trivially discoverable.

There are things that powershell does well, but I wouldn't say that it's really all that unixey. It relies far too heavily for the user to have an understanding of the windows object model, which frankly a lot of sysadmins don't have and refuse to learn. In unices the pipeline is just that, a way to send a stream of bytes from one place to another. In pwsh it's more complicated than that since it passes an object along with the preceding command's metadata.

In my personal experience, powershell is fantastic for writing scripts and tooling, but not really so great for actual use as a shell. What makes a good shell is speed and 'muscle memory', imo.

Post reply on HN