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

201–210 of 286 posts

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

#201

Post by pjmlp »

imglorp wrote: post #193
pjmlp wrote: post #29

Earlier quoted context omitted.

Well, that is the only reason why UNIX won and we got stuck with C, it is hard to win against free beer with source code available. The prices that Bell Labs was allowed to charge for symbolic UNIX licenses were a gift, when compared against traditional commercial OS prices in the 70's.

One more advantage was that C and UNIX were designed for portability. They started on PDP-7 and spread onwards from there. VMS was designed to sell mainframes so your choices were limited outside of that until the pedestal and workstation market arose around 88 (Alpha), MicroVAX, etc. Even then it was only DEC hardware. That's how you kill an OS.

There were already portable systems outside Bell Labs back then, and anyone that has written UNIX software knows how "portable" C actually was back then.

Had UNIX been sold with a price tag similar to VMS, without source available for universities to play around, and it would have been long dead by now.

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

#202

Post by saagarjha »

kazinator wrote: post #188
masklinn wrote: post #177

Earlier quoted context omitted.

The git UI is absolutely horribly designed, as demonstrated by the mercurial or darcs UIs which, while completely different, were significantly easier to discover, intuit and remember. > git is pretty damn good UI-wise, it really is not.

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.

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

#203

Post by WorldMaker »

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

In recent versions of git (since 2.23) the two main `git checkout` functions have been split into two newly supported dedicated commands: `git switch` and `git restore`.

Of course the next step is unlearning `git checkout` muscle memory and moving to using `git switch` and `git restore` more regularly.

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

#204

Post by GeorgeTirebiter »

kazinator wrote: post #188
masklinn wrote: post #177

Earlier quoted context omitted.

The git UI is absolutely horribly designed, as demonstrated by the mercurial or darcs UIs which, while completely different, were significantly easier to discover, intuit and remember. > git is pretty damn good UI-wise, it really is not.

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…

Check out: https://gitless.com/

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

#205

Post by Animats »

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

Some time ago, some UI designer asked, on HN, for what open source program should they build a UI to establish their reputation. I suggested "git". That was rejected as too hard. They just wanted to put eye candy on a command, not have to rethink its relationship with the user.

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

#206

Post by WorldMaker »

OldHand2018 wrote: post #143
folbec wrote: post #56

Earlier quoted context omitted.

The 4 things I love most in Powershell, from the point of view of a maintainer of scripts, is the relative verbosity of commands (at least I don't have to go hunting for obscure acronyms, or recursive puns such as yacc, when I read code), auto-completion an auto-documentation of scripts (when I have to change something), and object pipe (as a maintainer I hate awk and regular expressions in general). Only defect is t…

You know, it's funny, the topic in this article is the forced abandonment of VMS. Microsoft at one time had a video interview on their "Virtual Academy" with one of the PowerShell creators, and he talks about how they kept trying to create a "unixy" tool for managing Windows machines, and it never felt or worked right. So then they looked at VMS and realized it was the perfect inspiration. Most of what you love about…

Which also shouldn't be surprising given VMS also had a huge inspiration (and some key figures) on early NT Kernel development. In some ways modern Windows is "son of VMS".

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

#207

Post by laksdjfkasljdf »

dhosek wrote: post #171

I really miss VMS. Adding a command wasn't just simply a matter of throwing an executable on the path, it had to be declared, with two options: One was to declare a command that had its own argument parsing or the better option, there was a way of doing external configuration of the arguments using (iirc) a .cld file which provided a way of specifying all the arguments and options for the command in a straightforward…

never understood why so many people complain about the short commands, but nobody contributes a central list of aliases with verbose names to them.

alias copy_files_from_one_place_to_another=cp

this tells me short names aren't a problem to begin with. And everyone would have the same discoverability problems with longer ones.

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

#208

Post by rdhatt »

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.

Funny enough given the linked post - Powershell owes it philosophy to VMS as well, e.g. the verb-noun command structure.

https://devblogs.microsoft.com/powershell/verb-noun-vs-noun-...

https://ilovepowershell.com/2013/08/05/microsoft-virtual-aca...

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

#209

Post by AnIdiotOnTheNet »

3np wrote: post #161
AnIdiotOnTheNet wrote: post #124

Earlier quoted context omitted.

Because frankly I think the Linux Desktop as it exists is incompatible with a good personal computing platform. I have rambled on at quite some length about this elsewhere on HN. Were Windows to become just another cobbled-together leaky abstraction of a desktop on top of Linux, it would suffer from all of the same problems.

How much have you worked directly with the WinAPIs? Because oh lord. I imagine it'd be more holistic and maybe not so similar to current desktop distros. No X11 for sure, but not sure if it'd even be wayland. May not even be Linux - BSD seems more likely of the two, especially considering licenses. Remember that Apple did the same transition with OS X (which has roots in BSD).

> How much have you worked directly with the WinAPIs? Because oh lord.

What does that have to do with anything? Yeah, they're often anachronistic, but that's to be expected of something with over 2 decades of ABI compatibility.

> No X11 for sure, but not sure if it'd even be wayland.

WDDM and DWM have supported features for over a decade that Wayland still doesn't support.

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

#210

Post by cogman10 »

doublesCs wrote: post #98
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.

I'm not sure it is a monolith. It is a set of standards and that's about it.

But, as far as "what's wrong with monoliths" the biggest issue, IMO, is security. The more code you have, the more likely you are to run into security issues. By their nature, most security problems end up granting all access that a given program has. A monolith, by it's nature, usually has a LOT of permissions and a LOT of code.

Of course, this only matters when security matters. If you are making an app that isn't exposed to the internet then by all means make it a monolith. Otherwise, the best thing you can do for security's sake is to push for microservices with as limited a permission set as possible. That makes it so the exposed surface area is relatively small if any one microservice is compromised. (It's about risk management).

This is also why microkernels are so interesting to me. It's the same problem, a compromised kernel driver can do a whole lot of damage. So how do you solve that? By keeping the "root" kernel at a bare minimum and force drivers to run in user space as much as possible. That keeps drivers with security holes from giving an attacker full system control.

Post reply on HN