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

61–70 of 286 posts

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

#61

Post by yrro »

reagent_finder wrote: post #34
madhadron wrote: post #5

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.

In a normal sized terminal the most useful part is pushed away by the list of built-in commands. IMO it should be printed last, so that it's guaranteed to be displayer to a user who doesn't know how to scroll up:

    GNU bash, version 5.0.18(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

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

#62

Post by TheOtherHobbes »

m463 wrote: post #4
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…

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

Unix was "designed" by hyperactive comedy racoons with ADHD. There's no reason - beyond lack of attention span and professionalism - why basic features and expectations couldn't have been standardised. But the Unix way is to get something sort of working without paying much attention to what other people are doing, lose interest in it, and move on.

Or to hammer away at something for decades adding more and more obscure edge case config options in a text file, all of which need to be set carefully because otherwise the application fails - probably silently, maybe leaving a log message somewhere completely unexpected - and most of which are irrelevant to 90% of users who just want Something That Works.

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

#63

Post by fouc »

tromp wrote: post #49

> There is no effective way to find out how to use Unix, other than sitting next to an adept and asking for help That's a rather unfair claim. Hundreds of books and tutorials have been written to introduce people to Unix...

You're kind of making the article's point. What's the need for hundreds of books and tutorials if the system doesn't provide access to great documentation with just a "help" command?

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

#65

Post by wizzwizz4 »

cheph wrote: post #27

> Unix and C however form a powerful deterrent to the average astronomer to write her or his own code (and the average astronomer's C is much, much worse than his Fortran used to be). Compared to what? If I want to quickly bang out some code and run it, installing fedora (or another distro) is probbably the least painful way to get it done. I would say that Windows is a powerful deterrent to the average person writin…

This is about Unix v.s. VMS, not Windows v.s. Linux.

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

#66

Post by normanmatrix »

I have a feeling that Windows Nano Server w/ Powershell + .NET Core might make this text relevant again soon. Having a consistent OS that scales from containers to servers and desktop is a big benefit in corporate. Now if it matched performance of an Alpine, played well with WSL, and Microsoft would manage to push the major open source stuff for compatibility. I'd give Linux 5 years. But only time will tell..

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

#67

Post by jstimpfle »

arexxbifs wrote: post #53
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…

Completely agree. One of the problems is of course the freedom of choice a Unix system gives you. Instead of a single shell with a single set of commands, people can pick and mix. For beginners it's a nightmare but for power users it's, in general, very empowering. Getting help on Unix commands, particularly in Linux, has always been a mess. On most Linux distros, typing "help" will give you help about the shell buil…

I didn't find it that hard. Just realize the different backgrounds and cultures that all these projects originate from. They all have their own ways of doing it.

man pages work pretty well for a lot of stuff that is POSIX. C interfaces and basic CLI programs you'll all find documented in man (with documentation beyond what is specified in POSIX).

The GNU folks have tried to push their info system, so maybe you'll find more details there for their commands. I guess most people use man because it's quick to access and a single page is easy to grep through. If that doesn't help, I'll just do a web search.

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

#68

Post by 3np »

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…

One of my pet-peeves on a similar note is the inconsistencies between different ssh commands on if it's -p or -P that signifies the target port.

Apart from the obvious compatibility and legacy factor, I think a major reason is that by the time someone has both enough knowledge and experience to formulate a proper solution and have felt the pain-points, they're already deep enough that they've internalized that this is The Way It Is and are somewhat comfortable with it, those annoying flags aside.

We tend to settle on the lowest common denominator, because consistency and time-to-ready trumps any actual improvements. For example, I'd so much prefer vim bindings in tmux but stopped using customizations like that completely since it turns out it's less of a hassle to just get used to the crappy standard ones instead of customizing it on every new host I start up.

If you can't get your friends off Facebook, good luck getting engineers off POSIX.

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

#69

Post by 3np »

normanmatrix wrote: post #66

I have a feeling that Windows Nano Server w/ Powershell + .NET Core might make this text relevant again soon. Having a consistent OS that scales from containers to servers and desktop is a big benefit in corporate. Now if it matched performance of an Alpine, played well with WSL, and Microsoft would manage to push the major open source stuff for compatibility. I'd give Linux 5 years. But only time will tell..

I really, really hope that you're wrong.

I optimistically hope a not-too-future (within 10y?) major version update of Windows is in reality a *nix distribution. As long as they can keep runtime compatibility with older versions of Windows software, I think it'd be a big win for Microsoft for various reasons.

The only real challenge would be to get driver vendors in line.

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

#70

Post by Macha »

xioxox wrote: post #64
lixtra wrote: post #8

The last modified header suggests (2000) Last-Modified: Fri, 08 Dec 2000 14:02:09 GMT

The letter is from 1994. See Starlink Bulletin #13, pg : http://starlink.eao.hawaii.edu/starlink/Bulletins

It also mentions 1969 as being 25 years prior.

Which also makes this article closer to 1969 than the present day.

Post reply on HN