RAM could be a cheaper culprit. Try re-seating it.

Do not use Manjaro. It is a known trap. What you can do is install pamac, which is what Manjaro uses for GUI package management. It’s been a hot minute since I’ve used Arch, so here’s a tutorial:

https://itsfoss.com/install-pamac-arch-linux/

Alternatively you could look at Garuda, which is a solid Arch distro. You’ll either love or hate the theme, but that’s easy to change. It also comes with an interactive kernel by default (most distros use a regular kernel build, which works better for servers).

Whatever you do, please please please not Ubuntu. It’s the lowest common denominator. Emphasis on “lowest”. It was good in the past, but Canonical have really lost the plot.

Inadvertent oracle attack.

For your use case, consider it to be a packaging format (like AppImage, Flatpak, Deb, RPM, etc.) that includes all the dependencies (including services, not just libraries) for the app in question.

Should I change this?

If it’s not broken don’t fix it.

Use Podman (my preferred - the SystemD approach is awesome), containerd, or Incus. Docker is a graveyard of half-finished pet projects that have no reason for existing. Podman has a Docker-compatible socket, so 100% of Docker tooling will work with it.

I have read on more than one occasion that Wine is becoming the “Linux Gaming ABI.” It’s no longer just about Windows. With the huge variety presented by distros, Wine is simply a nice stable target that never moves.

Try forcing it to use Proton (game properties in Steam).

It does. I have it enabled and tested. “Client Device Isolation.” It’s enabled per SSID.

Ooh I like the idea of “no Internet.” I do trust all of those devices (open source), but they could still be pwned.

All this, and while you’re at it, Donate!

MacOS is a BSD, so go with Linux if you want variety.

I heard it in a podcast, but here’s a written source on that: https://fedoramagazine.org/pipewire-1-0-an-interview-with-pipewire-creator-wim-taymans/

The message is still to use the PulseAudio and JACK APIs. They are proven and they work and they are fully supported.

I know some projects now use the pw-stream API directly. There are some advantages for using this API such as being lower latency than the PulseAudio API and having more features than the JACK API. The problem is that I came to realize that the stream API (and filter API) are not the ultimate APIs. I want to move to a combination of the stream and filter API for the future.

Switching over to the discrete GPU work in the efi/bios might help. Optimus (the driver that chooses between discrete and integrated) is known to be a steaming pile.

PipeWire wins in the feature-set game, which is why it is being preferred over PulseAudio.

According to the inventor of PipeWire, this is the wrong perspective to take. PipeWire is preferred over PulseAudio as a server, clients (apps) should continue to use the PulseAudio/JACK APIs because the PipeWire API is not designed for general use (it’s designed for things like pipewire-pulse and pipewire-jack).

I’m not a fan of Rider, it’s just that OmniSharp outright breaks on large/real-world projects and Visual Studio doesn’t work on Linux. I don’t use their products out of choice.

The biggest hurdle to open sourcing proprietary stuff is often 3rd party code, but we can indeed hope.

What do you mean? Apple doesn’t have a package manager at all. Brew is a fucking mess that takes ages to do anything.

I use NixOS on my personal machine and nixpkgs on my work Ubuntu (22.04 LTS). In the absence of NixOS I would not be using it: it somehow breaks all the file (open, save, etc.) windows, causing any app that tries to open one to crash (particularly annoying for browsers).

Not to mention the wrapGL issue.

It needs more polish on “genericlinux”. I did previously use it on MacOS, and it did make MacOS almost bearable - definitely years ahead of brew.

GPU drivers. It uses the Ubuntu 22.04 (LTS) userspace side of drivers. Could be incompatible with your kernel. Had all sorts of graphical weirdness with my AMD GPU with flatpak Steam.

Silverblue doesn’t solve the same problems as Nix, or Ansible for that matter. I built my own in the past and it was non-trivial - although the CI process could pair quite nicely with Ansible. IMHO the primary advantage of Silverblue is that updates are a download, with practically zero work to do after the download has completed (this is a very big deal for RPM-based systems because an update boot can take a long time).

As for Ansible vs Nix, try switching from one program to another across all your machines. It’s doable but not fun. Now try switching back across all your machines. Nix makes your system equal a configuration, it does not add configuration.

Probably less resource intensive: https://conduit.rs/.