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.'"

Comments

Too bad they gave up on XEN

[d3vi1]

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.

Re:Too bad they gave up on XEN

[Pecisk]

They replaced it with KVM, but it still bears some stigmata in Xen community.

Re:Too bad they gave up on XEN

[jernejk]

Wow, that sucks. I wonder if they did it to screw Oracle (Oracle vm server uses xen and Oracle enterprise linux, which is more or less rebranded RHEL). This will be interesting.

Re:Too bad they gave up on XEN

[shinzawai]

This was announced about a year ago...old news. They were always going to give up on Xen when they purchased Qumranet...makers of KVM and the SPICE protocol.

Re:Too bad they gave up on XEN

[silentcoder]

>but it still bears some stigmata in Xen community.
You mean when Xen community members here "KVM" they hit nails through their wrists ?

Re:Too bad they gave up on XEN

[slashmojo]

I use xen extensively too so its a good job EL5 will still be supported for many more years (until 2014 they say but all bets are off after 2012 ;) ).

Re:Too bad they gave up on XEN

[silentcoder]

More like atheist making a pun out of the fact that your spelling error has meaning. Well, I thought it was funny.

May I recommend some humoroid supplements ?

Re:Too bad they gave up on XEN

[Anonymous Coward]

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

[d3vi1]

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

[mukund]

Try VirtualBox. It performs well, even when not using hardware virtualization support.

Re:Too bad they gave up on XEN

[greg1104]

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.

Re:Too bad they gave up on XEN

[jernejk]

VirtualBox = desktop Xen=server completely different products, comparing them is nonsense

Re:Too bad they gave up on XEN

[h00manist]

It's a good example of a glaring barrier for open source growth: programmer man-hours, and corporations filling in those man-hours and buying the product, basically for the technical features already reached and marketing effect, with no commitment whatsoever with open source. Then nobody can quite fork the product and continue maintaining it open, simply out of a man-hours shortage. More options to get people working on open-source projects, keeping them open, are needed. I sort of lean toward feature pledges, with qualified project-manager reviewers, programmers in developing countries will likely start jumping at these.

Re:Too bad they gave up on XEN

[greg1104]

I wasn't the one who suggested VirtualBox as a Xen replacement. If your position is that "VirtualBox = desktop", that's just further evidence that it's probably not appropriate for the FP here to adopt, which is in line with my suggestion to tread carefully in that direction.

While primarily targeting the desktop, VirtualBox was becoming increasingly useful as a server virtualization solution. My main point was that such improvements are less to continue now, because Oracle already has a Xen based solution for servers they're selling.

Re:Too bad they gave up on XEN

[Anonymous Coward]

>You mean when Xen community members here "KVM" they hit nails through their wrists ?
You mean only the Xen community members that are there do that?

Re:Too bad they gave up on XEN

[diegocg]

You also must notice that Virtualbox has a couple of proprietary features that are only available if you pay them: Support for USB and RDP. This is the typical Sun open source business model, open source it but require copyright assignment to all external code contributions, so that Sun can release an alternative version with propietary addons (which even the external contributors have to pay for)

Re:Too bad they gave up on XEN

[mukund]

VirtualBox = desktop Xen=server completely different products, comparing them is nonsense

By this, you either mean:

1. VirtualBox doesn't support 'server' guest operating systems -- This would be incorrect as VirtualBox does support server guest operating systems. In fact, if your guest OS is Linux, it doesn't matter if the distro is a 'server' distro or a 'desktop' distro.. the OS packages are the same, except for their versions and distro-specific patches.

OR

2. VirtualBox doesn't have features typically used by admins who deploy server operating systems -- While this may have been correct years ago, it is not so today. VirtualBox can be controlled from the commandline, has an API if you want to control it from scripts, supports snapshots, live migration, remote desktop, web console, and a range of networking configurations. Maybe you can find some specific feature it doesn't have when compared to another product, but this is like comparing Oracle and PostgreSQL. If 90% of admins are happy with the features that VirtualBox provides, that's good enough for that 90%.

Re:Too bad they gave up on XEN

[Anonymous Coward]

You also must notice that Virtualbox has a couple of proprietary features that are only available if you pay them: Support for USB and RDP. This is the typical Sun open source business model, open source it but require copyright assignment to all external code contributions, so that Sun can release an alternative version with propietary addons (which even the external contributors have to pay for)

Not to interrupt your kicking of a dead horse, but according to Wikipedia Innotek adopted this business model before Sun bought Virtualbox. It was previously an entirely proprietary product.

