[rossdavidh]

You're not wrong, but in this case I believe all I had to do was copy the line of text and paste it into a terminal (it's a while ago so I might be misremembering). But, given that is what people are doing, it does raise the question of whether requiring them to copy and paste is actually any more secure than allowing click-to-install...

[asoneth]

> whether requiring them to copy and paste is actually any more secure than allowing click-to-install...

Agreed. If your operating system requires that you occasionally search for instructions and copy-and-paste executable strings from the internet, that seems less efficient, less learnable, and less secure than any GUI I know of.

Perhaps at some point terminals will bake in an LLM as an intermediary to convert between human-readable instructions and terminal commands, and then we just have to worry about the alignment of those LLMs...

[lproven]

There are 2 things here to note which explain why.

* Most distros offer multiple desktops. This is true of Debian, Ubuntu, Fedora, openSUSE, Arch, etc.

Point-and-click instructions are limited to only 1 desktop. Shell instructions work on all of them.

* GUI instructions can't be copied and pasted. They must be performed by the user. But most people do not know the difference between buttons and spinners and input boxes. It's very very hard to write specific instructions for people who lack the vocabulary for GUI controls.

I speak as a former docs writer.

[asoneth]

> Point-and-click instructions are limited to only 1 desktop...

If a consumer product (computer, phone, TV, microwave, printer, radio, oven, washing machine, etc) requires reading through more than a quick start guide to access the advertised functionality, then it has failed as a consumer product.

> GUI instructions can't be copied and pasted

Training my nontechnical friends and relatives to copy, paste, and execute terminal commands they found on the internet does not strike me as a very good alternative.

[lproven]

Your comment is correct but it's a response to an entirely different and orthogonal point which I did not propose and wouldn't try to.

As such I can answer in several different ways which try to approach the point you're making, but they can only do it by trying to nudge your comment slightly back in the direction of "how things really are".

Point 1:

Why what you're saying does not address the real situation.

The thing is that about 99% of Linux distributions are not products.

They are the collaborative efforts of many small teams of volunteers. In rare instances, a few of them are collaborative efforts of large teams of paid engineers. However most of those are server OSes where UI is not a factor.

(The real competitive criteria of paid server distros are things like "what certifications do you have?" and "how long will you provide patches for?" They're nothing to do with its technical capabilities. That's why the paid enterprise distros are much smaller, much simpler, and technologically far inferior to free ones.)

They are not products, and they are definitely not CONSUMER products.

Point 2:

How to do easy end user 3rd party apps on Linux: prohibit them.

There is an easy answer to the question of "software installation on a consumer Linux desktop." There's only one consumer Linux desktop. It's ChromeOS. And you can't install native software. There is no native software.

(Some ChromeBooks can run Android apps but they are not native.)

Note, this product outsells all free distros by, conservatively, 10-20x over.

So this is clearly not a handicap.

Point 3:

Docs are really hard and don't pay.

I've written product documentation as my paid full-time job for 4-5 years.

Nobody reads it by choice, and it's expensive to produce, which is why consumer products mostly don't come with any now. You may get a quick-start guide and most customers ignore that.

This is why the only desktop Linux with users in the hundreds of millions is so stripped-down you can't install apps on it.

Point 4:

The real context here.

Given these aren't products and aren't for consumers, what we get is sub-optimal but it really is not bad these days.

[asoneth]

> Your comment is correct but it's a response to an entirely different and orthogonal point which I did not propose and wouldn't try to.

You're right, I was mixing up threads, I apologize. Your original point seems to be that it's less effort for a Linux distribution to write documentation for shell commands than for them to create a GUI and write the same level of documentation for that GUI, right? If so, I agree, and I understand why a volunteer-driven project would take this route.

However, two points:

First, a properly-designed GUI should require less documentation in the first place.

More importantly, I don't see how this refutes my original point that running shell commands copied from the internet is less efficient, learnable, and secure for end-users than using comparable functionality through a GUI.

Again, I understand why distros take this route, I'm merely pointing out that it is less efficient, learnable, and secure. With respect to the four points in your last post I agree so I'm not sure there's much worth discussing there.

[lproven]

> Your original point seems to be that it's less effort for a Linux distribution to write documentation for shell commands than for them to create a GUI and write the same level of documentation for that GUI, right?

Er, no, not at all. TBH I am puzzled by this interpretation. I had nothing like that in mind, no.