In my experience, the Debian installer is just confusing. Once you’re past that, the userbase is smaller than Ubuntu’s. Their repos are different too, meaning software packaged for Ubuntu isn’t guaranteed to work on Debian. Ubuntu itself is pretty terrible for its own reasons, so when asked for a desktop Linux distribution “close to Ubuntu” I’d put Mint first. (For general recommendation, I’d probably say Fedora now.)

Debian 13 is still relatively new, so the problems of it being out of date aren’t showing yet. Debian 12 just before 13 released had tons of these issues, like glibc being too old for some binary programs, or the kernel not being new enough for some “gaming” features.

For reference, I am on Arch Linux. I feel I have a good understanding of how to manually install Linux. The Debian installer confused me in many ways, the main one being that “language and region” are closely tied, and selecting en_US “language” forces you to choose an American timezone later in the installer. In general it was a slow install process too. This is something other “user friendly” distros handle much better. A default live environment, a quick installation, and options being there, but having the defaults automatically correct (like timezone).

Like (almost) every other distro, Debian has its own benefits and downsides. These make it a good fit on desktop for slightly more experienced users, or users familiar with apt. This means it isn’t in the list of distros I’d generally recommend to people when they’re not familiar with Linux.

CachyOS has a structure that’s much closer to Arch than Manjaro, but they still replace the majority of Arch repos with their own. I’ve seen both their repos and the optimizations they apply being the root cause of issues on some friends installs.

Use whatever you’re comfortable with, and what you know works.

On that note, Manjaro and CachyOS don’t work. You should avoid them. They both make changes that harm reliability, and both frequently make avoidable mistakes (especially Manjaro). If you need something like those two, EndeavourOS is a better option, or just base Arch Linux.

Arch Linux itself is a good distro, but made for a specific target audience. If you want to tinker with your system and learn along the way, it may be a good option for you. If you want to “set and forget” your media center PC, a stable-release distro like Debian or Rocky might be better options for you.

This website has some good resources for Linux VR and links some support channels: https://lvra.gitlab.io/

A device driver needs access to the system to control a device. There’s a couple ways of going about it, but GPUs are effectively required to use a kernel driver. A kernel driver runs as part of your system, and crashes have different effects from normal programs. If a normal program crashes, the system handles that, the program closes, too bad. If the kernel crashes, nothing can catch that, and your whole computer crashes.

That being said, with this little info on the crash there’s nothing anyone can do except speculate on the cause. It could be hardware, it could be the kernel. Whatever it is, you’d need more information (journalctl -b -1 after a crash and reboot) to diagnose this issue.

Though important to note; if holding the power button for an extended period of time (30s) doesn’t shut down the computer, it is most likely a hardware fault.

It depends heavily on headset. From what I hear, standalones with WiVRN or Steam Link work fine ootb, not much different than desktop gaming with Proton. I have a Valve Index, a PCVR headset. Getting it to run (properly) is a pain. Monado is making it easier, but it’s not 1 to 1 the same experience as on Windows.

Been using it for a couple years, my main ones currently are:

• VR. SteamVR is a broken mess, Monado is pretty much functional, but I haven’t switched yet. Mesa or the kernel sometimes forget about VR and break it in an update.
• QT5 to QT6 transition for my favorite Matrix client, Nheko. Scrolling is a pain, and the clipboard randomly stops working.
• Wayland freedom and featureset is nowhere close to X11. I can’t choose a window manager without locking myself in to a specific featureset on my display server. Stuff like global hotkeys isn’t supported in most applications. I’m still on the godawful GNOME desktop portals, which is most annoying for file picking. I have no HDR support because my window manager isn’t from KDE or GNOME.
• GTK4 apps looking like shit (there are patches luckily), I try to avoid them just because of libadwaita and GNOME’s awful design.

On the note of Wayland, I have switched, and for good reason. Besides unimplemented features, things “just work” a lot better than X11. Still wish I could have effectively bspwm window management with kwin featureset though. (Plugins for tiling are not the same experience)

Most likely yes, and if it works, this is one of the easier options (without needing to develop anything or change workflow). However, not all devices work properly with this. iPhones on iTunes are particularly difficult, as (iirc) they sometimes change device ID immediately after connecting/initializing. If you pass through a specific “USB Host Device”, an iPhone connected to a Windows VM with iTunes may not work.

If you pass through an entire USB controller, like an extra PCIe card or one from your motherboard (if it has multiple), this method should work on any USB device with any Windows tools/drivers.

If a Linux native method exists (which it does according to other comments), that is usually easier to set up than a VM with USB passthrough, but it might change the workflow.

It’s an old blog post, but this doesn’t look very good for System76. At the same time, GNOME (and GTK) is refusing to implement basic features. Stuff like server side window decorations, because they can’t “tolerate” SSD. The hard enforcing of Adwaita theming might make sense in GNOME, but on devices not 100% in the GNOME ecosystem, libadwaita apps have awful UX. I do not want shit like Zenity to take up 50% of my screen space for 3 words and 2 buttons, yet libadwaita enforces it.

As long as you use an AUR helper to update your system (replace pacman -Syu with yay -Syu), and keep the kernel EOLs in your calendar, it shouldn’t be constant babysitting. Updating a (non -bin) kernel from the AUR requires compiling the kernel, which makes updates take way longer, but doesn’t require extra manual maintenance.

