Hacker News new | comments | show | ask | jobs | submit login
Red Hat Enterprise Linux 7 Beta (redhat.com)
130 points by palebluedot on Dec 11, 2013 | hide | past | web | favorite | 103 comments

This is very exciting. I know until it gets all the government certs and rubber stamps I won't be able to use it at work but if it is out the ball can start rolling as they say.

Here is the list of all the detail (tech notes):


You can see updated and deprecated packages as well as issues so far in beta.

Which certs are most important these days for govt use? Or does it depend on which department you're going for?

FIPS 140-2, and Common Criteria (EAL) are the two most often checked in my area of work.

I'm surprised by their removal of all these wifi drivers.

Well, it is a server product so WiFi support isn't very relevant. The wire is still easier to secure so it might help for certification (speculating here).

Does government certs mean backdoors?

No. The government has to certify the system before it can be used on government networks.

This is so companies can sell compliant RHEL7-based solutions to military and other government organizations.

Those are orthogonal concepts ;-)

> Improved Application Performance and Isolation. Run applications in isolated and secure lightweight containers utilizing SELinux and resource management. Linux containers provide a method of isolating a process and simulating its environment inside a single host. It provides application sandboxing technology to run applications in a secure container environment, isolated from other applications running in the same host operating system environment. Linux containers are useful when multiple copies of an application or workload need to be run in isolation, but share environments and resources. [1]

Looks like there is a major shift in that they will support containers out of the box now. Hopefully we will see some type of GUI to create containers and manage cgroups. There has also been major effort assigned to getting containers working with OpenStack and Docker. You can manually download/compile LXC today, on RHEL 6.4, but it seems like a bit of a hack, since you need to figure out networking and LVM on your own, never mind building base container images. Should be interesting.

[1] https://access.redhat.com/site/sites/default/files/pages/att...

Hopefully we will see some type of GUI to create containers and manage cgroups.

The GUI for libvirt is called virt-manager: http://virt-manager.org/

It can be even more seamless and convenient than that with Systemd.


I’m not sure what Systemd version they’ll end up shipping though.

The best part about Systemd is that the default framework for launching and monitoring services is essentially LXC without the padding (extra PID0 etc). This means every service can benefit and there’s no need for the unnecessary abstraction (the container) and all the (mental not necessary performance) overhead that goes with it.

Needless to say, I’m quite excited about what is happening on Linux nowadays :)

systemd-nspawn isn't recommended for production use. I can't tell you why that is, but if you search for it, you'll find a few places where Lennart Poettering recommends libvirt-lxc for deployment (which is completely unrelated to the other "LXC" project).

This means every service can benefit and there’s no need for the unnecessary abstraction

Of course you could run software on bare metal ;-) But containers are a nice way to ship whole projects including the dependencies. Especially if you deploy to lots of machines.

Looks like systemd 207.

There has also been major effort assigned to getting containers working with OpenStack and Docker.

Relevant interview w/ Alexander Larsson: http://opensource.com/business/13/11/docker-fedora-red-hat-c...

There's significant effort underway in the Docker community to get libvirt as a viable execution engine for Docker. Very similar to how you can choose between AUFS and LVM.

Exactly - if they support and test LXC now, and the market demands Docker a year into the lifecycle (RH generally don't add features between major releases, so it'd have to be worth it for them), it's still doable as it's a userspace addition.

Red Hat just added Docker to RHEL 6.5, so there's your example of them adding something mid-lifetime.

"Added" via EPEL and supported by redhat officially isn't the same thing.

Red Hat Enterprise Linux 6.5 now Generally Available (adds Docker support) http://developerblog.redhat.com/2013/11/26/rhel6-5-ga/

True, but Software Collections are now a nice half-way house for fast-moving things RH customers want support for. It may turn up there.

If you really need that much support tooling around lxc, why not go with OpenShift?

Sounds a lot like Solaris containers of a decade ago.

Yeah, I have been doing some research for an upcoming screencast, and this type of idea is called Operating system-level virtualization [1], and there is a fairly good table with the various OS's and their take on OS-level virtualization. E.g. Solaris Containers, FreeBSD Jail, OpenVZ, HP-UX Containers, etc.

[1] http://en.wikipedia.org/wiki/Operating_system-level_virtuali...

Here's a background piece on containers that I wrote a few months back: http://bitmason.blogspot.com/2013/09/what-are-containers-any...

Thanks. FYI, I just posted this to HN [1]. Seeing as you put in all this effort, you should have people reading it, outside this thread. Looks like you made the front page too!

