aT LEaZt iT wErKz

HARDER!

Yes, I wanted to do that on stock Ubuntu and doing that on a side (I install it mostly just to /opt) is less invasive than replacing core system packages using packages from Neon. It’s rather not intended to use Neon repos when it’s not Neon. Besides, I wanted to spend 15h on tinkering I guess :)

I have no idea how something like that would work. I was stuck on it calling natively installed executables via dbus and with it uninstalled it wouldn’t launch. I didn’t try too deep, but I don’t think I would be perfectly happy with running everything inside Podman container and having to go outside additionally for native accees wasn’t super fun when I played with Hyprland run like that. Trying to integrate it with display manager and keep it secure wasn’t fun either.

Bazzite, huh?

Removed by mod

Exactly, while RTFM I haven’t have a single issue (apart from the driver quirks itself) and even automated the driver patching for NvFBC. Usual error is using nvidia-dkms and not setting up proper hook to rebuild the kernel module on kernel updates.

What are you talking about? I wish I could do stuff like installing or managing my Arch installations more often, as it’s very relaxing and satisfying. The problem is, my installs never break and there’s nothing to do about them most of the time. I work in IT however and my job throws rocks at me all the time with some bullshit corporate software and horrible Sysadm/DevOps practices and boy’oboy is it frustrating….

If the maximum speed pointer is too slow (which can also be subjective) for your touchpad, this might a be driver bug or some missing calibration for your variant of hardware. Reach out to libinput devs, they track issues here: https://gitlab.freedesktop.org/libinput/libinput/-/issues

For me putting the slider to 1.0 makes the touchpad so fast it’s barely usable

It hasn’t change since mid-2000s if you only talk about the installation process itself. Usually you would have at least some piece of hardware that wouldn’t work out of box and it used to be a lot of work until getting everything in place

AFAIK, the xz vulnerability was designed for Debian based on its workaround fixing systemd service status detection. Even if it shipped to something like Arch, the malicious code wouldn’t load.

Timeshift should only roll back your system and not home folder, unless you explicitly include it (and you shouldn’t, for the exact reason).

X11 or Wayland? Try switching between them to see if it persists

Op has Plasma 5.27, the color profiles from EDID were only introduced now in 6.1

The problem with HDR is that it’s very difficult to get working on X11, to the point that those who tried (NVIDIA, 8 years ago) gave up long time ago and moved on. X11/Xorg is legacy solution that is still there mostly because it always was and things still depend on it.

Wayland can get HDR and it gradually does, but it wasn’t priority for quite a long time as there was much more basic stuff missing, to the point many users wouldn’t switch until recently, and because X was still the preferred display system for most users for such a long time, it wasn’t priority to fill missing gaps on Wayland side and it wasn’t moving forward too fast.

Now that things are coming together, over half of the user base (probably) already switched to Wayland, there are more desktop/WM options on the Wayland side, with fewer showstoppers every year, finally NVIDIA drivers start working on Wayland, color management is also getting closer to be part of the official spec. It’s already possible to play games in HDR, but with some solvable caveats: if a game runs on X11 (which for Wine/Proton the Wayland driver is still experimental) they use swap-chain hack to that’s only available in the gamescope compositor, so either in full blown Steak Deck session or wrapped in nested gamescope instance. This will be more out-of-box when:

1. the stable color management protocol is actually in place, more compositors implement it (currently only gamescope and kwin_wayland have HDR)
2. winewayland.drv stabilizes and implements HDR
3. Wine and Proton run on Wayland natively by default

Ugh, no offence to someone who worked on it but sddm is such a failure of display manager. It was only introduced around 10 years ago replacing kdm. It was meant to be simple (duh, thus the name). It has all sorts of issues and is constantly being fixed, just for something super basic like login screen

Actually it looks surprisingly tidy. Would autohide it (when windows touch it) though

Around 12 years ago, I was able to break Debian or Ubuntu installs on weekly basis due to certain packages being too old, something being missing from repos so being forced to compile stuff manually, dealing with junky 3rd party repos etc. Then after switching, I hardly ever messed anything on Arch while also spending less time tweaking it than I did with Ubuntu. Even if I did break something, it was my fault. And it’s not that I cannot handle Debian-based OS installs if I have to. I think those systems are fine if they work for you by default and stock repos contain everything you need (and it’s usually enough for servers) The problem is, it’s not always like that and you just have to add some custom package (prepared by you or someone else) every once in a while, not necessarily with an official support. This is just plain easier on Arch.

Would change distro to something easier to maintain (like Arch for example), rice the experience to the oblivion, keep it forever :3

Breeze

Nice