I’ve been using Pop OS for the last two years at work, it just worked 
no tweaks just using it.
I used to be an extreme distro hoper lol 
until I found EOS, then Pop OS as I needed something with less updates and fixes.
Now I am on Mac for work and making music, but roll a rosetta Ubuntu 24.04 LTS in a VM.
I have an old thinkpad, just upgraded from Pop to Cosmic, its looks real nice, but have the itch to try a couple of distros to see how things stand nowadays including EOS of course!
Synaptic for Debian based distros.
Octopi for Arch based distros.
I’ve installed 21 updated versions of software using flatpak into ‘Trixie’ Debian 13.5 KDE plasma. I used synaptic to remove completely the outdated versions installed using Debian and synaptic. I am still attempting to see how far I can take this.
The flatpak packages are controversial but at least they all work in their modular form. Everything I removed from Debian using synaptic so far has been replaced by a ‘newer’ updated version of the software with the exception of Google-earth-pro which was actually an older flatpak version compared to the one installed with synaptic.
Other than the operational shell why hasn’t ‘Debian’ just dump all of the package software that is old and replace them all with updated flatpaks or appimages? This leads me ask one question. . . How long will flatpaks or appimages continue and who will use them? Why hasn’t this become the norm using linux in the first place. It seems to be a nightmare for distro’s to continue to integrate software as they update themselves fix and update operational shells of their distributions.
I can see some other problems. . . . I installed openshot flatpak v.3.3.1 and then downloaded v.3.5.1 appimage. . . This is another issue I can assume. ( flatpak vs appimage) who will reign supreme in keeping up with the tide of upgrades or updates?
Any thoughts or idea’s on this? It makes some sense but then it doesn’t. Integrating everything into an operational shell seems to be a nightmare at best for developers. Flatpaks or appimages updating seems easier. Who will lead this?
I’ll continue this just to see how far I can take this. So far this leaves me scratching my head.
Rich 
For openshot I would go with the appimage as it is released by them if I was choosing between the 2.
I think the key point there is your own personal update cadence. For zero days, yes, I’ll update asap. Beyond that, usually once a week, occasionally, monthly. So far that’s blunted down the sharp edge of niche bugs.
Going back to my question concerning distributions and the software that work from within distributions (i.e. shells structures).
Do you replace a car when you need new tires? That’s the quandary I am seeing here. . . . If programming is a moving conveyor how does one best decide how to fix issues when it comes to updated versions of software? Does this require replacing all code used to make the shell (environment) function or just remove and replace the program that has made changes to it’s functionality based on the code it was programmed with?
What would be easier? Dropping in the updated software or fixing the whole distribution making sure all coding is copacetic? This is the dilemma.
Windows started this whole mess. . . . making everyone subscribe to what benefited windows and Bill Gates financially along with software developers selling us this ‘new and improved’ version of their software at the cost and expense of the consumer. This is bullshit capitalism. . . we all lose using this model to the greed of a few running the operation. Opensource is the only way to go as long as development guidelines aren’t interfered with by the financial incentives of a few ‘greedy’ people who want to control everything just for the sake of money. Software and programming is indeed a slippery slope. . . .
Rich
Heck no.
Been using EOS exclusively on two desktops and a laptop, all daily driver workhorses, for years now.
Have been in the process of switching tires for past few weeks… From i3wm to sway in wayland. (Hands got a bit grubby, but that’s bound to happen when changing tires; keeps me from grabbing the mouse ).
Should be good now for many more miles to come. 
My main system (and gaming machine) is running EOS on Plasma, on my Thinkpad I am running the same combo - I am and always was a KDE guy, and I settled with EOS 
On my Thinkcentre turned Roon-server I am running Debian 13 Trixie, same as on my two Raspberry Pi 4. One Pi is basically running the much needed pi-hole and a backup Wireguard VPN in case I am unconfiguring my Netbird stuff, the second one is running some Podman-containers.
My Frankensein-esqe old gaming hardware turned NAS is running Truenas Scale.
Basically, in my world, desktop systems are EndeavourOS, server stuff is boring old Debian stable. None of which I think I am really mastering though 
I dropped Octopi because it relies on Qt-sudo which has been out of date on the AUR since April. At least KDE Discover is in the Extra repo. Or there’s Shelly (default in CachyOS). But Pacseek gets my vote.
I actually meant that in software development terms rolling release software is never labeled as stable. I wasn’t talking about how we personally can get a stable experience with a rolling/unstable distribution.
I have wondered about this though. Does only updating once a month really make it less likely you will have bugs? The bugs might only have been introduced that day.
Or am I being thick?
Absolutely not thick, it’s purely a probability question. In layperson’s terms
x = patch cadence so where x = 30 where the probability of getting a buggy patch is 100. Where x = 1, the probability of getting a buggy patch is lowered as remediation would have absorbed the bug, so 3.33(i) vs 100.
Does this factor in new features which could be buggy though?
This seems like it would work for Debian where you’re only getting bug/security fixes but on Arch I can’t get my head around it.
Imagine 2 different roads 1 with only a couple of cars on it (this is updating say once a week or month etc) and 1 with 100s (updating everytime you see there is an update), while there is chance of a car crash (bugs) on both the 1 with 100s there is more of a chance
Got you. I was thinking of it in the way that even 1 bug could be a system breaking disaster which equals 100 bugs being a system breaking disaster.
I can see where I was going wrong now.
Stable is death.
The only software I’ve ever used that has not had frequent updates and “rolling” releases has been software that is doomed to eventual obsolescence and security holes.
Stable scares me. If your software isn’t rolling, it’s dying.
I’ve never felt like I was in danger of becoming obsolete when I used Debian. For the times when I had zero spare time and no space for any level of cognitive load to troubleshoot and fix, where I just needed stuff to work, and be dependable, *(Debian) Stable fit really well, because it was a snapshot in time that I could depend upon.
*(On the point of security holes, Stable still receives security patches where critical).
RHEL and Debian do backported security fixes, nothing wrong with that.
Allow me to offer an observation…
When it comes to software, “stable” is largely a marketing term. For any vibrant software solution, it won’t be long before the “stable” version will be replaced by a new “stable” version.
As such, the distinction seems more about semantics than impermanence. 
LOL no. It absolutely and emprically isn’t. The release cadence for Stable releases (Debian et al) is exactly the opposite. It explicitly falls upon high level .dot versions which have been proven and cleared of transitory breaks and bugs.