There is certainly a very big amount of fuckery going on right now with nvidia drivers.

“Right now” meaning every year for the past decade or two.

It’s always something with Nvidia drivers. Performance+stability is more the exception than the rule.

That said, AMD drivers have a bad rep too. Personally I’ve had zero issues since I switched to AMD but experiences seen to vary a lot from what I’ve read.

Before that, I don’t think I ever got through a full year without at least one weekend lost to troubleshooting Nvidia bullshit. CUDA is a pain in the ass even on Windows.

The problem here is education.

And I’m not just talking about “average joes” who don’t know the first thing about statistics. It is mind-boggling how many people with advanced degrees do not understand the difference between correlation and causation, and will argue until they’re blue in the face that it doesn’t affect results.

AI is not helping. Modern machine learning is basically a correlation engine with no concept of causation. The idea of using it to predict the future is dead on arrival. The idea of using it in any prescriptive role in social sciences is grotesque; it will never be more than a violation of human dignity.

Billions upon billions of dollars are being invested in putting lipstick on that pig. At this point it is more lipstick than pig.

Debian Stable staying true to form!

Thanks for the writeup. Good stuff.

I’m a software developer first and a gamer second. Being a “gaming” distro does not detract from anything else, really. It just means that getting proper GPU acceleration is easy, and you’re likely to want that for development too. That was actually why I chose Bazzite. I was tired of wrestling with CUDA and ROCm.

It’s not “gaming” vs “developing”. That’s a false dichotomy.

The real choice is immutable vs traditional. And I’ll admit, immutable distros have a big learning curve. But it forces you to learn techniques that will make your life easier no matter where you go. The time I spent wrestling with dependencies on Debian or Ubuntu or OpenSuse just because I didn’t know about Distrobox…

Unless your needs are very narrow and unchanging, you’re likely to run into something that’s a giant pain in the ass no matter which distro you choose. I used to use Ubuntu LTSR so I could install a few big things in easy mode, but it made everything else harder because it was so outdated. Switched to OpenSuse Tumbleweed and everything was modern but those few vendors don’t support it so I had to wrestle with dependencies.

The answer to this problem is Distrobox. It’s the answer on Ubuntu, it’s the answer on OpenSuse, and it’s the answer on Bazzite. I’m never going back to dependency hell because I can just run everything the environment it is specifically designed for.

If you’re wondering “should I use distro X, Y, or Z”, the answer is simply “yes”. :D

On bazzite, your search order for apps/packages should be something like:

1. Flathub
2. ujust. This is more for general configs than specific apps, but take a look at what it offers.
3. Homebrew
4. Distrobox
5. Podman/Docker images
6. rpm-ostree

rpm-ostree is a last resort because it compromises the “atomic” principle of the system, but in a pinch it will give you access to anything you could get with dnf on a regular Fedora install.

Don’t sleep on Distrobox. I have a Debian box so I can run Signal from its official repo and install Geany with both GUI and CLI support. Once you export applications from distrobox they behave like first-class citizens within your desktop.

I strongly recommend trying Distrobox. If you instead hop distros, you’re going to find yourself in a similar situation eventually, where something is unreasonably difficult. That’s why Distrobox exists; so you can get the best of all worlds.

Thanks for posting the solution!

If you happen to be using a BTRFS or XFS file system, you might want to try duperemove. It will help you reclaim usable disk space without deleting any files, by using those filesystems’ built-in support for data deduplication and copy-on-write. In other words, it will make duplicate files point to the same data on disk, but still work as individual files. Files will appear and function exactly the same, and editing one copy will not change another (unlike with hard links, for example). That way it won’t interfere with cases like Flatpak or Python virtual environments where you really need multiple copies of the same files.

Generally speaking, xz provides higher compression.

None of these are well optimized for images. Depending on your image format, you might be better off leaving those files alone or converting them to a more modern format like JPEG-XL. Supposedly JPEG-XL can further compress JPEG files with no additional loss of quality, and it also has an efficient lossless mode.

