For me, I didn’t like patterns (or the work-arounds). A shame because it (or now, maybe slowroll) might be closer to what I’m looking for, especially if the talk of smoke-testing is true. (though I’ve also seen someone say that Zypper is slow)
I like some of what I’ve seen with NixOS, though I see quite a few things that make it seem like not the answer either. And some of the things (like distrobox) seem like they probably add weight to updating as well (and/or clunkiness, if I have to manually do it).
Also some of my issue is I’m still running a 1050Ti (and Arch putting the legacy drivers on the AUR, a bit of a pain for me… not sure if that has changed though), I know that’d likely be even worse on Nix as well.
EDIT: I’ve tried Flatpak for user apps as well, and needing to download graphics drivers again really defeats the purpose.
Ideally I’d like something that has an update system intended for slower internet. Something that can pull (/keep) slightly older dependencies when user-land stuff is a bit slow, or outright delay/reschedule possibly-broken (for any number of reasons) updates rather than wasting a user’s time and bandwidth. Guessing it doesn’t exist, though (or if it does, it has some other huge workflow flaw).
Mentioning @LostWanderer@fedia.io because they’ve talked about Tumbleweed and Nix.
I remember reading that you couldn’t turn it off unless you outright disabled recommended packages. Reading again, I see conflicting statements and it seems like a common thing people take issue with. Though even locking seems to me like it should just be something that happens during explicit removal, if that is a fix.
So I still kind of hate stuff like that.
My system is currently outdated and mostly usable, but has 4 different application issues (1 crash, 1 flicker, 1 compiling/library error, 1 feature error)… before I stopped updating, rolling updates gave me a few bad rolls that did not fix some of these issues (and if I’d have rolled not even week later w/o reading the news, I would’ve been toasted into terminal-fix-it-now-land).
So I’d say there’s a lot of room for improvement here. I dream of something that works like this:
Non-critical applications may be updated less. Security updates or marked-as-needed-fix more. Alternatively, supporting explicit branches (like Godot’s 3.X and 4.X) in official repos helps. Maintenance updates (nothing known broken) may be delayed if something seems/is-known wrong (build-bots, user reports or comments, upstream fix needed or dependency too new, admin/maintainer intervention etc)
Ultimately, this could mean an update about every week or slower than once a month depending on packages and if the user encounters issues or not. And I’m sure this may be possible with some package system, but again not something default (and less effective if a package system doesn’t provide the needed structure/information).
Hardware wise, yeah I’m otherwise still pretty happy with the performance level I have (and it’s a fine target for my own stylized projects, still working on that). A smaller(+more efficient) system would be nice, but GPUs seem to still be behind/lower-value than CPUs though. Polaris would be fine just to make things easier though, not that I want to buy a sidestep especially when the market is so stagnant. Same thing with workarounds that won’t be really cheaper either (esp, w/RAM etc pricing).
What I’m talking about was an issue with 1 package due to sandboxing, and it was Krita IIRC (something I don’t care about sandboxing on). I think KDE stuff was being pulled in too (I don’t use it, but I do use Kate and few other things that use Qt).