[blihp]

As a long time Debian user, I think you're doing Debian a disservice giving that advice. Debian testing is stable... except when it's not. Tell people that it's relatively stable, not that it's stable. And please don't tell them to run their daily driver on it unless they know what they're potentially getting into.

My own experience is that things can be broken for months in testing and of course good luck finding any help when that happens. For example, since the freeze for Buster I had broken sound drivers for a couple of months until someone else found that it wasn't actually the drivers but another broken package that as of a month or so ago still wasn't fixed (but the problem had been reported)

That's been my experience with testing for the last 3-4 Debian releases: it works great... except for a handful of annoying bugs that seem to linger almost until release. And assuming you know exactly which package is broken (which can be difficult to narrow down for driver/system level issues), you may or may not get the problem addressed in a timely manner. Then there's also the case of the occasional package that you depend on that disappears from testing for a month or two for any number of reasons.

[denormalfloat]

> I had broken sound drivers for a couple of months until someone else found that it wasn't actually the drivers but another broken package that as of a month or so ago still wasn't fixed (but the problem had been reported)

I had the _exact_ same problem (the issue ended up be a MIDI program called timidity). The main problem for me was that Debian doesn't give any advice on how to report such issues (the website is firmly planted in the early 90s), and the mailing lists I found all appear to be dead. I wish Debian had a slightly more modern website.

[blihp]

That would be the one! I posted a stackoverflow question along with my workaround not knowing the cause. Fortunately, someone else identified timidity as the root cause. Definitely one of the stranger issues I've run into using testing in recent years, but far from the only one.

[yaantc]

Yes, big transitions with desktop environments can lead to glitches for a while too. Theoretically independent parts can be upgraded at different times, but show subtle compatibility bugs not captured in the dependencies. I experienced this with big KDE Plasma updates. Nothing too big, and when you know about it it's easy to avoid with temporary pinning.

Like all rolling distros, it's best to be a bit technically savvy and know your way around the distro to handle those glitches. That's the big interest of stable: no bad surprise. Stability is not just lack of bugs, it's also lack of changes with the unavoidable little regressions here and there. There's room for both stable and current, but it's different and criticizing stable because it's stale misses the point IMHO.

Anyway, I agree with you that testing (and rolling distributions in general) are probably not a good idea for newcomers. For those who like to roll their sleeves and dig in once in a while, and like to learn, then fine.

Also, people usually don't need the latest in all. So stable with a few select up to date packages is usually a very good compromise. Just get the latest for what you really care about, and for the rest the no worry but slightly old is just fine. With flatpack/snapd and each language package manager this mix and match is really easy to do and probably a better trade-off than a rolling distro for many people (but not all, so just use what's best for you).

[ohazi]

I think it's reasonable advice if the user explicitly wants a rolling release, and knows what that entails.

What other options do I have if my criteria are:

- rolling release

- not Arch

As far as I can tell, Debian testing is still the least headachy way to get a rolling release, with the added bonus of out-of-the-box compatibility with most of the "we support Linux!" software that only ever gets tested on Ubuntu.

During my ten years (five release cycles) of using Debian testing, there hasn't been an update that required get-out-the-recovery-disk levels of surgery to fix. All of them have been minor user-facing software bugs or package version inconsistencies that could be safely ignored until I had the time or the inclination to investigate. But yes, you do have to be willing to poke around a bit, and not everybody likes that.

But this is why I wanted a rolling release in the first place. I prefer to do minor repair work on a regular basis (but on my own schedule) in order to avoid major repair work every 6-24 months (on somebody else's schedule).

I also don't really mind the investigative work when something goes wrong, since it forces me to learn more about how my system works, and that knowledge invariably ends up being useful later. Some people absolutely hate this, and they would probably be better off using something else.

[petre]

OpenSuSE Tumbleweed, Void Linux.