My best guess is that it’s not a Flatpak permissions issue as others are claiming; the software is just trying to use your iGPU (which is usually crappy) instead of your dGPU.

Try taking whatever command you use to start the program and tacking DRI_PRIME=1 on the front. This has often worked for me on applications regardless of whether they’re native or Flatpak.

iOS has been getting a bit buggier for me these past few years, but iOS 26 is a whole other level of bad.

With what Google’s been doing to AOSP, I just hope GrapheneOS and LineageOS can hold on just long enough until we can get some livable solution for Linux phones.

I like to use pythonz in this case; it’s a tool to manage Python installs, and it puts the installs in a directory under your home directory, not affecting anything in the system.

It does build each version from source, which introduces some quirks; I’ve found compilation for some Python versions works better with clang, and sometimes, you need to enable build options.

Still, I think this is a good way to do things; just start whichever Python version you want, and then create a venv with it.

The year of Linux on the desktop was the friends we made along the way…

No, I don’t want to spend weeks to learn GDB inside-out, so I don’t have to search online for 15-30 minutes on an AI infested internet every time I want to use it, for each feature I’m using it for that day.

1. Search “gdb cheatsheet” and bookmark it. This looks good, but you have plenty of choices. When you find one you like, you probably almost never have to go to the internet again.
2. Unfortunately, you can’t avoid a search engine while programming; you’re not going to get very far. All you can do is develop your search skills to avoid the slop.
3. If you’re using a statically typed language (C, C++, Rust, etc.) already, basic GDB is comparatively simple. For these languages, not knowing GDB is a bit like an electrician not knowing how to use a multimeter; it’s a matter of necessity rather than “gatekeeping”.

No, I don’t want to gatekeep Linux from “normies”, by making it as user-unfriendly as possible, so I can keep the Linux community a frat club for slur saying techbros.

For your sake, I must emphasize that insulting the people you want help from is not an effective tactic for obtaining help. There are certainly jerks in the broader Linux community, but effectively accusing anyone in this community unable to give you exactly what you want of being a “slur saying techbro” (unless I misunderstand you) is, no offense, an incredibly entitled view to have.

If you wish to make valuable use of internet forums, I would request you take heed of this: www.catb.org/~esr/faqs/smart-questions.html

Anyhow, I wish you luck in your endeavors.

In practice, Machine Owner Keys are a thing, though it depends on Microsoft still signing shim, I believe.

Having Microsoft in the chain of trust rather than a standards body is rather concerning, though.

Modern hardware absolutely should have an encryption processor; TPM just isn’t great.

Maybe it’s just I’m a relative noob to build systems, but gosh, do I love Meson.

The documentation’s pretty okay - not perfect, but better than cmake - and it feels like I can actually learn it by example through looking at other projects’ setups.

I can live with using other build systems for other projects, but for personal projects, I’ll always choose Meson. I’ll always push for it if a project I’m working on needs to choose a build system.

You could do signup through a form and just throw a QR code on a poster.

My university Linux Users Group usually uses Crytpad (which is FOSS and seems federated, and has a flagship instance) to create forms for votes, so that might do the trick for you.

Maybe ask around and request to put up posters in a local library?

Also, see if your local university has a group already, and maybe if the age difference isn’t creepy, see if you can hang with them.

Zaphod’s just zis guy, you know?

It gets less essential the more memory you have, though I have 32GB of RAM on my desktop and still have 32GB swap space, which is probably way overkill, but I can afford it for now become I have a 2TB SSD that still has several hundred gigabytes left and could probably have a bit freed. With the memory shortage caused by “artificial intelligence” companies, I may have to go less crazy on the storage now, though.

If I had any close friends who used Linux, I would install this for April fools.

That just sounds like insufficient swap space, honestly. For part of the summer of 2024, I used a laptop from 2016 with 8 GB of RAM as my man portable devicr. The swap partition size I used was fine for most things but a but small; however, I’d occasionally run Spleeter and run out of memory, leading to the issues you experienced, which were alleviated by just adding a temporary swap file. Before that, I used a gen 1 Surface Go, also with 8 GB RAM.

I don’t like Ubuntu, but objectively, this is probably a hardware issue and not a software issue.

I mean, you can try another distro to be sure, but the chances of it solving the issue are slim.

Wait… It’s a used stick? For future reference, that’s a key piece of information. I’m guessing it had a life before it was a server, making it older than 3 years. Depending on the history of the old laptop, I’d guess there’s a solid chance that stick is just worn out.

I’d disagree on the 16GB part. It’s nice to have, but I think 8GB is perfectly fine for most non-gaming use cases. Heck, a couple years ago, I used a laptop from 2010 with 4GB quite comfortably.

I mean, get at least 16GB if you can, especially in a dev setup, but 8 GB hasn’t murdered that many people yet.

I mean, that’s true, but that doesn’t mean that’s why Debian’s doing it.

If they were solving just that, then they would have just pushed for something like a reproducible tarball where you can point to a commit, branch, tag, etcetera from which that tarball can be reproduced and not bother migrating their package format.

Debian has a serious ease-of-packaging issue that I’ve witnessed first-hand, and I think they’ve made it clear that it’s moreso the ease factor they’re focused on that the security factor.

Not really. If xz were the issue, Debian would have just switched to a different tarball format like lz4.

This is more about Debian packaging conventions being very archaic and requiring a lot of futzing with upstream tarballs and patches.

I have an E16 gen 1 AMD that I run in a similar configuration- 8 GB soldered + 16 GB SODIMM. I’ve had no problems.

I’d recommend what others have suggested - try reseating the RAM and run a memory test. Also, what distro are you using, not that it’ll necessarily help.

Most software on that front works. I usually just use Cura for slicing.