Ah yes, did mess up looking at the specs table for bitrate modes. Correcting root comment for anyone else who views this thread.

You will need either an Intel discrete GPU or NVidia GPU if you want to use HDMI 2.1 to render at 8k@60. The Intel discrete GPUs have physical hardware that convert to HDMI and Nvidia uses proprietary drivers. If you can use displayport, any GPU (AMD, Intel, Nvidia) supporting displayport 1.4 is suitable for up to 8k@31 (limited to 8bpc). A displayport 2.0-capable card with a cable suitable for UHBR 13.5 should be able to handle 60 hz (8bpc) or a UHBR 20-rated cable capable of 60 hz at 10bpc.

It depends a bit on perspective and use-case, really. A flatpak’d application can be a fully-featured (all dependencies bundled) package in order to be portable. However, most flatpaks you might commonly encounter don’t quite do this. A good portion of the libraries may be distributed in common runtime packages. This will be the case if you use flatpaks from Flathub or Fedora. There still can be bundled libraries with vulnerabilities, but in many cases, there are basic dependencies from external, common library sets.

As far as varying dependency versions, a developer may be on a host with either newer or older dependencies than expected by the user, but as long as the developer’s application (and any unique libraries) are compiled against a common runtime as previously mentioned, it does make distribution to a wide variety of distros (LTS, 6-month, and rolling alike) relatively easy.

In comparison to OCI images (the kind of images that make up Docker, Podman, and a good portion of Kubernetes container images), flatpaks are a bit less extreme. Flatpaks contain much the same kind of files and structure that a standard distro package would, but simply get sandboxed into their own environment (via bubblewrap). Additionally, flatpaks don’t necessarily need system-level access for installation and usage (full userland confinement). It heavily depends on host environment and configuration, but typically OCI containers are a full, minimal, immutable filesystem structure run in a virtual environment. Not quite a virtual machine, as (in Linux anyway) they are run on the host (almost always in a sandbox) without extensive virtualization capabilities being needed. The general difference in security capabilities depends on the differences in sandboxing between a flatpak behind bubblewrap and an OCI container’s runtime sandboxing. There is also the notion with OCI containers being able to run as virtualized users, including root. With OCI containers that can obtain root access and a flaw in the sandboxing of say Docker in its standard rootful mode could allow for root level processes in the sandbox to act upon the host.

From what I can think of in comparison, there is the big problem with Flatpak in that it really isn’t suitable for packaging command-line applications: only GUI applications and libraries. OCI container images are often tailored for running web apps and other persistent CLI applications

KDE has had ICC support implemented for a while now in Wayland. The necessary protocol for ICC support/color management in Wayland recently got merged, so the next release of many popular compositors (plasma 6.3 for KDE) will be protocol-compliant.

You’re not referring to this satire article by chance?

I can only guess the previous BIOS wasn’t enabling every virtualization extension necessary for some applications for some reason then, given that GNOME Boxes did work. Glad you’ve found a solution.

I did accidentally type the relevant command incorrectly, forgetting that sudo swaps the user before subcommands like whoami will resolve. So that command attempted to add the kvm group to ‘root’ rather to your user. I have fixed the command in the relevant comment for anyone else reading this thread. You can try sudo adduser "<username>" kvm, manually substituting <username> for your username. As normal, restart after adding the group to your user. Additionally, I have added a warning to the solution in the original comment of why you may not want to keep this solution enabled forever as well as a way to disable it later if desired.

Based on using a local installation without elevated permissions (outside of /usr/(local)), I can only guess of two things happening:

The first is GNOME Boxes asks for elevated permissions when running or otherwise uses Polkit to gain those permissions. Your user by default likely isn’t granted access to /dev/kvm and running userland software without additional permissions will inherently not allow KVM access.

To allow this sanely, you can add your user to the KVM group to allow userland KVM access. It can be done via sudo adduser "<username>" kvm and then restarting your computer. To note, this is something that can allow any application to access virtualization without special permissions. If you don’t want this change to remain forever, the command sudo usermod -r -G kvm "<username>" followed by a restart can revert this change.

Alternatively, installing Android Studio via the Flathub Flatpak may handle permissions without needing to modify user groups in this case.

The second (unlikely, but possible) problem is the AppArmor profile blocking KVM access for userland. I don’t have particularly any experience with creating modified profiles for AppArmor, if this is the cause. I could only offer terrible advice for AppArmor (disabling AppArmor or switching to warn-only, both things I do not recommend doing). Again, it might be worth trying to install Android Studio via flatpak to see if things work better if this is the cause.

I am testing this currently to ensure correctness, but if you’re using Android Studio via Flatpak, you may need to enable kvm permissions for the application to have hardware-accelerated VMs. This can be done using Flatseal. The relevant permission (device=kvm) is under the Device section labeled as Virtualization.

Additionally, if problems are occurring outside of Flatpak, you might need to enable certain hardware virtualization technologies from your computer’s BIOS (AMD-V, VT-x, VT-d, Intel VT, Virtualization, or some other similar term depending on CPU and motherboard).

EDIT: Doing testing, it seems the default permissions provided for Android Studio’s Flathub Flatpak includes device=all. No permissions edits are necessary by default. If there are problems with the /dev/kvm device not being reachable, it is almost certainly due to the necessary extensions not being enabled in the BIOS, or your CPU doesn’t support virtualization. Pop! OS 22.04 has the necessary components in software for KVM to function pre-installed, so nothing should be wrong on the OS side.

Superior over what exactly? Most workstation/desktop distros have a graphical software manager and handle drivers in a similar manner.

On my mobile Lemmy client (Eternity), I already keep a multicommunity group for finding tech support posts in case I have something to offer in response. As it stands with [email protected], there aren’t too many posts that are pure conjecture or information and thus doesn’t really clog my feed. If this community grows to have more of these kinds of posts showing up, it may be worth having a split. As it stands currently though, I feel it would mostly serve to significantly lessen what gets posted to this community.

