If only Cycles would ever work on AMD Polaris…

Though honestly, I’ll probably get around to a GPU upgrade eventually. Rocm packaging looks to be pretty much done on Debian, although they still seem to need time on the problem of keeping it reasonably up to date in Testing and Sid - momentum will probably pick up after Trixie leaves hard freeze and goes stable.

Honestly, it’d be kind of nice to have a project with a repo that does nothing most of the time except during the Testing freeze, in which it would deliver package updates and keep Testing as a rolling release during that time.

I get why Debian doesn’t do this themselves - they tried and found it hell to both prepare a stable release and package new versions.

Two things:

• What input device(s) are you using? Are you using the built-in laptop keyboard, or a gamepad of sorts. (By Balatro, I’d assume it might even be happening with mouse.)
• Are you running these games on a platform like Steam, or are you running another way? (I’m assuming the answer is yes to Steam, by Balatro and Stardew.)

For Steam, try messing around with Steam input settings and see what happens.

Oh yeh. The font menu is crap. I can’t argue with that.

It’s one of those mysterious annoying things that’s up there with the GTK file picker in some apps taking 10 seconds to load.

But I also don’t change fonts that often. Still, that has much room for improvement.

Debian Stable actually updates Firefox ESR through the typically on by default security channel.

The current ESR version in there is 128, which is about a year old, which replaced the 115 that came with Debian 12 by default.

The newest ESR, 140 just came out 2 weeks ago. 128 still has 2 months of security updates, and 140 has already been packaged for sid. I have no doubts 140 will come before those 2 months are up.

Now the KDE thing actually sounds like it sucks.

As with others, I love Debian Stable.

Most packages have sane defaults, and it’s so stable. It’s true that it sometimes means older software versions, but there’s also something to be said for behavior staying the same for two years at a time.

If hardware support is an issue, using the backports repo is really easy - I’ve been using it on my laptop for almost a year with no problems that don’t exist on other distros. If you really need the shiniest new application, Flatpak isn’t that bad.

It also feels in a nice position - not so corporate as to not give a darn about its community, but with enough funding and backing the important stuff gets maintained.

What do you mean by “window roll-up”?

Also, the settings menu thing is weird - mine takes less than a second to load, and I’m on a machine with a 7 year old processor at this point. I almost worry that if that takes a long time KDE will be more miserable performance-wise, unless you’ve already tried it on here.

By the way, what distro and XFCE version are you running - just for good measure.

The outdated sentiment is probably based, honestly. I think it’s gotten better, but there are rough edges. In the end, do what works for you.

I feel like a lot of your points were true at one point, but are becoming lest relevant.

For one, at least with XFCE, I found myself not really running into DE bugs.

Also, I don’t think two years is as obnoxious anymore. During the era of the GTK 4 transition a couple, it drove me nuts, but now that a lot of APIs like that have stabilized, I really don’t notice much of a difference between Debian Testing and Stable. I installed and daily drove Bookworm late in its lifecycle on my laptop, and in terms of DE and applications, I haven’t noticed anything. I get the feeling Debian’s gotten better at maintenance in the past few years - I especially see this with Firefox ESR. There was a time where the version was several months behind the latest major release of ESR, but usually it now only takes a month or two for a new ESR Firefox to come to Debian Stable, well within the support window of the older release.

Also, I don’t think Flatpaks are a huge dealbreaker anyway - no matter what distro you’re using, you’re probably going to end up with some of them at some point because there’s some application that is the best at what it does and is only distributed as a Flatpak.

Frankly, I probably am a terrible reference for gaming, as I’m a very casual gamer, but I’ve found Steam usually eliminates most of these issues, even on Debian.

Also, the official backports repository has gotten really easy. My laptop had an unsupported Wi-Fi chipset (it was brand new), so I just installed over ethernet, added the repo, and the install went smoothly. There were a few bugs, but none of these were specific to Debian. Stability has been great as ever.

In conclusion, I think right around Bookworm, Debian went from being the stable savant to just being an all-around good distro. I’ll elaborate more on why I actually like Debian in a comment directly replying to the main post.

I might disagree with 99.999% like you - maybe I’d put it in the 50-75% range.

Before you give up on XFCE and/or Chicago95 - have you replaced the default menu with Whisker Menu? For me, Whisker Menu is a must-have for any sane XFCE user. When I used it with Chicago95, I found I could have a Windows 7 style interface with Windows 95 aesthetics.

Honestly, even if Chicago95 is aesthetically not what you want, I’d recommend trying an alternate theme on XFCE - I currently use modified DesktopPal '97 combined with a pack of Haiku-style icons.

Overall, I’d be interested to know more about your qualms with XFCE and see if customization can help you overcome them. A lot of distros have annoying defaults for XFCE, but I changed a few simple settings and have a desktop I rather enjoy using. It is totally fine if it still isn’t the thing for you after any potential discussion, but I just want to make sure you really know what XFCE has to offer before you move on.

