Slashdot Mirror
Red Hat Releases RHEL 6 Public Beta 1
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.'"
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.
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever ones.
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, which is Xen based. At this point it looks like Oracle is going to turn VirtualBox into a gateway product 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.
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
http://www.karan.org/stuff/rhel6-ppc64-beta-dvd.torrent
http://www.karan.org/stuff/rhel6-x86_64-beta-dvd.torrent
http://torrent.centos.org:6969/
Sums check out. Waaaay faster than the smoldering ftp.redhat heap that were all machine-gunning. ;)
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.
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.
https://www.redhat.com/apps/store/desktop/
https://www.redhat.com/apps/store/server/
They stopped?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
(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
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.
I am TheRaven on Soylent News
Comment removed based on user account deletion