Re:Too bad they gave up on XEN

[X0563511]

RDP I can understand, but please tell me the usage of USB passthrough in a datacenter environment? (that can't be easily done through the host by other means (such as shared directories))

Re:Too bad they gave up on XEN

[gbjbaanb]

Or you could go with VMWare, which also works with paravirtualised guests, and has pretty good support.

Re:Too bad they gave up on XEN

[Rhys]

Too bad except the Xen they shipped in RHEL5 has been nothing but a headache for me. VMs set to auto-start don't. Sometimes. Rarely they hang on the way down and have to be killed. Trying to put a different version of RHEL or Fedora on often results in failure (conflicting paravirt support from the kvm switch = no dice).

Re:Too bad they gave up on XEN

[Minwee]

but it still bears some stigmata in Xen community.

Do you mean that your virtualization hosts are bleeding for no explained reason, or are you trying to say that RedHat carries a social stigma because of their acquisition of Qumranet and support for their KVM platform?

Re:Too bad they gave up on XEN

[d3vi1]

http://www.linux-kvm.org/page/Main_Page - It says clearly that it uses "x86 hardware containing virtualization extensions (Intel VT or AMD V)".
See also: http://www.linux-kvm.org/page/Status
On http://en.wikipedia.org/wiki/X86_virtualization it says that the AMD V instructions came up in the second generation Opteron processors (the ones with Socket F).
Furthermore, from the same Wikipedia: "All Socket 939 and only Sempron processors except Sable, Huron and Sargas do not include support for AMD-V".

If you don't believe me, do a 'cat /proc/cpuinfo' and tell me if you see any virtualization instructions over there.

Re:Too bad they gave up on XEN

[zerocool^]

This is modded as funny, but if you see their Life Cycle page at:
https://www.redhat.com/security/updates/errata/

You can see that there's a 3 phase cycle for release support. Major versions are supported for 7 years, with the first 4 years being "primary support", i.e. new features, hardware support, and bug / security patches, and then after that they move into a maintenance cycle in which they will first not push new features, and finally only push bug fixes / security patches that are marked as "critical".

This is important to those of us that manage thousands of RHEL boxes.

Btw, got my RHCE a couple of months ago! So, technically, for me, the longer RHEL6 takes to come out, the better - my RHCE is valid until RHEL7.

Re:Too bad they gave up on XEN

[dAzED1]

VirtualBox was becoming increasingly useful as a server virtualization solution.

You must have had a lot of fun on 4/20 - you seem to still be under affects from that day.

VirtualBox is great for a 5 second "does this work for an XP user?" answer. There is no reasonable justification for using it to host a server of any sort of production value.

Re:Too bad they gave up on XEN

[pembo13]

You could always use Qemu sans KVM

Re:Too bad they gave up on XEN

[mysidia]

The Opteron 270 is ancient. Go send that server to the scrapyard with your other 6+ year old hardware.

And get a shiny new quad core proc. Just about any AMD server CPU released in the past 5 years has AMD-V support.

Re:Too bad they gave up on XEN

[mysidia]

And also requires VT or AMD-V. At least for 64-bit guests.

Re:Too bad they gave up on XEN

[billcopc]

I don't know the politics, but as someone who has to support two-too-many Xen hosts, I really can't fault Red Hat for ditching that bastard system. It had great potential until Citrix plastered their cursed name all over it, along with a nerfed GUI that doesn't even have a Linux port. Fast-forward to 2010 and the only people who don't retch at the sound of Xen, are the people who have already thrown gobs of money at Citrix to throw broken solutions at their non-problems.

Re:Too bad they gave up on XEN

[thule]

Just use KQEMU. libvirt will launch the basic qemu with the Accelerator. This is equivalent to VMWare without hardware visualization assistance.

Re:Too bad they gave up on XEN

[SlamMan]

There's still a few apps out there that either require USB keys for licensing, or that you want to have interact some sort of physical device that doesn't have its own IP stack. Thankfully, these cases are fairly uncommon these days, but they do still exist.

Re:Too bad they gave up on XEN

[X0563511]

Aaah yea, HASP keys. Gah, I hate those.

(Better than the old white Parallel port pass-through ones though)

Showing its age

[Anonymous Coward]

At last. The RHEL5 workstations at my Uni are almost unusable these days do to everything being so old and buggy. 3 years is a MASSIVE amount of time in terms of software improvements. Pity we don't have CentOS or Fedora, although we "can't do that' apparently because of the support contract that we NEVER use.

Re:Showing its age

[jernejk]

RHEL is probably not the best choice for workstations....

Re:Showing its age

[6031769]

Hmmm. Would you care to explain what you think it is that CentOS would give you that RHEL doesn't?

Re:Showing its age

[Anonymous Coward]

better pricing

Re:Showing its age

[shinzawai]

Troll...here eat this!

Re:Showing its age

[IBBoard]

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).

