Red Hat Releases RHEL 6 Public Beta 1 148
An anonymous reader writes "It was way back on 2006-09-07 when Red Hat released its first public beta of Enterprise Linux 5. Today, after more than three years, Red Hat finally releases its first public beta of its next-generation OS: RHEL 6 public beta 1. From the news release: 'We are excited to share with you news of our first public step toward our next major Red Hat Enterprise Linux platform release with today's Beta availability of Red Hat Enterprise Linux 6. Beginning today, we are inviting our customers, partners, and members of the public to install, test, and provide feedback for what we expect will be one of our most ambitious and important operating platform releases to date. This blog is the first in a series of upcoming posts that will cover different aspects of the new platform.'"
Re:Too bad they gave up on XEN (Score:1, Interesting)
Did You Know? After maintaining a vow of silence for almost 7 years, Red Hat Linux founder Marc Ewing now freely admits that he named Red Hat Linux after Limp Bizkit frontman Fred Durst's trademark red New York Yankees baseball cap.
Durst and Ewing met in Ewing's hometown of Raleigh, North Carolina (Durst was raised in Gastonia, NC), where they became fast friends, sharing the same passion for low-level system programming. Durst collaborated with Ewing on the first preview beta of Red Hat Linux before the demands of his rocketing stardom forced him to abandon his hobby and tour with his band.
Durst's position on the development team was filled by Damien Neil, and not many know of his contribution to the popular Linux distribution; however, a google search through the source code on Redhat.com (http://www.google.com/search?q=wfd+site:redhat.com) reveals many snippets of code authored by 'wfd', Durst's initials (William Frederick Durst).
Durst asked Ewing to keep his 'geeky' roots a secret as it would not lend itself to Durst's bad boy image, but as Ewing points out, it was "only a matter of time" before the origins of his NASDAQ-100 company's name were uncovered.
Re:Too bad they gave up on XEN (Score:3, Interesting)
Don't really care about Xen vs. KVM from a product perspective, but for the Opteron 270, Xen is the only one that works since that Opteron doesn't have hardware virtualization instructions. KVM doesn't (to my knowledge) support software based paravirtualization like Xen.
Re:Too bad they gave up on XEN (Score:3, Interesting)
While I've been a fan of VirtualBox for a while too, with the Oracle acquisition I wonder if adopting it now isn't just asking to take a ride onto another abandoned VM platform. Oracle already has Oracle VM [wikipedia.org], which is Xen based. At this point it looks like Oracle is going to turn VirtualBox into a gateway product [virtualization.info] used to hook people used to upsell onto Oracle VM. I'm not sure what that bodes for the future of VirtualBox development. I'm guessing that Oracle shifting development focus toward Oracle product compatibility concerns, so that it's easier to move paying customer to their more serious product, isn't a good sign for people who have been expecting VirtualBox to move further toward being more suitable for larger scale business deployments.
centos tracker! WAS Re:Direct download links (Score:3, Interesting)
Erm, why not try a more legit-smelling tracker? ;)
The CentOS project is serving the beta ISOs from their tracker, but Ill be damned if I can find the .torrent files served via CentOS. $random_blog_guy is serving some which link you up to the CentOS tracker.
http://www.karan.org/stuff/rhel6-i386-beta-dvd.torrent [karan.org]
http://www.karan.org/stuff/rhel6-ppc64-beta-dvd.torrent [karan.org]
http://www.karan.org/stuff/rhel6-x86_64-beta-dvd.torrent [karan.org]
http://torrent.centos.org:6969/ [centos.org]
Sums check out. Waaaay faster than the smoldering ftp.redhat heap that were all machine-gunning. ;)
Re:which fedora? (Score:3, Interesting)
It's not even quite that simple unfortunately. I highlighted the kernel example because FC12 is based on 2.6.31, RHEL6 on 2.6.32, and FC13 on 2.6.33. So in that particular case, they're picking a version that doesn't match any Fedora release.
Re:which fedora? (Score:2, Interesting)
It's not even quite that simple unfortunately. I highlighted the kernel example because FC12 is based on 2.6.31, RHEL6 on 2.6.32, and FC13 on 2.6.33. So in that particular case, they're picking a version that doesn't match any Fedora release.
FC12 was released with 2.6.31 but is now running 2.6.32, so I guess RHEL6 is closest to FC12.
Re:Showing its age (Score:1, Interesting)
I half-heartedly agree with you but Red Hat is a razor's edge away from violating the spirit of the of GPL if not the law.
I know the GPL, I realize all they really need to do is provide the source in some form and that SRPMS are actually a step above just pure source but there's something about it that leaves lingering doubt as to their ongoing commitment to maintaining even those so that distros like CentOS are even possible.
What's more, everybody talks about Red Hat putting money into their distro, what about all the real developers of the packages they re-package for their distribution? That money that you pay Red Hat? It never gets to the guys who actually developed the software. So, Red hat isn't completely innocent here. They're living for free off money, time and effort spent by those developers - just as much as CentOS users are living for free off the money, time and effort put in by Red Hat.
I'm okay with the strategy Red Hat is employing but the goodwill they earned in the past has certainly ebbed away over time. Open source is open source. Continue to be a trustworthy community partner and we won't have any problems.
Re:Showing its age (Score:3, Interesting)
https://www.redhat.com/apps/store/desktop/ [redhat.com]
https://www.redhat.com/apps/store/server/ [redhat.com]
They stopped?
Re:Showing its age (Score:2, Interesting)
(I use CentOS on development machines, RHEL for production)
1. Releases: Please compare the release date of say, RHEL 4.8 (19/5/09) to CentOS 4.8 (21/8/09).
Or better yet, compare RHEL 5.5 (30/3/10) to CentOS 5.5 (will be ready when its ready).
Now, CentOS devs tend to follow RedHat security updates fairly closely, and I usually see the CentOS updates ~12-48h after their RHEL parents.
However: A. In production environment, I rather not wait 12-48h. B. Given the complexity of major updates (E.g. RHEL 5.5), CentOS tends to lag RedHat by a considerable margin.
2. Support: We once had a RHEL kernel fix, specifically tailored to our issue, within 24h. CentOS devs simply cannot compete with RedHat. Period.
Make no mistakes, I bow before the CentOS devs for maintaining a great distribution, but when my job is on the line, I rather put RHEL. Period.
Nobody gets fired for using RHEL.
- Gilboa
Re:Showing its age (Score:3, Interesting)
I don't use RHEL, but I occasionally get complaints from people who do because it ships with a really ancient glibc that is missing features that I use in my code (you know, really new stuff from the 1999 version of the POSIX spec). For Linux-specific features, I don't believe that the glibc included with RHEL includes timerfd() support, which means that implementing an efficient event-driven application is difficult (you have to mess around with timeouts on epoll() and keep track of them yourself, rather than just adding a timer event source to your file descriptors).
The included version of GCC is pretty old too, so it doesn't support some of the newer extensions. The most obvious of these is atomic ops. I have to fall back to using some inline asm if I want to support RHEL which means, if I can be bothered, it's only on a couple of architectures that I have access to for testing.
Comment removed (Score:3, Interesting)