From: General Schvantzkoph on 3 Jun 2010 08:26 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 6 Jun 2010 02:38 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 6 Jun 2010 10:14 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
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: How do I tar to another computer? Next: Try this again: is Linux Linpus any good? |