Hacker News new | ask | show | jobs
by moxie 4864 days ago
What's interesting is that they are in part re-creating the original problem they were trying to solve.

The complaints about Debian were that they only cut a release like every two years. The Debian response was that people who wanted more timely updates could run the "testing" branch, which was a "rolling" release.

Ubuntu promised to solve the slow release cycles and the instability of a rolling branch by cutting stable and well-composed releases on a rigorous six month schedule.

This announcement sounds a lot like the original Debian model they were trying to get away from.

1 comments

A difference is that Debians testing branch was a testing branch, and as such did not have the same effort and priority put in to keeping it stable. Even as a rolling release, I would expect Ubuntu's main reopositories to be more stable than debian tesdting.
From extensive experience, debian testing is way more stable than Ubuntu's current LTS release even.
I would like to learn from others: how do you handle security with testing? I like debian testing very much, and occassionally I have the idea of using this in production, too, but I fear the responsibility to take care of many security fixes on my own. here are the high-urgency vulnarable sources for testing:

https://security-tracker.debian.org/tracker/status/release/t...

but even more surprisingly, this list for stable is even longer:

https://security-tracker.debian.org/tracker/status/release/s...

Can anybody explain this?

(Yes, I will take the shame on me and ask this on a debian mailing list, however, maybe anybody has a good explanation here...)

As follows:

1. Read the vulnerability description.

2. Ask yourself if you are vulnerable.

3. No? Don't worry about it.

4. Yes? External mitigation where possible or patch ourselves and commit back to debian (we a project member on our team).

We've not got to 4 yet, but have committed loads of fixes anyway.

OK, but real life (low budget) scenario is:

1. aptitude update && aptitude upgrade 2. ask yourself, if your system is vulnerable now 3. feel the good hope and go ahead.

If I had the budget / time to research every single CVE I would probably not trust repositories at all...

do YOU trust repositories?

Yeah and that's pretty much good enough for most people.

That's what we do for our internal dev systems.

Yeah, security fixes are the one thing that prevents using testing for real world stuff.

Ubuntu is probably going to take care of this in their rolling model.

labels and your expectations aside, testing usually is pretty stable and non-lts Ubuntu releases are sometimes not.at least with testing you can hope for fixes in less than six months - Ubuntu generally doesn't fix bugs until the next release in non-lts releases.