Slashdot Mirror


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?"

13 of 470 comments (clear)

  1. WSAD by jobsagoodun · · Score: 4, Informative

    WSAD (WebSphere App Dev) doesn't run under Fedora, so I'm with RH9 until it does. Something to do with libc. Heigh ho.

    1. Re:WSAD by Anonymous Coward · · Score: 4, Informative

      I am running it as we speak on FC1. The only issue I've had was when launching sub-VMs, you can solve that by running WSAD with LD_ASSUME_KERNEL=2.2.5 (other "milestone" values like 2.4.1 and 2.4.19 might work too). This is a known issue with older JVMs and NPTL.

      That said, I work for IBM, and I'm using an internal version probably newer than what's available externally. If the above trick doesn't work for you, post your exact problem or an email address and I'll try provide some more assistance.

    2. Re:WSAD by r_cerq · · Score: 5, Informative

      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)

  2. white box linux by ehackathorn · · Score: 5, Informative
    It didn't take long for someone to take redhat's enterprise linux source rpms and repackage them as a "free" distrubution...


    Check it out at: White Box Linux

  3. Re:Just switched... by GigsVT · · Score: 5, Informative

    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.
  4. Dealing With The End Of Life Of Red Hat Linux by seifried · · Score: 5, Informative

    I've written an article on this topic covering about a dozen alternatives, it's available at:
    http://www.seifried.org/security/redhat/20031230-r edhat-support.html.

    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

    1. Re:Dealing With The End Of Life Of Red Hat Linux by freaksta · · Score: 4, Informative

      "Slackware".. you forgot the most important one of all.

      --


      Hrrm... I usually just sign my name.
  5. Re:Short life span ? by _Sprocket_ · · Score: 4, Informative


    Fedora may be the "new" Redhat Linux, but some of the more idiotic corporate users they won't have the synaptic ability to Google that correlation, and will be led to believe that RHL is no longer a "Free" "Hacker" "Distribution" but rather a "mature" "enterprise" "solution".


    RedHat came out to our center last year to do a presentation. One of their claims is that Linux moves too fast for some Enterprise developer's tastes.

    An enterprise application developer will get done certifying that a specific build of RedHat will work with their application to their satisfaction when they realize that the official, stable build of several libraries have already jumped a few increments. Which, of course, invalidates their entire QA process.

    RedHat decided to handle this issue by developing a slower-moving "Enterprise" target. This offers a more stable and predictable platform for enterprise application developers to develop for, QA, and then provide support for their products on that certified platform.

    This was before the Fedora project had been announced. However, even at that point, they were saying that the RedHat Linux we all knew would be the faster-paced, more bleeding-edge version.
  6. Re:Mirror , just in case by ComputerSlicer23 · · Score: 4, Informative
    Have you lost the ability to use md5sum -v? Can't use rpm --checksig?

    You might have to track down a FedoraLegacy key. That shouldn't be too difficult.

    FedoraLegacy packages should be signed by a key (presumably you trust the people running FedoraLegacy, otherwise you'd question why you should install updates from some random OSS project). If they have the signature, either the source is the original, or the keys have escaped FedoraLegacy's control. If the second one has happened, you're screwed. There isn't much you can do to show that the packages are correct at that point.

    Unless you feel it's a major loss of time download the security updates, there's virtually nothing else for you to lose by downloading them from a mirror, if it's fast, and you have a fast connection.

    Kirby

  7. Re:Who's responsible? by sniggly · · Score: 4, Informative
    Thats a fairly clueless statement. Peer code review for all updates of all important software (kernel, apache, samba) is extremely competent, there wont be any backdoors in those! Also you can meet all of the maintainers openly on many different lists and websites.

    With a fedora rpm the actual code will most likely have been either written or reviewed by one of the thousands of professional linux coders be they paid by redhat, ibm or otherwise. Fedora just does the packaging.

    Live & learn....

    --
    Of those to whom much is given, much is required.
  8. I am not a "pirate" by jmorris42 · · Score: 5, Informative

    > 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
  9. Re:SuSE by bcs_metacon.ca · · Score: 4, Informative

    What kind of a comparison is that? You've compared YaST to Anaconda, and nothing else. You never even USED Fedora Core. The installer is just one package in a multitude. Your problem could probably have been fixed with a quick visit to fedora-list@redhat.com or http://bugzilla.redhat.com/ . Linux helps those who help themselves.

    --

    How appropriate. You fight like a cow.
  10. so did they by Crayon+Kid · · Score: 5, Informative

    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