Examples could be things like specific configuration defaults or general decision-making in leadership.
What would you change?
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.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”?I’ve also seen it as
pacman -Sy
andpacman -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.How about
pacman install vim
orpacman --install vim
orpacman -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.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.
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!
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 runsudo 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).
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.
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"
Just curious, why a script instead of just a bash alias or something like it?
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.
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
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.
Like u/lukmyly013 said, I’d love an official KDE version to mint. It isn’t that hard to get going, and I like cinnamon well enough on most things, but there are a few situations where I’d like to have plasma out of the box
They had a KDE version for a while. Ended up dropping it since all of their in-house tools and stuff were GTK.
Now they only have 3 GTK DE options.
I wish Debian picks KDE instead of GNOME as their default DE on the instalation menu. GNOME is so ill-fitted for point release due to its bleeding-edge nature. It works well with Fedora because the distro itself is bleeding-edge (same goes with Arch & Nix).
Arch should have the same zsh profile you have on the live image, installed after the installation by default.
Arch doesn’t have zsh installed by default. In case people wanted this profile - it’s in extra
grml-zsh-config
.grml-zsh-config
is its name, and it’s always one of the first things I install on a fresh system. I’ll never understand why it isn’t the default.
Debian, include /sbin and /usr/sbin in PATH by default.
I’d have Ubuntu stop forcing me to use Snaps.
Maybe you should switch your favourite then?
The enshittification of Ubuntu will not stop on an enforced Appstore.
honestly canonical has always been like this.
what do you suggest for an alternative thats similar to ubuntu?
There where Times when Ubuntu was Marks baby, but nowadays with pro, advertisement and tracking in the terminal an AppStore, everything has to have a businesscase.
I would recommend just plain Debian either with flatpak or in the testing branch. It’s almost the same, stable as a rock and driven by a community.
if i understand correctly the testing branch is similar to ubuntu non-lts?
Somewhat but it is a rolling release. Packages will be major-updated constantly.
is it stable?
Yes it runs quite stable. But the packages and their configuration can change.
If you’re looking for something more conservative, the stable branch fits better but on a desktop it’s very old (like an Ubuntu lts)
The common recommendation is Linux Mint, but there are lots of Ubuntu derivatives out there. Another common recommendation is Debian or a Debian derivative, and those will generally be similar to Ubuntu since Debian is the upstream of Ubuntu.
You can feel free to ignore it if you aren’t open to other options, but my personal distro recommendation for a Gnome-based desktop is Fedora. It has a much quicker update cycle, so you’ll actually get feature updates on your packages (which is great if you use neovim plugins, since the neovim packages in the Ubuntu repos are ancient at this point, or you know, any other package that benefits from being updated). Of course it obviously isn’t as bleeding edge as Arch, though I personally see that as a benefit because I found Arch to be unstable (haven’t really experienced any instability with Fedora in the past few years though). But don’t be mistaken, I’m not saying Fedora is similar to Ubuntu, just providing an alternative perspective since you seem to be open to switching to a different distro (though the differences may be more minor than you think from an end-user perspective).
BTW, Linux Mint isn’t just a “beginner distro”, it’s perfectly fine for anyone to use, and it fixes a lot of the Canonical BS from Ubuntu. I feel like some people get caught up in the thought that Mint is the distro that you ditch for another one when you become more comfortable with Linux, but that doesn’t have to be the case.
I would have Debian go back in time to 1999 and adopt Window Maker as it’s default DE. GNUstep would be integrated and made cross platform. All popular software on windows, Mac and Linux would be based off of it. We’d be used to lightning fast, beautiful DE, with an auto docking paradigm. World peace and the end of hunger would be achieved.
Wouldn’t you have to get GNUstep working first? That seems like a limiting factor in your otherwise admirable plan.
macOS and Linux could indeed have had a common Desktop API. GNUstep was started even before Cacoa and could have kept compatibility with it.
The other problem is that no GNUstep desktop environment ever really got off the ground either. WindowMaker ( really just a window manager, not a DE ) is not written in GNUstep. I imagine it is written in C against the X11 libs.
I like your dream though. I used to dream of the same.
I am pretty sure that GNUstep is cross platform though. At least we have that.
Have you seen NextSpace?
You forgot world peace and hunger.
It’s a pie in the sky by definition. It was the *Step paradigm I had fallen in love with. Very elegant. Mail.app was cool. It’s not the paradigm the industry adopted, in the end. MDI and Taskbar won for better or worse. Just look at the upheaval that Gnome caused by abandoning it, the sheer number of forks.
I miss my Window Maker that came rizzed up to nines by default on Conectiva. It made my 486 fast, elegant, and futuristic. I could listen to MP3, chat on IRC, and have a page open on Netscape all at the same time!
BTW GNUstep is alive. I’ll check out NextSpace, thanks for pointing me there!
Some defaults I would like to see:
-
Have zsh as the interactive shell (And also have its dotfiles in a better location like XDG_CONFIG_HOME/zsh)
-
Btrfs with compression enabled and subvolumes set. (Maybe also timeshift installed, not sure because not everyone uses timeshift for btrfs snapshots).
-
ZRAM (With proper sysctl.conf like PopOS does).
-
Pacman as the package manager with an Aur helper already installed.
-
No bloat™ preinstalled, nothing of shipping flatpak or snap by default or even a DE. So I can just boot into a tty without having to do the minimal install from zero.
-
Comply with the FHS and XDG specs (Arch fucking installs packages to /opt and doesnt set ~/.local/bin as part of PATH)
-
Dont break userspace (arch did this recently with an update to glibc that removed a patch that breaks steam games)
Edit: Also forgot to mention:
- Ship x86-64 v3 binaries, common arch, even Gentoo is doing it while on arch you have to use non official repos.
If you don’t want ANYTHING installed by default you should probably just go for the specialized distros that provide that.
The issue with many of those distros is that it usually means that you have to install everything from 0.
Arch is good at this because the archinstall script speeds it up and you don’t have to choose a DE. But with other distros that use a graphical installer, you are forced to use whatever they ship as the default desktop environment.
edit: And holy shit properly configuring Btrfs subvolumes from 0 is something that I tried with voidlinux and I ended up breaking the entire install.
Btrfs with compression enabled and subvolumes set.
And enable/automate maintenance services for BTRFS. For example:
balace
should be run on heavily used system disks orscrub
could help detect errors even on single disks.ZRAM (With proper sysctl.conf like PopOS does).
Could you explain the preference of ZRAM over ZSWAP? I thought the latter was the more advanced and better performing solution. Is there some magic in Pop’s config?
It is just that zram is much faster than zswap because it uses the ram to store compressed memory. Android already uses it by default.
These are worth reading:
https://old.reddit.com/r/Fedora/comments/mzun99/new_zram_tuning_benchmarks/ https://linuxreviews.org/The_Benefits_Of_Having_A_Compressed_zram_Swap_Device_On_Linux
Thanks for the links! I updated my config from z3fold to zsmalloc and adjusted the vm.page-cluster to test these out.
Reading a bit more, I think when using large max_pool_percent (>30) with Zswap the two solutions are more similar than not. A crucial difference is what use-case is more acceptable since Zswap can cause unresponsiveness (and potential lockup) under high memory pressure. While Zram could result in an OOM crash in a similar worst-case scenario.
-
It would be cool if it officially brought back KDE Plasma.
(Linux Mint)I’m using plasma on LMDE, are you telling me they don’t officially support it?
They won’t answer questions about KDE specifically on their official Discord. Not that it matters.
I wish Debian had better support for software that wants to do its own package management.
They do it a little bit with python, but for most things it’s either “stay within the wonderful Debian package management but then find out that the node thing you want to do is functionally impossible” or “abandon apt for a mismashed patchwork of randomly-placed and haphazardly-secured independently downloaded little mini-repos for Node, python, maybe some Docker containers, Composer, snap, some stuff that wants you to just wget a shell script and pipe it to
sudo sh
, and God help you, Nvidia drivers. At least libc6 is secure though.”I wish that there was a big multiarch-style push to acknowledge that lots of things want to do their own little package management now, and that’s okay, and somehow bring it into the fold (again their pyenv handling seems like a pretty good example of how it can be done in a mutually-working way) so it’s harmonious with the packaging system instead of existing as something of an opponent to it. Maybe this already exists and I’m not aware of it but if it exists I’m not aware of it.
No snaps or flatpak by default.
Nothing. Artix gives me all the freedoms.
I would want a FreeBSD type of packaging system where system libraries and apps are different. Their binary packages are separated into quarterly and latest so you get a very stable OS but either Debian or arch style package updates.
pacman
would allow me to install weak dependencies with a simple command-line option rather than black magic wizardry that rivals ffmpeg filtergraphs.You can use pacman -S --asdeps if that’s what you mean by “weak dependencies” iirc.
What I want to do is install all of these Optional Dependencies that are part of the
wine-staging
package without specifying every one of them:Optional Deps : giflib lib32-giflib gnutls lib32-gnutls v4l-utils lib32-v4l-utils libpulse lib32-libpulse alsa-plugins lib32-alsa-plugins alsa-lib lib32-alsa-lib libxcomposite lib32-libxcomposite libxinerama lib32-libxinerama opencl-icd-loader lib32-opencl-icd-loader libva lib32-libva gtk3 lib32-gtk3 gst-plugins-base-libs lib32-gst-plugins-base-libs vulkan-icd-loader lib32-vulkan-icd-loader sdl2 lib32-sdl2 sane libgphoto2 ffmpeg cups samba dosbox
--asdeps
doesn’t seem to do that.apt
has--install-recommended
, I think, or something similar. And for all the bad things I could say aboutapt
, that’s a nice feature.I think the reason that doesn’t exist is that it doesn’t make sense to install all of them usually. In this case, unless you have a scanner, you won’t want sane, if you don’t have a printer, you won’t want cups, I guess samba might be for AD or SMB network shares which many also don’t use, v4l is for webcams, it’s probably very rare to use opencl inside of wine, and I don’t even know what wine uses dosbox for. And so on. These are optional dependencies for a reason.
–asdeps installs a package as “not explicitly installed”, so it’ll be removed again when uninstalling unneeded packages. So yeah, that’s something else.
For Fedora, replace the current installer (Anaconda) with the openSUSE Tumbleweed installer.
One of the aspects I love about the openSUSE TW installer is the ability to remove groups of packages for the initial install. This is particularly useful if you never use certain programs or intend to replace them with the Flatpak version.
The everything ISO is more granular, but not to the point of openSUSE. Way back in the day you could mess with package selections in depth.