Email or username:

Password:

Forgot your password?
Dr. Quadragon ❌

I think, part of the reason why The Dreaded Terminal is still so prevailant in the perception of Linux is that it's just SO MUCH easier to write manuals for.

I mean, it's way more efficient to say: "run `apt install firefox` to install firefox" than "to install firefox, open the software center [screenshot], search for firefox [screenshot]", select firefox in the application list [screenshot], click install [screenshot]".

The results are the same. Why waste more time drawing a comic book when you can tell a person to just type one line in a box?

25 comments
/dev/urandom

@drq also customizability

imagine having to write several different manuals for users of GNOME, KDE, Xfce, etc.

Dr. Quadragon ❌

The Command Line Interface aka The Terminal has terrible PR. People think there's something really nerdy and complex and obsolete about it, when in reality there's none.

I propose: rename it into "Operating System Chat". Cause it's essentially what it is.

I mean, hell, it worked for certain other text-based tools people nowadays type away on.

WildPowerHammer

@drq
- Open terminal
- What is it?
- Hmm... console, shell, command line, text interface.
- Aaah! An operating system chat.
- Yeah... An operating system chat

Eugene :emacs: :freebsd:

@drq :emacs: buffer *scratch* == #Emacs Editor Chat :dragnsarc:

Шуро

It is nice to have both. Console commands are good for exact instructions and batch mode but the lack of visual guidance is a bitch.

GUI allows to do something even when you don't exactly know what it is called or where it is and it HUGE chunk of practical use cases. Especially when there are different distros or platforms involved.

There's a reason most stuff in our life has GUI :)

Dr. Quadragon ❌

@shuro Yes, it's nice to have both.

I'm just talking from the documentation writing perspective. If you want the reason why there's more guides that utilize the CLI - here it is. And that might be part of the reason why Linux is associated mostly with CLI: there's just way more Linux guides on the Internet that use it.

Шуро
I'm just talking from the documentation writing perspective. If you want the reason why there's more guides that utilize the CLI - here it is.


No.

Let's be honest - the main reason is that there is no GUI for these tasks or it sucks ass. Good stable GUI isn't hard to document either and you don't even need screenshots. "Go to App Store and install Firefox from there" is sufficient provided the said app store is working, easy to find and well-designed.

As for the writing docs... I agree but it depends on the application really. The goal of writing documentation is not to create documentation itself but to provide the user with assistance to get his task done - now and in the future. When we are talking about stuff like server components installation then sure, CLI rules. For some other things - not so much.

Also CLI documentation is often VERY version and environment dependent. There are tons of broken guides just because some config moved, version number changed or some parameter was renamed (and not necessarily in your application).

I'm just talking from the documentation writing perspective. If you want the reason why there's more guides that utilize the CLI - here it is.


No.

Let's be honest - the main reason is that there is no GUI for these tasks or it sucks ass. Good stable GUI isn't hard to document either and you don't even need screenshots. "Go to App Store and install Firefox from there" is sufficient provided the said app store is working, easy to find and well-designed.

Dr. Quadragon ❌

@shuro

> Let's be honest - the main reason is that there is no GUI for these tasks or it sucks ass

Sorry, but this is just plain wrong. I don't even need to change the example, GUI for package management is basically a solved problem. There are plenty of package management GUIs, and most of them are good.

"Issue this command" is still more efficient to write.

Шуро

Just fired up Gnome Software Center (or whatever it is called). It took good 15 seconds to start showing anything (which for average user means "something is broken"), search is counterintuitive and it offers Firefox from Flathub (I bet it wouldn't show anything if I had no Flatpak AND gnome extension installed before).

It is not a disaster but there's a lot of room for improvement.

And again it depends on how you view efficiency of your documentation. When it comes to package installation - most of the time it is true. When it comes to the rest of use cases - mostly there is no alternative anyway so it is easy to be efficient :)

Just fired up Gnome Software Center (or whatever it is called). It took good 15 seconds to start showing anything (which for average user means "something is broken"), search is counterintuitive and it offers Firefox from Flathub (I bet it wouldn't show anything if I had no Flatpak AND gnome extension installed before).

Dr. Quadragon ❌

@shuro

> It took good 15 seconds to start showing anything

How old is your machine? It fires up instantly for me.

> I bet it wouldn't show anything if I had no Flatpak

Of course it wouldn't, as GSC is a flatpak GUI.

> AND gnome extension

Huh?

> And again it depends on how you view efficiency of your documentation

I define it as "easier to write and works for most cases".

Шуро

T480 with 8GB and some kind of SSD :) And yes, it fires up instantly but then takes a theatrical pause before actually showing anything if it wasn't run recently. I guess it does something like "apt list" and "apt update" in the background and then parses it.

