[Gllug] Fedora Core 14

Steve Parker steve at steve-parker.org
Fri Feb 10 01:06:36 UTC 2012

On 04/02/12 22:41, Richard W.M. Jones wrote:
> On Sat, Feb 04, 2012 at 07:55:45PM +0000, James Courtier-Dutton wrote:
>> On Feb 4, 2012 2:14 AM, "Tethys"<sta296 at astradyne.co.uk>  wrote:
>>> Indeed. I recall a couple of years ago, someone from Red Hat posted
>>> a list of reasons why rolling upgrades couldn't be done in the general
>>> case, and a bunch of features that weren't possible without an external
>>> installer like anaconda. This was met with a deafening silence from all
>>> those in the Debian world that had been claiming RH was just being rubbish
>>> in requiring an external installer.
>> Don't suppose you have a url for that. I would like to read it.
> There was (just a few days ago) another huge discussion about rolling
> releases.  You don't need me to find it.
Apparently I do; I never saw my previous post on this thread either, 
though, so I'm not sure how reliable the list is?
> This doesn't change what I said in the grandparent article.  Even
> Debian's rolling release generally only works by luck, and dpkg/apt is
> something I constantly have to babysit on my servers.
http://www.debian.org/News/2012/20120209 says:
Upgrades to Debian GNU/Linux 6.0 from the previous release, Debian 
GNU/Linux 5.0 alias "Lenny", are automatically handled by the aptitude 
package management tool for most configurations, and to a certain degree 
also by the apt-get package management tool. As always, Debian GNU/Linux 
systems can be upgraded painlessly, in place, without any forced 
downtime, but it is strongly recommended to read the release notes 
<http://www.debian.org/releases/squeeze/releasenotes> for possible 
issues, and for detailed instructions on installing and upgrading.
> This won't ever change until programmers take a more serious attitude
> to their job, ... programming.  Which in the package manager case
> means going to the library and studying ACID databases (as applied to
> filesystems), formal specifications, and (semi-)formal proofs.
> Perhaps when programmers are held criminally liable for their bugs
> (like, say, civil engineers).  Until then I don't have much hope.
I remain curious as to why RedHat are reluctant to provide even a 
base-line level of confidence to RHEL users. Not even "Install RHEL5, 
Upgrade immediately to RHEL6" is supported. Purely legal/administrative 
reasons? Debian, Solaris, many other OSes manage at least this level of 
confidence. As I say, I am curious as to why RedHat take this stance 
with RHEL. This one thing made "Linux" (sic) look very bad to a recent 
customer of mine.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20120210/1de5a2d5/attachment.html>
-------------- next part --------------
Gllug mailing list  -  Gllug at gllug.org.uk

More information about the GLLUG mailing list