Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat Enterprise Linux 8 released

redhat.com

Post reply on HN
Print view View original

61–70 of 150 posts

Re: Red Hat Enterprise Linux 8 released

#61

Post by CoolGuySteve »

avar wrote: post #22
chomp wrote: post #4

Wrote this comment a while ago for anyone wondering about this: Just installed it in a VM, changes that jumped out at me: • No Python (that you should develop against) installed out of the box. There's a /usr/libexec/platform-python (3.6) that yum (dnf) runs against, and then python2/python3 packages you can optionally install if you want to run python scripts. • Kernel 4.18 • No more ntpd, chrony only • /etc/sysconf…

> Pretty colors when running dmesg! Neat, but a great isolated example of the ancient software people who use RHEL have to deal with. RHEL 7 has dmesg from util-linux 2.23, the "colors by default" feature[1] first came out with 2.24 released on October 21st, 2013, which is around the time[3] the first beta of RHEL 7 came out. 1. https://github.com/karelzak/util-linux/commit/9bc2b51a06dc9c... 2. https://github.com/kar…

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.

Re: Red Hat Enterprise Linux 8 released

#62

Post by fizgig »

vbezhenar wrote: post #60
CUViper wrote: post #56

Earlier quoted context omitted.

Try the developer download: https://developers.redhat.com/products/rhel/download

I would want to use it on at least 3 computers. I don't think that developer license allows that. And registering 3 different accounts probably is abuse of that system. Also I don't really do any development for RHEL, just using it for my personal computing needs.

I have a dev license and I can register 16 systems. Your mileage may vary, but it never hurts to try.

Re: Red Hat Enterprise Linux 8 released

#63

Post by vamega »

baijum wrote: post #12
robbyt wrote: post #6

With the whole IBM thing going on, I bet CentOS 8 is going to take longer than usual to be released.

Probably Red Hat Universal Base Image would be good enough for development instead of waiting for CentOS; https://www.redhat.com/en/blog/introducing-red-hat-universal...

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.

Re: Red Hat Enterprise Linux 8 released

#64

Post by Qerub »

chomp wrote: post #4

Wrote this comment a while ago for anyone wondering about this: Just installed it in a VM, changes that jumped out at me: • No Python (that you should develop against) installed out of the box. There's a /usr/libexec/platform-python (3.6) that yum (dnf) runs against, and then python2/python3 packages you can optionally install if you want to run python scripts. • Kernel 4.18 • No more ntpd, chrony only • /etc/sysconf…

• No Docker. But we got https://podman.io/ instead.

Re: Red Hat Enterprise Linux 8 released

#65

Post by lima »

avar wrote: post #22
chomp wrote: post #4

Wrote this comment a while ago for anyone wondering about this: Just installed it in a VM, changes that jumped out at me: • No Python (that you should develop against) installed out of the box. There's a /usr/libexec/platform-python (3.6) that yum (dnf) runs against, and then python2/python3 packages you can optionally install if you want to run python scripts. • Kernel 4.18 • No more ntpd, chrony only • /etc/sysconf…

> Pretty colors when running dmesg! Neat, but a great isolated example of the ancient software people who use RHEL have to deal with. RHEL 7 has dmesg from util-linux 2.23, the "colors by default" feature[1] first came out with 2.24 released on October 21st, 2013, which is around the time[3] the first beta of RHEL 7 came out. 1. https://github.com/karelzak/util-linux/commit/9bc2b51a06dc9c... 2. https://github.com/kar…

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.

Re: Red Hat Enterprise Linux 8 released

#66

Post by geofft »

CoolGuySteve wrote: post #61
avar wrote: post #22

Earlier quoted context omitted.

> Pretty colors when running dmesg! Neat, but a great isolated example of the ancient software people who use RHEL have to deal with. RHEL 7 has dmesg from util-linux 2.23, the "colors by default" feature[1] first came out with 2.24 released on October 21st, 2013, which is around the time[3] the first beta of RHEL 7 came out. 1. https://github.com/karelzak/util-linux/commit/9bc2b51a06dc9c... 2. https://github.com/kar…

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 De…