[1] https://news.ycombinator.com/item?id=6889679

Thanks! I was wondering where my piece popped up from :-)

Yep. Or BSD jails before that.

"Red Hat Enterprise Linux 7 beta includes three desktops to match different work styles and preferences: GNOME 3, GNOME Classic, and KDE."

I know that RHEL is mainly used on servers, but this development looks significant to me. I look forward to an eventual CentOS 7 release with a choice of desktops.

As someone who uses CentOS 6 on the desktop, people really should take a look at this.

For me, it's the only Linux desktop which I can find which is reliable and works out of the box with all my hardware.

Yes, I have CentOS 6 on a Thinkpad x200s with hard drive encryption enabled as my work machine. I find it stable and quite fast. I may leave that machine on CentOS 6 and put 7 on the 'play' laptop.

My point was giving a choice of desktops is a new departure for Red Hat. Remember that they employ, or have employed, a number of the Gnome developers, and that I gather Red Hat has been a major sponsor of Gnome in the past.

>> giving a choice of desktops is a new departure for Red Hat

Is it? I've only used RHEL on servers but I've used CentOS on my desktops and laptops for a long time with many re-installs - I've always seen the choice to use KDE as part of the base install.

Yeah, coming from the RH/Fedora world, it seemed weird when other distros starting spinning specialized versions for a different window manager on the desktop, such as kubuntu. I guess that's because they wanted to have more control over the "experience". RHEL is about getting shit done when you know what you are doing, not holding your hand and making you feel comfortable, so I guess with those different expectations it's a bit easier.

Fedora ships a whole bunch of different spins, including desktop flavors.


Did they always? I remember it usually being as simple as installing the RPMs, and running the switchdesk utility. I always had to do that (or generally something more involved because of my choice) to run FVWM2.

Ubuntu also allows you to just install the packages for a different desktop; the differently branded install CDs are mostly for people who come from windows or OSX and thus believe that the desktop == the OS and it's impossible to change once installed :P

Then I must be mistaken, thanks.

I've tended to associate CentOS with Gnome, and I installed from live CD with a reduced package set. I still think it is significant that Red Hat are publicising the choices.

Yeah - Gnome was definitely the subtle default. IIRC correctly, the Gnome option is called "Desktop", and the KDE option was called "KDE" (or something like this). So unless you had a known preference, you'd end up with Gnome. Contrast this with openSuSE that has 2 specifically-named download options.

Watch it with wifi on newer hardware though. It's rock solid 90% of the time, but I've had issues in the past (especially with Atheros cards)

I usually prefer that. I'm actually using fedora with MATE to get a similar UX.

> The Btrfs file system is now supported.

Nice. http://en.wikipedia.org/wiki/Btrfs#Features

From the draft of the new storage administration guide:

Btrfs is still being actively evaluated for stability during the Red Hat Enterprise Linux 7.0 beta. The following target use cases will only be fully supported if it passes our tests: * The system partition only use case. This will allow btrfs only to get used for system installation, not only for a user's data. Currently it is unclear whether this will be restricted to this single disk or not. * Use btrfs for desktop and laptop users including their data partitions. * Use btrfs as the base file system under scale out "big data" file systems, such as gluster and Ceph.


Wow, XFS by default, is there any other distro that uses it by default? Makes me miss my old SGI machines...

I was struck by that too, and came here to make the same comment.

Why do you suppose they went with XFS? Ext4 seems like the defacto file system these days, but I know a lot of people seem to prefer XFS for one reason or another. It's a surprise to me that RHEL decided to default too it.

Anybody care to shed some light?

It's all about expected disk sizes in 10 years time (when RHEL 7 main support ends). Ext4 scales up to around 16 TB -- I know it theoretically can support a much larger volume size, but in practice it doesn't work so well. XFS handles tens of terabytes without a problem and Red Hat has been supporting huge XFS volumes for years with many customers (who in earlier versions of RHEL paid extra for that support).

Dave Chinner's talk is great: http://www.youtube.com/watch?v=FegjLbCnoBw

Their gluster server offering also uses XFS, so probably for support reasons, they saw XFS had better long term support for both sets of users.

http://lwn.net/Articles/573690/ Dave is a redhat employee.

I remember using XFS some years ago. It was blazing fast for anything involving large files.

It also had a bug, in that a power failure or kernel crash was liable to truncate some freshly-written open files to zero size. Anyone knows if this problem has been eliminated?

Not sure actually, pretty bold of RH but they have put a ton of dev time behind it with gluster so I guess it only makes sense.