Do any of them have the ability to recover from a bit flip or at the very least detect with certainty whether the data is corrupted or not when extracting?

As far as I know, no common compression algorithms feature built-in error correction, nor does tar. This is something you can do with external tools, instead.

For validation, you can save a hash of the compressed output. md5 is a bad hashing algorithm but it’s still generally fine (and widely used) for this purpose. SHA256 is much more robust if you are worried about dedicated malicious forgery, and not just random corruption.

Usually, you’d just put hash files alongside your archive files with appropriate names, so you can manually check them later. Note that this will not provide you with information about which parts of the archive are corrupt, only that it is corrupt.

For error correction, consider par2. Same idea: you give it a file, and it creates a secondary file that can be used alongside the original for error correction later.

I also want the files to be extractable with just the Linux/Unix standard binutils

That is a key advantage of this method. Adding a hash file or par file does not change the basic archive, so you don’t need any special tools to work with it.

You should also consider your file system and media. Some file systems offer built-in error correction. And some media types are less susceptible to corruption than others, either due to physical durability or to baked-in error correction.

Android uses MTP as the transfer protocol. The Debian docs suggest Gigolo to mount devices with MTP. See: https://wiki.debian.org/mtp#XFCE

I’m on Bazzite now. It certainly made my life easier as far as GPU drivers go.

However, be aware that it comes with its own learning curve. It’s an “immutable” distro, and it has like half a dozen different ways to install software. You can’t use dnf like you would on regular Fedora. The idea is to get apps from Flatpak, or use Distrobox, or use Homebrew — all things that run on top of the base OS so you can use a monolithic “immutable” OS image. There are pros and cons to this approach.

Once I familiarized myself with Distrobox (BoxBuddy makes this a lot easier) and using Flatseal to grant Flatpak apps direct access to the folders they need to operate (like my music library on an external drive, in the case of my music player), it’s been pretty smooth sailing. But I do miss just being able to run sudo apt install <whatever>.

Well that sucks. You might be able to try “The Debian Way” mentioned here: https://help.ubuntu.com/community/Upgrades#The_Debian_way_of_upgrading

(Ubuntu is derived from Debian, which is why “the Debian way” works.)

The gist is to replace all instances of “noble” with “oracular” in your /etc/apt/sources.list file, then run some commands to do the distro upgrade.

Cool. I could well be wrong about the double-step requirement. It sure sounds that way, but the Upgrade Notes page is very old so maybe it’s easier now? Keep us posted!

On further investigation, it looks like you’d need to do an in-between upgrade to 24.10 before going to 25.04. I didn’t realize that before. It’s been a long time since I upgraded an Ubuntu system.

Here is the relevant documentation you’d need for upgrades:

From 24.04 to 24.10: https://help.ubuntu.com/community/OracularUpgrades/#Upgrading_Ubuntu_Desktops_to_24.10

And then basically the same thing again to go from 24.10 to 25.04: https://help.ubuntu.com/community/PluckyUpgrades#Upgrading_Ubuntu_Desktops_to_25.04

In case you’re not familiar with Ubuntu’s naming and update conventions, I’ll explain briefly, because it’s confusing for beginners: Each release has a name and number. The names loop through the alphabet in the format “Adjective Animal”, and the numbers are the release date in format “year.month”, with new releases every six months, in April and October. Then there are the “Long Term Support” (LTS) releases that are released every two years, matching the April “xx.04” main releases. You’re currently on “Noble Numbat” (24.04), which is followed by “Oracular Oriole” (24.10) and “Plucky Puffin” (25.04). Totally intuitive, right?! -_-

OR you could back up your stuff and install a clean 25.04. I’m not sure if the installer has an option to retain an existing home folder. Again, it’s been a long time since I used Ubuntu specifically. Perhaps someone with more recent experience can chime in.

You didn’t mention which version of Ubuntu Studio you’re running. Is it 24.04 LTS by any chance?