You can find when a kernel is EOL on kernel.org. When your chosen LTS goes out of support, you should update (for security reasons). You’ll have to hope the 580 nvidia drivers still support the newer kernel version you move to.

This path allows you to run your setup for as long as possible on Arch, when you run into issues with nvidia support, so does every other distro.

Unless Arch’s lts kernel switches to a newer lts (in a year or two?), you can run nvidia 580 dkms modules and the lts kernel with basically no maintenance.

After that, you can consider something like linux-lts66 from AUR, or switch to another distro if desired. The first option requires compiling the kernel (no maintenance, just processor time), and will keep your system security patched until the last LTS kernel supported by nvidia 580 modules stops being supported.

Whatever kernel you choose, ensure you have the -headers, like linux-lts-headers. That way, the nvidia-580xx-dkms package can install properly.

If you haven’t yet, look into an AUR helper like yay or paru. These significantly improve quality of life when using AUR packages.

The version from their F-Droid repo, SchildiChat[f], has no Google libraries. The version from the playstore includes proprietary blobs to support Firebase Cloud Messaging (Google notifications system). Exodus may be misidentifying this as “Google Admob”, which is not present in the app.

Or the service. Software that goes out of its way to ensure you paid, and poses limitations on the paying customer. Like always-online DRM for video games.

The difference is what code runs on your device. If proprietary libraries are included, F-Droid won’t build it, and it’s not allowed in their repository. There’s a lot to say about whether a FOSS app that relies on proprietary network services is truly “free”, there’s no arguing that an app with proprietary code blobs is “free”.

Take for example an app like NewPipe. The application itself doesn’t include proprietary code, but it contacts YouTube, a proprietary Google service. With the app itself being open source, you can tell exactly what it is doing on your device, and what information is sent over the network. Comparing that to something like Signal, which includes proprietary Google libraries, you’d have to decompile and reverse engineer it to try and figure out what it’s doing.

If you have a FOSS library that interacts with Google Play Services or microG to enable FCM, it would (probably) be allowed on F-Droid. (I’m not on their team, I can’t make a definitive statement about this).

“No Google Play services” falls under “app must be FOSS”. The average publicly developed open source app should not have much trouble getting into F-Droid if the developer wants to. Google Play services consists of several components, one of which is a proprietary library included in apps using it. If your app includes proprietary code, it is not FOSS.

If Signal decided a build without proprietary blobs isn’t worth it, they’re not getting into F-Droid. Forks of Signal exist that remove the Google Play services build requirement, those are in F-Droid.

With either a physical security key (which no “average user” owns), or a damn numeric pin, which is vastly less secure than a password of the same length.

when technical folks act like everyone and their grandma should run arch

As an Arch user, man I hate when people are like that. Arch certainly has a specific target audience. If you (the individual) are comfortable with a distro, and it works well for you, it’s a good option. If Arch isn’t that, then it’s not a good option for you. Some people don’t understand that even the “once a year single command” maintenance is too technical for most.

Having run Arch only the last few years, I don’t know how much it’s improved compared to say 10 years ago. I do know on most of my systems I don’t spend that much time updating or maintaining my Arch installations, usually just a yay, select which AUR packages not to update (the ones I have can have issues updating sometimes), wait for 15-ish minutes (depends how much I have to compile from AUR), and that’s it. From server to desktop, some weekly, others once every couple months. Although I would say it’s more than average, as I have a custom repository with some nightly compiled packages, which has its own issues.

The difference is rolling vs stable release.

Debian 13 is out, and it will stay exactly the same Debian 13 that it was when it released, even 5 years from now. The only changes are bugfixes, security patches, etc. No new features. This means you can basically do unattended sudo apt update && sudo apt upgrade with no problems. By the time Debian 14 comes out, there will have been a ton of changes to upstream software, Updating from 13 to 14 might be a one-click fix, or it might take effort fixing configs and ensuring the new software works.

Arch Linux is rolling release, it does not have version numbers, and does not hold back a major package update just “because it changes things”. This means basically every update might change things, and that can require intervention. If the Arch Linux team is aware of required intervention, it will be put on the Arch News. This is often just one or two commands. The possibility of intervention being required means unattended upgrades are a no-go on Arch, but that’s pretty much it.

If you don’t update your system for say, a year, everything that’s changed in that time will change all at once. This is often still a few commands to fix, but could be more depending on what updated exactly. Updating regularly is reccomended, because it’s easier to tell what exactly changed between updates, and thus easier to track down where a problem originates from.

Depends entirely on the device. On most desktops, you should be able to. On a lot of laptops, this may leave them in an unbootable state (due to GPU option ROMs).

Check for your specific hardware before removing factory default secure boot keys.

This is heavily sensationalized. UEFI “secure boot” has never been “secure” if you (the end user) trust vendor or Microsoft signatures. Alongside that, this ““backdoor”” (diagnostic/troubleshooting tool) requires physical access, at which point there are plenty of other things you can do with the same result.

Yes, the impact is theoretically high, but it’s the same for all the other vulnerable EFI applications MS and vendors sign willy-nilly. In order to get a properly locked-down secure boot, you need to trust only yourself.

When you trust Microsoft’s secure boot keys, all it takes is one signed EFI application with an exploit to make your machine vulnerable to this type of attack.

Another important part is persistence, especially for UEFI malware. The only reason it’s so easy is because Windows built-in “factory reset” is so terrible. Fresh installing from a USB drive can easily avoid that.