Re:Showing its age

[backwardMechanic]

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.

Re:Showing its age

[Anonymous Coward]

Would you care to explain what you think it is that CentOS would give you that RHEL doesn't?

The ability to reposync without being forced to pay for satellite.

Re:Showing its age

[zigmeister]

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.

Re:Showing its age

[dustwun]

Why do you think it doesn't have enterprise in the name? It's the Community ENTerprise OS.
Like RHEL, it's often shortened.

Re:Showing its age

[betterunixthanunix]

CentOS is a RHEL clone...

Re:Showing its age

[Anonymous Coward]

If you don't care about support, then certainly it would be stupid to buy red hat. But in my experience, i'd rather pay for support.

Re:Showing its age

[Anonymous Coward]

that's the biggy for us at work. the fact that we can host our own CentOS mirrors easily and simply blows RedHat away. the redhat network is extremely slow, and we've found it unreliable/unavailable in the past, which has left us in some _really_ bad situations!

Re:Showing its age

[EzInKy]

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.

Re:Showing its age

[shovas]

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

[1s44c]

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.

Re:Showing its age

[backwardMechanic]

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.

Re:Showing its age

[nicolas.kassis]

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.

Re:Showing its age

[shovas]

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.

Re:Showing its age

[X0563511]

https://www.redhat.com/apps/store/desktop/
https://www.redhat.com/apps/store/server/

They stopped?

Re:Showing its age

[pak9rabid]

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?

Re:Showing its age

[Anonymous Coward]

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.

They don't have to "prove" anything. They're complying with GPL, and they have corporate counsel along with the ability to out-money anybody who thinks they aren't.

Your socialist slip is showing; might want to adjust that skirt little girl.

Re:Showing its age

[gilboad]

(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

[gilboad]

.. 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

Re:Showing its age

[backwardMechanic]

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.

Re:Showing its age

[pak9rabid]

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?

Re:Showing its age

[TheRaven64]

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.

Re:Showing its age

[Anonymous Coward]

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.

In the past, I bought each version of Red Hat, beginning with 5x. After version 9, I only bought one license of RHEL 3, before switching to CentOS.

The problem is that I typically have about 3 installs at home, and a Red Hat license is tied to a single computer. The update rights expire after a year. So, the operating system becomes subscription based.

Having an annual subscription for the OS on each of my computers is too expensive for me, a lowly white collar computer programmer grunt worker. It's actually more expensive than buying Windows and getting free updates forever (or, about 10 years, usually).

I would be happy to buy a Red Hat license, if I can install it on all my home computers and get free updates forever.

Re:Showing its age

[Sosarian]

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.

Re:Showing its age

[DrgnDancer]

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.

Re:Showing its age

[MikeBabcock]

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.

Re:Showing its age

[TheRaven64]

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.

Re:Showing its age

[lewiscr]

If they have a support contract, they have access to the updates.

Re:Showing its age

[pak9rabid]

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).

Re:Showing its age

[billcopc]

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.

Re:Showing its age

[shutdown -p now]

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.

Re:Showing its age

[Anonymous Coward]

...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).

I found that all you have to do is rename the text in /etc/redhat-release. This allows Oracle installers to proceed as if you are running a Red Hat installation.

Re:Showing its age

[TheRaven64]

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.

Re:Showing its age

[jabuzz]

You have heard of mrepo? Lets you make mirrors of redhat that you can then use to yum update your servers.

Re:Showing its age

[IBBoard]

(yes, I realise CentOS is still based off "enterprise", but RHEL is short-hand for a full name where as CentOS is its name)

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".

Re:Showing its age

[lewiscr]

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.

Direct download links

[fearlezz]

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

Re:You know what?

[muckracer]

> Linux is killing me!

It does, as always, a good job!

which fedora?

[Kludge]

On which fedora is this based?

Re:which fedora?

[greg1104]

The packages mostly match those in Fedora 12, which makes sense as that came out in November and FC13 isn't released yet. However, they have bumped some things. Most notably, the FC12 kernel was 2.6.31, while RHEL6 uses 2.6.32. That's not surprising given a fair number of virtualization and performance features, as well as bug fixes, happened for 2.6.32.

Re:which fedora?

[diegocg]

