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

151–160 of 286 posts

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

#151

Post by zdragnar »

Joker_vD wrote: post #133
dangoljames wrote: post #117

Earlier quoted context omitted.

The one thing that all the negative commentary fails to acknowledge is that even in the face of this somewhat overstated inconsistency across all these command line tools and applications, is that for the knowledgeable and motivated, it is quite simple to wrap the more complex invocations in simplified scripts or, at the other extreme, a completely functional native GUI. They also fail to acknowledge that contemporar…

Sigh. Why are there still lots, heaps, and tons of horrible, inhumane, broken legacy technology still around in active use? Because its users/proponents are "knowledgeable and motivated" enough to keep pushing through. Sort of a Stockholm syndrome of computing, really. My brain is really quite small compared to all the knowledge about computers that is out there. And my willpower too is very limited. So I would rathe…

They are still around because, through historical accident, they are what everyone knows and uses.

Making a special snowflake that fits your brain better is good for you, but not necessarily anyone else.

Making something good for everyone will, almost inevitably, become a design-by-committee monstrosity that is as problematic as the tool being replaced.

The truth is, I am skeptical that these tools can be replaced by something that requires no effort to learn. At least, for the tools we already have, if you dont want to learn them, you can roll the dice and copy / paste from google overflow.

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

#152

Post by gnufx »

Some context might be useful.

Starlink was one of two somewhat similar subject-specific networks set up in a period of enlightenment by the UK Science Research Council (as I think it was then) operating in the 1980s, particularly for largely interactive analysis. The other was an un-named and ill-publicized one for nuclear structure as opposed to astronomy. I don't know about Starlink, not being an astronomer, but I guess it was also rather ahead of its time, like the nuclear structure one.

Obviously it had changed in astronomy by then, but I didn't see the attitude that physicists (and later, structural biologists) shouldn't write software or build the necessary hardware before or around that time. We had people and job titles like "physicist-programmer", and did what was necessary, and we did fit the facilities to the problem (when not working at foreign labs). The software systems were designed to be user-extensible anyhow, in our case.

Personally I was glad to have the lightning-fast interactive graphics system on the nuclear structure GEC systems, and not the stodgy performance -- even when they weren't running something like Macsyma -- of all the VAXen I used. VMS was somewhat inscrutable to a physics hacker anyhow, so I don't understand why Unix made it more difficult, though I hold no particular affection for Unix.

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

#153

Post by u801e »

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 fundamental assumption is that people will either ask how to do something, or read the documentation/manual. It's not that we'll try to figure out how something work by experimenting.

When I first started using UNIX/Linux after learning the DOS shell, I never said that using commands like rm or mkdir were not intuitive and that it should be like using del or md instead. I just learned the different commands by reading through documentation.

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

#155

Post by Joker_vD »

zdragnar wrote: post #151
Joker_vD wrote: post #133

Earlier quoted context omitted.

Sigh. Why are there still lots, heaps, and tons of horrible, inhumane, broken legacy technology still around in active use? Because its users/proponents are "knowledgeable and motivated" enough to keep pushing through. Sort of a Stockholm syndrome of computing, really. My brain is really quite small compared to all the knowledge about computers that is out there. And my willpower too is very limited. So I would rathe…

They are still around because, through historical accident, they are what everyone knows and uses. Making a special snowflake that fits your brain better is good for you, but not necessarily anyone else. Making something good for everyone will, almost inevitably, become a design-by-committee monstrosity that is as problematic as the tool being replaced. The truth is, I am skeptical that these tools can be replaced by…

> Making a special snowflake that fits your brain better is good for you, but not necessarily anyone else.

Yes, and that's why the parent's argument that "you can hack it together in any fashion you damn well please, and you can use it to build peer-grade native applications, typically with little more than a tip of the hat as 'overhead'" is not a convincing argument. Yes, you can learn a lot about it and tinker with it and "harness its power", as opposed to using something that's less flexible, but is already pretty damn ergonomical, and is much more accessible and easy to learn about (maybe to the point you're not even realizing you're learning).

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

#156

Post by gnufx »

