Red Hat Enterprise Linux 8 released (opens in new tab)

Most things on RHEL 7 aren't ancient - there's plenty of backports, even major ones.

Some examples:

- OpenSSL rebase to 1.0.2k (for HTTP/2 support).

- overlayfs2 kernel support.

- Kernel eBPF instrumentation.

- Introduction of podman and friends.

- Ansible is kept up-to-date.

- GCC 7 and Python 3.6 via Software Collections.

This includes extensive testing. I have non-production systems on Fedora which run mainline kernels and have seen my fair share of performance regressions and crashes.

I'm assuming there was no notable customer demand for colorful dmesg output.

I've always felt that RHEL really excels at that old school corporate Unix feel of having to deal with stodgy tools that are either really old and/or lack basic ease of use features.

Reminds me of the time I wrote a script that called 'hostname -x' on SunOS instead of Solaris and it changed the hostname to '-x' and broke X11. RHEL is the nostalgia Linux.

But seriously, has anyone ever empirically verified that the Debian Stable/RHEL model of shipping a bunch of really old packages and then layering years of patches over top actually generates more stable, more secure code?

My intuition after a couple decades of software dev is that bugs will fester longer in the old version and the patches themselves will start having bugs as the top of tree diverges more and more from the shipped package over time.

I have experienced only joy switching from ntpd (and worse, openntpd) to chrony.

Why aren't you happy with the ntpd->chrony move?

> For Python we tried to remove all the Python dependencies from the base image

Do you know why? I think it would be cool to not have any interpreted languages in the base image and FreeBSD manages to do that but I don't consider it that critical. For me it would be more interesting to not have Perl at all than Python...

I guess the situation with Python 2.7 on RHEL 7 was/is that painful?

what about ansible? how does it fit into the "only system installed python"?

Like Docker, but less insanity. Looks promising.

Red Hat Developer blog post on the topic:

https://developers.redhat.com/blog/2019/05/07/what-no-python...

This is an instance of what they're calling application streams, as explained in another post:

https://developers.redhat.com/blog/2018/11/15/rhel8-introduc...

Exactly, and with App Streams you won't be stuck on an old Python version! This is an awesome feature.

You already have that on CentOS/RHEL 7 with Software Collections, and App Streams make it a first-class citizen.

Oh it definitely does. I remember seriously messing up a Linux Mint installation a while back because I upgraded all of the 3rd party dependencies that were preinstalled (because hey, newer is better, right?).

Yes and no. It absolutely makes sense to ensure that admin scripts used by RHEL run in a predictable, tested environment; even more so since Python has dropped backward portability. OTOH not even being able to rely on Python's presence is exactly the kind of thing that makes Python unsuitable as the shell replacement it is being promoted as.

Aye; this should have been done a long time ago. I wanted to say 'since the beginning' (whenever that was), but maybe there were good reasons 20 years ago that I can't recall.

It probably made sense when disk space was a lot more constrained.

Do you think that there should be separate platform-sh interpreter for system shell scripts, and so on? That kind of strange for me. Probably difference is that shell is "complete" program, while Python is not.

For me, it comes down to the type of hosts I'm dealing with and how accurate I'd prefer their time to be. Years ago, I ran the reference implementation everywhere... but not anymore.

OpenNTPD's goals are to be "good enough" and provide "reasonable accuracy". On an OpenBSD laptop and several "play" VMs (running OpenBSD), it was indeed "good enough". For individual desktops or laptops and the random "standalone" machine, OpenNTPD is simpler and "just works" (I like that it can "verify" the time using HTTPS hosts of my choosing).

Nowadays, only my stratum 1 NTP servers still run the reference implementation. Everything else -- especially hosts which I may need to correlate events based on timestamps -- runs chrony.

A comparison of the three implementations [0] is available on chrony's website. From a quick glance, I don't see anything blatantly incorrect or "biased. The comparison was discussed here on HN ~18 months ago [1].

