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.'"
We have an environment with AMD Opteron 270 based servers where we use virtualization heavily. We either have to give up on the servers or on RHEL 6. I think that we'll stick with EL5 until we go into a server refresh cycle.
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever ones.
RHEL is probably not the best choice for workstations....
Hmmm. Would you care to explain what you think it is that CentOS would give you that RHEL doesn't?
Burns: We're building a casino!
McAllister: Arrr. Give me 5 minutes.
better pricing
ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/
Or torrent it:
http://www.torrentreactor.net/torrents/5568298/RHEL-6-Beta-64-Bit
Don't forget to check the sha1sum, which can be verified on the first address:
e0a3a906d7bbbc57b411a213bd5d6ad44d851689 RHEL6.0-20100414.0-AP-x86_64-DVD1.iso
.sig: No such file or directory
Those hugely important features like "more colours in your OS icon" and "a name that doesn't include 'Enterprise' so directly" (yes, I realise CentOS is still based off "enterprise", but RHEL is short-hand for a full name where as CentOS is its name).
> Linux is killing me!
It does, as always, a good job!
True. But Redhat put a lot of work into Linux, and I'm happy for my company to help fund those coders, so I buy RHEL licences.
Meh, we have RHEL5 at my uni in the cs labs and I don't really mind them at all. I mean, all I do in there is write c in emacs and debug it. We even get a web browser, MS Word, Open Office, Matlab and a couple others. What bugs are plaguing you, OTOH what features do you want that you need for lab work are missing?
Disclaimer: I don't do any graphics work, they have some pretty sweet 3D monitors on XP stations in the lab next door for those guys tho.
Failure formatting five FAQs of financial facts.
On which fedora is this based?
Why do you think it doesn't have enterprise in the name? It's the Community ENTerprise OS.
Like RHEL, it's often shortened.
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. ;)
CentOS is a RHEL clone...
Palm trees and 8
I don't know, ibiblio is kind of legit. Red Hat didn't feel like releasing a torrent, since they don't have a tracker lying around.
Actually I didn't quite understand if the favored linux virtualization code switched from xen to kvm because of Citrix buying xen and messing with the project, or some other reason.
Build your own energy sources from scratch. http://otherpower.com/
It would be quite wonderful if someone could figure out a way to make packages installable easily on all linux distros, or at least create a few "compatibility profiles". This whole repository ubuntu-vs-debian-vs-redhat-vs-mandriva-vs-older-versions-of-same is a nightmare for newbie users.
Build your own energy sources from scratch. http://otherpower.com/
True. But Redhat put a lot of work into Linux, and I'm happy for my company to help fund those coders, so I buy RHEL licences.
Couldn't agree more. I use to run out and plunk down $ every time a new release came out whether I was running RH as my distro or not until they quit selling personal editions.
Time is what keeps everything from happening all at once.
I could have supplied those links. But as this link was on top of the google results, I thought it was best for performance to let everybody join that tracker. I'm now trying to seed both.
.sig: No such file or directory
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.
Selah.ca. Pause, and calmly think on that.
True. But Redhat put a lot of work into Linux, and I'm happy for my company to help fund those coders, so I buy RHEL licences.
I don't but Linux licenses, the company I work for does.
This is the attitude that makes commercial open-source so difficult. Until Redhat employ every developer whose code is used in their distro, you can accuse them of freeloading. Redhat contribute to a variety of core packages, including the kernel. That's enough to keep me happy. I'm not saying they're perfect, but they're not bad. The very existence of CentOS should show that they're sticking to the GPL. But you also have to remember is all those patches that go back upstream, and appear in Debian, SuSE and the rest.
Thank you backwardMechanic. Calling RedHat freeloaders is completely ignoring all the contributions they made to OpenSource. They did not write 100% of the code that RHEL runs on but they did fix a lot of issues that would never be taken cared off by the upstream project for lack of coolness. The reality today is that the Kernel is mostly developed by programmers paid by large corporations such as RedHat. Same goes for Novell who employs a lot of opensource hackers.
It's all about balance. The current balance is acceptable. Red Hat just needs to prove long term they won't be trying to stretch the GPL very much further.
Selah.ca. Pause, and calmly think on that.
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...
Please, for the love of god, tell me they're finaly including PHP 5.2 in RHEL.
Mod point free since 2001
Hmmm. Would you care to explain what you think it is that CentOS would give you that RHEL doesn't?
Free access to their repositories..including updates?
(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
.. Argh.
The OP message was hidden, so I missed the reason for your answer.
(OP: RHEL is old and buggy, wish we could use CentOS or Fedora; You: CentOS -is- RHEL...)
My mistake.
- Gilboa
Um, did you read the thread? Or even that particular comment? Sheesh, I know it's not cool to read the article, but I thought maybe you'd read the message you're replying to.
Support in an enterprise environment. Enterprise/Professional level software vendors need a base to offer support on and Redhat was the first to be viable in that market. SUSE is kinda there, but Redhat is pretty much the standard when it comes to Linux running high end software packages for businesses.*
*Aside from Z-series/mainframes, but thats a whole other league.
unf.
True. But Redhat put a lot of work into Linux, and I'm happy for my company to help fund those coders, so I buy RHEL licences.
Well...if you don't actually need the support and are only purchasing it as a way to support RedHat, wouldn't it make more sense to just make a donation to them and continue using your distro of choice?
Ummmm. People who can hack the kernel or virtually any other package to fix your problem? Or do you have a staff of 20 elite Linux coders on staff?
Put identity in the browser.
fuzz:Packages silkey$ pwd /Volumes/RHEL_6.0 i386 Di/Packages
fuzz:Packages silkey$ ls -1 php*
php-5.3.1-7.el6.i686.rpm
php-cli-5.3.1-7.el6.i686.rpm
php-common-5.3.1-7.el6.i686.rpm
php-gd-5.3.1-7.el6.i686.rpm
php-ldap-5.3.1-7.el6.i686.rpm
php-mcrypt-5.3.1-7.el6.i686.rpm
php-mysql-5.3.1-7.el6.i686.rpm
php-odbc-5.3.1-7.el6.i686.rpm
php-pdo-5.3.1-7.el6.i686.rpm
php-pear-1.9.0-1.el6.noarch.rpm
php-pecl-apc-3.1.3p1-1.1.el6.i686.rpm
php-pecl-memcache-3.0.4-3.1.el6.i686.rpm
php-pgsql-5.3.1-7.el6.i686.rpm
php-soap-5.3.1-7.el6.i686.rpm
php-xml-5.3.1-7.el6.i686.rpm
php-xmlrpc-5.3.1-7.el6.i686.rpm
Comment removed based on user account deletion
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
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Is it included?
2011. The year Gnome decided Linux will never be on the desktop.
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Not surprised to see OSS gone, but I am summarized to see HFS and HFSPLUS go.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
It's 3 years old, but it's going to be supported in that configuration for 10 years.
To be honest your software sounds cutting edge and uses features that haven't made it into the mainstream long term supported server market that RHEL is in. Some future version of RHEL might have all the features you are looking for, or are you continually chasing the latest greatest glibc and gcc?
It all seems to become a moot point a little bit, I'm running RHEL5 as my Xen machine and virtualizing from there now, so creating virtual machines with newer software configurations is becoming less of a hassle than it once was.
Realistically how long term is "long term". They've been playing by the rules for what? 15 years now? Is it still possible that hey can totally sell out and go back on what they've done? Sure. It's also "possible" that RMS might spend a weekend playing with an iPhone and the App Store and realize he's been wrong all these years. (Which will no doubt lead to yet another complaint about the pain and suffering which is his life.) Red Hat has done a good job of balancing corporate health with Open Source values. Standing around just waiting for them to screw up doesn't accomplish anything. They are and have been good citizens of the community, if they cease to be, feel free to complain. Pro-active complaining about what they might someday do is really not fair.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
Try CentOSPlus for starters. It throws in Kernels with drivers that aren't included by default by RedHat for example.
I'm not sure if they'll do XEN support for CentOS6 or anything, but its a thought.
- Michael T. Babcock (Yes, I blog)
I develop on FreeBSD, so I only come across these issues when someone tries running my code on GNU/Linux. Glibc is a nightmare to work with, so I generally leave that to other people where possible (you need horrible combinations of -D directives to make it conform to recent versions of POSIX or SUS, and often these hide other things). I generally target GCC 4.2, because that was the last one released under GPLv2 and is the one that clang aims to be compatible with. There aren't many things in 4.2 that aren't in 4.1, but atomic ops are the big one; you can't easily implement portable thread-safe reference counting with 4.1, you can with 4.2 and clang.
I am TheRaven on Soylent News
If they have a support contract, they have access to the updates.
If they have a support contract, they have access to the updates.
Right..and unless Red Hat made a serious change to the way they do business, the support contracts aren't free.
CentOS, on the other hand, does not have this limitation. The public yum repositories available by default in CentOS allows you to install and update packages, whereas in RHEL you have to be a paying customer to use their private yum repos.
Oracle's approach with Oracle Unbreakable Linux (which is essentially a re-hash of CentOS, which in turn is a re-hash of RHEL) is if you're not a paying subscriber, you can have access to their public repos, which will allow you to use yum to install the same packages that would be available on the CDs/DVD, but do not offer any of the updates. Although not perfect (perfect being that Red Hat would allow you unfettered access to their yum repos whether you paid for support or not), it is a step above the way Red Hat does things, in that if I don't need/want their support services, I can still utilize yum to install base packages.
Obviously, the best choice for an admin that wouldn't benefit from Red Hat's support services is to just install CentOS (if a RHEL-like environment is required). However, if you plan on setting up a box to run Oracle on, Oracle Unbreakable Linux is probably your best bet since you can still use yum to install your base packages...and the fact that Oracle only provides support to you if you're running on either RHEL or Oracle Unbreakable Linux (I found this out the hard way using CentOS on some database servers).
libvirt will launch plain qemu instead of the KVM version. You could use the QEMU Accelerator to speed up the basic qemu.
Yup that's what led me away from CentOS too, after several years of fighting with packages that wouldn't compile due to unmet dependencies. I managed to survive for a while by packaging my own sets of PHP/MySQL and friends, but that only covered a tiny part of the spectrum. Trailing a few versions behind everything got really annoying, maybe not a big deal for big business, but my work is always on the more experimental side of things. I'm fine with building stuff from source, but the glibc issue crippled my ability to do so.
I got so fed up with CentOS that I now run Gentoo on my server, with just a handful of bleeding-edge packages where necessary. It does require a bit of care and attention to patch notes, but dammit if I can't build something on Gentoo, I can safely say the source is broken.
-Billco, Fnarg.com
They are NO WAY near violating the spirit of GPL *or* the law. That statement is completely ignorant.
They *bought* Sistina for $31 million and fully open sourced GFS (Global File System).
They *bought* iPlanet Directory Server from Sun and open sourced it.
They *bought* iPlanet Certificate Server from Sun and open sourced it.
They *bought* Qumranet for around $107 million and are currently working to open source the virtual machine management software.
I haven't even started to list the projects that RedHat engineers directly contribute to in major ways. RedHat has been an *extremely* good citizen of the GPL because they put their *time* and *money* into GPL software. It has also payed off for them. RedHat is a Fortune 500 company now. They *only* thing they ask is that if you take their SRPMS and redistribute them, you remove their company trademarks. That is a completely reasonable request and is consistent with trademark law.
To be honest your software sounds cutting edge and uses features that haven't made it into the mainstream long term supported server market that RHEL is in.
I'm not sure about his software, but the specific feature (timerfd) he's talking about is not "cutting edge" by any measure - other platforms have had it for decades. I'm surprised that it is still considered newish in Linux land.
Specifying the RPM file format is not enough. Without detailed spec of how packages are installed and managed, LSB is of little use. It also doesn't say much about which default settings are considered reasonable. Nor does it deal much with issues of vertical integration (without which a Linux distro can look like a pile of non-cooperating, user-hostile pieces).
Stating in effect ''insert Gnome or KDE here'' doesn't cut it. It leaves a design vacuum (esp. about device-UI and service-UI behaviors) that a desktop environment project on its own will never address.
Further, there are virtually no applications which state to the user: "LSB Compatible". This point alone-- the fact that app authors haven't been sold on LSB as a target platform-- speaks volumes.
...the functional definition of what is a "system library" and what is "other" in a typical Linux-based distro doesn't really exist.
$random_blog_guy merely happens to be a lead CentOS 5 developer. *grin*
I can throw myself at the ground, and miss.
Be nice; Linux got it within two decades of Windows NT. Okay, so Windows NT, Solaris, most other commercial UNIX variants, Symbian, QNX, and *BSD also all had unified event notification before Linux, but Linux is still the best OS in the world ever! Or so people keep telling me.
I am TheRaven on Soylent News
A lot of system management utilities had to treat execution under dom0 quite differently than on linux normally. A lot of the industry would rather have a hypervisor platform with a 'normal' OS behavior to it.
XML is like violence. If it doesn't solve the problem, use more.
You have heard of mrepo? Lets you make mirrors of redhat that you can then use to yum update your servers.
That'd be what I said - I've never seen anyone call CentOS anything but CentOS. As in "CentOS is called CentOS but no-one ever uses 'enterprise' in its name, even if the 'ent' comes from Enterprise, but RHEL is not just RHEL but Red Hat Enterprise Linux, which people shorten to RHEL because it is too long to say in full".
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.
It appears that you are referring to Karanbir Singh as "random blog guy". If this is indeed the case, have a look at The CentOS Development Team located at http://www.centos.org/modules/tinycontent/index.php?id=2.
Sorry if I mis-interpreted your statement.
Red Hat didn't feel like releasing a torrent, since they don't have a tracker lying around.
I think, had they put some effort into it, they probably could have found one.
I'd like to see a screenshot of a default install.
Right..and unless Red Hat made a serious change to the way they do business, the support contracts aren't free.
But the GP is already paying for it. It's not like I suggested they go out any buy a support contract so they can get the upgrades. They've paid for a contract that they're not using.
However, if you plan on setting up a box to run Oracle on...
If you're setting up a box to run Oracle, just buy the RedHat or Oracle OS support contract. It's a pittance compared to the Database support contract. If you can't afford the Oracle support and OS support, you can't really afford Oracle in the first place. Which is what Oracle told you when they listed the requirement in the first place.