ShittyKopper [they/them]

Alpine is completely separate by RHEL by a country mile (hell, it doesn’t even use glibc). You’re probably thinking of Rocky

I don’t see why it wouldn’t. You may need to enable a config option or two though. Documentation isn’t NixOS’s strongest suit.

It doesn’t have to. I ran Sway on Nix the entire time I used it, and I know Hyprland supports Nix as well

GNOME’s stance on user customization has been “users can do whatever they feel like using 3rd party tools like Gradience or entirely custom CSS, but if you’re a distro maker then only use the Approved Ways™ to customize things”

Now, I have zero clue if that solves anything (it very likely doesn’t), but it’s actually more than most people give them credit for.

I’d say “go join in on the issue tracker and tell GNOME about this” but hearing from some people who tried that before you I’m not too hopeful that would do much of a difference. All I know is that complaining here isn’t going to solve anything.

Decentraleyes - prevents tracking through content delivery.

Decentraleyes is AFAIK severely outdated. Use LocalCDN if you must, though I personally am not convinced there’s any real threat model where these are useful.

I surely hope you’re not running those two next to uBO. Multiple ad blockers WILL conflict.

Both LocalCDN and any anti ad-block scripts are useless nowadays. uBO by itself does quite a bit of defusing itself as long as no other extensions conflict with it (so, make sure it’s the only ad blocker you have) (also enable the built-in annoyance filters. They deal with anti-adblocks as well)

Noscript can also be replaced with uBO’s dynamic filters/advanced mode. Read it’s wiki if you want to learn how

The thing about NixOS is that while using packages are easy, creating them are still really hard and/or undocumented.

With most popular services already being packaged by people who know what they’re doing this isn’t that big of a deal, but when I want to try out something from Joe Schmoe’s GitHub (or worse, something I made myself) it is much easier for me to throw together a “good enough” Dockerfile and compose.yml together in barely a hour of work than to dig into Nixpkgs internals and wrestle with Nix’s syntax.

Because of the way it works, you can try out on a VM for a bit and move your config over to real hardware trivially if you end up liking it. That’s how I did it before I realized how immature it’s rocm support is and had to switch back to arch

I think “Plasma 6” just means “run everything off -git packages” for now.

Definitely not Gentoo based, but if you can get by with their unique approach to basically everything, NixOS can be pretty interesting, in that while it is technically source based, binary caches are widely used to basically “pretend” to be a binary distro. And it does let you patch things shouid you want it (at the expense of recompiling everything that even slightly comes in contact with the patched package)

There are some parts that are too “baked in” to change – requiring systemd, for instance – so that may be a dealbreaker for you.

That could possibly also explain why the XFCE spin was so broken for you.

XFCE (as a desktop, individual apps probably do since it’s GTK3) does not support Wayland yet.

Just leave the pirates be. People who’ll buy the game will buy the game regardless. Even the strongest DRM won’t get you more sales if people don’t want to buy the game. Piracy can also allow for word of mouth marketing though take that with quite a bit of salt as I don’t have the resources to back me up.

The “free code, proprietary assets” model seems to be the best option so far, as far as I’m aware. Of course this raises the issue of scripts in assets, like Godot’s GDScript. Do you consider them code or assets? It’s up to you of course.

Xorg is not even in maintenance mode at this point. It’s practically a zombie (and the devs are pretty clear that if you want that to change, YOU will have to step up to do it)

Wayland has the basics done bar Gnome being Gnome and Nvidia being Nvidia, and the uncommon use cases are having solutions built for them as we speak, although quality software will inevitably take time. Especially if we don’t want Wayland to end up an Xorg v2, but splintered.

Get something new enough and continue getting something new enough when AMD pushes them out. The drivers suck for anything older than an RX580, and things like Blender require even newer GPUs despite the hardware being more than capable.

Run Arch and use the ROCm’d PyTorch from the repos. Those packagers know what they’re doing.

Other than that, expect everything premade to be made for CUDA. There are some tools like https://github.com/ROCm-Developer-Tools/HIPIFY but they aren’t “there”.

Source: Been running Stable Diffusion on an RX580.