Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Requiem for a Dying Operating System (1994)

user.eng.umd.edu

Post reply on HN
Print view View original

81–90 of 286 posts

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

#81

Post by enriquto »

reagent_finder wrote: post #44

Pretty much each point raised in this post(?) are correct, current and relevant even 26 years later. POSIX is a monolith and really deserves to be improved. It's been around forever, yes. It will probably keep on being around forever, yes. Take the tar command (please!), which is already a nightmare where lower-case `a' means "check first" and upper-case `A' means "delete all my disk files without asking" (or somethi…

> I have honestly no idea how to even start fixing the problem. A proper documentation system would be a start.

Have you ever heard about OpenBSD?

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

#82

Post by arethuza »

webreac wrote: post #21
lalalandland wrote: post #9

"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

I have learned unix with sunOs in 1990. Man pages were excellent. The first command I learned was "man man". There was a paper version of the man pages available in the computer room (among many other sun documentations). I became pissed by man pages only when I switched to linux. At that time, I have discovered the crypt(3) command by looking at the index of man pages. One week later, I had cracked 10% of passwords…

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.

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

#83

Post by enriquto »

jiggawatts wrote: post #35
lalalandland wrote: post #9

"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.

No, it doesn't. Get out.

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

#84

Post by FartyMcFarter »

lioeters wrote: post #76
reagent_finder wrote: post #44

Pretty much each point raised in this post(?) are correct, current and relevant even 26 years later. POSIX is a monolith and really deserves to be improved. It's been around forever, yes. It will probably keep on being around forever, yes. Take the tar command (please!), which is already a nightmare where lower-case `a' means "check first" and upper-case `A' means "delete all my disk files without asking" (or somethi…

> Have you ever tried to read git documentation? It is the most useless godawful piece of nonsense I ran "man git" for the first time ever. https://www.man7.org/linux/man-pages/man1/git.1.html Heey, that's actually pretty good! I don't think it's "godawful". In the second sentence it recommends starting with gittutorial and giteveryday, for a "useful minimum set of commands". https://www.man7.org/linux/man-pages/man7…

The issue with git is that no matter how well documented, the user interface is horribly designed. For starters, how many different things does "git checkout" do, and how many of them actually reflect an intuitive meaning of "checking out" ?

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

#85

Post by Symmetry »

arexxbifs wrote: post #77
IggleSniggle wrote: post #75

Earlier quoted context omitted.

Been using “man” for years, understand it’s section system and have made a few man pages for various utility programs I’ve made. The man page for built-ins is never the quick reference I want, so I generally end up falling back to google for that stuff rather than try and figure out where it’s documented. Anyway, TIL “help” is a command I can try. I haven’t used it in awhile, but “cht.sh” is basically what I expect “…

I think the availability of "help" depends on what shell you're using. It's a builtin in bash.

In fish it launches a help web page if you're in a graphical session (but still has a fallback without).

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

#86

Post by lc9er »

rcarmo wrote: post #2

We had to use VAX/VMS when I was a freshman, decades ago. The “Computer Center” had dozens of VT220s hooked up to it via serial “hubs” in the main building basement (the very stereotype of a nerd dungeon). It wasn’t half bad. As multi-user systems went, it was actually quite good and we ran a number of projects on it before moving off to PCs, Sun Workstations and Linux in general. I remember all the staples of the er…

My freshman exposure to VMS was for an assembly class. The course also seemed to double as a history of computing. This was back in the early 00’s, for reference.

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

#88

Post by gooseyard »

I was getting started in the field right around the time this was written, attending college (and later being employed) at a university that was an all-DEC shop. I wound up being introduced to VMS and Unix at the same time. I greatly preferred Unix at the time, but looking back on it, it was for a completely different set of reasons than I would apply now.

The biggest was that I wanted a machine of my own to work on, not just a shell account on a big Vax with a tiny quota. The price of the lowest-end, used machine with a hope of running vms at a decent clip was astronomical, upgrades were proprietary and expensive. I think the machine in my office at the time came with a perpetual single user vms license, but if I wanted to create shell accounts for my friends, buying license paks was also quite expensive.

If I wanted to, say, run irc on the vaxstation, instead of the handful of popular clients that one could build on Ultrix, there was a single vms port, and to build it would require licensing a compiler. Downloading the source would require buying the tcp/ip module license as it would be years before that was bundled in.

So if I ditched the Vaxstation and got one of the MIPS based DEC pizza boxes, I could put Ultrix on it and at least get the GNU toolchain installed and be able to build and run a bunch of the software I wanted. My older colleagues who preferred working with VMS would spend weeks attempting to port some popular utility to VMS, which seemed goofy to me at the time.

Within a couple of years 386BSD and Linux came along, and my plan to save up the 5kUSD or so to buy my own DECStation quickly vaporized when I saw that pretty much everything I wanted to run on Ultrix would build on Linux, so I certainly had no more interest in VMS after that.

Now a couple of decades later, I sometimes think about the things that I desperately miss about products like VMS. The expansive, exhaustive documentation. The robustness of the systems in production, the great interoperability between the various compilers.

We also got pretty amazing support from DEC, but the amount of money that we paid for all those things was breathtaking. If you were using custom software for critical businesses or processes, it was not a terrible arrangement, but if you wanted to stick an email server in the closet of your small business and you weren't already a fan of VMS, it would have seemed crazy to choose one of those boxes. They were very much a premium product in a space where developers with DIY tendencies where suddenly being presented with heaps of cheaper choices, even if they weren't as reliable or well-documented.

I'm very curious to see what becomes of the x86_64 port; now that I'm a little older, more patient, and have a few bits of software that I'd like to stay running all the time, it might be nice to have the option. I think I even remember enough DCL to get around :)

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

#89

Post by ptero »

Those articles from mid-1990s are great to read; they are both funny and informative. Even as many of the points they make are still valid today, even more valuable is the ability to look at succeesses or failures with 20+ years of hindsight.

I feel the pain of the user in this particular case. But I also understand the frustration of the people who wanted to write their own smaller programs with less restrictions than the well architected but highly constrained VMS architecture. And ignoring such users can topple a better technology. That is why (a technically horrible) DOS spread like wildfire on personal computers, super unreliable Windows (Win 95 had to be rebooted daily) killed a much more robust OS-2, etc.

We can call such users who want capabilities quickly, even if they are not fully reliable "ignorant lemmings" or whatever, but ignoring them when a competitor does not is very risky. My 2c.

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

#90

Post by imglorp »

imglorp wrote: post #33
somesortofsystm wrote: post #22

Earlier quoted context omitted.

man -k "key words of the thing i'm searching for" ^^ also works fine ..

Finding man, cold from a prompt, is hard. If you type help, even today, you might get the shell one which doesn't take you there. Ditto info.

Oops, looks like Bash at least accounted for this case. Really, I think you want to route new user to "man intro" first, if they just asked for help.

    $ help
    GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
    These shell commands are defined internally.  Type `help' to see this list.
    Type `help name' to find out more about the function `name'.
    Use `info bash' to find out more about the shell in general.
    Use `man -k' or `info' to find out more about commands not in this list.
Post reply on HN