Ubuntu Rolling Release Proposal
81–90 of 92 posts
Re: Ubuntu Rolling Release Proposal
#82Earlier quoted context omitted.
But "stuff that was stable 4 months ago" is not a trivial case either. Suppose A version 1.1 was stable 4 months ago, but that the version of B that works with A 1.1 is horribly buggy still, and the stable version of B needs A 1.0. Do we upgrade A? I can imagine this becoming very tough to mange with 20k-30k packages. I hope Canonical can deal, but I do fear that the users will suffer.
That problem already exists, except currently there is generally a six month minimum before it gets resolved.
I view it differently: Currently, the situation doesn't unexpectedly change for six months :-)
Re: Ubuntu Rolling Release Proposal
#83I think that's a very well reasoned proposal and I'd be very happy to see it implemented. I might be unusual, but I find myself in both of the user groups that the proposal identifies. For my 'utility' machines (home server, XBMC host, web servers) I prefer the stability of the LTS series, but for my laptop I'm happy to trade that stability for getting new stuff sooner, particularly new usability features that are ge…
Re: Ubuntu Rolling Release Proposal
#84Earlier 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…
Ubuntu is probably going to take care of this in their rolling model.
Re: Ubuntu Rolling Release Proposal
#85I think that's a very well reasoned proposal and I'd be very happy to see it implemented. I might be unusual, but I find myself in both of the user groups that the proposal identifies. For my 'utility' machines (home server, XBMC host, web servers) I prefer the stability of the LTS series, but for my laptop I'm happy to trade that stability for getting new stuff sooner, particularly new usability features that are ge…
Your use case is exactly what many of us Debian users have been doing for a long time. I use Unstable on my laptop and Stable (+ backports) on my VPS for those exact reasons.
I think the expectation is the important thing: if an update breaks something, the response I want to see is 'sorry, we'll fix that ASAP and try to avoid doing it again'. I get the impression that Debian unstable (and to a lesser extent testing) is only intended for people who're willing to put up with things breaking often.
Re: Ubuntu Rolling Release Proposal
#86One thing I'd add as a suggestion: if they do a rolling release, hot-rebuild the package so that if you download an "Ubuntu rolling" ISO, you get a 100% up to the minute copy with all the latest security patches and so forth. This so that starting a new Ubuntu install is not annoying (which it would be if you basically had to throw away and redownload the whole OS as updates as soon as you installed).
Re: Ubuntu Rolling Release Proposal
#87This 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…
>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. And what happens in-between? What happens in the case of tablets? Notebooks with a touchscreen? Future devices like large format displays with full UI, and future paradigms like gesture control?
Re: Ubuntu Rolling Release Proposal
#88Earlier quoted context omitted.
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.
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?
Re: Ubuntu Rolling Release Proposal
#89Earlier quoted context omitted.
Your use case is exactly what many of us Debian users have been doing for a long time. I use Unstable on my laptop and Stable (+ backports) on my VPS for those exact reasons.
Technically, Debian unstable is close to what I want, but I don't want to be using something that comes with 'at your own risk' warnings day to day. I think the expectation is the important thing: if an update breaks something, the response I want to see is 'sorry, we'll fix that ASAP and try to avoid doing it again'. I get the impression that Debian unstable (and to a lesser extent testing) is only intended for peop…
Re: Ubuntu Rolling Release Proposal
#90Earlier quoted context omitted.
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?
That's what we do for our internal dev systems.