Red Hat Enterprise Linux 8 Beta | Hacker News Reader

Red Hat Enterprise Linux 8 Beta

redhat.com

148 pointsciupicri123 comments

> Btrfs has been removed

I'm still incredibly sad about that, especially as Btrfs has become a really solid filesystem over the last year or so in the upstream kernel...

Reference: https://access.redhat.com/documentation/en-us/red_hat_enterp...

Indeed, Btrfs is uniquely capable and important. It has lightweight snapshots of directory trees, and fully supports NFS exports and kernel namespaces, so it can easily solve technical problems that currently can't be easily solved using ZFS or other filesystems. Btrfs is also used now for ChromeOS's Crostini Linux application container.

bcachefs is another "competitor" to btrfs: https://bcachefs.org/

But Redhat is going all in with stratis: https://stratis-storage.github.io/

Notable: Btrfs is used for all of ChromeOS and the crostini container is just another volume.

It's incredibly robust, really confusing why RH would be pulling this.

It was never emphasized, and probably rarely used by their customers. Prior RHEL release used ext4, then xfs by default. People who run RHEL don't want to think about what filesystem to use. They want standard, stable, reliable -- not dozens of options and features.

When you're pushing the container stuff, Btrfs becomes extraordinarily valuable. Being able to snapshot a base thing and then layer on top, and do trivial rebasing, as well as cheap replication of container volumes is _very_ useful.

On my Fedora and EL7 systems, I use Btrfs for the OS and for my containers for those purposes. It's awesome.

Slight correction: we use btrfs for the disk image backing the user's crostini state only. The rest of Chrome OS, and the crostini VM rootfs, still use ext4.

I know, that broke libguestfs too :-( Btrfs was the only Linux filesystem that let me create an 8 exabyte virtual filesystem in a reasonable time.

https://rwmj.wordpress.com/2018/09/05/nbdkit-for-loopback-pt...

What's the use case for an 8 exabyte virtual file system?

Testing the limits :-) It's interesting because it shows you how things scale, and that information is useful even for normal-but-large filesystems. I've submitted a talk about this to FOSDEM next year.

Previous Hacker News thread https://news.ycombinator.com/item?id=14907771

Do they include other file systems which can provide data checksums? The linked stratis doesn't seem to have that feature, did they patch the underlying XFS? There don't seem to be that many filesystems with that capability yet:

https://en.wikipedia.org/wiki/Comparison_of_file_systems#Fil...

No, they plan to implement dm-integrity target as one of available dm layers.

See section 9.2.2 in https://stratis-storage.github.io/StratisSoftwareDesign.pdf

If it's only been "solid over the last year" it ain't solid.

Really not an expert here but Red Hat did acquire and open source VDO from Permabit which has similar functionality AIUI.

As far as I know VDO only provides compression and deduplication. So no snapshots like in Btrfs and ZFS, although you can use LVM snapshots. Also no RAID features.

I use subvolumes, snapshots, and send/recv functionality for cheap replication of data. Sometimes even on RAIDed disks!

There are only two file systems with that feature set today: Btrfs and ZFS. I personally prefer Btrfs because it's way more flexible and shipped with the Linux kernel.

I guess it depends on what Btrfs features you are using. I remember SUSE who are using Btrfs as a root fs in the enterprise distro restricting its use to a subset they consider stable.

On the Btrfs status page https://btrfs.wiki.kernel.org/index.php/Status you can see that the developers themselves consider several features "mostly ok", which is probably not an assessment most filesystem users will find reassuring.

I would actually be okay with Red Hat applying the same restriction SUSE did.

For what it's worth, this is the feature set SUSE offers: https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15/#TechI...

I would be absolutely okay if Red Hat applied the same restrictions.

Has SuSE turned these off, or are they going to tell you "you shouldn't have used this feature" when you go for support?

They are switched off. You can't use them. They patch btrfs-progs to prevent accessing those features.

Release notes here: https://access.redhat.com/documentation/en-us/red_hat_enterp...

For those that matters, MongoDB is not included because it uses Server Side Public License: https://access.redhat.com/documentation/en-us/red_hat_enterp...

Also, KDE is removed and GNOME + Wayland is default.

> Also, KDE is removed and GNOME + Wayland is default.

Yeah, and the important part is that migrating from RHEL 7 with KDE to RHEL 8 is not supported: https://access.redhat.com/documentation/en-us/red_hat_enterp...

Upgrading from RHEL 6 with GNOME to RHEL 7 was not and still is not supported either ;-)

Interesting takeaways for me: They still use yum (instead of dnf) for managing packages, and default to nftables as the firewalld backend, while even Fedora (afaik) is still using iptables.

yum is now based on dnf

https://access.redhat.com/documentation/en-us/red_hat_enterp...

