Try this again: is Linux Linpus any good?
in [Setup]
|
From: Stefan Patric on 2 Jun 2010 23:38 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
From: Stefan Patric on 3 Jun 2010 02:08 On Wed, 02 Jun 2010 17:24:36 -0400, despen wrote: > Stefan Patric <not(a)this.address.com> writes: > >> On Wed, 02 Jun 2010 10:00:19 -0400, despen wrote: >> >>> Stefan Patric <not(a)this.address.com> writes: >>> >>>> I'm >>>> tiring of Fedora's short life cycle even though since FC6 I've only >>>> upgraded every third release. I want to install an OS once and have >>>> it live on the system for 5 to 7 years--the average time between my >>>> system builds--with updates, of course. >>> >>> Since FC 8, I've upgraded to 9, 10, 11, 12 simply using yum to apply >>> release updates. It's gotten steadily easier. 11 and 12 applied with >>> no issues at all. >> >> You missed the point. I don't care how "easy" it is. I tire of doing >> it. Even every 15 months or so, that is, every third release. > > I think you missed the point. > Going to a new release is no different than applying updates. The point is I want at OS that is supported longer than 13 months that I don't have to change to a new release every year to stay current with the "improvements" of the 'net. That's why I'm looking for an alternative to Fedora. > "preupgrade" changes the repositories, then yum update finishes the job. Yes, I know what preupgrade does. And it is a great improvement over the old method, but it's not without flaws. So, I'll continue to keep my old install as a back up and do a clean install of the new system on separate partitions. > It takes longer, but it's the same process. Start it in the evening, > wake up in the AM and you're on a new release. If it were that easy. It takes me about 3 or 4 weeks to get the "problems" fixed and everything running smoothly after a new install. And from what's being posted on the Fedora forum, preupgraders from 12 to 13 aren't fairing any better. >> And if you didn't have problems after every release upgrade, you're one >> of the lucky ones. > > As I remember, the first 2 gave me some package conflicts, easily > resolved. The last 2 were issue free. I don't think that was an > accident. When the "preupgrade" tool appeared I realized this has been > tested. Yes. You're one of the lucky ones. >> Plus, upgrading destroys the old system. For safety, I only do clean >> installs on separate partitions, keeping the last release as a bootable >> back up just in case. > > You are missing the point. upgrading is using the same process as > updating. It does not "destroy" the system. Of course, it does. Upgrading is like doing a clean install over the old install. The old install is gone, wiped away. Upgrade 12->13? 12's gone, baby. The only thing that isn't changed or touched is the user data and personal user settings in /home, and some admin settings like for local networks, hosts, etc. However, I'd still recommend backing up everything just in case. >> 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. > > Disagree. It's there now, and will only get better. I should have said "rolling updates." Which is not implemented. And that is direct from Fedora development via the Fedora Users Forum. Stef
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 Prev: NAS server setup questions Next: Try this again: is Linux Linpus any good? |