Basically, if accuracy to the second is good enough, OpenNTPD is fine. If you want more precision than that, go with chrony. It'll be MUCH more accurate and it really isn't any "harder" than OpenNTPD. You'll probably want to stick with ntpd if you're using reference clocks, although chrony supports a subset of them. If you're a nerd that wants the absolutely most accurate time you can get, Google "PTP 1588" as well.

[0]: https://chrony.tuxfamily.org/comparison.html

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

YMMV, but in my experience, if for whatever reason your clock is wrong by an hour in one direction (either ahead or after, don't remember), openntpd will take ages to skew it back, whereas chrony (and ntpd) do the right thing.

The color choices are client-side. You can use something like base16-shell to customize it.

Wouldn't it use the colors your terminal is configured to use?

> That's a frankly irresponsible decision for Red Hat to make.

You say that without knowing anything at all about the situation? If you're a Red Hat customer, you could file a support ticket to get it pulled back in.

Historically speaking, Red Hat is rather conservative about the number of crypto libraries they pull into their system because of the requirement to validate the system for certifications. But if there are legitimate requirements to have it included and managed by the base system, then usually they'll work to fix this if they are informed that it's needed.

Again, if no one has officially requested it, then why would they pull it in?

It can also help to file bugs on RHEL 8 in the Red Hat Bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%...

Red Hat has a long history of harming cryptography.

Is it perhaps in a separate package, at least?

For gaming purposes, I also have to recommend Manjaro purely from how great it handles installing graphics drivers. I wouldn't necessarily recommend it for someone's first Linux install, but once you know the basics in case something breaks it provides a better gaming experience out of the box.

Why is that? Is it driver-related? Or is it that RHEL is more for stability rather than speed?

For gaming, Arch.

It's rolling release, including the whole stack that's supporting games. And they have a wrapper package that will install steam and its dependencies.

They use Debian. https://stadia.dev/intl/en_us/about/

Thanks! I hadn't seen that before and it's definitely relevant, especially the free-to-share part.

Why would you waste cycles invoking grep and xargs and memory piping data back and forth, where pure sed can do it? ;)

It is a little bit more than that.

It's Cockpit.

http://cockpit-project.org/

It's "cockpit"; I regularly give it a try, looking for a better structured, more elegant webmin replacement; alas, cockpit has like 5% of webmin features.

Nice. I'm currently building an operator and this comes in handy.

Quick question: how do I differentiate between freely available and subscription-only containers on the Red Hat Registry?

Can these containers be run hosts that are not RHEL? It seems like it's allowed, but I'm not completely sure I read that right.

I'm also looking to know what packages are available in RHEL8 that are not available to UBI containers. I'm not able to find information as to what subset of the RHEL package universe is available to UBI containers. If you're aware of information on this I'd love to be pointed to it.

The best advertising would be releasing RHEL 8 for free for personal usage. I wonder, how much workstation licenses ($300 per year) they are selling.

> why would they kill a cash machine that's proven to work so well?

You haven't been around a merger & acquisition process, I take it. It's usually like the scorpion and frog parable:

A scorpion asks a frog to carry it across a river. The frog hesitates, afraid of being stung by the scorpion, but the scorpion argues that if it did that, they would both drown. The frog considers this argument sensible and agrees to transport the scorpion. The scorpion climbs onto the frog's back and the frog begins to swim, but midway across the river, the scorpion stings the frog, dooming them both. The dying frog asks the scorpion why it stung the frog, to which the scorpion replies "I couldn't help it. It's in my nature."

(from https://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog )

There is no ETA, the CentOS team never gives one and they aren’t giving one for C8. This release has a lot of build structure unknowns, like appstreams, so there’s no telling how long it’ll take.

They are buying Red Hat.

They acquired RedHat

I learned that the logo now is all hat: https://www.zdnet.com/article/goodbye-shadowman-red-hat-chan...

OpenSUSE Leap looks interesting. They have a KDE option too, unlike RHEL 8.