[Sussex] Upgrading from RHEL to Fedora

[Paul Tansom]

Chris Jones wrote:
> On 12:17:00 pm 30/08/2005 Paul Tansom <paul at aptanet.com> wrote:
>>problem is that if all goes wrong and the decision is to go back to
>>the original setup I loose any updates that were installed (I won't
> 
> You mean you restore a backup and get it back exactly how it was? :)

Yup, that is a known workable situation and I never like not being able
to easily return to square one. That said there are a few downsides to
the current setup, the key ones being.

i) the cost of keeping the installation up to date with bug fixes makes
Windows look cheap
ii) the current installed system does not support the hardware and has
to be patched

Problem i) is an issue with many of the commercial distributions, the
ones that instantly come to mind are Red Hat and Linspire because I have
most familiarity with them (although I've never installed Linspire in
spite of having 3 legal licenses!).

Problem ii) is definitely an issue with Red Hat, but I can't speak for
other distributions. Until I'd tried it I had assumed that one of the
key advantages of a commercial distribution (prime candidate Red Hat)
was that it could easily include the less than idealogical extras like
(key in this case) the Nvidia drivers. The reality is that although you
can install them with relative ease they are unsupported and any kernel
upgrade breaks them - not necessarily unusual for Linux, but less than I
expected from Red Hat. Oddly on my last Debian upgrade when I'd been
surviving on the standard vesa driver in X I tweaked the setting to look
at installing the Nvidia ones and they just started working!!!

>>go down this path again, but I really don't see subscription to
>>updates as a good solution for the end user - unless there is a means
>>to keep access to all updates that were available when your
> 
> the RPMs are all available anyway from redhat's ftp site.

As far as I know that's the source ones (although these are what I
require to fix the current driver issue). I really don't see it as
particularly helpful to tell an end user to download the source RPMs
manually and manually install them when they are used to up2date! As a
technical user I could, but I'd be looking for a technically better
solution :)

>>basis) - although I think Ubuntu may well fall in that category too.
> 
> Definitely not, Ubuntu is only released every 6 months and once a version
> is released the only time it will get an update is if there is a security
> problem or a serious bug. If you're behind firewalls and proxies then you
> could avoid most updating altogether.

I must admit that although I've heard a lot of good things I've not
actually tried it and half assumed that it was likely to be a more
bleeding edge based approach - perhaps that's just relative to Debian ;)
Initially I though "great I'll give it a go", then I read something
about the user accounts running with root privileges and decided to
leave it. I've now heard that it doesn't, so it's on my list of things
to try - I think it did but fixed it, but I've not looked too closely yet.

>>With Debian stable being so up to date at the moment (more recent than
> 
> haha, say that again in 3 years when they are failing to get another
> release cut ;)

Well to be honest the slow release hasn't really bothered me much. I use
Debian stable on servers and there has been nothing driving me to need
any newer packages than are available. I'm still in the process of
upgrading. I did have an urge to try Exim 4, but no really pressing
need, and I was interested to try Dovecot too. The one thing I did do
was pull Spamassassin from Backports.

Desktop wise I was running unstable, but as soon as Sarge went stable I
backed off to testing - at which point I promptly broke Evolution! This
one is an outstanding issue, but I've switched back to Thunderbird so
don't really miss it much - just annoyed I haven't fixed it yet on
technical grounds!

>>there that has quite cracked the ideal update policy yet, although it
> 
> What is your personal ideal update policy?

Tricky on that. It is actually very close to the Debian way with the
unstable, testing and stable setup. A more organic feed through would
keep the packages more up to date, but leaves the risk of breaking
things with a rogue package a bit higher. What I might do is break out
two versions of stable - say stable-server and stable-desktop. The
server version feeding from testing as stable currently does, but the
desktop one having a slightly faster snapshot cycle. I'd also possibly
look at extra information in the packaging system which marked a package
as a bug fix, security fix, minor upgrade or major upgrade. Then you
could have a system that upgraded on bug fix and security fixes, with
the ability to choose when and how significant the other package
upgrades were. Of course the sheer number of different packages you have
to deal with make this difficult. It might make sense to have libraries
based on a different upgrade process - thereby any applications could be
upgraded more frequently so long as their dependencies were met (since
applications would most likely only break themselves), whereas libraries
and services worked on a different cycle since they could have much more
major repercussions! Quite where this leaves things like KDE and Gnome
that people seem to want the latest of all the time I've no idea -
personally I use XFCE :)

I guess that pretty much means that I'm not 100% sure what the best
method is, I'm just not 100% happy with any of them :) Debian is my
favourite for now by a long margin though.

-- 
Paul Tansom | Aptanet Ltd. | http://www.aptanet.com/