Yeah, but why not switch to dnf entirely since this is a major release? Fedora dropped yum some time ago.

I would imagine because it will break lot of scripts that use yum tooling. Just changing binary name could be painful.

Even on Fedora yum is still available

No, not really. You can install yum, but by default, any yum commands are translated to their dnf counterpart.

(Many don't need translation other than `alias yum dnf` sort of thing)

On my fedora 29 box:

[root@laptop ~]# which yum

/usr/bin/yum

[root@laptop ~]# ls -l /usr/bin/yum

lrwxrwxrwx. 1 root root 5 Oct 15 12:47 /usr/bin/yum -> dnf-3

Pretty sure "yum" in rhel8 will actually be dnf as well, but keeping the name for backwards compatability

You can type either ‘yum’ or ‘dnf’, but they decided to keep ‘yum’ to avoid a lot of scripts/documentation from breaking. ‘yum’ is a compatibility layer over dnf that keeps the old command line syntax but uses the fast depsolver, weak dependencies and other new features from dnf.

It is dnf, they just didn't want to change the name, so they call it yum.

Enterprises are babies when it comes to change and would have been mad if they needed to update their scripts.

Too bad it doesn't come with Python 3.7, only 3.6. Fedora 29 managed to switch to 3.7, although it was released just two weeks ago.

Later versions of Python will be supplied as modules. So will Python 2. They are parallel installable with "system-python" which remains at 3.6 for the lifetime of RHEL 8. (Note that in general modules are not parallel installable, but in this one case it is).

As a module will it have as many libraries available as the system Python? For example does it come with scipy packages, twisted, pyserial, xlrd/xlwt/openpyxl, gobject (for GTK+ apps), etc?

AIUI the plan is to build everything for each Python module (plus system-python).

However there are two things that mean it's not quite as good as you would like:

(1) Base RHEL 8 will only have a fairly minimal set of Python packages (indeed, packages in general).

(2) Products on top - things like OpenStack - will settle on a particular Python version (ie. module) and only be built against that version, and will require the corresponding Python module to be enabled.

I'm more surprised by the fact that no Python is installed by default on a Red Hat distribution

https://access.redhat.com/documentation/en-us/red_hat_enterp...

I think Perl and Python were only ever installed by default because there were management utilities (GUI and console) written in them, so they were prerequisites for what was considered a minimal system. RHEL has been pretty good the last few years at paring down the base minimal install to actual essentials. I view getting to the point that Python is not required for a base install an achievement.

Me as well, since someone had the clever idea to create GUI distribution management tools in Python, it is a pain to use them, given how slow some of them are.

It's unlikely Python is to blame for that, unless they implemented something very CPU bound in it. I wrote wxPython apps in 2000 or so and they were very responsive.

Well the previous generations written in C used to perform quite well.

It is likely a combo of Python + someone not good at using Python with networking. When working with anything that talks a lot over networks you need to use threads or separate processes to keep things feeling responsive during network delays. Python doesn't make this easy, so lots of devs skip it and it makes the programs feel sluggish.

Hmm, that might make sense on a server, but this is talking about a GUI client. Also, Python has trouble with CPU-bound threads but not those IO-bound.

A huge amount of work was done to minimize the base set of packages (called "BaseOS"). Including rewriting parts of dnf from Python to C++.

Wasn't python required for YUM to function correctly? Or has DNF been written in something other than python?

yes. https://rpm-software-management.github.io/page4/ (some of the specific posts seem to be unavilable)

Platform python see comment above

Actually there is a default python and it’s called platform python. That one lives on purpose in /usr/libexec however is mainly supposed to be used by platform tooling like dnf/yum etc

> Linux containers, Kubernetes, artificial intelligence, blockchain...

Bingo!

Damm, I had unikernels on my card. :)

Not in RHEL 8 but I'm working with a student on this. There's a rather general non-technical article here:

https://next.redhat.com/2018/11/14/ukl-a-unikernel-based-on-...

Cool! Thanks for the heads up.

I love it when I learn something new from a joke.

This made me cringe so hard when I read it.

Sounds like a IBM Watson promo already :D

Red Hat marketing was already playing buzzword bingo before they got bought :D

Probably right. I think I might just be paying attention to it now looking for IBM-isms :)

You get that with any large company, unfortunately.

The big takeaway for me is that they consider Podman ready to use because it's honestly amazing. A fully featured container engine that doesn't need any elevated privileges or a central daemon -- using just Linux namespacing features. Once people realize the implications of having containers just being something you can run like any other program with zero fanfare I expect adoption to explode.

I suspect that Windows and macOS support going to be a big impediment to adoption of RH's container tools. Fedora has become a really good OS and Silverblue is going to be another level of awesome on top, but I don't see huge numbers of developers switching.

