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

91–100 of 286 posts

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

#91

Post by rswail »

3np wrote: post #69
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.

I don't think either is likely. Linux is embedded into the cloud space and the embedded space.

People have been down the Windows CE and Windows RT rabbit holes before. Windows Nano does nothing there.

In the server space, it's a possibility, but why? Other than running MS specific software, what is the benefit?

On the other hand, even with WSL2, Linux is not going to have it's mythologized "year of the desktop", unless you count Chromebooks. So Windows will maintain its niche there.

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

#92

Post by ubermonkey »

My first corporate job in computing, in 1994, was at TeleCheck. They used an all VMS environment, though by then the machines themselves were about 30% Alphas and not actual Vaxes.

The denial about the platform's future was SUPER strong. TeleCheck IT and software development, at least in those days, was staffed by people who would either move on quickly or stay forever. They mostly hired right out of college, too, so the lifers were people who had never worked anywhere else. (This kind of employment monoculture is pretty destructive, IMO -- get some new ideas in there!)

This created a super weird environment. Everywhere else I worked back in those days was rife with industry publications, curiosity about how other systems worked, excitement about developments in software or networking even if they were on stacks or platforms other than whatever the site used, etc.

Not so there. I think this may have been mostly because to read, say, InfoWorld in 1994 would have made it much harder to avoid how narrow a niche they were occupying. The nature of the systems and software there meant people who stayed were gaining skills not useful anywhere else; pretty much everything (even the database system) was built in-house.

People were out the door constantly, going to other big tech employers in the area to either (a) pick up more marketable skills or (b) pick up a huge bump in pay. That's what I did after 2 years. (Turnover in the dev group was something like 35% a year, which is HELL on institutional knowledge.)

All that said, you could see SOME of the appeal of staying on VMS from their POV. Clustering was a big deal, because downtime cost dollars. File versioning in the OS -- which I still haven't seen implemented the same way anywhere else -- was fucking genius and made rolling back a bad release almost trivial.

But when you decide to ignore where the market is going, and stay on a doomed platform, there are real costs to pay.

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

#93

Post by sirsuki »

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…

> There's never been a standard for naming and abbreviating flags, which means that for EACH program you will have to learn new flags.

How is this different than web pages or GUI apps? Everyone is different and a button that does one thing in one app/page does something different in another.

Have you tried to read GUI help files? They are written for 5 year olds and provide nothing you need as a dedicated user. Have you had to inspect the DOM of a website to try and intuit what something does it does not do?

Least with command line apps usually you have a --help or man page.

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

#94

Post by rswail »

arethuza wrote: post #82
webreac wrote: post #21

Earlier quoted context omitted.

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.

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

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

#95

Post by rswail »

C1sc0cat wrote: post #24
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

DEC documentation was always very good but then it was a product you paid for.

Lots of people paid lots of money to DEC and Sun and HP and IBM and others for Unix as well.

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

#96

Post by sirsuki »

FartyMcFarter wrote: post #84
lioeters wrote: post #76

Earlier quoted context omitted.

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

Is it true to think that because they made some choices early on that those choices forever blemish its value even is said choices are later addressed?

Much of the complaints about checkout have been split to other commands in newer versions. Does this make Git still invalid in your opinion?

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

#97

Post by ubermonkey »

somesortofsystm wrote: post #19

I remain amazed that the #1 shipper of Unix systems today is .. Apple. I grew up on Unix in the 80's, cut my teeth on MIPS RISC/os and then Irix and SunOS and all the joys of the very first days of Linux, oh my .. and I was fully prepared to be an SGI fanboy for the rest of my life - and then, they abandoned Irix and shipped NT. sadface So when the tiBook came out, and it was promised to have a Unix on it, I jumped o…

It's been said pretty often -- and I think it's true -- that the introduction and success of OS X drastically slowed the adoption of Linux as a mainstream desktop option.

I take no position on whether this was good or bad overall; it's just a statement of fact. Lots of us who would've otherwise needed to shift to Linux for LAMP development or whatever after the dot-com crash migrated to the Mac instead, because it meant a unix laptop that Just Works that also allowed us to run native MS Office, etc. That was a powerful value proposition (and remains one).

" the writing is definitely on the wall for us Unix geeks who nevertheless carry a Macbook."

I do not yet see this writing.

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

#98

Post by doublesCs »

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…

> POSIX is a monolith and really deserves to be improved.

Care to explain what's intrinsically wrong with monoliths? I'd have thought that the most important point of a solution is whether or not it solves the problem, not the arhictecture by which it solves the problem.

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

#99

Post by twic »

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…

Some of it is pretty good. But some of it is, or at least was, so legendarily bad that it inspired this:

https://git-man-page-generator.lokaltog.net/

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

#100

Post by tomxor »

FartyMcFarter wrote: post #84
lioeters wrote: post #76

Earlier quoted context omitted.

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

> the user interface is horribly designed

I see this type of remark against git quite often on HN and I think it's exaggerated.

I agree some of the porcelain are misleading and overloaded as convenience functions such as checkout, however a decent chunk of it is inline with the underlying data structure. Nothing is perfect, and git is pretty damn good - horribly designed? no, could do with some breaking porcelain re-writes? sure.

Post reply on HN