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

111–120 of 150 posts

Re: Red Hat Enterprise Linux 8 released

#111

Post by pfranz »

owl57 wrote: post #47
auscompgeek wrote: post #26

Earlier quoted context omitted.

The difference with system shell scripts is that you can't accidentally clobber libraries that the system tools require to work - shell scripts don't really have any notion of installable libraries.

It's not like you can't clobber PATH with ease and in diverse ways… It's just less easy to unclobber: huge hacks like Nix are born in this quest.

> huge hacks like Nix are born in this quest.

Would you mind elaborating on this? Maybe I'm using Linux wrong, but Nix seems like a huge step forward fixing a lot of my frustrations. Admittedly, I haven't used it in production.

One huge benefit of language-specific package managers is having multiple versions of packages on the same system and you can choose which you'd like for the project (without changing the OS). I feel like 10 years ago I heard a lot of grumbling about languages like Ruby or Python should just use apt/rpm, but I haven't see any OS package manager put much effort into this use-case (this is ignoring mac/win support). The closest I've seen is something like Red Hat's Software Collections.

Personally, I feel strongly that any software that's critical to your company should be decoupled from the OS. This is borne through painful and much delayed OS updates and following it makes things much easier long term.

My personal use-case is that different projects (working on multiple in tandem) need different stacks of versions. Also giving the ability to swap versions on the fly. Here's one package manager specifically designed for it https://github.com/nerdvegas/rez

Swapping versions in Linux is pretty heavy out of the box (with rpm/apt); download, remove old versions files, write new versions files. Only one installed at a time. a/b comparing libraries is a pain. For the things I need, I build things into folders like libjpeg-turbo/2.0.2 and nasm/2.14.02 and set the ./configure flags to point to these...basically a more ad hoc approach to what Nix does.

Where am I going wrong?

Re: Red Hat Enterprise Linux 8 released

#112

Post by rwmj »

CameronNemo wrote: post #93
X-Istence wrote: post #90

Earlier quoted context omitted.

Some of the backports aren't nearly as fast or performant as using a newer kernel though. For example eBPF was back ported (and also in CentOS), but running a syscall heavy work-load in a docker container on the older kernel about 50% of the CPU time was spent in the kernel filter. I ended up moving our entire CI/CD platform to Ubuntu 18.04 and the performance issues went away and my workloads now run at full speed w…

Seriously why did they not up it to 4.19? Do they hate bicycles? Do they make money based on the fact that upstream LTS kernels have short shelf lives compared to RHEL's own LTS kernels?

The kernel version was finalized some time before this release when 4.18 was current. Red Hat expends a ton of effort on long term maintenance and huge backports of new features to the kernel, so while I don't want to speak for the kernel team, I don't think the upstream stable kernels bring very much to the table.

Plus (my personal view) what goes into the upstream stable kernel is fairly random based on just mailing list NACKs, whereas what goes into the RH kernel has to pass a massive range of automated tests on a wide variety of real hardware.

Re: Red Hat Enterprise Linux 8 released

#113

Post by pas »

paulcarroty wrote: post #100
X-Istence wrote: post #90

Earlier quoted context omitted.

Some of the backports aren't nearly as fast or performant as using a newer kernel though. For example eBPF was back ported (and also in CentOS), but running a syscall heavy work-load in a docker container on the older kernel about 50% of the CPU time was spent in the kernel filter. I ended up moving our entire CI/CD platform to Ubuntu 18.04 and the performance issues went away and my workloads now run at full speed w…

> That's a shame and once again it will fall behind quickly RH use kernel with TONS of patches, so, version isn't critical here.

Their frankenkernel is very hit and miss, backports or not. Docker had to disable a few features, because at first they seemed to work, but then they were buggy on RHEL.

Re: Red Hat Enterprise Linux 8 released

#114

Post by Spivak »

pas wrote: post #113
paulcarroty wrote: post #100

Earlier quoted context omitted.

> That's a shame and once again it will fall behind quickly RH use kernel with TONS of patches, so, version isn't critical here.

Their frankenkernel is very hit and miss, backports or not. Docker had to disable a few features, because at first they seemed to work, but then they were buggy on RHEL.

But why wouldn't you use Red Hat's build of Docker? I mean if you're already paying them...

Re: Red Hat Enterprise Linux 8 released

#115

Post by merb »

rwmj wrote: post #101
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…

So I hope I can answer some of these [disclaimer: I work for Red Hat]: Python: This is about the module system. Modules let you install different versions of parts of the stack. For example, different Python, different Apache version, different QEMU. These will move much faster than base RHEL because they're now decoupled. You can install one version of each module from a choice of several versions available at any o…

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

Re: Red Hat Enterprise Linux 8 released

#116

Post by beagle3 »

rwmj wrote: post #101
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…

So I hope I can answer some of these [disclaimer: I work for Red Hat]: Python: This is about the module system. Modules let you install different versions of parts of the stack. For example, different Python, different Apache version, different QEMU. These will move much faster than base RHEL because they're now decoupled. You can install one version of each module from a choice of several versions available at any o…

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

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

Re: Red Hat Enterprise Linux 8 released

#117

Post by beagle3 »

eikenberry wrote: post #105
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…

Anyone have any thoughts on why chrony vs openntpd? Back when the ntpd security became a thing I evaluated chrony and openntpd as replacements and went with openntpd. It seemed to be simpler, used fewer system resources and had the openbsd teams reputation behind it.

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.

Re: Red Hat Enterprise Linux 8 released

#118

Post by xorcist »

Qerub wrote: post #64
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.

Like Docker, but less insanity. Looks promising.

Re: Red Hat Enterprise Linux 8 released

#119

Post by eikenberry »

jlgaddis wrote: post #109
eikenberry wrote: post #105

Earlier quoted context omitted.

Anyone have any thoughts on why chrony vs openntpd? Back when the ntpd security became a thing I evaluated chrony and openntpd as replacements and went with openntpd. It seemed to be simpler, used fewer system resources and had the openbsd teams reputation behind it.

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" machin…

Thanks for the detailed response.

Re: Red Hat Enterprise Linux 8 released

#120

Post by evil-olive »

beagle3 wrote: post #117
eikenberry wrote: post #105

Earlier quoted context omitted.

Anyone have any thoughts on why chrony vs openntpd? Back when the ntpd security became a thing I evaluated chrony and openntpd as replacements and went with openntpd. It seemed to be simpler, used fewer system resources and had the openbsd teams reputation behind it.

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.

openntpd can set the clock on startup, but it requires a non-default `-s` option [0]. In chrony it's optional and controlled by an `initstepslew` parameter [1] which also considers a threshold to determine if the clock needs a large adjustment or if it's fine to just skew it as normal.

0: https://man.openbsd.org/ntpd

1: https://chrony.tuxfamily.org/doc/3.4/chrony.conf.html

Post reply on HN