Even Arch Linux could learn from the Arch Wiki.

The Debian Wiki would actually like a word.

There is stuff in there that’s not found anywhere else. For example while researching driverless printing recently I found a huge page on the Debian Wiki but the Arch wiki only has a paragraph saying supporting printers should be detected automatically.

Who made the Arch Wiki? Was it done by the community? Genuine question.

Why can’t the installation create aliases like

flatpak run jellyfin-media-player ? And then highlight conflicts during?

This is extremely simple to fix with scripts that can be automatically created on install time. Here is a quick script I just wrote. It will search for first matching app and run it. Just save the script as flatrun, give it executable bit and put it into $PATH. Run it as like this: flatrun freetube

#!/usr/bin/env bash

# flatrun e
# flatrun freetube

if [ "${#}" -eq 0 ]; then
	flatpak list --app --columns=name,application
else
	app="$(
		flatpak list --app --columns=name,application |
			grep -i -F "${@}" |
			awk -F'\t' '{print $2}'
	)"

	if [ -z "${app}" ]; then
		flatpak list --app --columns=name,application
	elif [[ "$(echo "${app}" | wc -l)" -gt 1 ]]; then
		echo "${app}"
	else
		flatpak run "${app}"
	fi
fi

Edit: Just updated the script to output the list of matching apps, if it matches more than one.

It’d be dangerous if an installed app claimed to be something like sudo or bash. Even if a mechanism was created for flatpak apps to claim a single shell command, there is no centralized authority on all flatpak apps to vet them. If there was for flathub, and each uploaded package was checked, that still leaves every other non-flathub flatpak repo which must implement the same vetting. Because there’s no way to guarantee to do it safely, and because flatpak devs are unwilling to compromise, this is just what we get.

https://github.com/flatpak/flatpak/issues/1188

flatpak run com.github.iwalton3.jellyfin-media-player

You can use /var/lib/flatpak/exports/bin/com.github.iwalton3.jellyfin-media-player instead. and then create aliases or symlinks (for example in ~/bin/) for that.

https://github.com/boredsquirrel/flatalias

Or my PR for that, that makes aliases on every login. I just have to fix it to work with user flatpaks as well: https://github.com/bjoern-tantau/flatalias/tree/patch-1

It would be pretty neat if they did like zsh does, where it asks you if you mean a certain command when you only type it partially.

you’re missing a directory from your PATH if you have to do that. flatpak Has friendly names

You can create a alisis

There’s a reason security people don’t use flatpak, but that’s not it.

While you will get somewhat the same from apt, I like the Debian way of providing base config support in packages and have local config loaded by include statements.

As you don’t edit the default config and automatic updates can happen w/o user input and your config will stay safe

Pacman just dumps you a .pacnew, leaving the comparison to you (y’know, KISS). Your change isn’t touched, unless it’s .pacsave.

Pacdiff does this on arch-based distros

honestly I wished the arch wiki turned into a distro agnostic wiki. i have been using debian for decades and use arch wiki all the time but it would be nice to have a one stop shop for linux documentation. the Wikipedia of Linux run as a coalition.

NixOS is at least starting to work on a new wiki. The old one is gone and is only accessible from archive.org.

Seconded. NixOS’s documentation has consistently been the worst I’ve read, always forcing me to go to the source code to try and understand what in the world is happening. It makes quick changes to new things nigh impossible. I had to resort to taking notes when I understood things about nix in order to retain the knowledge or at least link to where I could easily regain it.

The nixos wiki was marginally better and https://nixlang.wiki/ has been better. However the latter is less known so has less content. All in all, nix documentation is still bad.

Most distros could also learn from Arch and create something similar to the AUR.

i’ve seen Void’s xbps-src tool compared to the AUR multiple times in /r/voidlinux (and i guess it’s like a decentralized AUR?? you can build+install pkgs from source using the package manager, sure, but there’s no one big diy xbps packages registry like aur.archlinux.org for Void) and while i don’t really see it, if you follow that train of thought, void’s pretty set in the “right direction” :D

The Debian Wiki is so much better than the Arch one.

What’s wrong with it?