There still seems to be some confusing overlap in their tools. For example, what is the difference between "buildah" and "podman build"?

`podman` keeps the compatibility with Docker CLI params, so `podman build` is a wrapper around `buildah bud`

> It also includes a new TCP/IP stack with Bandwidth and Round-trip propagation time (BBR) congestion control, which enables higher performance, minimized latency and decreased packet loss for Internet-connected services like streaming video or hosted storage.

I suspect Red Hat didn't rewrite the TCP/IP stack, so can someone translate this from marketing into nerd? Google doesn't seem to know.

BBR is just an algorithm that tries to figure out the best sending rate of TCP packets. So you don't have to wait for every ACK after a PSH. it was added the the linux kernel a couple of years ago, good to see it in RHEL.

https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR

As I understand it there was a new TCP/IP stack added to the linux kernel back somewhere around 2015/2016 that couldn't be backported to the RHEL7 3.10 kernel without breaking the kernel ABI that red hat tries to only change with major versions.

So new to rhel TCP/IP stack not to linux as a whole.

I'm excited to see Apache bumped to 2.4.35 with HTTP/2 support.

Also, PHP has been bumped from 5.4 to PHP 7.2, which will be extremely nice to have out of the box.

They didn't really have a choice, PHP runtime versions have aggressive EOL dates these days.

They might, but ISPs still aren't in a hurry to support v7.

If you accept community repositories, https://ius.io/ (sponsored by rackspace) provides very up-to-date packages for Apache and Haproxy.

Maybe they'll include Apache 2.4.37 in the final release, so we can also get TLS 1.3.

The linux box sitting on my desk at work is running RHEL6 (which is really starting to get super annoying). My IT dept is just now starting to roll out RHEL7.

One place I worked for had a similar setup. I just installed the latest Ubuntu and ssh'd into nearby boxes when I needed something from them.

No way I'd tolerate a desktop almost 10 years behind.

In our place we still have boxes on Rhel 5, some even on Rhel 4. But Redhat did keep the things more or less the same visually over all these years, unlike Ubuntu which seems to change its look and feel bit too much.

That RHEL6 will still be supported with security and stability patches until 2020.

People can be snarky at Red Hat for being slow, but this is the exact reason why.

If your company has the engineering prowess to maintain the latest and greatest, that's great. Unfortunately most large enterprises just don't move at that velocity which is who Red Hat is trying to support.

Wow, they based on Linux 4.18! Good for them! I was worried they’d pick 4.14 or earlier, which would have been regrettable in terms of keeping the speculation attack mitigations maintainable.

I wonder why not 4.19 which I thought was an LTS kernel?

Red Hat don't use the upstream stable kernels, they totally maintain their own. As they backport things not just do fixes, I guess it doesn't matter.

Red Hat backports features aggressively and is one of the largest contributors upstream. The kernel version or whether it's LTS upstream doesn't matter.

gcc 8.2! Being on gcc 4.8.5 for RHEL 7 instead of 4.9 was a minor pain point for some c++11 or newer libraries when developing. Nice to see them jump all the way to the 8.x series.

Also great to see xfs gain COW support in RHEL, they are working to make up (in features) for dropping btrfs with xfs. We'll see how stratis works out.

gcc 8.2 is also available for RHEL 7: https://developers.redhat.com/products/developertoolset/over... It's included in the subscription.

I wonder how many companies will either not upgrade to RHEL 8 or seek to leave RHEL because of the acquisition by IBM.

Most companies are more pragmatic than this. Change adds risk, and companies which select RHEL are relying on it's stability and enterprise support, and will likely continue to do so, until there is a real, material reason to reconsider, such as IBM changing the pricing or service agreement.

(Note as a comparison, individuals who distrust Microsoft moved their projects off GitHub when it was acquired, but most businesses, even those in direct competition with Microsoft, such as Google, did not.)

About as many that left Github when it was acquired by Microsoft.

Judging by the surge of new users on alternative platforms (gitlab), that's at least a couple of thousand.

https://thenextweb.com/dd/2018/06/04/devs-are-flooding-to-gi...

Edit: Your silly comparison deserved a silly response. Customer bases and services between the two are not similar.

But how many paying customers? It's slightly different also because Github may not want to lose non-paying customers either, because of name recognition and not wanting competitors being seen much, but I don't think the IBM acquisition will sway most people that are using CentOS, since it's already somewhat divorced from RHEL proper.

No, it's incredibly different to compare the number of customers who might leave Red Hat to the number of customers who left Github. The services are not even close to being similar, and the customers are generally not even close to being similar.

> it's incredibly different to compare the number of customers who might leave Red Hat to the number of customers who left Github.

I don't think it's that different. Github makes somewhere around 50% of it's revenue from enterprise customers.[1] That said, my point was that they aren't very similar, so we seem to be saying the same thing, you just seem to be doing so rather aggressively.

