On Sat, Nov 3, 2012 at 12:32 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
> On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
> > [...]
> > * Upgrading every year, with an unreliable upgrade process, is not
> > something you have to do with a proper stable OS
>
> I am not sure why you call it unreliable ... I *never* reinstall
Because I read the forums =)
It's not usually terribly unreliable for me either. But I'm a smart
cookie like you. I update my systems with yum and I know what I have to
do to make it work properly - I follow the instructions and I know how
to wiggle my way around dependency issues. This is second nature to me
as I'm sure it is to you. You've probably dealt with bugs on upgrades
before that you've forgotten about, even. Also, I don't use third party
repositories. Normal people do. Especially with a distro like Fedora
which doesn't ship Flash, proprietary drivers, Chrome...
I've been hanging around user forums for Mandriva, Fedora and Ubuntu for
a decade now and I can tell you, every time a new release of any of
those comes out, the forums get a big dump of people with problems
upgrading.
What kind of problems? "I did upgrade and now my sound card does not
work?" or actually problems with the upgrade itself?
The former would just have happened with a reinstall as well.
The number of variables involved in one is astronomical. Note
that neither Red Hat nor Microsoft actually support major version
upgrades for their operating systems,
Microsoft does. They do even sell upgrade boxes ...
much lower levels of churn,
No they actually have way higher levels of churn ... just think about
it ... in fedora we are talking about 6 months worth of chrun not 5+
years. Can't speak for Red Hat but maybe this is one of the reasons
why they don't support upgrades.
(Also note how much trouble phone companies have
updating Android.)
That has more to do with how bad forking is for maintenance ... we
don't really have this problem in fedora (ubuntu is driving themselves
into this corner but that's OT).
I also know what we do to test upgrades before we sign off on a
release,
which is 'do a clean install of F-N in a VM and check it can be upgraded
to F-N+1'. If that passes, we ship. That is not a level of testing which
allows me to declare with confidence that our upgrade process is solid
and reliable ;)
Well it means that the process works. Everything else are bugs in the
packages itself which you would have hit during a normal yum update
otherwise.
> unless I really had to (moving one installation from i386 to
x86_64).
> Otherwise I always upgrade using either anaconda back in the days and
> then preupgrade.
>
> There is some weird attitude that "upgrades don't work anyway people
> should just reinstall". Not only is a reinstall a lot more work it is
> just not something you could ask from a user to do every 6-12 months.
>
> Technically there is no difference between an upgrade and package
> updates just the package set is larger, it just makes dealing with
> stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
> the whole system it will regardless whether you upgrade from FN-1 to
> FN or doing a "yum update" in a rolling release.
Well, kinda. The advantage of a rolling release is that it tends to
narrow the focus. You don't have a million people hitting five hundred
potentially destabilizing updates all at once; you have a million people
all getting one potentially destabilizing update at a time (or, at
least, a fairly small set at a time). When everyone starts yelling, you
can just look at what got updated the night before and probably find the
culprit. That's what happens with Rawhide, after all. And anyway, I
don't think a rolling release would be *better* from this point of view
- as with my other points, I think a rolling release would allow us to
do *just as well* while reducing our testing and development overheads.
In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then
a week later they deal with bar-1.0 to bar-2.0, then a week later they
deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model,
everyone gets to deal with foo, bar, monkeys and five hundred other
changes all at once. Which is chaos on a stick.
But then you have to deal with this kind of stuff every time you
update something. That's not really usable if you want to get work
done.
While the bigger upgrade leaves only hits you once or twice a year.