Yeah I totally agree. But still, I feel like there are much more terrible GUI programs out there than terrible CLI programs. The only truly awful CLIs I can think of is that tool for managing MegaRAID controllers that has the weird abbreviations everywhere, and shell interfaces to GUI-first bloatware like Dconf that were probably added as an afterthought. I think with CLI there’s only so many things that the developer can fuck up. It’s all just text. Meanwhile with GUI there are endless opportunities for truly horrid design. Think of Teams. Think of the github web interface. Think of the r*ddit redesign. Or go watch that Tantacrul video on Sibelius. CLI could never have such a breadth of terribleness.
Here’s two commands. See if you can guess what they might do:
pacman -S package_name
pacman -Syu
Solution
The first command installs a package.
The second command updates all packages.
I believe, there’s some sort of logic to the letters, but man, most users seriously do not care. They just want to install, update and remove packages 99% of the time, so they shouldn’t need to learn that intricate logic for three commands.
I guess, you could use pkcon to do that instead, but that doesn’t really help new users…
Arch presumes that the user has some familiarity with CLI tools and can read documentation. You couldn’t even install it without using the terminal until archinstall became a thing. If it’s an issue, Arch is the wrong OS for you.
Besides:
pacman -S - synchronises packages between the remote and local repo.
I figured, I’d ruffle some feathers by saying that. 😅
But yeah, I stand by my point. Just because your target users are capable of dealing with complexity, doesn’t mean you should be making use of that rather than simplifying usability, since your users have plenty other things they could be learning instead.
I will caveat that I can see it becoming worth it to learn an intricate logic for a power user, when things fall into place and make sense at a higher level as you learn more about it.
But in my experience, that’s just not the case with package managers. You need a few specific commands to be obvious and then the special cases can be obscure flags.
AFAIK, arch never pretended to cater to new linux/cli users, I’ve always read it as a recommandation for advanced (or at least comfortable with reading docs and using CLI) users.
My first time using arch required me following the arch wiki for install and when I finally got a working system (I’m as bad at following tutorials as I am at following cooking recipes) the pacman commands were not something I struggled with.
But yeah coming from Debian where I had the gloriously intuitive apt syntax, I get your point.
I only learned what pacman -Syu meant, after literal years of typing it in not knowing anything other than “this updates the packages”, because I got curious and googled it.
To me it was just an adeptus mechanicus incantation.
EDIT: And I still have no clue how ‘y’ translates to ‘refresh the database’. Like. Sure. S to synchronise from the server to the computer. And u to mark for update all the updatable packages. But – Why the fuck is ‘y’ the refresh?
I think they either just ran out of letters, or y was seen as reinforcing the action (as in “yes, download the database too”), with yy being an even stronger action (“yes, download the database even if there’s nothing to update”).
You think that’s bad? For as much as I love seeing a well-configured Nix system, it’s beginner-unfriendly learning curve is almost as bad as “compile everything yourself” distros.
As a beginner, do you have a question about Nix? RTFM. You did? Well, wrong Nix. You wanted to learn something about Nix the language, but those docs were about Nix the OS and Nix the package manager.
You just read a guide for using the nix command and wanted to install a program with nix-env? That’s an outdated guide. You should be using flakes and nix profile. You tried that, but it said the nix command is experimental so you didn’t do it? No, you were supposed to edit /etc/nix/nix.conf to enable them first.
Don’t get me wrong here though, I like Nix. It just desperately needs an actual beginner-friendly beginner guide for flakes and nix command commands that doesn’t assume everyone is a software developer. 80% of the Nix documentation tutorials aren’t even relevant to regular users, only package maintainers and NixOS users.
Eh, I’m fine with man pages. I looked at tldr before, but I’ve been using the command line for many things almost exclusively for like 10+ years now. I usually just need the reference details.
It’s is not either or. Also good cli require an eye for design just like gui. Lots of cli suck because there is no eye.
Yeah I totally agree. But still, I feel like there are much more terrible GUI programs out there than terrible CLI programs. The only truly awful CLIs I can think of is that tool for managing MegaRAID controllers that has the weird abbreviations everywhere, and shell interfaces to GUI-first bloatware like Dconf that were probably added as an afterthought. I think with CLI there’s only so many things that the developer can fuck up. It’s all just text. Meanwhile with GUI there are endless opportunities for truly horrid design. Think of Teams. Think of the github web interface. Think of the r*ddit redesign. Or go watch that Tantacrul video on Sibelius. CLI could never have such a breadth of terribleness.
Arch’s package manager is pretty terrible.
Here’s two commands. See if you can guess what they might do:
Solution
The first command installs a package.
The second command updates all packages.
I believe, there’s some sort of logic to the letters, but man, most users seriously do not care. They just want to install, update and remove packages 99% of the time, so they shouldn’t need to learn that intricate logic for three commands.
I guess, you could use
pkconto do that instead, but that doesn’t really help new users…Arch presumes that the user has some familiarity with CLI tools and can read documentation. You couldn’t even install it without using the terminal until archinstall became a thing. If it’s an issue, Arch is the wrong OS for you.
Besides:
pacman -S- synchronises packages between the remote and local repo.pacman -Q- queries the local repo.pacman -R- removes packages.pacman -F- queries the files of a package.Et cetera.
I figured, I’d ruffle some feathers by saying that. 😅
But yeah, I stand by my point. Just because your target users are capable of dealing with complexity, doesn’t mean you should be making use of that rather than simplifying usability, since your users have plenty other things they could be learning instead.
I will caveat that I can see it becoming worth it to learn an intricate logic for a power user, when things fall into place and make sense at a higher level as you learn more about it.
But in my experience, that’s just not the case with package managers. You need a few specific commands to be obvious and then the special cases can be obscure flags.
Ui designers should not presume people are familar with the ui. That’s not design.
Yeah built in user screening process. Screwed by endeavourOS though.
AFAIK, arch never pretended to cater to new linux/cli users, I’ve always read it as a recommandation for advanced (or at least comfortable with reading docs and using CLI) users.
My first time using arch required me following the arch wiki for install and when I finally got a working system (I’m as bad at following tutorials as I am at following cooking recipes) the
pacmancommands were not something I struggled with.But yeah coming from Debian where I had the gloriously intuitive
aptsyntax, I get your point.Advanced users would still benefit from good design.
I do agree, I’m just not surprised it wasn’t done this way at the start and I’m not bothered enough by it to want a change.
I only learned what
pacman -Syumeant, after literal years of typing it in not knowing anything other than “this updates the packages”, because I got curious and googled it.To me it was just an adeptus mechanicus incantation.
EDIT: And I still have no clue how ‘y’ translates to ‘refresh the database’. Like. Sure. S to synchronise from the server to the computer. And u to mark for update all the updatable packages. But – Why the fuck is ‘y’ the refresh?
The
ystands for “yoink the database”./s
I think they either just ran out of letters, or
ywas seen as reinforcing the action (as in “yes, download the database too”), withyybeing an even stronger action (“yes, download the database even if there’s nothing to update”).You think that’s bad? For as much as I love seeing a well-configured Nix system, it’s beginner-unfriendly learning curve is almost as bad as “compile everything yourself” distros.
As a beginner, do you have a question about Nix? RTFM. You did? Well, wrong Nix. You wanted to learn something about Nix the language, but those docs were about Nix the OS and Nix the package manager.
You just read a guide for using the nix command and wanted to install a program with nix-env? That’s an outdated guide. You should be using flakes and
nix profile. You tried that, but it said the nix command is experimental so you didn’t do it? No, you were supposed to edit /etc/nix/nix.conf to enable them first.Don’t get me wrong here though, I like Nix. It just desperately needs an actual beginner-friendly beginner guide for flakes and
nix commandcommands that doesn’t assume everyone is a software developer. 80% of the Nix documentation tutorials aren’t even relevant to regular users, only package maintainers and NixOS users.i raise you the man command
Manpages are great though? They’re not the best if you need examples, but as a reference for the behavior of flags? I love’em.
Install tldr if you haven’t already
Eh, I’m fine with man pages. I looked at tldr before, but I’ve been using the command line for many things almost exclusively for like 10+ years now. I usually just need the reference details.
But that’s why I love tldr!
It gives written examples of a handful of the most common use cases with a super brief explanation. It’s perfect for quick reference.
But you do you, I don’t own any tldr stock or anything.
thanks for the reminder! I’ll try it out
The good thing about CLIs is that if they suck too much, you can easily create a wrapper around them.