you are viewing a single comment's thread
view the rest of the comments
[–] 27 points 2 years ago (19 children)

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.

  • source
  • hideshow 19 child comments
  • [–] [S] 4 points 2 years ago (18 children)

    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.

  • source
  • parent
  • hideshow 18 child comments
  • [–] 5 points 2 years ago (10 children)

    Arch's package manager is pretty terrible.

    Here's two commands. See if you can guess what they might do:

    pacman -S package_name
    pacman -Syu
    

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

  • source
  • parent
  • hideshow 10 child comments
  • [–] 7 points 2 years ago* (3 children)

    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.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 5 points 2 years ago

    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.

  • source
  • parent
  • [–] 3 points 2 years ago*

    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.

  • source
  • parent
  • [–] 3 points 2 years ago* (1 child)

    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?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 2 years ago*

    The y stands for "yoink the database".

    /s

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

  • source
  • parent
  • [–] 3 points 2 years ago (2 children)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 2 years ago (5 children)
  • [–] 5 points 2 years ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 5 points 2 years ago (3 children)

    Install tldr if you haven't already

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 2 years ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 2 years ago*

    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.

  • source
  • parent