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

241–250 of 286 posts

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

#241

Post by thewebcount »

u801e wrote: post #153
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" ?

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 re…

And what if you don't have anyone to ask? The article very clearly states why the documentation is useless for a beginner.

Other OSes have a concept called forgiveness that allows you to easily reverse a change you made explicitly so that you can experiment with it and figure things out for yourself. The problem is that Unix fundamentally doesn't allow you to figure things out by yourself. You absolutely need either a manual (that you will never find if you haven't already been told how to find it), or you need to have someone you can ask questions to.

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

#242

Post by enriquto »

Arnavion wrote: post #235
enriquto wrote: post #229

Earlier quoted context omitted.

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

It's exactly the same for PS. Just as you have to look at a text output of a unix command to figure out how to parse it and extract the subset of information you need from it, so do you have to look at the help metadata of a PS command to figure out how to extract the subset of information you need from its output. The advantage of having objects instead of text is that if you thought you could parse the filename of…

Thanks for your answer, and I see where you are coming from. But your unix is not the same as my unix. For me, unix means programs that can be easily written using only the getchar and putchar functions. If you have "types" and whatnot, it's not unix.

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

#243

Post by AnIdiotOnTheNet »

_emacsomancer_ wrote: post #230
AnIdiotOnTheNet wrote: post #211

Earlier quoted context omitted.

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.

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 around software without middlemen the way it has been in real personal computing systems since the 80s.

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

#244

Post by [deleted] »

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…

[deleted]

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

#245

Post by JdeBP »

PaulDavisThe1st wrote: post #166
Yetanfou wrote: post #59

Earlier quoted context omitted.

That's because 'help' on most Linux-based systems is actually a shell builtin which explains other shell builtin commands. This, in turn, is related to the fact that Linux-based systems are flexible - you could use a totally different shell which does not even have the _help_ builtin - while VMS was a comprehensive single-sourced top-down controlled system. Both have their strengths and weaknesses, the fact that you…

help on VMS wasn't a builtin. It was a system-provided program, with data files that could be accessed via other software.

The same was true on MS-DOS, DR-DOS, and OS/2. Microsoft provided a help file compiler with some of its DOS development tools, and IBM provided an INF/HLP compiler and (if memory serves correctly) a message file compiler with the OS/2 SDK (HELP using both hypertext help files and message files on OS/2).

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

#246

Post by JdeBP »

reagent_finder wrote: post #34
madhadron wrote: post #5

Earlier quoted context omitted.

> but largely (functionally) indistinguishable from a UNIX machine when accessing it via teletype (glass or otherwise). I disagree. I first sat down at a VMS terminal in a library in North Carolina when the OPAC broke and dropped me back to a prompt. I knew Linux passably well at that point but had never used VMS before. I typed ls, tried dir, that worked, and finally tried help. In half an hour I was investigating t…

I just tried 'help' on a linux system. It is absolute garbage.

If you had tried it on an actual Unix system, your experience would have been rather different. AT&T Unix System 5 Release 3.2 had a standalone help command that provided an interactive menu-driven help system. It looked something like this:

    $ help
    help:   UNIX System On-line Help

        Choices      description 
        s            starter: general information

        l            locate:find a command with keyword

        u            usage: information about command 

        g            glossary: definition of terms 

        r            redirect to a file or a command 
        q            Quit
    Enter choice >

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

#247

Post by mehrdadn »

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

I've had a lot of issues with git UI but git checkout seems among the more sane ones. Compared to how, say, git add can remove a file...

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

#248

Post by JdeBP »

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…

Were you amazed back in the days when one of the most popular Unix flavours was produced by Microsoft? Yes, Xenix.

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

#249

Post by codezero »

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 module for IDL - IDL is a proprietary scripting language that mimics and interoperates with Fortran in a lot of ways). Fortran was able to stick around because of a lot of work on great compilers, and I think, in general, the great speed up of commercial hardware has made the need for hyper optimization less necessary for a lot of day-to-day physics study.

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

#250

Post by laksdjfkasljdf »

dhosek wrote: post #214
laksdjfkasljdf wrote: post #207

Earlier quoted context omitted.

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.

Verbose is a relative thing. `copy` is an intuitive name, `cp` not so much. Likewise, it's a lot easier to remember how to do something like copy /exclude=* .bak [.work] [.prod] (that space after the asterisk shouldn't be there but markdown) than the equivalent command in a Unix shell, apparently: $ shopt -s extglob # to enable extglob $ cp work/!(*.bak) prod/

You realize all that has a huge IF you are a native english speaker, right?

the glob stuff is a case of power vs convenience. but you can do very similar with bash [] or {} syntax.

not being apologist, but I like unix approach of blurring the lines of a computer user and programmer. It makes everyone up their game both ways. Users being more demanding, and code being more accessible.

Post reply on HN