On Saturday 28 May 2005 00:37, Collins Richey wrote: > I get a chuckle out of this. You may not have actually said that the > RedHat enterprise releases are better than other distros, but you have > vigorously sought to prove RedHat totally blameless when confronted by > the effects of their release choices (inclusions and omissions). When > anyone dares to complain, SLA is offered as a panacea for all supposed > failings. Bryan has simply tried to balance against Red Hat bashers who seem to think that Red Hat connot do anything right. Red Hat is not blameless; but neither is Red Hat a Demon Evil. Red Hat has done a lot of good for the open source community. > I find RHEL/CentOS to be a blessing and a curse. I find computers in general to be a blessing and a curse. A blessing in that it keeps me employed; a curse in that that employment can be frustrating at times dealing with the people effects of computers (that is, computers are made by people; operating systems are written by people; computers are used by people: and people are not perfect, nor is anything made by people ever perfect). > It's certainly > reliable (my desktop system has encountered no significant problems) > and the CentOS list is a real gem, but what's going to happen when the > next round of 2-2-2 6-6-6 hits? Actually, it's already underway. Will > there be just as many functions dropped that people know and love and > cannot relinquish without a lot of extra rework, and what new (only > partially backwards compatible and perhaps still in their infancy) > functions will be added that cause real grief and more rework for some > portion of the community? Track Fedora and make up your own mind; this is the way it works and is the original reason for the existence of RawHide (now know by the much more mundane name of Fedora Core Development). Jonathan Kamens, for instance, tracks RawHide on several machines that he uses on a daily basis, and he catches all kinds of issues by so doing. Otherwise, you can at least put of the decision five years until RHEL4 (and by extension) CentOS4 are EOL'ed. If you don't want to spend the time, effort, and money to track RawHide you can track the FC releases (don't bother with Fedora Core Test if you're not willing to track RawHide with it). If you don't want to spend the time, effort, and money to track FC releases, then you really must approach things the classical IT way: read the release notes, and wait on the .1 to deploy at a minimum (in RHEL-speak wait on the U1 at minimum). And run it on a development server set up identically to your production server before trying to migrate production. If you can't afford a development server you really have a problem (one site I work at is in this shape; it's a school, and in that case I roll out to them what I already know works, and in fact waited on a rollout for the CentOS4 release so that I wouldn't be saddled with CentOS3 for the next four years). But you will get what you pay for, even running a 'free' release; you don't want to spend the time before hand you WILL spend the same amount or more of time and a whole lot more grief afterwards if you ignore basic preparations. If you're still employed, that it. I was serious about the 'in my shop such could be grounds for dismissal' remark I made earlier; admins should not be so reckless, and will not be so reckless on my servers. And you don't blindly cron a yum -y update, either. You stage yum updates on a dev box, too, or be prepared for breakage if someone upstream made a mistake (mistakes do and will happen). Things like the MegaRAID driver being upgraded; in that particular case you really must have an identical development server to fully mirror your production server, because the MegaRAID drive can work or not work based on chipset lot number, all other things being the same. The flip side of the freedom of open source is the same as the flip side of any other freedom; with rights come responsibilities. If you want all decisions made for you run Windows. And even then you run a pair of identical servers to roll out deployments (as people who have deployed Server 2k3 SP1 have found out the hard way) or you run considerable risks. Risk-cost-benefit analysis must be done, or you can get burnt, badly. It boils down to just how critical that server really is. For example, a JIT-ERP (Just in Time Enterprise Resource Planning) server being actively used for production line scheduling in a busy factory with a couple of thousand line workers would be very critical and probably would still be running RHAS 2.1 even now, since even RHEL3 is not well-tested enough for that application. Hmm, one might even still be running RHL 6.2EE on that kind of app, given the flack over gcc 2.96 (at the base of RHAS 2.1). A misstep in the deployment of an upgrade there could cause the entire IT department to lose their jobs easily; if done very poorly could cost the whole business if the production line were taken down for an appreciable amount of time. And Linux would never be found in that factory again. This is the market towards which Red Hat Enterprise Linux (R) is striving. > One thing that would help would be a roadmap. It shouldn't be > necessary to pore over change logs to get an idea what is coming. The roadmap exists, and it's called Fedora Core. You can watch it develop in real time. With as many projects and packages as there are represented in RHEL it would be impossible to accurately predict any future feature 18 months distant. Instead, you can track what they are trying to do (and you can track their backsteps!) by simply tracking RawHide. On a development machine, of course. If you don't have time to do this, hire someone who does. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu