Red Hat Linux 9 Reaches End-of-Life
egburr writes "Well, today is the last day for Red Hat Linux 9. The Fedora Legacy Project is supposed to start legacy support. I am still planning to stick with RHL9, for a while at least. How many others are planning to do the same? How many are switching to Fedora? How many are switching to some other distribution altogether? How many have already switched? For people still using earlier levels of Red Hat Linux (6.x,7.x,8), how well has the Fedora Legacy Project worked for you?"
I'm already using fedora legacy to update rh8.0 and 7.2 boxes (only four fortunately).
No complains.
apt-get update && apt-get dist-upgrade from fedora legacy work flawlessly.
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
Might as well wait until Fedora Core 2 is released.
I can't recall the taste of food, nor the sound of water, nor the touch of grass. I'm naked in the dark. There's nothing - no veil between me and the wheel of fire. I can see him with my waking eyes.
I'm glad to be with you, Redhat 9... here, at the end of all things.
You cannot always be torn in two, RH. You must be one and a whole for many years. You have so much to enjoy, and to be, and to do...
"Music is everybody's possession. It's only publishers who think that people own it." - John Lennon.
Check it out at: White Box Linux
When RedHat decided to throw in the towel for any real distro
When did this happen'?
Redhat just moved people distro where it belongs. Between people.
Redhat still supports development in Fedora, and even funds it. Funny I've been noticing only improvements (since the change) and no stepbacks. Fedora is just as supported as RH ever was, no better, no worse (except there's much more choices now, yum instead up2date, and more public repositories). You'd notice if you try to search package for RH9 and same package for Fedora.
I really don't know what is people problem with Fedora and neither does anyone that didn't jump to conclusion before even trying.
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
If you'd done any research, you'd have found that those nessus hits were false positives, because Red Hat backports security fixes. The products will report a vulerable version, but they are not vulnerable because RH fixed them.
Nessus just looks at the version, because trying the actual expoit is too risky on running systems, many exploits crash the system (or at least the daemon) in the process of exploiting them.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
I've written an article on this topic covering about a dozen alternatives, it's available at:r edhat-support.html.
http://www.seifried.org/security/redhat/20031230-
Your basic options are:
Continue using Red Hat Linux 7.x and 8.0
Continue using Red Hat Linux 9
Red Hat Advanced Workstation
Red Hat Advanced Server and Enterprise Server
Red Hat Fedora Linux
WhiteBox Linux
SuSE Linux
SuSE Linux Enterprise
Mandrake Linux
Mandrake Linux Enterprise
OpenBSD
FreeBSD
Solaris for Intel and Sparc
Windows 2003
Mac OS X Server
The community wrote it.
If you don't trust them, then why the hell are you running the software they wrote?
I've had enough abrasive sigs. Kittens are cute and fuzzy.
> The little money it makes will be sucked out by "legal" pirates
> from its very movement.
As the alleged "pirate" in question, allow me to disagree. Those who need the SUPPORT offered by RH should purchase RHEL3. Those of us who DON'T need the support shouldn't since RHEL3 is 100% Free Software. Red Hat does not sell software since that would be kinda daft, it being Free Software and all that. What they sell is support and if you are the sort of site deploying an Oracle box you will be writing them a check just like you wrote one to Sun when Oracle was sitting on an UltraSparc.
Basically, WhiteBox should be thought of a product between Fedora and RHEL, offering the longer deployment window and most of the stability of RHEL but with the community support more like that of Fedora.
And I have heard my little project from the swamps of Louisiana mantioned by several RH people, but never disparagingly. So if they don't have a problem with what I (and the cAos, tao, etc. rebuild efforts) am doing why don't you hold off on condemming me for another couple of years, until you learn a little more about how the Open Source/Free Software ecology actually works.
Democrat delenda est
My brother's company did pretty much the same thing. Actually, I'd like to elaborate, since the person who asked (and others) may want some reasons to go with the move, and I got all the details.
So first here's the WHO: they are a small web development company. They have several development servers and a couple of deployment servers. They were running Red Hat, all the same version (the kernel configuration and the actual packages installed differred from the production to the work machines). They were using pretty much everything from RPM's, except for some central webdev things (Apache, PHP, Postgres) which they compiled from source because they needed special settings for them. They host they own servers and bandwidth is not a problem.
Now the HOW: They started with one of the development machines, by making a new root partition in the unused space. They chrooted in it and unpacked the base stable Debian tarball, then set up the apt sources to some nearby mirrors and fired up an upgrade to testing (it was a chroot, so networking was already up) as well as apt-get'ting whatever packages were needed to replicate the original environment.
Next they recompiled the kernel and those special apps I mentioned before, and copied over the work resources (projects and stuff). After a Grub setup and a reboot, it worked fine (just a few details to iron out). The whole thing took about an hour and a half (skilled guy doing it, I guess).
Next came about a week of testing. When everything turned out fine, they made a backup of the entire testing machine and then moved the Debian partition to the start of the disk and reorganized it with whatever other partitions were needed (/var, /tmp, swap).
Made an image of the disk, ghosted it to the other machines, restored work environments from backup, and they were done. Actually, the production machines were a bit tricky, but only because they had to make each of them serve everything while the other one was being changed. Plus they had to cross-compile the kernel and the webdev packages for them on the work machines, but they did that all the time already.
And now here's the WHY: why Debian? Because they were looking for: the lowest cost (cheap bastards); no support needed (they relied on their own syadmin -- yeah, one guy); painless package updates, from a variety of nearby mirrors; a distro similar enough to Red Hat so as not to need too much adjusting for the people; another end of life as far away into the future as possible (didn't fancy doing this again in 12 months). They felt that Debian and Slackware would fit the bill, because they were the oldest and most reliable Linux distro's around. (Eventually Slack got booted--you can guess why.)
Finally, a brief overview of why they rejected other choices: Red Hat = too pricey, life-time too short, plus it would imply a reinstall anyway; Gentoo = they felt that compilation and servers don't go very well together, plus Gentoo is too young; SuSE = it came very close, but the beancounters pushed for as little spending as possible; Mandrake = they felt none too sure that it won't dissapear suddenly someday, given it's history of financial problems; any BSD = too much a step from Red Hat. (Fedora wasn't yet a serious option at the time.)
Some of you are probably gonna say they're cheap bastards who wouldn't give back to open-source by at least investing in some support. What can I say, except "small company, gotta cut the expenses to stay ahead these days". The whole switch took a little over one week and cost them just a bonus for the sysadmin.
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
The difference between RH8 and RH9 isn't artificial. Most threaded apps break in RH9 due to the NPTL (there are workarounds, but ISVs don't support them)