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

221–230 of 286 posts

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

#221

Post by barbarbar »

Animats wrote: post #205
FartyMcFarter wrote: post #84

Earlier quoted context omitted.

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.

It was very good idea. Though perhaps establish reputation is probably not a good starting point.

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

#222

Post by rbanffy »

reallydontask wrote: post #219
rbanffy wrote: post #216

Earlier quoted context omitted.

> 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) "yacc" is not a command. It's an executable file that's read and executed. In fact, most of the things in a shell script are not commands, but files that are loaded and executed. If someone built a shell with everything built in it'd be a bloated monster full of inconsisten…

> Maybe for Windows transplants. In general, not at all. care to elaborate In my experience, Powershell is so much nicer than bash that even on my work mac I tend to use it when doing stuff for me (not going to force it on my team)

Powershell originated on Windows and garnered a fan base on the platform. It's not much appreciated outside that niche and most people who like it are people who use or used it on Windows.

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

#223

Post by cxr »

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.

The sin of Git's staging area is that Git forces it into the default interaction path—requiring you to take it into consideration whether or not you're interested in only committing some of the changes. Git should default to including all changes, and iff you direct it to (i.e. by explicitly specifying `git add`) should you have to take into consideration the notion that some changes are staged and others aren't.

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

#224

Post by bregma »

alxlaz wrote: post #14
thenoblesunfish wrote: post #7

The complaints here don't seem to be much about how Unix works in a deep way, but rather the particular language/syntax which is used to interact with it ("rm", etc.). While that's certainly annoying in many ways, so are almost all languages in common use. You could write a lot about how horrible English is (or German, as Mark Twain famously did). But English is a useful standard - politics, inertia, and the value of…

The back story to this is that the DIGITAL Command Language (more or less the equivalent of an Unix shell), with its excellent filesystem-level features and the environment around it (e.g. the well-written and extremely thorough documentation) was very much light-years ahead of anything you could get on most Unix environments at the time. Going back to the Unix shell felt a bit like a step back. FWIW, there are plent…

DCL was so much better than MCR. In DCL I could use "DELETE sys$home:* .* ;* " but with MCR I had to resort to "PIP/DELE [7,1]* .* ; * " DEC just kept evolving for the better.

Of course, sh was just "rm -rf * .??*" and that is so much more discoverable because nothings says "delete all your files" more than some line noise.

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

#225

Post by throw0101a »

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…

> Completely agree. One of the problems is of course the freedom of choice a Unix system gives you.

This is because Unix (or large parts of the environment) evolved over time rather than being designed at the beginning.

We started with the Bourne shell, then got the C shell, with the Korn shell splitting the difference between the two. Bash then came along taking lessons from each of those three, and then Z shell.

That's a few decades' worth of changes.

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

#226

Post by Torwald »

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?

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

#227

Post by cxr »

Animats wrote: post #205
FartyMcFarter wrote: post #84

Earlier quoted context omitted.

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.

A few years back, a designer waded into the middle of the echochamber on some HN thread about inculcating people from other disciplines. They wrote that "as a designer" they did not consider Git (GitHub?) to be thoughtfully put together or well-suited for the kind of work they do or something like that. It was a short comment, about as long as that, and there was no flaw or faux pas or even anything incendiary about it. HN wasn't having it, though, and downvoted it mercilessly. (There were no responses to say why it had been downvoted; the subthread dead-ended there.) It's things like this that remind me of the now-infamous comment in the Dropbox thread.

I didn't think at the time to bookmark it with my "hn sucks" tag, and over the past year or two, I've tried several times to find it again, for reasons similar to[1], but I've been unable to.

1. https://news.ycombinator.com/item?id=22991033

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

#228

Post by icedchai »

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…

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.

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

#229

Post by enriquto »

majkinetor wrote: post #172
yabones wrote: post #170

Earlier quoted context omitted.

There are things that powershell does well, but I wouldn't say that it's really all that unixey. It relies far too heavily for the user to have an understanding of the windows object model, which frankly a lot of sysadmins don't have and refuse to learn. In unices the pipeline is just that, a way to send a stream of bytes from one place to another. In pwsh it's more complicated than that since it passes an object alo…

Thats nonsense really. What windows object model ??? Your 'simple' pipeline becomes hard core once you take into account all other things you require like grep, awk, sed, xargs, mount etc. Hack, even basic boolean stuff is from another dimension with executables like `[` or `true/false` (yeah, I know mostly builtin nowdays)

> your 'simple' pipeline becomes hard core once you take into account all other things you require like grep, awk, sed, xargs, mount etc.

That's the whole point of unix. Non-integrated tools that talk to each other using plain text.

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

#230

Post by _emacsomancer_ »

AnIdiotOnTheNet wrote: post #211
_emacsomancer_ wrote: post #191

Earlier quoted context omitted.

Talking about Canonical (which advocates Snaps as a supplement to the distro's repo) and "it is highly discouraged to install software from outside your distro's repository" in the same breath is rather odd. As is thinking that Linux of all OSes is in any way a walled garden.

Snap is very canonical centric. You cannot set up your own snap store, automatic updates are mandatory, etc. It's is for all intents and purposes a second Ubuntu repo with even stricter control.

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.

Post reply on HN