My initial thought is that you are probably running Wayland, and that your version of Ubuntu has KDE Plasma 5 instead of 6 and/or outdated Nvidia drivers that don’t work super well with Wayland.

A quick search shows that this is all default on Ubuntu Studio 24.04 LTS, which is the first version you’ll find at ubuntustudio.org. :(

Ubuntu 25.04 (non-LTS) has Plasma 6, which is a very important upgrade if you are using Wayland, especially with Nvidia GPUs.

Just a guess. If I’m right, you have a few choices:

1. Upgrade to Ubuntu Studio 25.04 (non-LTS). It has newer stuff like Plasma 6 that fixes a LOT of problems like this.

2. Switch to X11 instead of Wayland. This will likely introduce a new set of problems though. X11 has no future.

3. Switch to a different DE than KDE. I am not sure what is best in this situation.

4. Install the latest Nvidia drivers manually instead of getting them from the Ubuntu repo.

Option 1 is by far the simplest choice.

The Linux desktop is in a big transitional phase these past few years, as more distros default to Wayland even before a lot of their packages are updated to fully support it. It’s a terrible time to be stuck with outdated “LTS” distros. This is why I hopped away from Debian 12 (13 is out now so yay, but it was a year too late for me).

Oh wow, they already have a 2.0 prerelease build. That was fast!

I’m in no rush. 1.x has been doing its job without demanding any of my attention since I set it up a year or so ago. Setup was a bit complex, but it was definitely worth learning.

There are interesting and important points being raised here, but the particular programming language used is irrelevant. The author is only undermining himself by focusing so much energy on the tired old holy war between C and Rust proponents.

Seems like most mods work fine on Linux, but I’m sure it depends on the game. For games with built-in mod managers like Baldur’s Gate 3, it all just works. For games with manual mods that involve replacing or editing game files, they should generally work since you’re running the same game files to begin with.

I haven’t had any big compatibility problems recently, though again, I’m sure it depends on that game. Proton (built into Steam) works very very well nowadays.

Just a few years ago I found the experience frustrating. It seemed like everything had something wrong with it, even if it wasn’t big. Lots of games had glitchy input, whether using a controller or keyboard/mouse. But somewhere down the line it totally flipped, and everything I play runs great now. I still have a bootable Windows 10 system, but I haven’t actually booted it in…two years, maybe?

This must depend on country and carrier. My carrier has never removed 4G or 5G bands. They’ve added new ones and they’ve phased out 2G and some 3G but that’s all. My phones from 10 years ago can still connect just fine, although obviously newer ones are faster.

I mean that an individual folder will always look the same (consistent), and also look distinctly different from any other folder (unique) if that’s how you arranged it. So you could identify a folder instantly.

Everything in list view looks the same at a glance, and most file managers don’t retain a folder window’s size and placement. Modern macOS kiiiind of does but you have to fight it if you don’t want a single-window browsing UI.

The last time I found icon view useful was in Mac OS 9. There were three main characteristics that made it useful that no current systems have AFAIK:

1. The icon grid was tight (32 pixels) and you could either snap items to that grid or place them freely.

2. Window sizes and places were directly associated with folders. (There was no “browser-style” single-window mode.)

3. File names used dynamic spacing. Longer names would occupy multiple grid spaces as needed.

These factors meant that every folder had a consistent and potentially unique size, placment, and layout.

OS X took the Finder and either ruined or neglected everything good about it. Windows explorer has always been garbage. Never found a Linux file manager with a compelling icon view either (though to be fair, I’ve never looked all that hard). The lack of system-level metadata for layout kind of mandates an abstraction between a directory and its display.

Kind of funny how quickly we’ve flipped from “you should treat LLM output like advice from a random stranger” to “you should treat advice from a random stranger like LLM output”.

Either way, it’s the right idea. If you can’t understand what you’re doing but you do it anyway, you’re going to create all kinds of problems for yourself.