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

251–260 of 286 posts

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

#251

Post by dfalzone »

codezero wrote: post #249

This brings back memories (of ten years ago). I worked in astrophysics for a while, and maintained a large codebase that included a ton of Fortran, and had a lot of references to Vax VMS systems within the comments as that's what the team I worked with used mostly through the 80s and early 90s before moving to Linux. One of the things that didn't seem to happen was C - there was some code here and there (I wrote a mo…

Funny, today one of my coworkers was talking about how she used IDL at one of her previous jobs, and later I happened to see this comment. Neat coincidence :)

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

#252

Post by erik_seaberg »

saagarjha wrote: post #202
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…

I like the staging area, though–at any given time I always have code that I do not want to put in a commit object (perhaps I changed some build flags, or my IDE touched some files I don't care for, or…) However, I do agree 100% that all the terminology is pretty bad.

Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.

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

#253

Post by JdeBP »

einpoklum wrote: post #174
SAI_Peregrinus wrote: post #120

Earlier quoted context omitted.

> I then tell them to check with "echo $SHELL" if they're on another system than the one we are working on, and if they don't see "/bin/bash" or "/usr/bin/bash" then they should ask someone for help. Some systems will be weird. EG my default shell is bash, but my interactive shell for all my terminal emulators is fish. So "echo $SHELL" returns "/bin/bash", even from fish. Of course I know this, I set it up this way d…

Hmm... interesting. But - echo $SHELL should tell you what the current shell is, not what the default shell is.

No, It tells you what program image file is going to be used when a program "shells out" or spawns a shell to run a shell command (e.g. via the ! command in mail or the :shell command in nvi).

It is a way for applications to know where the shell to invoke is, not a way for a user to find out what program xe is using to run commands. echo $0 is more informative on that score.

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

#254

Post by 3np »

ThinkBeat wrote: post #198
3np wrote: post #69

Earlier quoted context omitted.

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.

Why would you want that? That is the last thing I want. It is like saying that in ten years we will only have Pepsi Cola. As the only soft drink. You can get Pepsi Cola Mint ,Pepsi Cola Cherry, Pepsi Cola regular etc. But no matter what it will always be Pepsi Cola. I want more, a lot more viable operating systems than we have ow. Now is a sad place to be. Linux was never created to be a modern operating system. Part…

Some that you forget: BSD (Net, Open, Free, Dragon), macOS, OpenVMS, Haiku.

And hey, I’m sure if you work on implementing one maybe others will be interested in writing software for it. And that’s kind of the point, I guess: it’s a huge undertaking with little financial value for a business as opposed to extending on existing work. Standards give us a common language.

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

#255

Post by a1369209993 »

codesections wrote: post #39

> [the name] Grep suggests to me that the author of this one had been reading too much Robert Heinlein (you grok?), or possibly --- and this is in fact quite likely --- was under the influence of psychotropic substances at the time. As funny as this is, the actual origin for "grep" is even more interesting – and, at least to me, quite mnemonic. "grep" comes from ed, and stands for the command "g/re/p", that is global…

Note that it's not "global" or "print" - the commands are the literal single letters "g" and "p".

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

#256

Post by kstrauser »

codesections wrote: post #39

> [the name] Grep suggests to me that the author of this one had been reading too much Robert Heinlein (you grok?), or possibly --- and this is in fact quite likely --- was under the influence of psychotropic substances at the time. As funny as this is, the actual origin for "grep" is even more interesting – and, at least to me, quite mnemonic. "grep" comes from ed, and stands for the command "g/re/p", that is global…

A once asked my then-mentor if it was an abbreviation of "GNU rep". He was highly amused.

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

#257

Post by microtherion »

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…

git has quite extensive documentation, and it is, in principle, really useful. The problem is that it suffers from what Geoffrey Pullum called "Nerdview" " rel="nofollow">https://languagelog.ldc.upenn.edu/nll/?p=276>: It is written from the perspective of the author of the program, rather than the user, and therefore it is easiest to understand if you are already thoroughly familiar with the underlying architecture of git.

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

#258

Post by _emacsomancer_ »

AnIdiotOnTheNet wrote: post #243
_emacsomancer_ wrote: post #230

Earlier quoted context omitted.

Multiple repos using different applications then. And the general proliferation of Appimages, Flatpak, Nix, Guix, Docker containers, and of course local building of software all tell against the "using software from outside the distro's repos is discouraged" representation.

Of those listed, only AppImage is as easy to publish and install as your average Windows software (Flatpak is a not-so-close second with significantly more limitations). And then you get prominent FOSS developers like Drew DeVault saying that those distribution methods are terrible ideas because they are dangerous. The way things work in the Linux Desktop and its community are just not conducive to simply passing aro…

You can make assertions like this if you like, but they're simply untrue. Windows is nightmare to install software on, while on Linux one usually has multiple, easy-to-install-and-keep-updated options (Appimage being the worst choice, because it is the most Windows-distribution-like, and requires the application itself to check for updates etc.).

You can also distribute binaries on Linux easily enough. There's just no general reason to want to do so.

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

#259

Post by a1369209993 »

rswail wrote: post #94
arethuza wrote: post #82

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

> "You can tune a file system, but you cannot tune a fish."

Well of course not; that would be "tunefsh", which no one has gotten around to writing.

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

#260

Post by mimixco »

Torwald wrote: post #226
mimixco wrote: post #185

Unix is the ultimate example of "worse is better." VMS, which is what the article is about, was definitely more elegant, easier to grok, and far better documented. So was IBM's VM which had what we now call "containers" working simply and reliably 30 years ago.

> 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.
Post reply on HN