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

141–150 of 150 posts

Re: Red Hat Enterprise Linux 8 released

#141

Post by h1d »

mroche wrote: post #129
adontz wrote: post #107

Earlier quoted context omitted.

And what is CentOS 8 ETA? I found nothing at CentOS web site :-( Do I miss anything?

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.

There is a telling. (Except for CentOS 6. Wonder why it delayed so much.)

https://en.wikipedia.org/wiki/CentOS#Older_version_informati...

(Expand the table for older releases.)

Re: Red Hat Enterprise Linux 8 released

#142

Post by Conan_Kudo »

CiPHPerCoder wrote: post #44
w-m wrote: post #3

Here are the actual release notes (which don't seem to be linked anywhere from this marketing page): https://access.redhat.com/documentation/en-us/red_hat_enterp...

Good news: They ship PHP 7.2 Bad news: ...without ext/sodium That's a frankly irresponsible decision for Red Hat to make.

> 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%...

Re: Red Hat Enterprise Linux 8 released

#143

Post by Conan_Kudo »

wbl wrote: post #59
CiPHPerCoder wrote: post #44

Earlier quoted context omitted.

Good news: They ship PHP 7.2 Bad news: ...without ext/sodium That's a frankly irresponsible decision for Red Hat to make.

Red Hat has a long history of harming cryptography.

That's not fair. If you want to blame something for that, blame software patents. Some stuff used to be a huge minefield because of that.

Re: Red Hat Enterprise Linux 8 released

#144

Post by linuxftw »

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…

Stable doesn't necessarily mean 'doesn't crash' what it means is that the API/ABI interface is stable.

EG: let's say libfoo.so.1 implements DO_FOO; libfoo.so.2 implements DO_FOO2, but not DO_FOO. In this case, anything you need that links to libfoo.so.1 and needs DO_FOO would need to be patched, recompiled, and shipped out to all your customers. For the distribution provider, this is not really a huge deal. But RHEL is merely the platform. The value-add is that 3rd parties can write software and compile against libs and know they're not going to break arbitrarily.

Similarly, if you've ever written a kernel driver, you'd know that kernel function names and signatures can change from release to release. The same example above applies to kernel code as well. So, compiled binary drivers would have to be patched and recompiled, and shipped out. If you're writing a driver for a network card, would you prefer having to ship your (non bug) driver updates every few months, or every few years?

Re: Red Hat Enterprise Linux 8 released

#145

Post by burk96 »

int_19h wrote: post #140
burk96 wrote: post #92

Earlier quoted context omitted.

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.

Mint has been doing that for a while. And I believe Ubuntu has finally started doing it as well in the most recent release?

I wouldn't be surprised if Mint and Ubuntu are both in a better state in that regard since I last used them. Last time I used Mint on my gaming rig, the bundled Mint drivers had something funky with them. I don't remember what it was but I do remember I had to reinstall them. This was around Ubuntu's 15.04 I believe?

Re: Red Hat Enterprise Linux 8 released

#146

Post by Conan_Kudo »

lima wrote: post #34
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...

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?

If they are in the ubi namespace, they are freely available. The Container Catalog also will tell you if you can pull without a login when you look at the details of a container.

Re: Red Hat Enterprise Linux 8 released

#147

Post by CiPHPerCoder »

Conan_Kudo wrote: post #142
CiPHPerCoder wrote: post #44

Earlier quoted context omitted.

Good news: They ship PHP 7.2 Bad news: ...without ext/sodium That's a frankly irresponsible decision for Red Hat to make.

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

> If you're a Red Hat customer, you could file a support ticket to get it pulled back in.

I have never spent $1 of my own money on Red Hat. After seeing this, I never will.

Re: Red Hat Enterprise Linux 8 released

#148

Post by Conan_Kudo »

CiPHPerCoder wrote: post #147
Conan_Kudo wrote: post #142

Earlier quoted context omitted.

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

> If you're a Red Hat customer, you could file a support ticket to get it pulled back in. I have never spent $1 of my own money on Red Hat. After seeing this, I never will.

You could also file a bug report in Red Hat Bugzilla even as a non-customer. But clearly you think that Red Hat is being malicious about this, which is definitely not the case.

Re: Red Hat Enterprise Linux 8 released

#149

Post by rincebrain »

CameronNemo wrote: post #94
secabeen wrote: post #88

Earlier quoted context omitted.

> 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? Debian has released a new stable version every 2 years for the last 14 years. RHEL/CentOS are the only ones on a 3-5 year cycle.

And yet they wait months between freezing the distribution and releasing, because a few troublesome packages have issues. Someone needs to thaw Debian out.

No?

The fact that there's a freeze to allow for shaking out troublesome issues in a few packages (and possibly discover ones you didn't already find in older ones) without much risk of others newly breaking is a feature, not a bug.

Debian testing/unstable, backports and third-party repos exist if people really want the latest anyone's packaged, or the latest version of one specific thing on their otherwise stable system.

You may disagree with the philosophy, but every part of that behavior is working as intended.

Re: Red Hat Enterprise Linux 8 released

#150

Post by Conan_Kudo »

CiPHPerCoder wrote: post #147
Conan_Kudo wrote: post #142

Earlier quoted context omitted.

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

> If you're a Red Hat customer, you could file a support ticket to get it pulled back in. I have never spent $1 of my own money on Red Hat. After seeing this, I never will.

Just so you know, there's a bug report requesting this extension to be enabled and shipped: https://bugzilla.redhat.com/show_bug.cgi?id=1714591
Post reply on HN