Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Businesses Red Hat Software Software

Free Alternatives to Red Hat Enterprise Linux 3.0? 113

Posted by Cliff from the more-crimson-caps dept.
looper_man writes "I'm a hardware design engineer, and our tools have been migrating to Linux over the last years. I've been running Red Hat Linux 9.0 on our compute servers for a while now without a problem. The latest release of one of our CAD tools requires Red Hat Enterprise Linux 3.0, and will *not* run with RH9.0. I'm not very happy with the (yearly!) licensing fees that Red Hat wants for RHEL3.0, so I'm looking for alternatives. I plan on running one real RHEL3.0 server (for any OS/tool issues if I need to verify that the problem is real), and the rest of the machines running a RHEL3.0 clone. I've seen CentOS, TaoLinux, WhiteBox, and a few others. I don't have the time to spare to test these out, so I was looking for recommendations from the Slashdot masses. I need something that's stable, easy to install/maintain, and closely tracks RHEL3.0. Any words of wisdom?"
This discussion has been archived. No new comments can be posted.

Free Alternatives to Red Hat Enterprise Linux 3.0? More

Free Alternatives to Red Hat Enterprise Linux 3.0?

Comments Filter:

  • CentOS (Score:5, Informative)

    by Erik Hensema ( 12898 ) on Tuesday May 03, 2005 @02:58PM (#12423327) Homepage
    CentOS is simply a recompiled and rebranded RHEL with swift security updates. If you want something as similar as the real thing, CentOS is certainly the way to go.

    • Re:CentOS (Score:3, Interesting)

      by gid ( 5195 )
      Out of curiosity, does anyone know if you use CentOS to update an already installed RHEL install (say your license ran out and you can't get updates anymore or something)? Or do you have to reinstall? I couldn't find this information on the CentOS website anywhere, so I guess it means a reinstall is required.

      • Re:CentOS (Score:4, Informative)

        by Erik Hensema ( 12898 ) on Tuesday May 03, 2005 @03:42PM (#12423991) Homepage
        I did it. No problem at all. I installed yum, pointed it to the right installation source, and my redhat was transformed into CentOS without any problems.
        • Well, there is a LITTLE more to it than that, but google finds some nice instructions for "upgrading rhel to centos with yum".
      • While I have not done a migration from RHEL to CentOS, I have cross migrated from Whitebox, and Tao to CentOS and back. I am willing to bet the process from RHEL to CentOS is just as easy.

        Checkout these [centos.org] instructions on migrating from Whitebox to CentOS
      • Just follow the CentOS instructions for converting from white box, it worked for me.

        Now if only I had installed Debian to begin with. Oh yeah, thats right, AS2.1 had already been purchased and we were considering Notes at the time. I have 2 licensed and supported RHEL ES machines where vendor support is needed, one CentOS machine, and the rest are Debian. Converting from RH to Debian isn't my idea of fun.

        • Re:CentOS (Score:1)

          by gid ( 5195 )
          Well it looks like we're gonna stick with RHEL AS 2.1, so we gotta cough up the dough for a few more licenses or something. Since Oracle won't support CentOS.

          RHEL does offer piece of mind I guess, which is nice when your entire business depends on the stability of your servers.

    • But Remember to edit /etc/redhat-release (Score:5, Informative)

      by HighOrbit ( 631451 ) on Tuesday May 03, 2005 @03:22PM (#12423717)
      The latest release of one of our CAD tools requires Red Hat Enterprise Linux 3.0, and will *not* run with RH9.0

      CentOS is pretty much an exact copy of RHEL, except for trademark names and artwork, so it should work flawlessly...except for one thing. If the installer is explicitly checking versions, backup and then replace the redhat-release file found in /etc from CentOS to the appropriate Redhat version that says "Red Hat Enterprise Linux AS release 3 (Taroon)". This will fool some installers (such as Oracle) that demand a supported OS before they will install. After the install is complete, you should be able to copy the old redhat-release (that says CentOS) back without problems.

      • CentOS is pretty much an exact copy of RHEL, except for trademark names and artwork, so it should work flawlessly...except for one thing. If the installer is explicitly checking versions, backup and then replace the redhat-release file found in /etc from CentOS to the appropriate Redhat version that says "Red Hat Enterprise Linux AS release 3 (Taroon)". This will fool some installers (such as Oracle) that demand a supported OS before they will install. After the install is complete, you should be able to c
        • Point of the parent noted, but just a little too knee-jerk. The majority of the cost of RedHat products is in support, and maybe the box. If support from an external source is not what you're after, then RedHat is not for you.

          Remember RedHat 5, 6, 7, 8 and 9? I know with 7 8 and 9 there was a different release cycle, free download of ISOs of one of many mirrors, free off-peak access (paying customers got priority when demand was high), and no enterprise level support. That's what you bought RH AS2.1 f

        • I don't think I could justify to my boss that we should pay triple our hardware costs per year for a support contract we're unlikely to use. I'd give a little out of my own pocket but I don't see a donate link either, and my home desktop runs Ubuntu for the moment.

          They're really not doing too bad financially though.
        • Theft of whose intellectual Property? The things in RHEL are not written by RedHat ... they are GPL items written by others and repackaged by redhat. RedHat has a whole section of their website telling you exactly how to redistibute their software, because it is open source. That is how open source and the GPL works ... RedHat makes their money on the support contracts, they do not own the software they distribute.
      • A better way to fool Oracle is to run it with --help (I think) and it will ignore the host OS checks. I don't know *why*, as there is actually a documented command-line flag that is supposed to do this, but it seems as though pretty much anything will do.
        • I think you are looking for -ignoreSysPrereqs option during the oracle install. That is what I used to make Oracle install on Solaris 10 for sparc because Oracle looks for Solaris 9. However, this would be a dangerous option to use on Linux because there are so may versions of linux/gnu libraries floating around for Linux as opposed to fewer differences between solaris versions. Overriding the prereq check on Linux is likely to cause more trouble than its worth. Better to fix the redhat-release file to foo
  • Well at first I was going to post a list or two of different distrubutions, and then I read this:

    I don't have the time to spare to test these out

    So then I was going to recommend a distro or two that's stable, easy to install/maintain

    But then I read this:
    and closely tracks RHEL3.0

    So now I'm going to recommend Fedora.


    • Actually, IIRC, Fedora isn't actually binary-compatible with RHEL 3.0.
    • The thing is, Fedora isn't probably as close at CentOS. CentOS is basically a third-party recompile of RHEL, but Fedora is more of a testing ground and much less stable and predictable than RHEL. That's not to say Fedora is bad, but relatively speaking it's not on the same level.

  • Err... (Score:3, Insightful)

    by Anonymous Coward on Tuesday May 03, 2005 @03:01PM (#12423376)
    You're an engineer.
    You're not the guy who decides that management doesn't want to fork out the cash for RHEL.

    -r

    • Management doesn't get much say in it.
      "What's this item in the budget?"
      "The licence fees to keep our tools working."
      "Can we cut it?"
      "Not and keep working."

      Management hates items like that and it's best to solve them before the PHBs get creative.

    • Re:Err... (Score:5, Funny)

      by snorklewacker ( 836663 ) on Tuesday May 03, 2005 @04:36PM (#12424678)
      Right. He's an engineer. Who has to fill out requisition forms in triplicate with business justifications for purchasing redhat provisioning, have it routed to IT support who will send it to your manager's manager who is on vacation for the next three years or something, where you will wonder what happened, take it back, escalate it, get the budget allocated next quarter, get your credits, IT will get your RHN password instead of yourself, forget to send it to you, make you open a ticket to get it, forget the password, tell you you don't have provisioning credits, have you escalate, find out you do have provisiong credits, get the password reset ...

      And they'll forget to renew it next year.

      Maybe he just wants to admin the box without having to go through that.

      • Re:Err... (Score:3, Informative)

        by walt-sjc ( 145127 )
        That's modded funny, but the unfortunate truth is that it's a farily accurate portrayal of the Dilbert-esq corporate environment that so many of us deal with.

        Purchasing ANYTHING that requires ongoing license fees is a TOTAL PITA in any company.
      • Funny, I didn't think there were too many other slashdotters working in my building.

        This exact thing happened to me, except it was our department secretary (who handles order paperwork) that got the RHN password, not IT.
        • Well, I don't imagine you work in my building, but I didn't exactly make up the whole story either (it's sort of a pastiche of real issues).

          I feel I should be fair though: none of this is really Redhat's fault, because they make it as easy as a magazine subscription, the price is really fairly reasonable, and they deserve to have their business model survive. Unfortunately, the mechanics of corporate bureacracy aim to defeat that model, and when other choices such as Centos exist, techies and low level ma

  • redhat closeness (Score:5, Interesting)

    by bendsley ( 217788 ) <moc]tod[eibaolf]ta[darb> on Tuesday May 03, 2005 @03:01PM (#12423377) Homepage
    This is taken directly from CentOS.org's page.

    CentOS : Community ENTerprise Operating System

    CentOS 2 and 3 are a 100% compatible rebuild of the RHEL 2 and 3 versions, in full compliance with RedHat's redistribution requirements. CentOS is for people who need an enterprise class OS stability without the cost of certification and support.

    This should answer your question.

    Link I found info. on is below.
    http://www.centos.org/modules/tinycontent/index.ph p?id=2 [centos.org]

    • CentOS is for people who need an enterprise class OS stability without the cost of certification and support.

      Not to flame, but someone had to put in the time to create that stability. It is only fair that if they want to be compensated for their time, then you should either:

      A) Pay them for their efforts

      B) Don't use their product

      NOT

      C) Use a loop hole to take their work and use it as your own for free.

      Remember that it is RedHat that is ultimately creating the updates for both its Enterprise

      • Re:redhat closeness (Score:5, Insightful)

        by Undertaker43017 ( 586306 ) on Tuesday May 03, 2005 @04:04PM (#12424257)
        "C) Use a loop hole to take their work and use it as your own for free."

        It's not a loop hole, it is a requirement of the GPL that RH releases the code. It is the risky business model (charging for packaging and support of OSS software) that RH has chosen to undertake, that could cause them to go backrupt.
        • Plus, it's silly to accuse CentOS of taking someone else's stuff as their own for free. Don't forget that a massive amount of the stuff found in the products Red Hat charges for is in turn based on work that others did for free. And the CentOS distributors aren't (at least I don't think!) profiting from it.
        • Further, if Red Hat wanted to make things awkward for CentOS, they could do whilst still complying with the letter of the GPL (e.g. by not releasing src.rpms - just the pristine sources and any patches they apply, and maybe the %prep and %build parts of the specfiles).

          The fact that they don't do this indicates to me, at least, that Red Hat tacitly approve of CentOS and friends.

          • they could do whilst still complying with the letter of the GPL (e.g. by not releasing src.rpms - just the pristine sources and any patches they apply, and maybe the %prep and %build parts of the specfiles).

            No, they couldn't.

            The GPL explictly states "The source code for a work means the preferred form of the work for making modifications to it." Sources + diffs is not the preferred form for making modifications.

      • Re:redhat closeness (Score:4, Insightful)

        by FidelCatsro ( 861135 ) <fidelcatsro&gmail,com> on Tuesday May 03, 2005 @04:28PM (#12424567) Journal
        Yes , well I submitted a few bug reports to several diffrent linux programs.
        So do hundreds of thousands of others(if not multiple millions , anyway a really really big number ;) ).
        So where is our cheque ?.
        This is not why we do it atall though. We do it for the love of the systems and to see our OS improve.
        Thats the GPL way . Freedom! in its various forms.

        I pay for Debian (order CDs reqularly) and i donate to a few projects.Its my choise to do so .. there is nothing forcing me to do this.
        Not even a moral obligation , Contribution is part of the GPL was too.

        dont forget how many bug reports that probably get passed back to RedHat proper from projects like Cent-Os too .

        So remember the part the community plays in all this .

        Anyway..
        Redhats bussiness model is not based on OS sales anyway it is based primarly on Support .If he really needs the support he will have to pay for it from redhat or another source.
      • Think about that thousands of independent projects that Red Hat bundles up and puts into their own RHEL product while giving those projects little or no compensation in return.

        It's just how the GPL works. Everybody benefits from the work of everybody else.
      • Um, by the same logic, Red Hat shouldn't be distributing 90% of the software that they ship, or should be paying thousands of open source programmers for their work.

        And remember: this is open source. If RH stops updaing their software, the community could take over.

        Open source is a tit-for-tat business. Red Hat's product is built on the backs of others, and Centos is built on Red Hat's. That's the way it should be. Red Hat is selling a brand, support, and piece of mind for the corporate market. Centos doe
      • C) Use a loop hole to take their work and use it as your own for free.

        This is not a "loophole". This is the essence of Free Software.

        Don't pity Red Hat. It's up to them to make their business model work in the Free Software world, not up to the Free Software world to un-free software just because Red Hat has touched it. (I hope they can do so, but I have doubts about their current attempt.)

  • Now I've seen it all... (Score:5, Funny)

    by 0x461FAB0BD7D2 ( 812236 ) on Tuesday May 03, 2005 @03:01PM (#12423388) Journal
    3 Slashvertisements in a row, Microsoft working, with Ford no less, to prevent crashes on the road and now we need free alternatives to Linux distros.

    This is what April 1st should be like.

  • Scientific Linux (Score:5, Informative)

    by mewyn ( 663989 ) on Tuesday May 03, 2005 @03:06PM (#12423454) Homepage
    To all you reccomending Fedora: Fedora is NOT binary compatable with RHEL. Binaries made for RHEL may not run under Fedora. I'd reccomend Scientific Linux, maintained by Fermi Lab. They keep it as up-to-date as RHEL is, and they include apt and yum for updating. Install mirrors the RHEL install, and is binary-compatable with RHEL.

    • Re:Scientific Linux (Score:1, Flamebait)

      by cpeterso ( 19082 )

      Does RedHat purposely make Fedora incompatible with RHEL to protect their "semi-proprietary" RHEL product line? Or are they incompatible just because Fedura version N will become RHEL version N+1?
      • Does RedHat purposely make Fedora incompatible with RHEL to protect their "semi-proprietary" RHEL product line? Or are they incompatible just because Fedura version N will become RHEL version N+1?

        The latter, pretty much; RHEL3 was RH9-ish, RHEL4 is FC3-ish.

        Obviously, though, RH benefit from there being such a clear differentiator.

    • I second this recommendation. In fact, I thought I had submitted a similar post, but apparently I had a brain fart or something.

      Not only is SL maintained by people from several of the USA national labs, but their mailing lists are excellent for support.

      They track pretty quickly on RH's heels, and try to be 100% compatible with RHEL. They've complied with RH's terms (replaced copyrighted images and trademarked logos), and don't even mention RH on their site.

      https://www.scientificlinux.org/ [scientificlinux.org]

      We expec
  • I've been using CentOS 3.3 and 3.4 on my two CPanel servers this year, and so far, I've been nothing but impressed. Easy installation, easy to maintain, fast updates.
  • I think a more interesting question is what's RHEL got over another distro that would be a requirement in a CAD tool. Plus, are we talking about a commercial CAD tool or some in-house thing?

    • Re:requires RHEL? (Score:3, Insightful)

      by saintp ( 595331 )
      There is *lots* of software out there that requires RHEL. What does RH offer? Name recognition, and that's about it. Most of this software would just need a quick recompile at most to make it run on SuSE or Debian or whatever the distro-du-jour is, but that's more work compiling and more work supporting that the vendor has to do. So they choose a distro, and the distro that most suits have heard of is Redhat. The end. It's not that Redhat offers some nifty sweet functionality; it's just that people wh
      • ok, i think there's some confusion between "require" and "support". If the posted system requirements state RHEL, I wouldn't be surprised then that the product would run just fine in Debian or Suse without a recompile. If the package is provided in RPM, in many cases the program can be installed onto a Debian with alien.

        My original question was more along the lines of whether or not RHEL included any special runtime libraries that would make it a real requirement as opposed to a support issue.
      • I think it's deeper than that.

        First of all, RedHat themselves are the ones driving a huge amount of the bleeding-edge 'enterprise' features found in Linux, and generally integrating them first. So, RH is proactively designing/writing enterprise-friendly features, while distros like Debian are "downstream" and will only get them when Linus gets around to patching them into the mainline.

        Second, RedHat is actually someone that vendors like Oracle can pick up the phone and call, which certainly helps while ev
        • For Oracle at least it goes even deeper than that. Oracle was a vendor that set the specs for RH Ent 2.1 and 3. That is RH designed the system specifically to handle Oracle well.
  • Distrowatch [distrowatch.com] lists [distrowatch.com] 21 distros based on RHEL including CentOS, Lineox, White Box, Pie Box and Scientific Linux.

    I've not used any, but from what I hear CentOS is a very popular choice.

  • I'm a hardware design engineer... (Score:5, Insightful)

    by pg133 ( 307365 ) on Tuesday May 03, 2005 @03:13PM (#12423552)
    I'm a hardware design engineer
    ...I don't have the time to spare
    sorry, but isn't that the point, you pay some else, in this case RH, to do all the hardwork of testing and producing a stable OS and providing support, and this allow you to concentrate on what you do best hardware design engineering. I presume you don't want to 'waste time' on trouble shooting any OS that is less than stable.
    • Based on the terms of the RH license, someone can take a stable, tested build of RHEL and redistributite it for free (in both senses of the word), so he wont have to "'waste time' on trouble shooting any OS that is less than stable."

  • What does it require? (Score:2, Interesting)

    by Anonymous Coward
    What specifically does this special software package require?
    I would guess, absolutely nothing. It probably just checks /etc/redhat_version to make sure they have already reamed you for the cost of linux in addition to reaming you for the cost of the software.
    add RHEL or something to /etc/redhat_version, that should work

  • Poor priorities (Score:5, Insightful)

    by duffbeer703 ( 177751 ) on Tuesday May 03, 2005 @03:26PM (#12423768)
    You're spending thousands of dollars on a CAD tool that's critical to your business, yet are balking at a lousy couple of hundred bucks?

    Your CAD vendor wants RHEL because they need a consistent, supported baseline to develop their software for.

    Personally, I wouldn't want to risk problems later to save a few thousand dollars. If you run into some problem down the road, your software vendor will point the finger at CENTOS or whatever instead of their crappy software.
    • 2nd this.

      You should be talking to your tool vendor, not looking at changing your OS choice.

    • Agreed. Frankly, my company will close the case as soon as we find out you are on an unsupported platform. The second paragraph says it all. If you don't like that, talk to your account team about supporting different versions. I'll be honest with you, though, I seriously doubt they are going to support CENTOS for the reasons in paragraph 2. This CAD tool is critical to your business, but it is your CAD vendor's business. They aren't going to risk their business on some fly-by-night distribution.

  • The latest release of one of our CAD tools requires Red Hat Enterprise Linux 3.0

    is it possible to change the CAD abit to enable it to run on other linux? or would it even be better to develope the program on a different distro?

  • BS! It will work with any Linux you chose (Score:4, Informative)

    by Master Bait ( 115103 ) on Tuesday May 03, 2005 @03:29PM (#12423809) Homepage Journal
    Just be sure to install the correct libraries (ldd your CAD's binary to see which libs), and look at your crappy CAD's startup script to see if it looks at/for RH specific /etc files. This isn't rocket science -- really!

    • I've got call BS on this comment actually. Some vendors require RHEL (I work for one such vendor) because their code is specifically tied to RHEL kernel versions (as in they check it). Further, support for application is generally only going to be applicable on the supported platform (RHEL in this case). While it may work if these free/low-cost versions actually mimic the naming of the RHEL kernel, support is where you'll get nailed.

  • Only tried WBEL (Score:3, Informative)

    by Bravo_Two_Zero ( 516479 ) on Tuesday May 03, 2005 @03:30PM (#12423823)

    I've tried WBEL, and I didn't put it into production because we standardized on RHEL.

    Our platform needs/requirements...

    1. Custom J2EE development using OSS tools
    2. Implementing non-OSS, commercial packages
    3. Package-based updates
    4. GUI administration for the NT admins
    5. SMP kernel


    There were a few packages for which I had to hunt to satisfy certain application requirements (I wanna say one was the Sun JRE, but that may be different now... and I think the application requirements were driven by Scalix 9.0... scalix.com). The reccomendation at the time was to pull them from RH9 or Fedora Core 1 if they didn't live in WBEL packages yet. Usually, that works fine.

    I've installed RHEL 2.1 and 3.0 in addition to WBEL 3.0. The install is pretty much the same. The package list wasn't really that different for my needs. And, installing either on older HP LT6000Rs led to no difference in hardware support.

    I wasn't a big fan of the stock Yum updater (I'm more apt-for-rpm, but only because I'm more comfortable with it). You may or may not care about the package updating.

    I haven't tried the other EL clones, so I can't comment there. I can say that, if I wasn't able to spend the money on RHEL, I do feel confident we could have made WBEL work for us in its place.

  • ...Anyone mentioned RHEL4 yet?
    I know its new and all, but it seems pretty solid to me.

    Also, I would consider Fedora as an option. It may not be RH-certified with all the support and everything that comes with RHEL3/4, but I've yet to have a single really bad experience with Core 2/3.
    • RHEL4 has issues to be ironed out... IMO I wouldn't expect it to be worthy of an Enterprise hardware setup until Update 2 is released at the minimum. Hardware certifications are way behind where EL3 got to, and they've made a couple of IMHO stupid backward steps.

      One detailed example: after much ado, RH capitulated to user demand last year and included the config module in EL3 for QLogic HBAs (in a semi-broken way) so users could FINALLY take advantage of the multi-pathing feature of the cards. Better st

  • Post should have read.... (Score:5, Insightful)

    by Tsunayoshi ( 789351 ) <tsunayoshi&gmail,com> on Tuesday May 03, 2005 @03:56PM (#12424141) Journal
    <edit>I want to have a kick ass stable OS that is supported by all of the software I need but I am too goddamn cheap to actually pay money for this. Can the Slashdot audience please do all of the testing and evaluation for me, let me know which is the best, and them spoon feed me the updates so it stays current?</edit>

    Holy shit, I can understand bitching about paying Windows Server licensing fees (pay for the OS, each connection to the OS, each mail user on the OS...) but for RHEL you pay a ONE time support fee per year to use their automated updates system.

    If you need more than one box and really want to be cheap (and violate your license agreement, but IANAL), buy one copy of RHEL, install it somewhere, update it, pull the RPM's from the cache and setup a LAN update server and install as many copies as you wish. We actually do this where I work except we do it for convenience. We actually have more RHEL licenses than we use.

    • Re:Post should have read.... (Score:1, Insightful)

      by Anonymous Coward
      RHEL you pay a ONE time support fee per year

      It's not ONE time if its yearly...thats like my car only costs me ONE PAYMENT every month, for 60 months.

      If you need more than one box and really want to be cheap (and violate your license agreement, but IANAL), buy one copy of RHEL.....We actually have more RHEL licenses than we use.

      If you're going to rip them off anyway, why even pay for one copy? How can you bitch about cheapness when you are doing a similar thing?

      • Car payments (Score:1, Insightful)

        by Anonymous Coward
        ...thats like my car only costs me ONE PAYMENT every month, for 60 months.

        The difference is that with your car, the payment requirements end after 60 months. However, with Red Hat, the payment requirement is perpetual. Using the car analogy, Red Hat is a lease where you pay on a scheduled basis forever but get a new one(car/Red Hat version) every three years.

        I like owning my cars, not leasing them. I feel the same way about my software.

  • I've tried 3 alternatives (Score:5, Informative)

    by the eric conspiracy ( 20178 ) on Tuesday May 03, 2005 @04:33PM (#12424624)
    CentOS, WBEL, and Fermi LTS Linux. All of them worked well enough for me - the differences were that it seemed Fermi LTS was fairly heavily customized for the lab's needs, so it wasn't that great for new package installation. WBEL was very vanilla, but sometimes support was slow. CentOS seemed to have the best support behind it, so I use it now - recently I upgraded to CentOS 4.

    Another option to look at for low cost is SuSE. SuSE Pro is inexpensive, and the odds are that your CAD vendor supports it. Plus you can actually get support from SuSE.

    • SuSE Pro is inexpensive, and the odds are that your CAD vendor supports it.

      Where do you get your odds?

      We've been asking all our CAD tool vendors, and every last one of them either supports running on RHEL or will within a very short time. No other Linux distribution even comes close. Probably the most supported OS after RHEL3 among these vendors is Soalris, not another Linux (or Windows).

  • Do your job. (Score:4, Insightful)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Tuesday May 03, 2005 @04:34PM (#12424640)
    Do your job. If you have authority to decide which of these distros to use, you have the responsibility to make the right decision.

    And where are you posting to? Slashdot. What's Slashdot well-known for? Being visited, by and large, by a lot of young geeks with more ambition than they have knowledge. This is the place where people love to trash-talk technology without first bothering to learn what the technology is first (because, after all, all the cool kids know that technology's lame).

    Yeah, there's the occasional gem in the comments, but there's a sea of bullshit you have to wade through in order to find it. By the time you're done wading, it would've been easier to just grab all three distros and evaluate them for yourself.

    You have a job to do. I suggest you do it, and not substitute a horde of lemmings for your better judgment.
    • Wow, that was a useful comment. Thanks for your input. I'm sure the original poster will find it to be of use. Why are you so bitter?

  • We use CentOS (Score:4, Informative)

    by dtfinch ( 661405 ) * on Tuesday May 03, 2005 @04:39PM (#12424704) Journal
    It's worked out fine. Updates are released in a timely manner and such. The mailing lists are active and people appear get their problems solved (though we haven't posted to them). The only issue was that the GPG key used for signing the yum updates isn't automatically installed, but the faq mentions the one-line command needed to install it. Suggested donation is $12 per system per year.

    RHEL3 in general is starting to feel a bit stale. For example, the samba packages are behind on many important bug fixes. Is this what you want?

  • Fermi Linux or Scientific Linux (Score:1, Informative)

    by Anonymous Coward
    From Distrowatch: http://distrowatch.com/table.php?distribution=ferm i [distrowatch.com]

    "About Fermi
    Fermi Linux LTS (Long Term Support) is a site distribution based on Scientific Linux, which is in essence Red Hat Enterprise Linux, recompiled. It is Scientific Linux with Fermilab's security hardening and customised configurations to allow an administrator to install Fermi Linux and have the machine meet Fermilab's security requirements with little or no extra configuration. Since Fermi Linux LTS is based on Scientific Lin
  • CentOS

    it seems to have the biggest userbase

    and it works well

  • Mandriva/Mandrake (Score:2, Interesting)

    by toddbu ( 748790 )
    A great distro that was originally based off of Red Hat. Switched back to it after Red Hat instituted the new licensing structure. I still spend $120/year for MandrakeClub to support their efforts, and for that money I get access to the Powerpack DVD with all the extras on it. Uses RPM format, and virtually any Red Hat 9 RPM will run on it. More and more sites support Mandriva RPMS directly. Patch support is fabulous.

    My only complaint is that they can be a little too bleeding edge. They shipped the

  • CentOS simply rocks. If you like Red Hat, you'll love CentOS because it looks and smells like Red Hat. So far everyone I have talked to has said they can not find anything that won't work on it, and the updates are free. I guess if you can get it for free, why would you pay Red Hat for it? CentOS gets my vote!

  • LWN tells all (Score:4, Informative)

    by jensend ( 71114 ) on Tuesday May 03, 2005 @08:22PM (#12427228)
    LWN reviews RHEL clones [lwn.net]

  • I've done some work with this (Score:3, Informative)

    by anomaly ( 15035 ) <tom DOT cooper3 AT gmail DOT com> on Tuesday May 03, 2005 @09:18PM (#12427686)
    For my Fortune 500 company, I needed to build an automated update process (using the cross-platform enterprise-ready tools we already owned.)

    Of course, politics and contract negotiations made it so that I was not allowed to have my own box for engineering patch deployment, so what's a guy to do?

    I found and installed WBEL on some commodity hardware in the lab and began my testing by pushing 'approved' RHEL patches to the lab box. Eventually I crushed the lab box. I thought either I had done something wrong, or there were bugs in WBEL that made it incompatible with RHEL.

    What I later learned was that there was an RPM bug in both RHEL and WBEL that corrupted the RPM database.

    I tested WBEL with dozens of patches and found it to be binary compatible down to the bugs.

    Of course, after we had been live for six months, pushing RHEL patches to fully-licensed RHEL servers on server-class hardware, I was finally allowed licenses for the lab.

    This is why people use free alternatives in corporations. The deadlines don't move out just because all the licensing and political ducks are not lined up.

    I switched to CentOS because it seemed that WBEL was not as quick to build updates, and there seemed to be a stronger community around it.

    Conversion of my home server from WBEL to CentOS was trivial. The same was true for my 'utility-player' linux box at the office.

    Of course, it's not officially sanctioned, but when you need a copy of grep that doesn't choke at 2048 character lines, or a quick and dirty ftp server, or a place to rsync production logs so you don't have to give vendors access to production boxes, or you need to set up a lab with a custom mail server and web front end, or......That's why I call it a utility player.

  • glibc and kernel Matter most (Score:2, Informative)

    by Anonymous Coward
    I need something that's stable, easy to install/maintain, and closely tracks RHEL3.0. Any words of wisdom?
    As a hardware design engineer myself and having moved from Sun/Sparc to x86/Linux about four years ago, be very careful. For example, some of the tools used by Synopsys are native to Linux and some use a Windows emulator (gui tools). The Windows emulator is usually tied closely to the kernel and may appear to operate on a new kernel but fail during heavy duty use. glibc is also important. I've had

  • CentOS is cheap, but RedHat is worth it (Score:2, Interesting)

    by Anonymous Coward
    I have used CentOS 4 and found it to be very stable. I use apt-get for updates and add-on packages.

    But if you need a reliable OS, and don't have the time to support it yourself, RedHat's support is a good deal: you get a wide variety of high-quality, tested software, plus you can call them when you can't figure out how to use or fix it, and don't have the time to look it up.

    I have been supporting UNIX and Linux for years, so I have elected to take the risk of running my (small) business without that safet

  • Should be obvious, but... (Score:3, Insightful)

    by MrResistor ( 120588 ) <peterahoff.gmail@com> on Wednesday May 04, 2005 @10:01PM (#12437756) Homepage
    It isn't a license subscription, it's a support subscription.

    Pay up for one system, like you say you plan to, and just install it anywhere else you need it from whatever media they give you. Just understand that you've only paid for support for one system.

    Honestly, try reading the GPL before you ask stupid Linux licensing questions like this.

    • Ixnay on the ondescensioncay Chuck!
    • Actually, go read the FAQs on their site -- several files on the CD are Copyright RedHat and not GPL'd. Those files must be removed if you wish to redistribute the rest.

      You only have distribution rights for the GPL'd and other binaries with open licenses -- some are not.
      • He's not redistributing, he's installing it on multiple machines belonging to the purchasing entity.

        Now, as for reading the FAQ, here's what I found:

        Except for a few components provided by third parties (like Java) all the code in Red Hat products is open source and licensed under the GPL (or a similar license, such as the LGPL).

        So, according to that, all code that's copyright Red Hat is GPL compatable.

        Again, the subscription is for support, not the software itself.
  • Its not 'linux', but it meets your other requirments: "I need something that's stable, easy to install/maintain"

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close