Being able to choose the OS and kernel is also important. I would not want my hypervisor machine to load GPU kernel modules, especially not on an older LTS kernel (which often don’t support the latest hardware). Passing the GPU to a VM ensures stability of the host machine, with the flexibility to choose whatever kernel I need for specific hardware. This alongside running entirely different OSes (like *BSD, Windows :(, etc) is pretty useful for some services.
Same here, though more out of lack of control over the host. Libvirt works on basically any distro, and you can easily configure whatever Linux distro you like best for running it. I can’t configure my boot process the way I want on Proxmox (at least not without learning/sidestepping its “convenience” tools/setup).
Looking at this, I’d personally delete both EFI and boot partitions, then remake them with the EFI partition significantly smaller (it should not exceed >100MB used). I have no idea what issues this would cause on Debian, and what specific configuration needs to be changed/updated. I’d guess you need to change the fstab entries, remake the initrds, and reinstall/reconfigure the bootloader.
Any manual messing with partitions, especially rootfs/boot/efi, can easily lead to a broken system. The fix will not be a simple procedure.
As you’re considering messing with your rootfs, I’m going to assume you have a backup. It’ll be significantly easier for you to wipe everything, install fresh new Debian, and copy your personal files over to the new installation.
sudo systemctl status shows you what services are running, sudo systemctl list-units lists everything, including the services that failed. sudo systemctl status gdm.service shows you the status of one service in particular, and sudo journalctl -u gdm.service shows the output/logs of that service.
There’s a decent chance something is not starting due to misconfiguration. I’m guessing GDM based on previous comments. You can also check /var/log/pacman.log (make sure to save a copy, just in case), to see what packages changed/updated.
If you think it’s a pacman issue somehow, you can reinstall your entire system (excluding AUR or self-made PKGBUILDs). Note that this is almost never required to fix an issue. In a properly working system this “shouldn’t harm anything”, but nothing can be guaranteed on a broken system. The command for that is sudo pacman -S $(pacman -Qqn)
had to find and get the dependencies by myself
Luckily, Linux has evolved in the past 30 years. A package manager (one usually comes with your system, like apt, dnf, pacman) will handle almost all direct dependencies for you. When installing Steam, you may be asked which 32-bit Vulkan library you want to install, but aside from that it should get everything automatically. (Hint: vulkan-radeon on AMD, otherwise pick the one for your GPU brand)
Managing and “maintaining” (updating, sometimes cleaning) an Arch Linux installation is definitely more involved than what you are used to on Windows or the Steam Deck. Some people prefer this workflow, as it offers more control over their system. Others prefer an already set up and maintained environment.
Bazzite is a very SteamOS-like experience. You click update once in a while, and shouldn’t have to touch anything else internal to the system. You get Steam and Flatpaks out of the box.
Since Linux gives everyone the freedom to do things the way they want, there will always be people shitting on a specific way to do things. There are definitely good reasons to dislike certain software, but generally you should be just fine. Just because someone thinks their way of doing things is better doesn’t mean you should immediately switch to that.
That being said, the main downside of Steam in a flatpak is the sandboxing possibly getting in the way of modding your games, or games that use unique hardware (like steering wheels or so). steam (pacman package) does not have those specific issues, but it lacks sandboxing (aside from Steam’s pressure vessel for games).
You can continue with Arch if you want, and there’s certainly good resources to learn (like the wiki) or get help (like the IRC or Matrix rooms). It will require you to learn about how to actually set up and configure your Linux installation the way you prefer. Other distros (usually marketed as “user friendly”), like Fedora, Bazzite, Mint, will automatically perform or set up some of the maintenance you’d have to do manually on Arch.
Yeah but that’s not limited to physical DVD size constraints.
The main issue is UX imo. On Windows 11, it’s “5 clicks”, but you have to open the settings app and find the setting two submenus deep. On KDE, it’s right click > configure application launcher > toggle setting > apply.
I was very annoyed when I got this, but remembered that it’s KDE, and turning it off is 4 clicks. Proprietary software often doesn’t allow you to turn this off (easily). Windows has this “feature”, where is the setting?
I don’t think it’s a productive “feature”, but considering it can be turned off so easily I don’t consider it a complete showstopper.
You don’t get control of the incoming port that way. For LetsEncrypt to issue a certificate primarily intended for HTTPS, they will check that the HTTP server on that IP is owned by the requesting party. That has to live on port 80, which you can’t forward on CGNAT.
Probably because they’re incapable of maintaining a distribution: https://manjarno.pages.dev/
Manjaro is not Arch based. They use pacman, but they use their own repositories. They create a ton of issues that way.
Reminder that the license was changed to a “custom” non-free license.
Keyguard, which works on Bitwarden-compatible servers like Vaultwarden
SteamOS is immutable, and has its own updater because of it. While SteamOS is related to Arch Linux, it is far from the same distro.
Regular Arch Linux can install local packages, the process is described on the Arch wiki. SteamOS has no built in mechanism to update without an internet connection, and installing packages manually is not recommended (due to the immutable nature of the system).
In order to update SteamOS from a local file, you would need to figure out how SteamOS updates work, and somehow trick the Steam Deck into accepting your local images. This is far outside the scope of anything related to Arch Linux, and not very well documented. The better option is to update your Steam Deck by connecting it to the internet.
Also of note, the latest version of SteamOS (as far as I’m aware) does not have any significant changes when it comes to controlling the fan speed.
Article doesn’t even cite their sources correctly, typo-ing “Bringus Studios” as “Dingus Studios”
Probably, yes. Dual-booting may also be an option for the one or two games that don’t work.
Not every game works, but as another user pointed out, ProtonDB is a good resource. If you buy a new game on Steam, and it doesn’t work, you can refund it within the first 2 weeks (and below 2 hours playtime) for any reason. That includes “Ths game does not work on my operating system”.
Try WiVRN, it’s not built on SteamVR, and doesn’t have the same issues SteamVR does. You can get it through a flatpak or by using Envision, as described on the LVRA wiki.
I don’t play VRChat myself, but I have to disagree. I’m in several Linux VR groups, and the general sentiment is that it’s not as easy to set up, but works well for the more popular games, including VRChat. This is similar to my experience. There’s good resources (like LVRA) to help people set things up, or when they’re running into issues. I’m also not saying VR on Linux is flawless, far from it, but to describe it as just “scuffed” without context doesn’t explain the whole state of it.
To answer the question in the title: No, because these systems inherently have different architecture. Something like OpenBSD (the OS) is relatively self-contained. Linux distributions have system components that are externally developed, but a user might rely upon.
What exactly is the “problem” you have with Linux package managers? It’s specifically extra complexity to separate “system” and “packages”. This works well for *BSDs that often develop the entire OS themselves, but would pose extra challenges for Linux distributions, where the line between “OS” and “user installed package” is much more blurred.