It doesn't generate more secure code—as you say, patches themselves may have bugs, and way fewer people are looking at the patched branches. Active development happens on HEAD, and dodgy code is often rewritten before anyone goes actually looking for bugs (security or otherwise). Many years ago I helped with a paper on how the practice of applying only "important" security bug fixes doesn't work: https://arxiv.org/abs/0904.4058

But the goal of the long-term-stable approach isn't security or stability per se: it's striking a tradeoff between operator work and risks to security and stability. You could, of course, snapshot Fedora (or Debian testing, or Arch, or whatever) from 2013 and keep running it. Nobody is stopping you, and it'll still run on new machines. And then you have to do zero work to keep your system up-to-date, but you'll likely have tons of security and stability bugs. On the other extreme, you could run Fedora rawhide (or Debian unstable, or current Arch, or whatever) and update nightly, which would mean you get security fixes as fast as possible (they're almost always developed on HEAD and backported to release branches), and you get performance and stability fixes that people haven't deemed worth backporting, but you also risk API-incompatible changes that break the actual applications you care about. You'll need to set up really good CI to make sure you have coverage of everything in your application, and it's not just a matter of automation: you'll need a well-staffed team to respond quickly every time that CI goes red, figure out what changed, and update your applications to match. (And, of course, you have the risk of security issues in new code that hasn't been subject to public scrutiny yet—the inverse problem of security issues in old code that's no longer subject to public scrutiny.)

The goal of a long-term stable distro is to be in the middle of those two, to give you something that changes rarely (stability in the sense of "no surprises," not "doesn't crash in prod") but often enough that you get major, identified security fixes and particularly safe performance (and stability-as-in-"no longer crashes in prod") fixes.

And yes, part of the goal of a long-term stable distro is that it provides you measurable security and stability over unmeasurable but potentially greater security and stability. They don't fix every CVE, but they do fix the flashy ones. You can look at it cynically and say, this is the distro for people who want to tell their boss "Yes, we patched Heartbleed and Shellshock" but don't inherently care about security. But on the other hand, flashy vulnerabilities are more likely to be exploited, so it's not a particularly bad tradeoff.

Re: Red Hat Enterprise Linux 8 released

#67

Post by devops4free »

pnutjam wrote: post #38
digitalsushi wrote: post #33

anyone have any insights on how oracle does their intake of this to create OEL? it's always been a bit of a mystery to me.

Download CentOS grep -rli 'centos' * | xargs -i @sed -i 's/centos]/Oracle\ Unbreakable\ Linux/gi' @ done

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

Re: Red Hat Enterprise Linux 8 released

#68

Post by VintageCool »

lima wrote: post #65
avar wrote: post #22

Earlier quoted context omitted.

> Pretty colors when running dmesg! Neat, but a great isolated example of the ancient software people who use RHEL have to deal with. RHEL 7 has dmesg from util-linux 2.23, the "colors by default" feature[1] first came out with 2.24 released on October 21st, 2013, which is around the time[3] the first beta of RHEL 7 came out. 1. https://github.com/karelzak/util-linux/commit/9bc2b51a06dc9c... 2. https://github.com/kar…

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 ke…

Colorful dmesg output was already available on Cent7, just not the default.

Re: Red Hat Enterprise Linux 8 released

#69

Post by lima »

geofft wrote: post #66
CoolGuySteve wrote: post #61

Earlier quoted context omitted.

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 De…

It doesn't generate more secure code—as you say, patches themselves may have bugs, and way fewer people are looking at the patched branches. Active development happens on HEAD, and dodgy code is often rewritten before anyone goes actually looking for bugs (security or otherwise). Many years ago I helped with a paper on how the practice of applying only "important" security bug fixes doesn't work: https://arxiv.org/ab…

As you say, it goes both ways. Many kernel vulnerabilities are found and fixed within weeks to months of introducing them, with LTS distros totally unaffected.

And then you have bugs being fixed on master (sometimes silently), and the backport maintainers fail to backport them.

Re: Red Hat Enterprise Linux 8 released

#70

Post by lima »

vamega wrote: post #63
baijum wrote: post #12

Earlier quoted context omitted.

Probably Red Hat Universal Base Image would be good enough for development instead of waiting for CentOS; https://www.redhat.com/en/blog/introducing-red-hat-universal...

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 article is clear on it being allowed.
Post reply on HN