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."
CentOS (Score:3, Interesting)
Only 2000 packages (Score:3, Interesting)
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)
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...
Still the gold standard of long-supported releases (Score:5, Interesting)
RHEL provides a 7 year lifecycle [redhat.com], 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.
Re:erode Windows server how? (Score:4, Interesting)
85% increase in code? (Score:4, Interesting)
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.
Re:erode Windows server how? (Score:5, Interesting)
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.
Re:RHEL comes with free CALs (Score:5, Interesting)
Re:More than you need (Score:3, Interesting)
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.
Re:Still the gold standard of long-supported relea (Score:3, Interesting)
Re:RHEL comes with free CALs (Score:5, Interesting)
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).
Windows network effect (Score:4, Interesting)
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)
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)
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.
Re:Windows network effect (Score:4, Interesting)
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.
Re:Only 2000 packages (Score:3, Interesting)
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.