Hacker News Reader

Comment by bayindirh | Hacker News Reader

I'm using testing for the last decade, and it's pretty solid. Testing received the bulk of the "-t64" packages last week (~1.200), and the update went pretty smoothly.

Testing and unstable requires a bit more experience to drive daily, but neither of them just collapses into a pile of smoking ash with an update. They're pretty stable and usable. I didn't reinstall any testing systems since I started using them.

The only thing about Testing and unstable is: "None of them receives security updates. They are not intended for internet facing production systems".

View on HN

Did you just run apt update && apt full-upgrade and all went well?

For me, aptitude showed a bunch of conflicts but when I selected all the required -t64 ones manually, they disappeared. Guess the algorithm is not so great at resolving the changes seamlessly.

Hope that changes until the packets move to stable.

It removed the Bluetooth stack once, because I didn't look at the packages being removed. Other than that, other two big upgrades (~350 & ~550 packages each) went smoothly. It removes tons of libraries and installs "t64" versions, so small glitches like this is expected in testing.

Stable will iron out all of them.

Yeah, I noticed these t64 versions. Do you know if these t64 versions will forever have t64 in the package name? Or will they, one day, revert to their previous package names with the t64 removed?

I'd expect packages to drop the suffix at their next ABI version bump, which changes the package name anyway.

They'll probably remove the t64 suffix when all packages are migrated and t64 becomes the norm. However, I didn't dig the list too much to see what they're planning.

That lack of security updates is the only reason that I'm not using Debian testing or unstable as my daily driver at home.

If it's behind a NAT, there's no serious risk since they can't reach you, but if there's nothing between you and the internet, then it becomes a problem.

Please don't spread these false assurances.

Yes, the probability of being attacked is less but it is a false sense of security. Nowadays, you download loads of code from the internet just by navigating to a website using the web browser. Are you 100% sure there is no bug in the sandbox? How about all the other protocols on your computer, or all the other computers on the same "internal" network. Are you sure, those are 100% resistant too?

Well, Kernel follows the upstream fairly well, so unless something catastrophic like Spectre and the like happens, you follow the upstream closely. Currently Testing runs 6.7.12 from April, 24.

Firefox follows upstream from 24-48h behind, unless something big like t64 transition is happening (which happens once every 5 years or so). Unstable currently provides 125.0.3. If you wish, you can use Mozilla's official Firefox builds updates which arrive as soon as new versions are released. However, Debian hardens Firefox to its own standards.

Other libraries and everything follows pretty close to upstream when the distro is not frozen for release.

Also, Stable has the "Patches in 24h even if upstream doesn't provide" guarantee (which we have seen during Bash's RCE bug). This is what testing and unstable lacks.

So, it's no FUD. It's nuanced. As I said before. Using testing and unstable needs some experience and understanding how a distribution works. Stable is install and forget.

> or all the other computers on the same "internal" network.

Considering we manage all the other computers in the same internal network, I'm sure they're fine. They all run prod-ready software. Some BSD, rest is Linux.

I was addressing the NAT point. NAT itself is not a firewall, there are different implementations of NAT e.g. full cone NAT that are particularly bad if what you expect is a layer of stateful randomness. And a firewall these days is not perfect either btw. if you can get your code to run on the client directly in some capacity.

Debian Testing and Unstable are mostly fine if you know what you are doing - you seem to have a clue. Security guidance is usually for people that need it - those that might not understand the full implications. Even for professionals it can be a useful reminder.

> I was addressing the NAT point.

Oh, OK. My bad, sorry. Thanks for the clarification.

Reply on news.ycombinator.com