Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Red Hat Software Linux

Red Hat Releases RHEL 6 Public Beta 1 148

Posted by samzenpus from the how-about-a-test-drive dept.
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.'"
This discussion has been archived. No new comments can be posted.

Red Hat Releases RHEL 6 Public Beta 1 More

Red Hat Releases RHEL 6 Public Beta 1

Comments Filter:

  • Too bad they gave up on XEN (Score:5, Informative)

    by d3vi1 ( 710592 ) on Thursday April 22, 2010 @05:02AM (#31936668)

    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: (Score:3, Informative)

      by Pecisk ( 688001 )

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

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

      • Re: (Score:3, Interesting)

        by d3vi1 ( 710592 )

        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: (Score:2)

          by mukund ( 163654 )

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

          • Re: (Score:3, Interesting)

            by greg1104 ( 461138 )

            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 produc

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

              • 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: (Score:2)

                  by SlamMan ( 221834 )
                  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.

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

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

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

        • Re: (Score:2)

          by pembo13 ( 770295 )

          You could always use Qemu sans KVM

        • Re: (Score:2)

          by thule ( 9041 )
          Just use KQEMU. libvirt will launch the basic qemu with the Accelerator. This is equivalent to VMWare without hardware visualization assistance.
      • 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 pl

      • Re: (Score:2)

        by Minwee ( 522556 )

        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: (Score:3, Funny)

      by slashmojo ( 818930 )

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

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

        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

    • Re: (Score:2)

      by Rhys ( 96510 )

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

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

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

  • Direct download links (Score:4, Informative)

    by fearlezz ( 594718 ) on Thursday April 22, 2010 @05:31AM (#31936776)

    ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/ [redhat.com]

    Or torrent it:
    http://www.torrentreactor.net/torrents/5568298/RHEL-6-Beta-64-Bit [torrentreactor.net]
    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

  • which fedora? (Score:4, Funny)

    by Kludge ( 13653 ) on Thursday April 22, 2010 @07:06AM (#31937140)

    On which fedora is this based?

    • Re:which fedora? (Score:5, Informative)

      by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Thursday April 22, 2010 @07:31AM (#31937238) Homepage

      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 [kernelnewbies.org].

      • Re: (Score:3, Informative)

        by Macka ( 9388 )

        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: (Score:3, Interesting)

          by greg1104 ( 461138 )

          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: (Score:2, Interesting)

            by mowall ( 865642 )

            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.

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

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

    • 12. ish.

  • Too many Linux-incompatible-with-Linux distros (Score:4, Insightful)

    by h00manist ( 800926 ) on Thursday April 22, 2010 @08:05AM (#31937420) Journal
    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: (Score:2)

      by 1s44c ( 552956 )

      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: (Score:2)

        by kc8apf ( 89233 )

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

        • Re: (Score:2)

          by 1s44c ( 552956 )

          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.

      • Comment removed based on user account deletion

      • 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 desk

    • 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 dri

      • Re: (Score:2)

        by kc8apf ( 89233 )

        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.

      • Comment removed based on user account deletion
      • Comment removed based on user account deletion

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

      • From https://help.ubuntu.com/community/VMware/Player [ubuntu.com]

        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 [vmware.com] 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.

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

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

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

    • 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

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close