Follow Slashdot stories on Twitter


Forgot your password?
Red Hat Software Upgrades Linux

Red Hat Releases RHEL 6 228

alphadogg writes "Red Hat on Wednesday released version 6 of its Red Hat Enterprise Linux (RHEL) distribution. 'RHEL 6 is the culmination of 10 years of learning and partnering,' said Paul Cormier, Red Hat's president of products and technologies, in a webcast announcing the launch. Cormier positioned the OS both as a foundation for cloud deployments and a potential replacement for Windows Server. 'We want to drive Linux deeper into every single IT organization. It is a great product to erode the Microsoft Server ecosystem,' he said. Overall, RHEL 6 has more than 2,000 packages, and an 85 percent increase in the amount of code from the previous version, said Jim Totton, vice president of Red Hat's platform business unit. The company has added 1,800 features to the OS and resolved more than 14,000 bug issues."
This discussion has been archived. No new comments can be posted.

Red Hat Releases RHEL 6

Comments Filter:
  • CentOS (Score:3, Interesting)

    by ravenspear ( 756059 ) on Wednesday November 10, 2010 @08:15PM (#34191946)
    Anyone know when we can expect CentOS 6?
  • Only 2000 packages (Score:3, Interesting)

    by iYk6 ( 1425255 ) on Wednesday November 10, 2010 @08:19PM (#34191976)

    I tried CentOS about a year ago, and the big problem I ran into was that the OS had so few packages. I am a Debian user and I really like having over 20,000 packages in the official repositories. I rarely have to go somewhere else to download software.

  • About time (Score:3, Interesting)

    by Mad Merlin ( 837387 ) on Wednesday November 10, 2010 @08:42PM (#34192144) Homepage

    It's about time they released RHEL 6, RHEL 5 has become outrageously crusty in the almost 4 years that it's been out now. Nevermind that it's a mediocre distro with virtually nothing packaged in the base repository, $dayjob forces a lot of people to use RHEL, and it'll be nice to have something that isn't quite so crusty.

    Anyone know why RHEL 6 took so long? Previous major releases were 2 years or less apart from eachother, 4 years is a really long time...

  • by proxima ( 165692 ) on Wednesday November 10, 2010 @08:58PM (#34192268)

    RHEL provides a 7 year lifecycle [], which is unmatched by the other major distributions I know about (even Debian). This is crucial for the enterprise; I know of a number of systems which are still running RHEL3 after 6-7 years. Upgrading production computers is not a trivial process, and 2-3 year lifecycles just don't cut it in some situations.

  • by Nerdfest ( 867930 ) on Wednesday November 10, 2010 @08:58PM (#34192270)
    I've always thought that one should pay for support on a per-incident basis for software that one considers reliable. Count your incidents per year for the last few years and do the math.
  • by onyxruby ( 118189 ) <onyxruby&comcast,net> on Wednesday November 10, 2010 @08:59PM (#34192276)

    I distinctly remember when a lack of bloat was one of Linux's bragging points. What happened to Red Hat? Time was they were also once cheaper than the windows servers they lampooned.

  • by h4rr4r ( 612664 ) on Wednesday November 10, 2010 @09:09PM (#34192336)

    Redhat would never make a dime.
    Truth is lots of places use Centos as it is now.

    RHEL should offer site licenses or something like that. No need to be cheaper just even more easy to deal with. The lack of CALs and different levels of the OS already makes them easier to deal with than windows licensing.

  • by seifried ( 12921 ) on Wednesday November 10, 2010 @09:25PM (#34192452) Homepage
    Or you can just install CentOS which is Red Hat minus the artwork and the word "Red Hat" like most of us. I find Linux generally stable/reliable enough that I don't need support (I can't even remember my last Linux server crash, it's been years and stuff "just works").
  • by AdamWill ( 604569 ) on Wednesday November 10, 2010 @09:31PM (#34192490) Homepage

    This is kind of overstated. RHEL works fine as an enterprise desktop; it's used that way internally at RH and by some RH customers. It's probably not what you want on your home desktop, but it's going too far to say RHEL is for servers only.

  • by afidel ( 530433 ) on Wednesday November 10, 2010 @09:48PM (#34192586)
    5 years is generally the limit I will push, since I can buy 5 year support contracts (and did with our most recent SAN purchase since year 4 and 5 can be outrageously expensive if bought after the fact) I feel I'm well enough protected. Also as you pointed out virtualization means that an OS install isn't tied to any particular box so it can live on well after the host has been retired. Since it generally takes 6-18 months to really get comfortable with a new OS, then 6-18 months to bring any new large scale project to production on it you're already up to 3 years into an OS's lifecycle before you have anything critical on it and add 5 years for hardware lifecycle and you are at 8 years, a year longer than RHEL's support lifecycle which is why the other major vendors offer 10 or 12 year support lifecycles.
  • by cduffy ( 652 ) <> on Wednesday November 10, 2010 @11:24PM (#34193012)

    That's fine and dandy if it's just your own server hooked up to your cable, but when it matters, going without support isn't a realistic option no matter how good the software is.

    It's also fine and dandy if you have an in-house systems engineering team who can hack anything from the kernel through the app layer.

    I've been part of that team at multiple shops. It's a pretty fun role -- lots of variety (everything from patching buggy DSDTs in the firmware of the servers we were using to extending the virtualization libraries with features we needed and pushing those upstream... and everything inbetween).

    Not everyone needs a support contract, even if they're doing Serious Business. Indeed, if you're running tens of thousands of relatively cheap servers, those support contracts can be pretty expensive. (Not nearly as expensive as power and cooling, to be sure, but not entirely trivial either).

  • by Craig Ringer ( 302899 ) on Thursday November 11, 2010 @12:12AM (#34193266) Homepage Journal

    Alas, right now I'm moving many services from RHEL to Windows 2008 Server.

    Why? Group Policy, and Volume Shadow Copy Service.

    I cannot overstate the importance of Group Policy in simplifying the management of a client network. Especially when combined with Windows Software Update Services, it's been wonderful. I've been a Linux guy since forever, but I'm really being swayed against my will toward the Windows server stuff for managing Windows clients.

    As for the Volume Shadow Copy Service - it's all well and good to have 10-minutely Bacula incrementals thoughout the day, but nothing beats near-zero-cost snapshots that automatically age out when space is exhausted and that are very space efficient because they're done at the file system level. No, LVM cannot do this, it's block level and thus wastes a lot of space snapshotting changes to "free" space etc. Additionally, snapshots must be mounted, and old snapshots age out rather ungracefully. I've had a server fail to boot because of a broken LVM snapshot multiple times, and it's a major piss-off. It can't touch versioned files in NTFS. Maybe BTRFS will be there in 5 years.

    Truly, though, it's Samba's quirks/limitations, and the lack of Group Policy, that's driven me to drop Linux for managing Windows clients. This isn't surprising, as Microsoft doesn't want to make it easy to manage Windows clients with anything other than Windows servers, and while the Samba folks are doing a heroic job there's only so much they can do.

  • Re:Oracle? (Score:3, Interesting)

    by gethoht ( 757871 ) on Thursday November 11, 2010 @03:39AM (#34194044)
    I call bullshit on Fran. I work with OEL and RHEL everyday at work. I have done a bunch of installs of RAC on both platforms over many years and support many clusters both in house and at customer sites. There is hardly a difference between the two distro's at all... the main difference is some tweaked entries in /etc/sysctl.conf and their "custom" kernel, which will more than likely turn out to be a tool they use to lock you in to their hardware/software stack even more. Oracle software itself isn't terrible, RAC is a nice, speedy database but as a company they're despicable. Before we made the giant, multi-billion dollar enterprise wide switch to OEL, they blamed any issue on RHEL even when RHEL support could prove it was Oracle's code that was fubar. Literally a day after the contract is signed... "oh yeah, there's a problem with our software code, it wasn't a RHEL problem after all... sorry about that, here's the fix". Even to this day with all their supposed hacking of their kernel and uber-custom sysctl.conf entry, they still blame every goddamn problem that we or a customer has on something else... hardware, network, the moons gravitational pull, etc... Their support is atrocious, filled with people who have no interest in actually fixing your problems and quite frankly are well... idiots. If I ever have a hand in any future business decisions for my current company or any other company I ever work for, I will always vehemently recommend against Oracle because their business model is a nasty mix of vendor hardware/software stack lock-in and extortion.

    Fuck Oracle. At least RedHat appreciates your business, is uber-helpful if you do have a problem and really quick to fix things if you can prove to them through kernel dumps or some other means that the OS is having an issue.
  • Fixes? (Score:3, Interesting)

    by CAIMLAS ( 41445 ) on Thursday November 11, 2010 @12:07PM (#34197086) Homepage

    So, forget their 'improvements'. How about 'fixes' - specifically, NFS (due to nfs-tools?)? All throughout 5.x, NFS performance has been atrocious - despite any attempts to tune it. We're talking a 5th of the throughput that should be realizable.

  • by CAIMLAS ( 41445 ) on Thursday November 11, 2010 @12:18PM (#34197246) Homepage

    There are a couple ways around doing this, but none of them seem to make much sense from a time investment perspective - your's included.

    There's something to be said for 'knowing' through GPOs and the like, what's on a system. You can't do this with registry hacks.

    As for LVM2... I've avoided it like the plague that it is: slow/inefficient and buggy are good words for it. It's also awkward to manage.

    This is what I've done... we've got a Windows domain for our Windows servers (mostly terminal servers), and a domain for our Windows workstations. The Windows servers are all virtualized, and workstations are locked down to a bare minimum - most of what they use now is either online or on the terminal servers. Heavy, non-networked applications, like Office, remain on the workstations.

    The virtual hosts, as well as a mess of BSD and OpenSol/Nexenta servers, are all on Kerberos + LDAP. Samba is on systems where it is appropriate to allow one or more domain to access files. Anything important goes on in Unixland, and the ZFS snapshots kick the snot out of VSS. In fact, with the ZFS SAN and XenServer, I'm able to integrate VSS into ZFS to take snapshots at the SAN level transparently. I can ship those over the network to another system for backup using the snapshot mechanisms.

    Currently, I'm playing with the idea of Samba 4 on the Unix machines, because it's easier to handle (though the maturity isn't there yet for AD master, and you sort of need to know what you're doing - while having a fairly intimate understanding of krb5 and ldap in the process). I might be able to do away with the use of a handful of pricey CALs for the Windows servers while improving network file transfer performance for the users by doing this: somehow, beta Samba still manages to trump W2k8R2 for CIFS performance.

  • by Zeio ( 325157 ) on Friday November 12, 2010 @02:17AM (#34204376)

    I have many developers on CentOS 4 and 5, and the last developer on CentOS 3.x retired it due to hardware failure. The bloody OS outlasted the HARDWARE.

    People drastically underestimate an OS running for more than a half a decade in security/errata support mode with a totally stable ABI, KABI and API.

    CentOS and its parent, RHEL, are a godsend.

As of next Tuesday, C will be flushed in favor of COBOL. Please update your programs.