Fedora 11, i think.

Re:which fedora?

[prefect42]

12. ish.

Re:which fedora?

[Macka]

I can confirm that. I was told by a guy from Red Hat recently that it's based on FC12 with some things from FC13 included.

Re:which fedora?

[greg1104]

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?

[mowall]

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:which fedora?

[blitzkrieg3]

It's a very fast moving tree. For example, I'm running 2.6.32 on F12 right now even though it shipped with .31. The .32 kernel just happens to be the release that balances the need for test enough with the latest release out of kernel.org.

Re:which fedora?

[Anonymous Coward]

also, 2.6.32 is a long term support kernel. ie 2-3 years instead of 6 months.

Re:which fedora?

[Luke has no name]

IIRC 2.6.32 is considered an "LTS" kernel. Occasionally, kernels are "suggested" to be used for longer support cycle releases for distros. Ubuntu 10.04 is using .32 as well.

Re:which fedora?

[Anonymous Coward]

EL is Fedora based. I wonder why parent was modded as funny?! :)

centos tracker! WAS Re:Direct download links

[nfsilkey]

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. ;)

Re:centos tracker! WAS Re:Direct download links

[blitzkrieg3]

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.

Why the KVM vs XEN dispute?

[h00manist]

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.

Re:Why the KVM vs XEN dispute?

[greg1104]

The Citrix stuff had little to do with it. Th Linux kernel developers favor code that is easy for them to integrate and maintain, and KVM fit better into that model than Xen. There are some situations where it performs quite a bit better too, and frankly few people care about those stuck with processors that don't have the right extensions to use KVM. Some good reading on the background here includes Discover the Linux Kernel Virtual Machine, Linux: KVM Paravirtualization, and The truth about KVM and Xen.

Re:Why the KVM vs XEN dispute?

[1s44c]

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.

KVM is Linux, XEN isn't Linux. Redhat is a Linux vendor so prefers Linux over things that are not Linux.

It's not a matter of one being better than the other but a matter of picking one that's closer to what you already know.

Re:Why the KVM vs XEN dispute?

[jon3k]

Can you explain that a little better? In what way is kvm linux and xen isn't? I don't know much about either of the two pieces of software and I'm genuinely curious.

Too many Linux-incompatible-with-Linux distros

[h00manist]

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.

Re:Too many Linux-incompatible-with-Linux distros

[1s44c]

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.

This has existed for a long time. It's called 'linux standard base' or LSB.

Re:Too many Linux-incompatible-with-Linux distros

[drinkypoo]

It would be quite wonderful if someone could figure out a way to make packages installable easily on all linux distros,

