This is the same for Intel variant Framework boards.
jrgd
Under what means? The target is public sector and the OS to replace (Windows 10, Windows 11) would be a relatively compatible release target. Fedora is a competent leading edge (Wayland, Pipewire, BTRFS) distro that runs as a 6 month point release. I wouldn't see many reasons to not go with Fedora Workstation as a base unless going for an immutable base or a different core distro (OpenSUSE or Debian mainly).
EDIT: Missed that this is going to be immutabe, so it is likely being based on Fedora Kinoite, meaning there really aren't many alternatives besides OpenSUSE's offerings.
If you are looking for Steam Deck compatibility, PrismLauncher has a page for bootstrapping it to look nice on Deck. PrismLauncher does also support controller navigation, though this breaks for me on my Steam Controller when using SteamInput rather Xinput. Perhaps this is different for the deck's controls?
Obviously for desktop, there isn't much point to doing this unless you really make use of big picture mode.
What repos do you have enabled for your system? The recommended way to install the NVidia proprietary drivers (akmod-nvidia
for classic proprietary drivers or akmod-nvidia-open
for nvidia-open drivers (closed source driver, open source kernel module for attachment)) assumes you have the RPMFusion repos (free, nonfree) enabled in your system. There is also xorg-x11-drv-nvidia-cuda
for CUDA support.
I am curious what repo you are pulling the package nvidia-driver
from as it doesn't appear in either Fedora repos nor RPMFusion. dnf info nvidia-driver
will find this quickly if you don't know what repo the package is coming from. More than likely, installing from sources other than RPMFusion will lead to a poor experience in terms of NVidia drivers. Additionally, ensure you don't have secure boot enabled with NVidia, at least initially. If you really desire or need secure boot, you can follow this guide to register your own MOK.
Additionally (based on recent testing on RTX 4000-series hardware), NVidia may have problems with being stable on Wayland environments other than GNOME. Your mileage may vary, but I had observed severe issues in KDE under Wayland in the past few months.
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
As far as KDE vs. GNOME is concerned: KDE contains a lot of customizable features as an expectation and thus has great support for a wide array of customization. Both KDE and GNOME are extensible, with third-party extensions to extend or change functionality available. What makes GNOME less customizable, albeit supporting stylesheets and extensions, both are not expected to be used in any form (outside of defaults provided via Adwaita), and neither do many independent apps written in GTK3, GTK4. GNOME offers fairly minimal customization options without resorting to GNOME Tweaks, third-party extensions, and unsupported customized themes: all things that can break GNOME as while the customization does exist, the developers don't embrace it and have no expectation to not break it with any update.
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.
A general checklist for flags that software will enshittify:
- owned by publicly-traded company
- backed by VC or other expecting sources of funding
- product is closed-source
- company tries to circumvent open-source licensing of product (often for financial gain)
- product has transferred ownership to a different company (through monetary transaction or similar)
- product incorporates DRM
- organization that owns the product has a track record for bad behavior
On their own, not all of these flags are excellent indicators. Some are better than others in a vacuum. If you see a product start to check several of these flags, it might be time to jump ship early (to a fork or other competing project).
Without getting into more outright malicious possibilities as I don't use Windows and cannot inspect how the application behaves on the platform, you could have things as simple like:
- EA didn't see Linux users as profitable enough to support long-term
- EA/Respawn wanted an attempt to garner good will from the community by dropping support for a minority platform
Given the Linux initramfs targets a block device as a file that then gets mounted as the persistent root filesystem, I don't think it would really be possible to unmount / and replace the location with a file. Root isn't represented as a file or directory in any filesystem structure and is a construct of many Unix and Unix-like kernels.