[hlieberman]

Running Debian testing is generally the practice I recommend on systems which are single-user, like desktops and laptops. It's quite stable and very up to date, except for a couple of months in the run-up to freeze.

Disclaimer: I'm a Debian developer.

[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.

[ChrisSD]

I've been told before that this advice isn't appropriate for anyone who isn't a Debian developer. Things can break and testing may not get important security patches until a while after unstable and stable.

[ohazi]

Not a Debian developer here. I've been running both Debian testing and unstable on various machines for about a decade and it's been great.

In my experience, the "here be dragons" description of testing/unstable is way overstated... they're both very reliable. If you install apt-listbugs and `apt-mark hold` anything with bugs that sound scary, you'll be fine.

It seems like a lot of people try Debian stable (perhaps thinking of it as an upgrade path from Ubuntu), are surprised by the ancient software packages, and then look elsewhere. Debian might want to consider changing the recommendations they make for new users. Instead of stable / testing / unstable, they could be server / workstation / testing.

[ufo]

I think that having to check the issue tracker before installing packages is exactly the kind of thing that people are talking about when they say "here be dragons". By your argument, we would also be able to call Arch Linux a very reliable distro. It can be if you know what you are doing, but it isn't something I would want to recommend to the average user...

> Instead of stable / testing / unstable, they could be server / workstation / testing.

I would love to see something like that, but I think it would need significant changes to Testing to make it usable for the masses. Some years ago there was some work towards that direction with Constantly Usable Testing, which explains some of the challenges: https://old.lwn.net/Articles/406301/

[hlieberman]

The security patches is certainly a concern (though testing-security does exist, albeit not with the coverage of security-updates from stable). In my experience, testing is quite stable for 95% of packages; I can only think of a few instances in the last decade that testing has really broken my computer in a way that required me to break out my developer skills. More frequently, you'll find packages which can't be installed because they've been dropped from testing due to RC bugs -- but that's not necessarily a bad thing!

[thrwayxyz]

Who ever told you that has no idea what they are talking about. Debian testing is more stable than the average release of other distros.

[ufo]

I've had a more pleasant experience using Fedora than Debian Testing.

Debian is great in general but the wonkyness surrounding the freeze period gave me the impression that Debian Testing really is something that should only be used if you are interested in helping Debian produce the next Debian Stable release. Some packages don't get timely updates and are only updated close to the freeze period, in preparation for the next stable release. And during the freeze period itself everything is super awkward because preparing the next stable release takes priority over keeping Debian Testing usable.

[andrewshadura]

Wait, that can't be right. Preparations for the release precisely is the work needed to make the testing usable, since testing is the future release.

[lamby]

For all the same reasons... I would recommend Debian unstable (ignore the name).

[ohazi]

I've used Debian unstable and agree, but given that most packages in testing usually only lag behind those in unstable by a few weeks... any particular reason?

[chungy]

That's kind of the same question I would have about choosing testing over sid.

If the intention is to be on rolling-release, you might as well just use sid. If you'd rather just be on rolling-release until the stable release is carved out (new features desired, for example), testing is pretty fine since it will transition into being the stable release.

[lamby]

In my experience, testing is (across the entire release cycle) often more buggy than sid, especially as it will get scant detailed attention in, say, the first year after a stable release. Using testing (for me) is usually just another annoying speedbump too - for example, one's issue is usually fixed in unstable and you are "just" waiting for it to migrate but it won't due to some boring, unrelated reason about 7-dependencies deep that might take a week or so to be resolved...

[h43z]

The problem with testing is you may wait for security updates much longer.

[xmichael999]

Running Debian, and in my case Devuan never leaves me hanging. Ubuntu and similar distro's often break everything with a regular update. Thanks for your hard work, a huge fan for 20 years+!!!

[diehunde]

Is there a testing image for Buster already?