seriously recommend people who care their data on disk to use ext4. http://lwn.net/Articles/476263/ XFS behaves not so well on power failure case.

That is pretty much 12 months old does it still apply?

Performance Co-Pilot being bundled as part of the monitoring tools is pretty interesting; I see one of the devs has been blogging about it in the last month or so: http://developerblog.redhat.com/2013/11/19/exploratory-perfo... and http://developerblog.redhat.com/2013/11/26/performance-regre...

That is a very awesome tool, I am really wondering why I have not seen it before.

I saw at at linux.conf.au in 2010 and it looked good, but also as though it hadn't been worked on for a while. It looks like it's had a lot of neat stuff added in the last 3 years.

"All Java 7 packages (java-1.7.0-openjdk, java-1.7.0-oracle, java-1.7.0-ibm) in Red Hat Enterprise Linux 7 beta let you install multiple versions in parallel, similarly to the kernel."

This sounds pretty convenient to me.

I don't think that this is new (other than 1.7 being the default now) unless they are using something other than alternatives: https://access.redhat.com/site/documentation/en-US/JBoss_Ent...

New to me :)

What I recall from a while ago is finding systems with just openjdk and having to install the 'official' version manually. That could have been Fedora though.

64-bit ISO: ftp://ftp.redhat.com/pub/redhat/rhel/beta/7/x86_64/iso/rhel-everything-7.0-beta-1-x86_64-dvd.iso

Is this an 'open' beta or do you need a subscriber key? Just curious, I usually wait for CentOS for a desktop installation on a laptop

Their betas are open, but you may not receive much in the way of updates (including security updates) if my experience with the RHEL 6 beta was anything to go by.

You should be able to flip into CentOS 7 fairly easily when they release, though.

I'll install it on an external hard drive and have a play. Thanks.

For Desktop users (RHEL is also used in workstation environments):

"Red Hat Enterprise Linux 7 beta includes three desktops to match different work styles and preferences: GNOME 3, GNOME Classic, and KDE"

I'm happy that MariaDB 5.5 is replacing MySQL but not so happy that Thunderbird is being removed in favor of Evolution.

XFS is the default filesystem.

"Multiple required authentications" in OpenSSH. Nifty.

It's probably because Mozilla announced that Thunderbird is now in maintenance mode. They do not plan to add features or make major changes anymore.

To some that may mean Thunderbird is complete and mature, but RedHat must believe that Thunderbird is now a dead end.


Fedora 18 is already matured?) Or it is based on outdated 17th?


Suggests Fedora 19 package set and 3.10 kernel.

If I'm not mistaken nodejs was in that package set, good step forward for enterprise adoption if it's in RHEL7!

node.js is already in the Software Collections repo for RHEL 6, so you can get a Red Hat supported, maintained node.js already.

Did not know that, cheers!

Supposed to be based off F19, with full systemd support (just like fedora).

The removed packages listing[1] is chock full of items being replaced by systemd.

1: https://access.redhat.com/site/documentation/en-US/Red_Hat_E...

At least the installer is a newer version, looks like it's from Fedora 19.

uses tmux yay!

Anyone know which Python version will get bundled with RHEL 7?

From the release notes[1], at least the beta version comes with Python 2.7.5.

[1]: https://access.redhat.com/site/documentation/en-US/Red_Hat_E...