Systemd is both in a lot more large distros than just Fedora, RHEL and has limited viable alternatives (OpenRC as a partial replacement, no others I can think of that come close). While it has its issues particularly with the extra bundled services of mixed quality, SystemD is generally a flexible and suitable option for service management on Linux.

Not to mention how inflammatory the parent comment is.

GrapheneOS only publishes updates for devices with active security updates. Your device is EOL and therefore won’t receive any further mainline updates. It still will receive extended support from the Android 14 legacy branch with whatever security patches arrive in upstream AOSP, but unlikely to see device-specific patches nor firmware patches. Your device isn’t getting the same care and attention that active devices are receiving nor will it receive any future versions of Android through GrapheneOS.

You use Steam for games on Linux primarily. Independent native games exist as well. Many Windows-only titles will be best run through Proton: Valve’s modified WINE bundle. Other store titles can be configured to run through WINE or Proton via apps like Lutris or Heroic (GOG, Itch.io, Epic Games, etc.).

A good amount of distros actively have this functionality. To avoid breaking system packages, you can install the distro package for the given module or as the error recommends: use a venv for the given project.

As to why many guides don’t include it, I suspect as typical for many Linux-centric articles: they weren’t been written by knowledgeable individuals or just in general are writing with knowledge that is often 5+ years out of date.

My top picks currently for distros that support KDE are the following:

• ArchLinux
• Debian
• Fedora KDE
• OpenSUSE Leap
• OpenSUSE Tumbleweed

For your use case (Nvidia, Wayland preferential), the better choices among these will likely be the rolling releases (OpenSUSE Tumbleweed, ArchLinux) or 6 month point releases (Fedora KDE). Debian and OpenSUSE Leap are solid choices for LTS, but given the state of Nvidia and Wayland, it’s best to use the latest releases of KDE and the proprietary Nvidia drivers. If you switch GPUs to AMD or Intel in the future, you should have no issues using any of the distros listed.

To put points against some of the distros your contending list:

Many of the direct Ubuntu-based distros tend to have a certain level of lesser quality in packages (such as many releases never end up pushing bugfix patches that get patched in many other distros including Debian). Additionally, there is no guarantee that Ubuntu-derivative distros that don’t directly source from Ubuntu software repos may have breakages when using PPA repos or developer-distributed .deb packages.

I’m sure you’re aware of this bit as well, but the mainline Canonical-maintained distros (Ubuntu, Xubuntu, Kubuntu, etc.) rely heavily on Snap: a containerized application platform similar to flatpak, but with no freedom of choice of package sourcing. Every Snap package will be pulled from Canonical’s proprietary publishing platform. A lot of derivative distros (Linux Mint, Pop! OS, etc.) end up stripping out Snap from default installations and removing package redirects, recommends for Snap.

For Arch derivatives (Endeavour, Manjaro, etc.), don’t expect to be able to use AUR packages without issues unless your derivative directly sources from the ArchLinux repos. Many AUR packages explicitly expect the latest packages, which some derivatives defer updates to, causing breakages.

In particular, Manjaro has a track record of poor maintenance and questionable choices (recommending users to roll back system clocks after forgetting to renew TLS certs, shipping outright broken versions of Asahi Linux in order to tout support for Apple hardware, DDOS’ing the AUR, etc.)

Debian Sid (the unstable (rolling) variant Debian) is an option, but it’s really not recommended for end-use, and mostly only for testing.

To put points against some of the distros on my recommendation list:

Fedora explicitly only ships with FOSS software. This does mean that initial NVidia driver setup is more involved compared to most distros. The process shortlist is initial boot with nomodeset, install rpmfusion repos, and then install the NVidia drivers from RPMFusion-nonfree. Once that is done, the proprietary drivers should be installed and all configurations necessary should already be made. Simply rebooting should allow using the system accordingly.

Installing ArchLinux specifically expects some knowledge of the inner workings of a Linux system. Modern Arch live images do come with Archinstall: a utility that assists in getting an installation from configuration options. In general, an Arch install is a more involved process. ArchLinux also expects that you read from the news page before pushing updates to your system. While this kind of practice can also be true for many other rolling systems/point releases between feature upgrades, it is fairly imperative that due diligence and backups are taken on Arch systems when updating.

For the most part, you won’t be able to escape Unix-like paradigms when using Unix-like systems. Notably, users have to exist in some form. You don’t necessarily need to give them passwords for the frontend signage, but they need to exist. The shortlist of setting up cage would be:

• install your favorite server distro of choice
• Have a rootless, sudoless user available to use
• install cage and your app(s) of choice
• Add autologin for the user and edit the user’s BASH profile to autolaunch cage
• Attend to any other backend setup (remote access, only allowing tty1 to exist, etc.)
• reboot

It’s not quite a few clicks, but this can in contrast also be fully automated trivially if it’s something you need to setup more than once.

In what way does Windows fulfill a ‘kiosk’ display mode better than Linux for you? Are you looking for permanent installations or just temporary lockdown to a single application. One of the more modern and straightforward methods currently is using cage.

Cage lets you spawn a Wayland compositor from command-line (or via system service, obviously) that launches either a singular or multiple exclusively-fullscreen applications.

What hardware, audio interface, and sound server is in use for your 5.1 Surround setup?

I am under the presumption that the current state of the Intel Arc Alchemist GPUs will likely remain about the same under Mesa even if support is dropped today by Intel. Am I mistaken in the amount of continued driver effort Intel has been putting in for the Mesa GPU drivers?

Obviously if this is true, one should probably remain wary of upcoming Battlemage GPUs.