1: https://www.businessinsider.com/githubs-enterprise-service-b...

The question about who will leave is always silly because we don’t have privileged info about IBM’s plans for what happens after the acquisition. Things that keep people with RedHat could go away without much notice.

That’s why the uproar and threats to leave over the MS acquisition was dumb.

And it isn't as if the new home couldn't be bought as well.

I'm affiliated with a number of projects that moved from github after the MS acquisition, and I'm aware of a few others. So at least some of us decided to act and not threaten.

There is more optimism about the future of Microsoft than the future of IBM. Evidence: Microsoft's stock price has nearly tripled during the last 5 years, whereas IBM's has dropped almost 40% during the same period.

The real question is if IBM will cut off CentOS in the hope of driving customers to pay for RHEL.

So I work for Red Hat and the truth is no one will know until after the acquisition, but there are certainly no plans for that, nor have I heard anyone even discussing such a thing. CentOS is a valuable part of Red Hat and an important part of keeping users in the ecosystem even if they're not paying us, so it wouldn't really make any sense. IBM aren't stupid (despite nonsense that people write online), and Red Hat is a cash machine and they'd be stupid if they messed with a proven model which works.

Seems like supporting and incorporating RHEL support into IBM’s business is the reason they bought RHEL. They effectively grew their business contracts with the addition of all the RHEL contracts.

If anything, I would expect business as usual for their business customers. It was a really obvious market move in hindsight.

my guess is they bought redhat because it bought coreos. and ibm wanted that, too.

That’s a big premium over this what? 250 million?

It would do damage to the brand, and then you'd see developers fork Fedora and build their own RHEL-like "enterprise Linux".

IBM has never struck me as that clueless about open source, and I imagine Red Hat management would fight that as much as possible realizing how much of a long term strategic blunder it would be.

CentOS is being used by a lot of HPC shops, academia and research units like one where I administer a HPC.

For the number of cores that HPC shops run, the bill would become FAT real soon if we have to pay for OS. I'd imagine that if IBM messed with CentOS, it'd be called out for being incredibly dumb about RH business, and there would emerge an open fork of RHEL that is not owned by IBM like CentOS is.

To give you an idea, we run CentOS 7.5 on all compute nodes, but make use of paid for RHEL for our identity server, DB servers and the like. If IBM touches CentOS, the whole domino falls and we start looking for alternatives.

I haven't used scientific linux since version 6, but it was a very nice centos alternative at the time.

Still is.

Regardless of who owns Redhat, they still have to provide the source RPM's for most of the packages. The best they could do is change the build format enough and often enough to make it painful to repackage.

I don't envision them doing this however. That would force a lot of people away from Redhat based distros and guarantee barring conversion to RHEL entitlements.

From the people I know using huge amounts of centos in production, they're not going to pay for RHEL, if centos becomes non viable they'll be switching to debian-stable and debian-testing.

I don't think "but IBM sucks" is a good enough reason to change an entire infrastructure away from RHEL/CentOS.

I don't think any serious Enterprise will leave until they're giving a reason that's more than the acquisition itself.

So if Red Hat continues doing good by their customers, things will continue business as usual.

> Linux containers, Kubernetes, artificial intelligence, blockchain and too many other technical breakthroughs to list all share a common component - Linux

Erm what? Only two of those are built on Linux. If there's too many to list at least don't list unrelated technologies.

Anyone know what AI and blockchain it has?

Rust, python 3.6, great stuff!

Here is a download link to the DVD iso (rhel-8.0-beta-1-x86_64-dvd.iso) for those that are interested:

https://red.ht/2ROrd80

Yay finally 4.18 Kernel in RHEL.

I guess if you cross a Red Hat and a Big Blue dinosaur a big purple dinosaur could be the result...

https://i.etsystatic.com/5700633/r/il/ea2ba9/1552167872/il_5...

Finally no Python 2.7 anymore!

Well, not exactly, you can still get it, it just isn't default :) https://developers.redhat.com/blog/2018/11/14/python-in-rhel...

With the AppStream, does that mean Software Collections is no longer needed?

Not really an "either or". However, AppStream provides similar functionality. See this post: https://developers.redhat.com/blog/2018/11/15/rhel8-introduc... for more info.

Is there anything public on release date aims?

When it's ready. If there's one thing Red Hat have been pretty good at it's being conservative and not worrying too much about schedule slips.

I don't think that Red Hat announces release dates for RHEL. At least I don't remember one in the last 10 years.

RHEL 7 took 6 months to go from the first beta to the first release. Don’t hold your breath.

Thought for a moment I read IBM Enterprise Linux 8 Beta, anyone else?

Reply on news.ycombinator.com