2.7.5 according to Distrowatch (http://distrowatch.com/table.php?distribution=redhat)

It says in the link, though I suppose it is only a beta still.

Python 3 will be an option.

Anybody know if they have the new C++ toolchain that will allow Chrome to start working again?

How long were the beta periods for RHEL 4, 5, 6? I know there's no commitment, but I'd like to tighten my vague idea of how long the beta period will be. Right now, I guess more than a day and less than a year.

Typically about 6 months, judging from the press releases announcing the public betas of 4, 5, and 6, and comparing to the GA release dates.

RHEL 4 beta: Sep 27, 2004 / GA: Feb 15, 2005

RHEL 5 beta: Sep 7, 2006 / GA: Mar 15, 2007

RHEL 6 beta: Apr 21, 2010 / GA: Nov 9, 2010

> systemd & OpenLMI

With the next SLES also going systemd by default, Do you think this will force the hand of the few holdouts left? Going I can't see vendors wanting to support all of systemd, upstart, sysvinit.

Debian seems to feel that way and is choosing between upstart and systemd http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708

Has anyone found the root password for the kvm qcow2?

I had to boot from an .iso and mount up the filesystem to reset it. Also disabled selinux on reboot. If you find it out, please post, I'm curious myself.

I mounted it (by the ways of qemu-nbd and so forth) and chrooted into it. It seems like there are no accounts with a valid password in it..

Based on https://access.redhat.com/site/solutions/641193 the root account is disabled but sudo is granted to the uid 'cloud-user'. Basically, it is configured to use cloud-init and be provisioned ssh keys.

If a root password is required, the KB recommends using 'guestfish --rw -a <image>', mounting the filesystem, and running vi against /etc/shadow.

No idea, but virt-edit will let you remove the root password from any disk image:


Can anyone explain a bit more about what happened to Red Hat? I'm about behind the history of this Distribution. Last time I read about it I found out that is paid and I never considered it, because of that. I'm using Slackware for most of my servers, but I don't know what is the target market or what is more special in Red Hat Enterprise.

There are some misconceptions here. RHEL does not cost a cent. Support for RHEL, which includes security fixes through the package manager costs money. Security fixes and other patches and updates are still released as source by RHEL, as required by the GPL.

If you really wanted, you could run RHEL with no subscription and compile your own updates from the source that they release. In practice, this is next to impossible to maintain as an individual, but it is exactly what CentOS, Scientific Linux, and other related EL distributions do. They remove the RHEL trademarked logos, compile the code released by RHEL, and make it available through a generic yum repository that doesn't require a RHEL subscription.

So, in short, RHEL doesn't cost money, support and packaged patches do. CentOS gives you binary and version compatibility of RHEL without the cost.

> I don't know what is the target market or what is more special in Red Hat Enterprise.

Enterprise. You kind of answered your own question.

> Slackware for most of my servers

Ya, you're not the target market. Also, you might be a masochist.

It's been necessary to pay for RHEL for a while now. When you pay your subscription, you do get support from RHEL as well. However, if you just want to try the OS, you can go get CentOS. Since RHEL is open source, the CentOS team removes the RHEL name from everywhere and recompiles it.

One market that it seems to be strong in is the defense world, since RHEL is one of the few OS' that get various certifications for safety and security.

The biggest reason to get RHEL is certification (assuming you don't need their tech support or updates). A number of third party vendors will only support one of the Enterprise Linux distributions (RedHat, Suse, Oracle Linux, etc). Now the technical differences between RHEL and, say Fedora, is that RHEL gives you a long time of getting bug / security fixes that are "minimally invasive", that is you can apply them and have a very good chance that your existing configuration and apps still work without a reinstall ore reconfiguration. (This is what is meant by "stability").

For personal use, you can get similar stability from either CentOS or Scientific Linux, although the bug fixes will lag behind Red Hat by a few days (although some critical updates have been released only a few hours after Red Hat).

> what is more special in Red Hat Enterprise.

In essence, you pay for their excellent support.

Anyone know what version of gcc it'll ship with? Couldn't find that in the tech overview PDF...

From Chapter 11: Compilers and Tools in release notes:

11.1. GCC Toolchain

In Red Hat Enterprise Linux 7.0 Beta, the gcc toolchain is based on the gcc-4.8.x release series, and includes numerous enhancements and bugfixes relative to the Red Hat Enterprise Linux 6 equivalent. Similarly, Red Hat Enterprise Linux 7 includes binutils-2.23.52.x.

These versions correspond to the equivalent tools in Red Hat Developer Toolset 2.0; a detailed comparison of Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 gcc and binutils versions can therefore be seen here:



Notable highlights of the Red Hat Enterprise Linux 7.0 Beta toolchain are the following:

- Experimental support for building applications compliant with C++11 (including full C++11 language support) and some experimental support for C11 features.

- Improved support for programming parallel applications, including OpenMP v3.1, C++11 Types and GCC Built-ins for Atomic Memory Access and experimental support for transactional memory (including Intel RTM/HLE intrinsics, built-ins, and code generation)

- A new local register allocator (LRA), improving code performance.

- DWARF4 is now used as the default debug format. A variety of new architecture-specific options.

- Support for AMD family 15h and 16h processors.

- Link-time optimization support.

- Enhanced warnings and diagnostics.

- A variety of new Fortran features.

It's 4.8.2

4.8.2 it looks like

I'm glad to see XFS got some love. Also PTP is nice feature.

PTP testing so far is looking quite good!

I'm glad I can stay on 6.x until all the kinks are worked out with systemd. I was on whatever Fedora made the switch to systemd and it was pretty painful.

I am looking forward work with XFS....how is possible to migrate XFS from ext4 if i want to update RHEL 6.x to RHEL 7....

How far away do you think is the release?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact