archinstall script worked good for me, i installed arch on 2 kvm yesterday, i just filled blank this script offers and everything was done without me, only one advice, include your users in sudoers file as script doesn’t do that automatically, also there’s gentooinstall script derived from archinstall one

The option to enable Nvidia drivers is buried

You just type Nvidia into Software. They’ll never promote it unfortunately.

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

You might like vanilla then. It has containers for each distro, I’m pretty sure.

What’s wrong with it?

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

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.

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

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

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.

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.

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

Ya, that bothers me too. Not enough to contribute time to prevent it though. So, I do not have much moral standing to complain.

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.

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.

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

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.

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.

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

Why can’t the installation create aliases like

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

That’s like saying you don’t get pyramids because they tip over so easily. It sounds like a you problem.

If Debian fails in the same predictable way every time, for the same reason, it could be argued that it’s very stable, just not functional :) What kind of hardware do you use by the way?

The Arch Linux wiki has been the best source for information for a long time for me. Many years ago the Gentoo wiki was good as well, till they lost all content and had to start from scratch.

Downvote because i like the arch wiki very much and it was beginner friendly enough for me, tho (installed arch as a noob recently)

(Well I did not really downvote to be honest, but if I did, that would be the reason)

Idk about instability but in my experience it always required the highest amount of work to fix and set up (on very different machines) compared to other distros smh

NixOS with YaST support would indeed be an incredibly powerful setup. It would make the whole Nix ecosystem significantly more beginner friendly and even for someone who wants to be a poweruser. It would be really nice to have config options laid out for you in a UI. Most of the time I have to have the options search, and package search websites open because there’s no easy way to get those lists within the console.

What do you miss in NixOS (Unstable)?

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

NixOS on your mind too? lol

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