From: General Schvantzkoph on
On Thu, 03 Jun 2010 03:38:02 +0000, Stefan Patric wrote:

> On Wed, 02 Jun 2010 19:59:23 +0000, General Schvantzkoph wrote:
>
>> On Wed, 02 Jun 2010 19:04:28 +0000, Stefan Patric wrote:
>>
>>> [snip]
>>> I would prefer if Fedora went to "rolling upgrades" where as you
>>> update at some point the current release becomes the next. Nothing
>>> special need be done. There has been discussion of this on the Fedora
>>> forums, but so far, it's only been said by the developers that it is
>>> "being considered" which means it probably won't be implemented.
>>>
>>> Stef
>>
>> A rolling update would be fine assuming that you could go backwards and
>> forwards on individual components. That's a very hard problem because
>> there are so many inter-dependencies. Over the years I've stuck with a
>
> That problem/ability was discussed recently on the Fedora forum (in
> conjunction with rolling updates), but it seems that yum, the Fedora
> package manager, already has that ability (though somewhat simplisticly)
> to "rollback" an update to a earlier version. However, it's is not
> perfected.
>
>> particular Fedora release longer than I would have liked because there
>> was some important application that was broken in newer releases. The
>> last thing you want to happen is to lose some critical program because
>> an update replaced it with a newer broken version. The current release
>> system gives you check points that you can always return to.
>
> You can exclude the updating of anything you want, but it can cause
> dependency issues. Usually, the transaction analysis checks for those
> problems, and it's gotten very good at it, too.
>
> Stef

The problem of being able to upgrade one particular subsystem without
having to upgrade others is important and needs to be solved, not just in
Fedora but also in RHEL. Anyone who uses RHEL/CentOS/SL knows how
difficult it is to use because everything is frozen in time. There is the
obvious problem of not being able to run it on new desktop/laptop type
hardware because the antique kernel lacks the necessary drivers. You can
make an excuse for that because the distro is aimed at servers. However
even in the environment that it's targeted at, RHEL and clones can be
very difficult to use. For example I just installed a couple of InfiniBand
cards on a pair of server boxes. I put CentOS 5.4 on the systems figuring
that it should work out of the box (they were older IB cards). The IB
market is almost entirely a Linux market because IB is only used in high
performance applications. The OpenFabrics (OFED) stack is free software
by everyone's definition (dual licensed GPL/BSD) and the drivers are in
the Linux kernel. As it turns out the process of making it work was very
time consuming because the version of OFED that's in RHEL 5.4 is so old
as to be totally useless. There were two options available, one was to
use an ISO that Mellanox created that has the current version of OFED
compiled for RHEL. The 5.4 compatible version became available about the
same time as Redhat released 5.5. The packages are compiled for the
initial kernel which means that you can't ever do a kernel upgrade on
that system once you've done the install. The other alternative was to
download the latest version of OFED from the OpenFabrics site and compile
the RPMs yourself (that's what I did). In that case you can do kernel
upgrades at the cost of doing new compiles every time you do an upgrade.
When I asked the Mellanox FAE how big companies handle updates his
response was that they don't do updates. That means that all those Wall
Street trading systems (which are mostly IB based) don't ever get
patched. If RHEL maintained multiple versions of OFED instead of just one
then this wouldn't have been so difficult, all I would have had to do is
select the appropriate rev and install the packages from Yumex. Future
updates would then be handled painlessly.

A mechanism that allows you to control the revs of individual sub systems
rather that tying everything together would also allow enterprise to
distinguish between critical sub-systems that have to be locked down and
non-critical sub-systems (CUPS for example) which would work better if
they could always be completely current.

From: Matt Giwer on
On 06/01/2010 07:46 AM, RayLopez99 wrote:
> Update: Linux anti-Windows trolls please keep out.

It is difficult to keep out as you are clearly only bright enough to use
windows.

Anyone who knew anything about computers and given the user you describe --
very like yourself -- then you would know it is application not the
distribution that matters.

As such things have been explained to you many times and you are unable to
grasp something so simple and so obvious people despair in ever being able to
simplify the discussion to a point where you can grasp the answer.

--
After you switch to the new light bulbs you forget
where you keep the spare bulbs. It is a very
strange feeling.
-- The Iron Webmaster, 4265
http://www.giwersworld.org/antisem/ Antisemitism a10
Sun Jun 6 02:34:18 EDT 2010
From: William Poaster on
Matt Giwer wrote:

> On 06/01/2010 07:46 AM, RayLopez99 wrote:
>> Update: Linux anti-Windows trolls please keep out.
>
> It is difficult to keep out as you are clearly only bright enough to use
> windows.

That's debatable.

> Anyone who knew anything about computers and given the user you describe --
> very like yourself -- then you would know it is application not the
> distribution that matters.
>
> As such things have been explained to you many times and you are unable to
> grasp something so simple and so obvious people despair in ever being able to
> simplify the discussion to a point where you can grasp the answer.

In other words, a dumb troll.

--
FreeBSD 8.0 64-bit
Kubuntu 10.04 64-bit
Mandriva 2010 64-bit