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 can create a alisis

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

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?

And know how to use an existing btrfs partition. And always [at least have an option to] show exactly what the automatic installer is going to do before I run anything. There’s gotta be a middle ground between “we’ll just surprise you” and “here, do everything yourself”.

I’m on Fedora too and quite often end up on the Arch wiki. A lot of the stuff there applies on other distros too.

NixOS on your mind too? lol

I think that’s what BlendOS is working towards. You might keep an eye on them.

What do you miss in NixOS (Unstable)?

I think a declarative, atomic LTS distro (e.g. Alma) would be quite nice for business use.

How are those new binary applications coming along? is it feasible to mix. I don’t want to compile everything.

the other 2/5 are about printers

Relatable, everyone hates printers

Fedora’s installer is abysmal.

I thought so too. It doesn’t have enough options for power users and too many for newcomers. It caters to a middleground that barely exists.

Enabling access to proprietary software should also install audio/video codecs.

The codecs are also the #1 thing that annoy me in Fedora. Because of shitty US patent laws the rest of the world has to suffer.

Why won’t they just use Calamares?

Fortunately many flatpak browser now comes with codecs, like ungoogled chromium and librewolf.

The installer is the single one reason I can’t switch to fedora. I have several drives in my machine and I like to separate them, but their installer scares the shit out of me. I can pull it off for sure, but I just don’t want to take the risk

I am sure you are aware of this: https://linuxmint.com/download_lmde.php

The Debian web site needs a good UX overhaul. Prioritize the things people are most likely to want, make them prominent and uncluttered, and present a logical flow from one task to its follow-ups.

Just a quick glance yields the simplest example: the download link is not the first or most prominent thing on the main page. Clicking “download” gives you the netinst AMD64 ISO, which is reasonable enough, but there is no indication of how to install it. Clicking “user support” takes me to a page with extremely verbose descriptions of IRC, usenet groups, and mailing lists. I think the fastest way to get installation instructions is to click the tiny “other downloads” link (after I’ve already downloaded the one I want!), and then a link to the manual from there.

This is not a good UX. This is a demographic filter. You can argue that’s appropriate for a technically-oriented OS. 9front explicitly makes itself unapproachable to dissuade casual users, but I think Debian can and should be more appealing to mainstream, casual newcomers.

Slackware needs to learn how to be hip like arch. I’m the baby in our irc group, and I’m 40. All the cool kids are using arch BTW.

Slackware is broken, though.

• Its releases are so far apart that the default installer stops working in between releases cause it can’t handle the changes to the repos.
• Its default software selection is outdated, makes no sense (multiple tools for the same task), and is grouped illogically. If I want to run Xfce, I shouldn’t have to install the KDE group to satisfy necessary dependencies. If I install the base group, all dependencies for using the package manager should be satisified. And Libreoffice shouldn’t be installable only via an unofficial, unsupported third party repo.
• Its documentation is so outdated it isn’t useful anymore:
  https://docs.slackware.com/howtos:slackware_admin:installing_on_uefi_hardware

“Some modern computers have started to offer motherboards that use Unified Extensible Firmware Interface (UEFI) as a replacement for the traditional BIOS.”

Possible in Debian. The SpiralLinux guy (who also made Gecko Linux) has it set up on install.

You mention that their kernel is bloated, would you mind sharing how you measure it compared to other kernels. Such as their kernel vs something more trimmed down. Is it a storage space savings or memory? I’ve never really considered the weight of a kernel when considering different distros so if you have some method I’d love to try and compare what I’m running.

It wouldn’t be too difficult™ to fork their kernel and make custom configs of it. Here’s the git repo that holds their rpms and their respective kernel configs, it’s just that nobody has cared enough to create/propose “slimmed down” specialized kernel images: https://src.fedoraproject.org/rpms/kernel/tree/rawhide You can just clone the repo and point COPR to it, then automatically build custom kernels.

Awhile ago there was a proposal to move the x86 microarchitecture level. Here’s recent discussion on that proposal: https://discussion.fedoraproject.org/t/what-happened-to-bumping-the-minimum-supported-architecture-from-x86-64-to-x86-64-v2/96787/2

In general, though, Fedora would not want to leave any users behind. Instead, the proposal for hwcaps is currently being drafted: https://pagure.io/fesco/issue/3151 With hwcaps, default installs will be x86_64 v1, but will be upgraded to “optimized” packages if available upon updating. This makes packaging a bit awkward, though. Packagers already need to maintain packages for multiple versions of the distro. In fact, they need to support F38, F39, F40, and rawhide atm. Needing to maintain an extra 3 builds for each package on top of x86, x64, aarch64, ppc64le, and s390x is a bit of a burden, so success might be limited.

Distrobox, while feature-rich, is still a bit hacky (though it’s still more reliable in my experience than toolbx). You’re not the first to want this, though: https://github.com/fedora-silverblue/issue-tracker/issues/440

Secureblue removes a good amount of unused kernel component, and even some useful ones like bluetooth and thunderbolts, but you can always manually enable them.