Live data from Hacker News

Ubuntu Rolling Release Proposal

lists.ubuntu.com

71–80 of 92 posts

Re: Ubuntu Rolling Release Proposal

#71
post #50

This repeated notion of a truly converged OS is really annoying and it is very disappointing to see Ubuntu continue to pursue it despite the loud complaints of most of their users. Lets point out the obvious: the user interaction of a small handheld device is very different than that of a computer with a full size monitor and mouse. Thus any os's on those two devices have to have different UI features. That's it. Of…

> despite the loud complaints of most of their users.

Citation needed. All I see are loud complaints of a minority of mostly non-users.

Real users either use Ubuntu with Unity and are happy with it, or use Ubuntu with an alternative desktop (eg. Xubuntu, Kubuntu, Lubuntu) and are happy with it.

Re: Ubuntu Rolling Release Proposal

#72
post #54

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 st…

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.

Re: Ubuntu Rolling Release Proposal

#73
post #48

I'm sure the decision wasn't taken lightly, and I'm sure Canonical has concluded that an 18 month LTS + rolling makes the most sense for the project. As a user, I am a bit worried about rolling releases though. Maybe someone here can alleviate my worries? As I see it, software has to change. The question for distros is just when? A rolling distro sees such changes continuously, and each package may in principle chang…

The decision hasn't been made yet. Canonical's CTO may have decided he likes it, but the Ubuntu project hasn't yet given it a pass. If you've got workflow-critical programs you don't want updating, use the LTS release. That's what it's for.

> If you've got workflow-critical programs you don't want updating, use the LTS release. That's what it's for.

I know. And it could be that I'm just grumpy that I'm losing the great thing Ubuntu gave me: essentially 6 months of frozen Debian Unstable.

Now we might get 18 months of frozen Unstable along with a Testing/Unstable-like rolling thing. Except for the regular-guy-friendly installer, what will Ubuntu really add over Debian anymore then?

What's kept me on Ubuntu for 6 years was that it gave me exactly what I wanted: relatively frequent, but frozen snapshots of Sid! But then again, if I'm in a small minority thinking like this, I won't complain :-)

Re: Ubuntu Rolling Release Proposal

#74
post #30

This could work, rolling-release + LTS. Archlinux seems to be doing quite well under the rolling-release auspice, so why not. Of course, never in my experience has rolling-release ever worked in anything close to production environments - it's what killed FreeBSD in the data centre, however, if you're a techie with some time on your hands it could be cool.

totally dead https://signup.netflix.com/openconnect/software

Not totally dead, it still has some strongholds left, but I'm sure Netflix doesn't use the rolling-release side of it (ports mainly). :-)

Re: Ubuntu Rolling Release Proposal

#75
post #47

Earlier quoted context omitted.

Arch is very good if you run it as your main system and keep it updated very frequently. Forget it for six months (because it's an unused multiboot, or whatever) and try to do an upgrade, and it might be more painful. I got burnt by the glibc mess last summer, where you had to run a specific set of --force things in a given order to get through and if you didn't, well, you lost your /lib (at which point it's game ove…

Couldn't you solve that problem with some type of repository snapshoting/versioning. So if you try to update more than, say, 1 month, the system installs the updates incrementally.

That is precisely what the Ubuntu proposal describes.

Re: Ubuntu Rolling Release Proposal

#76
post #17

I'll miss the bi-yearly fun with trying out a new release, and the name alliteration, but I think overall it's a smart move for Ubuntu. Does anyone have any reasons why they shouldn't move toward this? I'm curious.

If major changes (like dumping Gnome for Unity) get triggered by the same button as security patches etc users might be reluctant to press that button.

And if there's a major change and some users decide to wait before upgrading (while the bugs get ironed out) it's easier to support them if they all wait at the same version.

Re: Ubuntu Rolling Release Proposal

#77
post #50

This repeated notion of a truly converged OS is really annoying and it is very disappointing to see Ubuntu continue to pursue it despite the loud complaints of most of their users. Lets point out the obvious: the user interaction of a small handheld device is very different than that of a computer with a full size monitor and mouse. Thus any os's on those two devices have to have different UI features. That's it. Of…

That would be why they created or are in the process of creating four entirely different UIs for different devices - Ubuntu Desktop, Ubuntu Phone, Ubuntu Tablet, and Ubuntu TV (if that's what it's called) . Have you actually been following what you're talking about? There are different UIs, and they are only converging the underlying codebase. What exactly are you talking about?

Re: Ubuntu Rolling Release Proposal

#78
post #72

Earlier quoted context omitted.

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

Re: Ubuntu Rolling Release Proposal

#79
post #23
post #14

Earlier quoted context omitted.

Yes, I agree that ubuntu's time based releases are generally a better experience that debian's "whenever it's ready" stable releases. Debian's testing and unstable branches are rolling releases though, and those were the only alternatives I was actually considering.

Although, I'm not sure we can even look at the Debian when trying to predict what a rolling release Ubuntu would look like (even considering that they are "relatives"). The current difference in manpower and mind share is pretty big between these two related distros. Regardless of which one each of us may like better, Canonical has the manpower and mindshare to probably have a bit more success with this model. I real…

> The current difference in manpower and mind share is pretty big between these two related distros

Do you realize that Ubuntu uses Debian as a base and most of the effort is actually done by Debian developers?

Re: Ubuntu Rolling Release Proposal

#80
post #72

Earlier quoted context omitted.

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 st…

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.

Post reply on HN