I think GSC needs gnome-software-plugin-flatpak to show flatpack repos (in addition to core package) which I have installed but I think it doesn't get installed by default.

As for everything else - again, you don't really have a choice in most cases. In Windows you can install and configure web server (IIS) both GUI and CLI way. In Linux it is mostly just CLI.

Actually I can't even think of anything except software installation where you can have reasonable choice between CLI and GUI approaches in Linux.

T480 with 8GB and some kind of SSD :) And yes, it fires up instantly but then takes a theatrical pause before actually showing anything if it wasn't run recently. I guess it does something like "apt list" and "apt update" in the background and then parses it.

I think GSC needs gnome-software-plugin-flatpak to show flatpack repos (in addition to core package) which I have installed but I think it doesn't get installed by default.

D:\side\

@drq one reason I can think of is newcomers being *scared* of said box, after being conditioned by numerous jokes (some of them pretty cruel) about the destructive commands.

And command naming doesn't help, making most commands look like arcane language of random letters mashed together (Pacman being probably the worst offenders among package managers in particular) and not even readable *aliases* available by default. It's ergonomic for day-to-day manual use to someone already familiar with it all, but approachability suffers as a result.

And don't get me started on VT-100 still holding on to dear life of ruining the consistency of textual inputs between itself and the rest of GUIs. Like, copying actually *interrupts* ongoing work? Right-click is *paste*? «Dafuq?»

@drq one reason I can think of is newcomers being *scared* of said box, after being conditioned by numerous jokes (some of them pretty cruel) about the destructive commands.

And command naming doesn't help, making most commands look like arcane language of random letters mashed together (Pacman being probably the worst offenders among package managers in particular) and not even readable *aliases* available by default. It's ergonomic for day-to-day manual use to someone already familiar with it all,...

Dr. Quadragon ❌

@dside Yeah. That fucking Perl one-liner.

Also, yes, those VT-100 conventions clashing with desktop conventions are also disorienting as hell if you don't know what's going on.

As for command naming... Well, keyboard shortcuts can also be counterintuinive, the advantage however is that you need to learn them once. But yeah, Pacman sucks for this.

Шуро

> keyboard shortcuts

Another "nice to have" for power users but suck greatly when there is no more visual alternative.

I remember having some application at work used for generating crypto keys and there was some admin mode invoked with something like Shift-Alt-F7 and since everyone used it only occasionally it always took FOREVER to remember (or to find the manual). Maybe the developers imagined their audience revoking keys all the time and decided to save time and space on the toolbar.

D:\side\

@drq yes, hotkeys. It's like command line crystallized around hotkeys.

Hotkeys are *shortcuts*. You still gotta have discoverable (and shareable!) longer routes to make software easy to pick up, and right now they all go through documentation. Every concept you're forcing a user to learn *discourages* them. There might be "gentle encouragement" externally, like one's paycheck contingent on doing whatever the guide is about, but curious strangers are lost right there.

