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

271–280 of 286 posts

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

#271

Post by ninefathom »

Meh... I think the author of this article was cherry-picking a bit. VMS is no cake-walk either, and has its fair share of idiosyncrasies.

So you're a system administrator, and you want to change a user's password?

$ set default sys$system

$ mcr authorize

UAF> modify jimbob /pass="whatever"

UAF> exit

...while on just about any nix, one might simply:

# passwd jimbob

>

For every example of the original author complaining about *nix, I could probably find a counter-example of VMS being awful. Really, I think it reduces down to this: people prefer to stick with what they're used to, and what they were trained on. Anything else is "awful" and "inferior."

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

#272

Post by FartyMcFarter »

icedchai wrote: post #228
kazinator wrote: post #188

Earlier quoted context omitted.

The concept of the git staging area is utterly superfluous. All local changes that are propagated to the version control system should go directly into a durable commit object, and not to a pseudo-commit object that isn't a commit, and that can be casually trashed. That commit object could be pointed at by a separate COMMIT_HEAD pointer. If you have a COMMIT_HEAD different from HEAD, then you have a commit brewing. F…

Git has weird terminology. Though a lot of commercial SCMs are also a bit strange. Example: Perforce which has depots and shelves. At least with git, I can create a branch without waiting 2 weeks for the IT department.

Perforce shelves make total sense. "Shelving" something means literally what the command does - setting them aside and saving them.

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

#273

Post by michaelcampbell »

mimixco wrote: post #260
Torwald wrote: post #226

Earlier quoted context omitted.

> VMS was definitely more elegant Please, can you offer an example for this?

After 30 years away from it, I can't. But others have echoed my comments. Perhaps Bitsavers has some VMS doc. One thing was clear: you could learn VMS from the manuals. That wasn't the case with any Unix manuals I've ever seen.

> One thing was clear: you could learn VMS from the manuals.

Is that a defining characteristic of "elegance"? So far from the threads here all I've come away with is that VMS was easier to learn and/or had better docs, not that it was necessarily any better at actually performing work.

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

#274

Post by scroot »

rbanffy wrote: post #179
scroot wrote: post #118

> One can only conclude that the makers of Unix held, and still hold, the ordinary computer user in total contempt, and this viewpoint seems to me to be mirrored in the attitudes of the people who are inflicting this awful system on the rest of us. Does Unix's enormously steep learning curve have any function other than to deter the faint-hearted, those who may want to use computers without necessarily dedicating the…

> but it's likely that the unixification of computing has contributed to this divide. It took a long time until a meaningful part of humanity got access to computers. The fraction that had access to timeshared machines via serial terminals was tiny. In the age of the PET, the Apple II, the C64, it was usual to boot up your home computer and be greeted by a BASIC prompt (REPL, if you allow me). It was an immediate int…

I'm with you, but want to add that this transition isn't the fault of GUIs. The group at PARC that invented the GUI that everyone else commercialized had invented the GUI equivalent of "booting into a BASIC" -- Smalltalk.

Which brings me to another point: this divide has gone hand in hand with the idea that parts of a computing system should be universally swappable. But that prevents any "holistic" nature to a computing system, and therefore we get caught up in the idea of individual languages rather than environment and how everything works together.

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

#275

Post by jiggawatts »

enriquto wrote: post #242
Arnavion wrote: post #235

Earlier quoted context omitted.

It's exactly the same for PS. Just as you have to look at a text output of a unix command to figure out how to parse it and extract the subset of information you need from it, so do you have to look at the help metadata of a PS command to figure out how to extract the subset of information you need from its output. The advantage of having objects instead of text is that if you thought you could parse the filename of…

Thanks for your answer, and I see where you are coming from. But your unix is not the same as my unix. For me, unix means programs that can be easily written using only the getchar and putchar functions. If you have "types" and whatnot, it's not unix.

It's not often you hear someone criticise a tool for not having enough unnecessary encoding and parsing steps involved.

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

#276

Post by icedchai »

FartyMcFarter wrote: post #272
icedchai wrote: post #228

Earlier quoted context omitted.

Git has weird terminology. Though a lot of commercial SCMs are also a bit strange. Example: Perforce which has depots and shelves. At least with git, I can create a branch without waiting 2 weeks for the IT department.

Perforce shelves make total sense. "Shelving" something means literally what the command does - setting them aside and saving them.

It “sort of” makes sense. When a company shelves a movie, they’re probably never finishing it. When I shelve my code, I’m probably coming back to it at some point soon. For example, I worked at a place that would have everyone “shelve” all their code before code review. In that context it didn’t make sense to me.

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

#277

Post by enriquto »

jiggawatts wrote: post #275
enriquto wrote: post #242

Earlier quoted context omitted.

Thanks for your answer, and I see where you are coming from. But your unix is not the same as my unix. For me, unix means programs that can be easily written using only the getchar and putchar functions. If you have "types" and whatnot, it's not unix.

It's not often you hear someone criticise a tool for not having enough unnecessary encoding and parsing steps involved.

Are you talking about people who promote JSON-RPC and whatnot? Sure, they are nuts, but what does it have to do with unix?

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

#278

Post by mimixco »

michaelcampbell wrote: post #273
mimixco wrote: post #260

Earlier quoted context omitted.

After 30 years away from it, I can't. But others have echoed my comments. Perhaps Bitsavers has some VMS doc. One thing was clear: you could learn VMS from the manuals. That wasn't the case with any Unix manuals I've ever seen.

> One thing was clear: you could learn VMS from the manuals. Is that a defining characteristic of "elegance"? So far from the threads here all I've come away with is that VMS was easier to learn and/or had better docs, not that it was necessarily any better at actually performing work.

Turing proved that the only difference between any two computers is how easy they are to program and how fast they run. All computers are functionality equivalent in that every computer that can be made can solve all the same problems as any other computer which has ever (or can ever) be made.

So, in that sense, yes. VMS was more elegant than Unix because its design, syntax, and documentation made it easier and faster for users to grok and complete their tasks. As far as how fast or well the programs run, that's all about implementation details.

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

#279

Post by mcswell »

I started at a company in 1984 where VMS was pretty standard, running on 80x25 terminals. (They also had Xerox Stars, some people ran 1980s-era Macs, and there were a few LISP machines.)

Then someone introduced me to a sort of minimal unix that was running on top of VMS. Although I had never seen Unix before then, I immediately saw the advantages and switched over. If I had to do something on VMS, it was painful.

Later the company got first generation Sun workstations, running unix on metal, with large (for the time) graphic displays. SO advanced...and so much fun (except when I had to do stuff in C--mainly our team used LISP or Prolog). Eventually we even got an ARPAnet connection. But I digress.

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

#280

Post by fouc »

411111111111111 wrote: post #72
fouc wrote: post #54

Earlier quoted context omitted.

It's depressing to think that the Cambrian explosion that lead to a variety of hardware, software, operating systems, and web browsers and great freedom and power for the end user is gradually getting culled and turning into a monoculture of walled gardens and the end users are just getting screwed.

Linux is considered a walled garden? Really? I mean yeah, there were more operating systems before, some of which were open.. but I'm not convinced it's necessarily bad to have one open system win. If it didn't, I'm pretty sure there would be a lot more people using windows servers, which I think would've been far worse for the open community.

To be clear I wasn't calling Linux a walled garden. But I was talking about overall trends. For example, there some are efforts to push Linux in this direction, most recently with some centralized app/package store.

Also Linux Foundation was setup and is funded by big corporations like Microsoft, Google, etc in order to find ways to exert influence over Linux's growth.

Post reply on HN