Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In the Beginning Was the Command Line (1999)

web.stanford.edu

Post reply on HN
Print view View original

201–210 of 271 posts

Re: In the Beginning Was the Command Line (1999)

#201

Post by mjevans »

dredmorbius wrote: post #183
ndsipa_pomu wrote: post #134

Earlier quoted context omitted.

You raise a good point about GUIs changing over time. Obviously, CLIs can change, but that happens less often and is usually in response to a poorly thought out first attempt at providing functionality (or when additional functionality is bolted on).

Scripts are UI glue in more than one sense. The usual interpretation is that scripts glue together system commands that don't otherwise incorporate one another. This is tremendously useful and is by itself a huge advantage over GUIs. But the second sense is that vast libraries of scripts keep developers bound to their previous UI promises . You don't capriciously change command-line options without raising all kinds…

The correct response to an API change is to re-version the API for the library. E.G.

bsdtar -> libarchive -- Arguments as presently known

bsdtar2 -> libarchive -- Some new overhaul that does things way differently

Re: In the Beginning Was the Command Line (1999)

#202

Post by mjevans »

gregw2 wrote: post #150
ndsipa_pomu wrote: post #97

One major advantage of the CLI is that instructions/fixes etc are very concise and can be easily communicated. If someone has a Linux system that needs a known fix, then it's trivial to send someone the commands to copy/paste into a terminal. However, if there's a known fix for a graphical program, then it suddenly becomes much harder to communicate - do you go for a textual instruction (e.g. click on the hamburger m…

Agreed. Poor scripting/replay inherently limits the GUI. That said, the best late 90s expression of the core advantage of the GUI over the TUI/CLI is that it demands less of the user: "recognize and click" vs "remember and type" That seems very fundamental to me. I have not seen as succinct expression of tradeoffs for V(oice)UI or L(LM)UIs

The 90s UIs all had 'hints' for how to activate UI features using keyboard shortcuts.

Want to know how to copy and paste quickly? It's Right There in the menu you found the action in. Don't know that yet? Alt + E (underlined in Edit) then some other key to jump to the action in the list, or you now see the list, abort the previous command sequence with Esc, and then start memorizing the new shortcut for Ctrl+c + Ctrl+v.

Re: In the Beginning Was the Command Line (1999)

#203

Post by jholman »

wpm wrote: post #125
Phiwise_ wrote: post #85

Earlier quoted context omitted.

"Obsolete" is too strong a word, I think. OSX isn't an evolution of the Macintosh's operating system; That'd be Pink, which was even mentioned, and it crashed and burned. OSX was far closer to a Linux box and a Mac box on the same desk, therefore the only change really needed is to replace mentions of Unix or specifically Linux with Linux/OSX as far as the points of the piece are concerned. If Jobs had paid Torvalds…

macOS shares zero lineage with Linux, which itself shares zero lineage with the UNIX derivatives. It would make zero sense for Apple to call macOS "Apple Linux" when it doesn't use the Linux kernel. Mac OS X is closest to a NeXTStep box with a coat of Mac-like polish on top. Even calling it "Apple Berkeley Unix" wouldn't make sense, because the XNU kernel is a mish mash of both BSD 4.3 and the Mach kernel. Linux and…

I used to have a coworker, a senior dev of decades of experience, who insisted that MacOS was a real Linux, "just like BSD". Sigh.

Of course, this belief probably had no downsides or negative consequences, other than hurting my brain, which they probably did not regard as a significant problem.

Re: In the Beginning Was the Command Line (1999)

#204

Post by jholman »

throwawaydummy wrote: post #184
justin66 wrote: post #156

Earlier quoted context omitted.

> recent Acquired episode on Microsoft, where Vista was a Dodge Viper but Windows 7 was a Toyota Camry, which is what users actually wanted. I assume if anyone associated with Microsoft compared Vista to anything other than an abject failure, it's because they are - at best - broken or defective people who were involved in the creation of Vista, and therefore not objective and not to be trusted in any way. Dodge Vipe…

Doge Vipers get a bad rep even in need for speed lol but idk enough about cars to know why

This might help?

https://youtu.be/WdtK9Sj8ADw?list=PLoTU9_iCGa6go3vsnxlNn1wZS...

Re: In the Beginning Was the Command Line (1999)

#207

Post by owl57 »

heraldgeezer wrote: post #66
lukan wrote: post #54

Earlier quoted context omitted.

"By what I assume would be some project contributor ssh-ing into your machine" Who would want that? "Stay away from my house, you freak!" would be the normal reaction. Unless some serious trust is developed, I would not let people into my house while I sleep. Also the actual usual reaction would have been more like: "hey it is open source, you can fix anything on your tank yourself" You need a new module to connect w…

Companies want that when prod stops.

Reminded me of an extreme case. In 2012, the largest Russian bank brought its prod back online, and then posted literally this:

> We invite specialists to take part in a professional discussion to identify the causes of Oracle DBMS failure

> System logs and a more complete description of the situation will be posted in the blog. To participate in the discussion, you must fill out the registration form and wait for an invitation to your email.

https://web.archive.org/web/20120716225650/http://www.sbrf.r...

Re: In the Beginning Was the Command Line (1999)

#208

Post by psd1 »

Animats wrote: post #199
jthoward64 wrote: post #175

Earlier quoted context omitted.

Whereas Linux never stopped coming up with new ideas, but doesn't have the manpower to implement them

systemd! (Currently struggling with the way systemd inserts itself into the DNS query chain and then botches things.)

It likes to fall over to the secondary server, doesn't it.

Re: In the Beginning Was the Command Line (1999)

#209

Post by dredmorbius »

mjevans wrote: post #201
dredmorbius wrote: post #183

Earlier quoted context omitted.

Scripts are UI glue in more than one sense. The usual interpretation is that scripts glue together system commands that don't otherwise incorporate one another. This is tremendously useful and is by itself a huge advantage over GUIs. But the second sense is that vast libraries of scripts keep developers bound to their previous UI promises . You don't capriciously change command-line options without raising all kinds…

The correct response to an API change is to re-version the API for the library. E.G. bsdtar -> libarchive -- Arguments as presently known bsdtar2 -> libarchive -- Some new overhaul that does things way differently

Sure, for APIs or CLI tools.

Doesn't work so well for GUIs, which was sort of the original point.

Re: In the Beginning Was the Command Line (1999)

#210

Post by ndsipa_pomu »

dredmorbius wrote: post #183
ndsipa_pomu wrote: post #134

Earlier quoted context omitted.

You raise a good point about GUIs changing over time. Obviously, CLIs can change, but that happens less often and is usually in response to a poorly thought out first attempt at providing functionality (or when additional functionality is bolted on).

Scripts are UI glue in more than one sense. The usual interpretation is that scripts glue together system commands that don't otherwise incorporate one another. This is tremendously useful and is by itself a huge advantage over GUIs. But the second sense is that vast libraries of scripts keep developers bound to their previous UI promises . You don't capriciously change command-line options without raising all kinds…

There's also a lot of text based tools that are designed to be used as part of a script and don't provide much functionality in themselves - the philosophy of do one thing (and do it well). GUIs tend to be designed to provide the entire functionality that's wanted and little thought is given to them being used as part of a toolchain.
Post reply on HN