I’d take a well-maintained native package for my distro over a Flatpak, but sometimes, a Flatpak is just the the easiest way to get the latest version of an application working on Debian without too much tinkering - not always no tinkering, but better than nothing.

This is especially true of GIMP - Flatpak GIMP + Resynthesizer feels like the easiest way to experience GIMP these days. Same with OBS - although I have to weather the Flatpak directory structure, plugins otherwise feel easier to get working than the native package. The bundled runtimes are somewhat annoying, but I’m also not exactly hurting for storage at the moment - I could probaby do to put more of my 2 TB main SSD to use.

I usually just manage Flatpaks from the terminal, though I often have to refresh myself on application URLs. I somewhat wish one could set nicknames so they need not remember the full name.

And that is still largely true - I’m still running XFCE with xorg on Debian, and I think the only issue I’ve had was Waydroid.

Will there come a day where what you say is true? Yes.

However, right now, a more apt example to convey your point is systemd; that’s true for most distros with a lot of community support. Even then, its hold isn’t absolute - Alpine seems like the most livable non-systemd distro, though I could be wrong.

As I’ve commented elsewhere on this post and others have said, this is a change that affects pretty much no one. I didn’t even know MBR (legacy BIOS) partition tables on UEFI boot was possible, honestly.

By no longer putting in the effort to maintain this bit that no one uses, work can be put to something someone uses.

Also, with Linux, specific distros can get encrapified (kind of happened to Ubuntu), but as others have said, there’s usually always another distro to jump to at worst.

For those panicking about it, this is not something you need to worry about. Here’s what this actually does:

Enforce the use of GPT partition tables for all UEFI-based Fedora installations for x86 architecture. This removes support for installing Fedora in UEFI mode on MBR-partitioned disks on x86 systems

You probably have already been using GPT on your UEFI system since you had a UEFI system. Even if you somehow were using MBR, this probably;

1. Won’t break existing installations, as it’s merely support for installs of this type
2. Would not be a problem even if somehow the broke existing installs, as it’s not difficult to convert MBR to GPT.

As much as I resonate with the issues, in this case, this isn’t what they’re doing at all.

This drops support only for UEFI on the MBR partition scheme typically used by a BIOS setup, which I honestly didn’t even know was possible.

This ends support for no hardware - almost all distro installations on UEFI have defaulted to GPT partition tables for a long time.

That’s not what this is saying.

It’s only support for UEFI on the old MBR partition table - GPT partitioning has been the default for ages now.

Also used it before, for Rounds I believe.

You’re right that it was power-related - one of the options was an ASPM modification - but the issue seemed to be common to this chipset accross laptop brands.

The fix I used came from this post: https://bbs.archlinux.org/viewtopic.php?id=286109

My machine was a Thinkpad, but this article was also talking about problems on HP, Asus, etcetera. I think the 8852BE might just be cursed

To be fair, I was using an E series Thinkpad, but in my defense, the E series seems to have improved a lot in the past few years - this was luckily the only issue I’ve had. I’ve had much more difficult times with Linux on other laptops. Heck, even my desktop had more setup than this when I was first starting out, though it was because I was using a Broadcom Wi-Fi card, as I also dual-booted with a Hackintosh and macOS only supports Broadcom Wi-Fi chipsets.

Otherwise agree, but I did run into pain with Realtek on my Thinkpad - the module would sometimes crash and disconnect entirely (on a PCI-e level) from the system.

I did manage to find a fix, but I would not recommend Realtek to someone.

Vulnerabilities certainly do exist, but I’m pretty sure the attacker has to be well-equipped

I’d call it a protection against data getting cracked in a petty theft, but if your attack vector is much more than that, there are other measures you should probably take. I think Clevis also works with Yubikeys and similar, meaning the system won’t decrypt without it plugged in.

Heck, I think I know someone who just keeps their boot partition with the keys on it on a flash drive and hide it on their person.

In my case, no; it’s all a single machine - it is in the initramfs and uses the system’s TPM to (relatively) securely store the keys.

It can be set up with an attestation server, but you certainly don’t have to do it. The Arch wiki has a really good article on getting it set up.

I use Clevis to auto-unlock my encrypted root partition with my TPM; this means when my boot partition is updated (E.G a kernel update), I have to update the PCR register values in my TPM. I do it with my little script /usr/bin/update_pcr:

#!/bin/bash
clevis luks regen -d /dev/nvme1n1p3 -s 1 tpm2

I run it with sudo and this handles it for me. The only issue is I can’t regenerate the binding immediately after the update; I have to reboot, manually enter my password to decrypt the drive, and then do it.

Now, if I were really fancy and could get it to correctly update the TPM binding immediately after the update, I would have something like an apt package shim with a hook that does it seamlessly. Honestly, I’m surprised that distributions haven’t developed robust support for this; the technology is clearly available (I’m using it), but no one seems to have made a user-friendly way for the common user to have TPM encryption in the installer.