Command palettes have existed since at least 2013 (probably even longer, it's the year of the first release of Sublime Text 2 that had this feature). They are keyed by human-readable explanations and advertise shortcuts right there in search results. Auto completion with documentation in annotations is close, but can we perhaps normalize making shareable forms of commands serve as their own documentation, with longer-form flags and command names? With the way CLIs designed right now it's actually impossible!

@drq yes, hotkeys. It's like command line crystallized around hotkeys.

Hotkeys are *shortcuts*. You still gotta have discoverable (and shareable!) longer routes to make software easy to pick up, and right now they all go through documentation. Every concept you're forcing a user to learn *discourages* them. There might be "gentle encouragement" externally, like one's paycheck contingent on doing whatever the guide is about, but curious strangers are lost right there.

D:\side\

@drq and you know what pisses me off about this the most?

We've dragged the issue on for long enough by now to get a solution.

A horribly inefficient, inconsistent, power-hungry, hard to update and straight up only available as a service to many, but one that speaks to users in a language they know without boatloads of trivia they don't need in the moment.

You know the one.

Dr. Quadragon ❌

@dside I actually have been toying with the idea of using something like Llama as a shell.

Dr. Quadragon ❌

@dside Yes, I agree about forcing people to learn discouraging the adoption of, but all of this is actually beside the point, and we digressed.

Most of the guides ain't really about learning, they're about getting shit done. You need something done, find a guide, you follow instructions, and never look at it again.

D:\side\

@drq no we didn't.

If you want to help the user get shit done give them a script[1] without explaining the steps in it whatsoever. That's how `curl $URL | sudo sh` installation methods have become the norm.

But it goes deeper.

When you don't teach a person the components involved in whatever it is you're telling them to do you're normalizing the attitude "I have no idea what I'm doin' but ok", condemning them to nasty troubleshooting sessions when the guide becomes out of date. And it will, it's a matter of time.

And I hear what you're saying, you don't want users reading documentation and learning every single variation of every component involved because the information they *need* is buried in the middle of waves of extraneous stuff they have no use for.

Because apparently there are no points on the documentation spectrum in between "an arcane spell" and "a hefty spell tome you have to read fully". What happened to "sensible defaults"?

[1]: garden.dside.ru/put-the-info-w

@drq no we didn't.

If you want to help the user get shit done give them a script[1] without explaining the steps in it whatsoever. That's how `curl $URL | sudo sh` installation methods have become the norm.

But it goes deeper.

When you don't teach a person the components involved in whatever it is you're telling them to do you're normalizing the attitude "I have no idea what I'm doin' but ok", condemning them to nasty troubleshooting sessions when the guide becomes out of date. And it will, it's a matter of time.

Dr. Quadragon ❌

@dside Uh... You seem to be under impression that I'm assigning some vauation to either CLI or GUI themselves, like "this good, this bad", or smth. This is not the case.

What I'm saying, is, if I'm ever to write some guides or something in that vein, given the choice, I'd probably prefer to throw together some commands to making screenshots and describing mouseclicks. Because I'm lazy, and it'll work. So that's what happens more often. And this affects the perception of the platform as a whole.

I'm also not saying that it's good or bad. Just that it happens.

@dside Uh... You seem to be under impression that I'm assigning some vauation to either CLI or GUI themselves, like "this good, this bad", or smth. This is not the case.

What I'm saying, is, if I'm ever to write some guides or something in that vein, given the choice, I'd probably prefer to throw together some commands to making screenshots and describing mouseclicks. Because I'm lazy, and it'll work. So that's what happens more often. And this affects the perception of the platform as a whole.

Serious Dick
@drq @dside computers went wrong wen you made em for niggers
D:\side\

@drq that's not my point, no.

My point, which I ran out of character limit going towards, is that the only reason you actually have to produce a guide *yourself* is that the only forms of projects' own documentation, y'know, by the people probably best equipped with keeping it up-to-date, either assume you already know *all of it* (which scares off newcomers) or suggest you learn *all of it* (which scares off even some power users). And the abyss between two cliffs is bridged by these guides scattered all over the internet.

I'm saying that in a perfect world you shouldn't *need* to write this guide at all. And I'm throwing some ideas around on how we might get there.

I probably made this whole rant sound somewhat personal, but it's not really aimed at you, but rather at the situation and the sheer size of the hole we might have to dig ourselves out of for this to improve.

@drq that's not my point, no.

My point, which I ran out of character limit going towards, is that the only reason you actually have to produce a guide *yourself* is that the only forms of projects' own documentation, y'know, by the people probably best equipped with keeping it up-to-date, either assume you already know *all of it* (which scares off newcomers) or suggest you learn *all of it* (which scares off even some power users). And the abyss between two cliffs is bridged by these guides scattered...

D:\side\

@drq and the good news is that I might just have "concepts of a plan"[1] to maybe make that a reality and pool the efforts of guide writers together:
garden.dside.ru/redo-list

It's a long climb, but it's been eating away at me for so long that I've finally started to crawl in this direction, slow as I might be in my current mental state.

[1]: knowyourmeme.com/memes/i-have-

Meko #nowar
@dside @drq @shuro

Also some instructions with CLI commands are overcomplicated.

I remember not too long ago I had to learn how to set up https (with let's encrypt). Yeah, I know today that single "certbot --nginx" was enough. But trying before and seeing instructions with numerous commands and flags with questionable meaning scared me a lot.
@dside @drq @shuro

Also some instructions with CLI commands are overcomplicated.

I remember not too long ago I had to learn how to set up https (with let's encrypt). Yeah, I know today that single "certbot --nginx" was enough. But trying before and seeing instructions with numerous commands and flags...
Go Up