It's called building all the libraries and bundling them all together. Include them all in the package, and then using a script, craft an LD_LIBRARY_PATH that places this library location at the end of the path, using the OS' libraries if they are present. You need only link to the proper versions of libraries to make this work (that is, most projects just link against the major version; link against the minor as well. That avoids a lot of incompatibility problems, at the expense of being more likely to drive the user to your version of the driver. Or in other words, do what they do in OSX. Although they don't do it precisely this way, laying down a big directory full of libraries is their answer to this problem.

Re:Too many Linux-incompatible-with-Linux distros

[greg1104]

Why do newbie users even need to care about that? If you pick a distribution that has a good set of packages, they should rarely have to leave the ones provided with it. Run whatever front-end for package management you've got, make sure all the optional repositories are enabled, and there should be so many packages there the hard part is sorting through them all--not finding even more. Particularly given that so many things that used to be run as local apps have moved onto web applications nowadays, the main headaches for Linux newbies I see is getting their hardware working and making Flash work.

Re:Too many Linux-incompatible-with-Linux distros

[X0563511]

That would be nice, and it's entirely capable of being done... but it's a nightmare of work all put on the package maintainer's shoulders. So, it usually doesn't happen.

Re:Too many Linux-incompatible-with-Linux distros

[kc8apf]

Which only covers the filesystem layout and basic services. It says nothing about APIs or versions of libraries.

Re:Too many Linux-incompatible-with-Linux distros

[kc8apf]

Uh, no. OS X provides a rich set of libraries as part of the base OS. Apple goes to great lengths to ensure compatibility between OS versions (libSystem is compatible to version 1). The only time any software includes a library inside their app bundle is if they wrote it or it is an OSS library that isn't in the base OS. Most apps don't need to.

Re:Too many Linux-incompatible-with-Linux distros

[drinkypoo]

Nothing in your comment contradicted anything in my comment. Try again.

Re:Too many Linux-incompatible-with-Linux distros

[Anonymous Coward]

Personally I think Shuttleworth has a better solution with his calls for cadence. What is the point in having a common packaging standard if each distro is going to test and design around different versions anyway?

Re:Too many Linux-incompatible-with-Linux distros

[Anonymous Coward]

Easy, stick with Debian.

But seriously, I've only heard one argument for RH over Debian besides its enterprise support; that being that Debian's use of /etc/network/interfaces is archaic @_@

Re:Too many Linux-incompatible-with-Linux distros

[1s44c]

Which only covers the filesystem layout and basic services. It says nothing about APIs or versions of libraries.

It specifies versions of libraries. Google it.

Re:Too many Linux-incompatible-with-Linux distros

[MikeBabcock]

Repos aren't what you think they are.

Repos are FOR distros. Source is for compatibility.

If you want binaries AND compatibility you want statically compiled binaries which have very few or no dependencies, like the version of Firefox on mozilla.com.

Re:Too many Linux-incompatible-with-Linux distros

[Anonymous Coward]

man alien

Re:Too many Linux-incompatible-with-Linux distros

[vbraga]

This is the only reasonable way I ever found to ship closed source on Linux.

Re:Too many Linux-incompatible-with-Linux distros

[h00manist]

From https://help.ubuntu.com/community/VMware/Player

Installing VMware Player on Ubuntu 8.04 LTS and Ubuntu 8.10

1. Install required packages build-essential, linux-kernel-headers and linux-kernel-devel

   sudo aptitude install build-essential linux-kernel-headers linux-kernel-devel

2. Download the latest VMware player e.g. VMware-Player-2.5.1-126130.i386.bundle (download the bundle version, not the rpm one) and run it as root using gksudo. You'll get a graphical installer that installs VMware player for you.

Re:centos tracker! WAS Re:Direct download links

[fearlezz]

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.

Current PHP?

[SlamMan]

Please, for the love of god, tell me they're finaly including PHP 5.2 in RHEL.

Re:Current PHP?

[Anonymous Coward]

It's even more amusing than that. They're including PHP 5.3.

Re:Current PHP?

[dingman]

Looks like PHP 5.3.1, plus some patches ;)

Why

[Anonymous Coward]

I never tried RedHat, but I can't understand what more it can offer than a free distro? Seems the same to me, would be stupid to pay for this.

Re:Why

[jpmoney]

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.

Re:Why

[Daengbo]

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?

They don't understand

[Anonymous Coward]

In Linux, you don't download software installers from third parties like in the Windows world. If you're trying to do it that way, you're doing it wrong. The correct way to install software in Linux is to use the provided software repository and provided package management tools. Yes, package management differs according to distribution, but that's completely irrelevant to the end user. If they're using the provided tools, they don't even have to know what a deb or rpm file is.

5.3.1 + pecl mcd and apc! Re:Current PHP?

[nfsilkey]

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

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

SSD Trim support?

[Kakao]

Is it included?

Re:SSD Trim support?

[steveg]

Don't know the answer to that, but the first mainline kernel to have it is 2.6.33, and it looks like RH6 is using 2.6.32. However, Red Hat has a history of backporting features and bug fixes to their kernel without changing the version, so it's possible. Considering that it takes as long as it does for a major version change (kinda reminds me of Debian there) it would make sense for an Enterprise distro to make sure TRIM support is there.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Dropping OSS support?

[armanox]

Not surprised to see OSS gone, but I am summarized to see HFS and HFSPLUS go.

QEMU Accelerator

[thule]

libvirt will launch plain qemu instead of the KVM version. You could use the QEMU Accelerator to speed up the basic qemu.

Ignorant!

[thule]

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.

Re:Ignorant!

[jon3k]

very well said - where are my mod points when I need them. let's also not forget the untold lines of code that they've contributed to the kernel and other upstream projects. anyone who thinks redhat hasn't been exceptionally good to the community is a moron.

Installation interface is a crucial omission

[Burz]

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.

maybe that is because

[Burz]

...the functional definition of what is a "system library" and what is "other" in a typical Linux-based distro doesn't really exist.

Re:centos tracker! WAS Re:Direct download links

[dodobh]

$random_blog_guy merely happens to be a lead CentOS 5 developer. *grin*

Simpler for maintenance

[Junta]

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.

Re:centos tracker! WAS Re:Direct download links

[srvivn21]

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.

Re:centos tracker! WAS Re:Direct download links

[srvivn21]

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.

Screenshot?

[bloodandsoil]

I'd like to see a screenshot of a default install.