mwcampbell wrote: post #140

This passage at the end was the most thought-provoking for me: > 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). The powers-that-be in the software world of course have always felt that "ordinary" users (astronomers in this case) should be using software and not writing it. The cynic m…

At least in the previous decade, and even at that time in other parts of UK science, I don't think there was a "software priesthood". It probably invaded astronomy and HEP earlier than elsewhere, and to some extent now resides in Research Software Engineering. The first OS on the nuclear structure interactive graphics system was written by a Birmingham physicist, for instance. I wrote analysis software as necessary (and read up on software engineering as well as the other techniques needed for the research, like electronics and high vacuum systems). The UK Computational Computing Projects were run by scientists who did the work, and you could get Fellow of the Royal Society-level help (though the two mainstays of CCP4 only got the title much later).

I don't know where this free software elitism is prevalent, as someone involved with it in research since before the term became necessary. I could appreciate the UHH, by the way, from a time when Unix was largely not free software.

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

#157

Post by Avshalom »

Joker_vD wrote: post #133
dangoljames wrote: post #117

Earlier quoted context omitted.

The one thing that all the negative commentary fails to acknowledge is that even in the face of this somewhat overstated inconsistency across all these command line tools and applications, is that for the knowledgeable and motivated, it is quite simple to wrap the more complex invocations in simplified scripts or, at the other extreme, a completely functional native GUI. They also fail to acknowledge that contemporar…

Sigh. Why are there still lots, heaps, and tons of horrible, inhumane, broken legacy technology still around in active use? Because its users/proponents are "knowledgeable and motivated" enough to keep pushing through. Sort of a Stockholm syndrome of computing, really. My brain is really quite small compared to all the knowledge about computers that is out there. And my willpower too is very limited. So I would rathe…

>>"It is very easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all."

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

#158

Post by scroot »

dsego wrote: post #134
scroot wrote: post #118

> One can only conclude that the makers of Unix held, and still hold, the ordinary computer user in total contempt, and this viewpoint seems to me to be mirrored in the attitudes of the people who are inflicting this awful system on the rest of us. Does Unix's enormously steep learning curve have any function other than to deter the faint-hearted, those who may want to use computers without necessarily dedicating the…

As someone who grew up with Win 95 and remember the Atari and Amiga in the early to mid 90s, Linux would surely seem archaic even at that time. I'm sure my preteen cousin who was showing my even younger self cool games and apps on the Atari didn't write a single line of code and I doubt a large percentage of ordinary computer users were writing much code at the time. Someone using a computer could be seen as more tec…

I think about tools like Hypercard, Applescript, and other systems that really allowed "users" to easily do things that today we might view as strictly the purview of "programmers". These kinds of things are no longer popular, but it's not because they were never popular, nor is it because they didn't "work." Our culture changed.

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

#159

Post by jovial_cavalier »

>is "rm" (pronounced "remove") really synonymous with "delete". Do I call the deleters when I want to move house. How would my first cousins once-deleted feel?

I don't think it's good to make the command name an English word. Perhaps it would make the command easier to discover, but it would also introduce certain unpredictable connotations.

For instance, if the command was called 'remove', then someone might presume that it was being 'removed,' and 'replaced,' somewhere else. 'Remove' has the connotation that you are taking something and necessarily putting it somewhere else, which is not what 'rm' does.

'delete' has less ambiguity, but I'm not confident that similar mixups wouldn't happen. It's better for the command to be something ideosyncratic so that the user goes in with no assumptions about its function.

To paraphrase Rob Pike, the command is not remove, but 'rm'. It's called 'rm' because rm is what it does.

http://mail.9fans.net/pipermail/9fans/2016-September/035429....

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

#160

Post by gnufx »

pjmlp wrote: post #29
ginko wrote: post #12

Well, maybe more people would have used VAX/VMS or OpenVMS if it had been open source.

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.

Unix in the 1970s was completely irrelevant to the context of the article. I don't know to what extent we paid separately for the OS, but we had source for at least MVT/MVS and OS4000, of ones I used, which we didn't later for SunOS.
Post reply on HN