this post was submitted on 06 Feb 2024
142 points (96.7% liked)

Linux

48287 readers
651 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

Examples could be things like specific configuration defaults or general decision-making in leadership.

What would you change?

you are viewing a single comment's thread
view the rest of the comments
[–] nycki@lemmy.world 13 points 9 months ago* (last edited 9 months ago) (2 children)

pacman and nix are both really neat conceptually but they both fail at the most obvious usability test, which is "I just want to install a package"; its like exiting vim all over again.

edit: yes, I know you can set an alias to pacman -Sy or whatever, but if you need to set up an alias for a command to be usable, then I can't in good faith recommend that OS to anyone, and I don't want to use an OS I wouldn't recommend to others.

[–] ccdfa@lemm.ee 11 points 9 months ago (1 children)

What's complex about pacman? I've found pacman to be more reliable and easier to manage than apt, so I'm just curious about your experience

[–] nycki@lemmy.world 4 points 9 months ago

My experience with pacman was via rwfus on steam deck. I was coming in as someone with experience with apt, npm, pip, even choco and winget on windows. My expectation from pretty much every other command line tool is that commands are verbs, flags are adverbs. So having to install with "pacman -S" (or is it "pacman -Sy"?) just feels unnecessarily cryptic. Same with "nix-env -iA". I understand that there are some clever internals going on under the hood, but you can have clever internals and sane defaults. For instance, "npm install foo" both downloads the package to node_modules and updates package.json for me, so I can see what change was made to my environment. Nix should do that.

[–] Bogasse@lemmy.ml 10 points 9 months ago (2 children)

Yeah, I don't understand how you could make installing vim simpler than pacman -S vim? Is it about "-S" being less obvious than "install"?

[–] blackstrat@lemmy.fwgx.uk 21 points 9 months ago (3 children)

How about pacman install vim or pacman --install vim or pacman -i vim

What the heck does S mean?! What's all the syncing nonsense. A million obscure parameters that are all single letter, don't tie in with anything meaningful. You might be used to it, but it's a mess of parameters.

[–] 2xsaiko@discuss.tchncs.de 6 points 9 months ago

My guess is it’s called sync because it’s the “do stuff directly relating to remote repository” sub-command, including remote repo search (--sync --search) and syncing package database/updating packages (--sync --refresh --sysupgrade). Notably, installing or updating a local package file you do with --upgrade.

A lot of package managers just have separate commands instead. It’s just a matter of organization.

[–] kuberoot@discuss.tchncs.de 5 points 9 months ago

To me that's part of the ideology I associate with Arch. If you actually use -h in pacman, I find that the help is presented in a nice and contextual way. You only need a few commands on a daily basis, and most of the other things you might need are easy to figure out when you need them.

In regard to -S being confusing, I think it's basically making the external operations map to how the software works internally. I feel like learning what the software is doing, rather than expecting the software to hide away the details, is also part of it. When you want to do more complex operations, or when something breaks, you'll have a better understanding of what happened.

I wouldn't mind a better interface, I'm not claiming it's the best it can be or even close to it, but I wouldn't want the improvement to come at the cost of obscuring how the software works. I don't want the commands categorized just by convenience rather than logic, or magic buttons that automatically perform a sequence of hidden operations. I want something I can learn, understand, commands I can dissect into their components, not something I'm expected to use in the 10 ways provided and hope it does what I need.

I see this in the same way as people tend to use git - some GUIs will offer convenient buttons with their own made up names, and when git throws an unexpected error, the user will have no idea what the error means, or what the software did to get there.

People often complain that git doesn't make sense. They might have a point in terms of it being unintuitive... But I find that with a general understanding how it's built and what the commands do, the complaints are often people trying to force the issue using the wrong tool for the job.

And, honestly, sorry for the rant. In the end it's just my opinion, I don't want to force it on anybody, I just started writing and kept finding things I wanted to elaborate on. If you're reading this, I hope you have a good day!

[–] Samueru@lemmy.world 0 points 9 months ago* (last edited 9 months ago) (2 children)

You can use an alias for that. Or even a wrapper script that intercepts that.

For example you could place this script in your PATH named idk mmm installpkg (install might be an issue for a name)

Which would do the following:

#!/bin/sh

sudo pacman -S $@

So when you type installpkg vim it will run sudo pacman -S vim

You can repeat that for pacman -Syu, pacman -Rsn, etc. You can even replace pacman for your aur helper instead. (remove the sudo if you will use an aur helper instead).

[–] brb@feddit.nl 5 points 9 months ago (1 children)

I think the point is that if one needs to read a thousand pages of documentation before they can start using a new operating system they will just give up regardless of how good it is.

Installing packages is probably one of the first things you'd want to do so there is a lot of value in keeping its design intuitive.

The 'you can make an alias or script for it' argument only works if someone already has a working understanding of the underlying mechanisms. Which you can assume it someone gradually gets introduced to a Programme, but not if they are making a big switch like installing a new OS.

[–] Samueru@lemmy.world 5 points 9 months ago* (last edited 9 months ago)

Oh I totally agree with that. But I don't think the regular a new user should be using CLI tools to install packages. There are plenty of GUI tools that should be doing that for you instead.

And if they did, it should be very simplified with a wrapper script like in the example above, iirc the common command update-grub is a wrapper script that simplifies it, it is a shame this isn't more common with other tasks.

This could be even standardized, like regardless of the distro if you type installpkg vim, the installpkg script would do something like this that will run it thru the most popular packages managers to do the simple operation:

# Install with 'pacman' (if available)
if command -v pacman >/dev/null 2>&1; then
    sudo pacman -S $@ || exit 1
fi

# Install with 'apt' (if available)
if command -v apt >/dev/null 2>&1; then
    sudo apt install $@ || exit 1
fi

# Install with 'dnf' (if available)
if command -v dnf >/dev/null 2>&1; then
    sudo dnf install $@ || exit 1
fi

echo "No package manager found"
[–] Contort3860@links.hackliberty.org 4 points 9 months ago (1 children)

Just curious, why a script instead of just a bash alias or something like it?

[–] Samueru@lemmy.world 3 points 9 months ago* (last edited 9 months ago) (1 children)

alias totally works, but if you want to simplify it for multiple package managers then it is better to use a script.

Like this example that when the user types pkginstall vim, pkginstall would be a script in path that would do the operation regarless of the package manager:

# Install with 'pacman' (if available)
if command -v pacman >/dev/null 2>&1; then
    sudo pacman -S $@ || exit 1
fi

# Install with 'apt' (if available)
if command -v apt >/dev/null 2>&1; then
    sudo apt install $@ || exit 1
fi

# Install with 'dnf' (if available)
if command -v dnf >/dev/null 2>&1; then
    sudo dnf install $@ || exit 1
fi

They could even install it in their ~/.local/bin, and as long as their distro makes that part of PATH (which arch does not kek) by just using that same home with another distro they already could install/remove packages and update using those wrapper scripts regardless of the distro.

If you are wondering why the script needs to check if the package manager exists, it is because when testing it I discovered that if the first one is not installed it will cancel the operation and not continue, and if I remove the exit 1 it will attempt to use the next package manager when canceling the operation with ctrl+c.

Thanks for the solid explanation.

As a noob that doesn't change my distro too often, I never would have thought of something like this.

[–] nycki@lemmy.world 2 points 9 months ago

I've also seen it as pacman -Sy and pacman -Syu and so on. I really just think "install" should be a subcommand, not a flag. That's really my only issue I guess, I've only ever used pacman via rwfus on steam deck so maybe my usability problem is with that.