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

131–140 of 150 posts

Re: Red Hat Enterprise Linux 8 released

#131

Post by X-Istence »

justinclift wrote: post #127
X-Istence wrote: post #91

Earlier quoted context omitted.

The enterprises I've worked where we've used RHEL... epel is not allowed near a system, only officially sanctioned repos and updates.

Isn't EPEL the "officially sanctioned" third party repo?

No, it's maintained by a special interest group within Fedora:

Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).

EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.

Re: Red Hat Enterprise Linux 8 released

#132

Post by X-Istence »

paulcarroty wrote: post #121
pas wrote: post #113

Earlier quoted context omitted.

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.

Can't remember any real problems with docker on RHEL/Fedora.

I mentioned my sys call filtering issue with eBPF taking up massive amounts of CPU time...

Re: Red Hat Enterprise Linux 8 released

#133

Post by shoo »

slrz wrote: post #130
rwmj wrote: post #123

Earlier quoted context omitted.

Ansible the client, or the target? Ansible doesn't need anything installed on the target (except sshd). For the client which presumably would be installed explicitly on far fewer machines it would bring in whatever Python it needs. I don't know if it uses System Python or a module however since I don't have it installed on RHEL 8 right now.

Ansible does require that some flavour of Python is available on the target hosts. Without a Python interpreter, you're basically restricted to using the raw module (which, of course, you may use to bootstrap Python by invoking the package manager). Still, I guess most people don't bother with that and just assume the presence of Python (at least on Linux, the bootstrap-using-raw approach is already required on FreeB…

> Ansible does require that some flavour of Python is available on the target hosts.

Support for managing windows hosts with ansible is implemented by replacing the use of SSH & python with winrm & PowerShell respectively.

Re: Red Hat Enterprise Linux 8 released

#134

Post by justinclift »

X-Istence wrote: post #131
justinclift wrote: post #127

Earlier quoted context omitted.

Isn't EPEL the "officially sanctioned" third party repo?

No, it's maintained by a special interest group within Fedora: Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterpar…

Ahhh. More "blessed" than "officially sanctioned" then. :)

Re: Red Hat Enterprise Linux 8 released

#135

Post by rashkov »

Tor3 wrote: post #126
Bjartr wrote: post #40

Earlier quoted context omitted.

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

My terminal isn't configured to use any colors. It's just xterm. The only colors configured are background and foreground, and those colors various tools insist on as default are always clashing with them (and with my vision too). There are no color environment variables enabled, or anything else indicating that colors should be used, but even so colors are coming out of various command line tools lately.

I think that if you configure the rest of the colors, then the commands will use those. I’ve set my urxvt term to use the solarized theme and I don’t have any problems with viewing colorized output. I’d have to test it, but I’m reasonably sure of this.

Re: Red Hat Enterprise Linux 8 released

#137

Post by Bjartr »

Tor3 wrote: post #126
Bjartr wrote: post #40

Earlier quoted context omitted.

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

My terminal isn't configured to use any colors. It's just xterm. The only colors configured are background and foreground, and those colors various tools insist on as default are always clashing with them (and with my vision too). There are no color environment variables enabled, or anything else indicating that colors should be used, but even so colors are coming out of various command line tools lately.

If you run the script described in this post[1] you can display the colors that your terminal is configured to use. Just because you've overridden foreground and background doesn't mean you've altered the other colors xterm uses by default.

[1] https://bbs.archlinux.org/viewtopic.php?id=51818&p=1

Re: Red Hat Enterprise Linux 8 released

#138

Post by snuxoll »

rwmj wrote: post #112
CameronNemo wrote: post #93

Earlier quoted context omitted.

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

Red Hat also certifies a whitelist of symbols that will remain identical in all future releases for the life cycle, stuff like that takes time so just grabbing the newest LTS kernel the moment they cut a release isn’t feasible.

Re: Red Hat Enterprise Linux 8 released

#139

Post by int_19h »

Crontab wrote: post #108
rwmj wrote: post #106

Earlier quoted context omitted.

There's been a huge effort to get the base RHEL image size right down, so obviously getting rid of Python would help there. As for why we need to reduce the size of the base image, the answer is - as always - because containers.

I agree with this. My personal opinion is that advanced scripting languages, outside of shells, shouldn't be installed by default. (Of course, this usually gets killed pretty quickly, as dependency hell quickly brings in advanced scripting languages.)

I'm curious where the line for "advanced" lies, although in principle I'd agree that Python is certainly past it.

But shouldn't interpreters be good for reducing the overall runtime code size in principle, if enough system tools run on them? High-level bytecode can be very compact.

Or better yet, compile natively, but to threaded code, and share the stdlib behind it.

Re: Red Hat Enterprise Linux 8 released

#140

Post by int_19h »

burk96 wrote: post #92
aetimmes wrote: post #15

Earlier quoted context omitted.

Probably a little bit of both. You can game on RHEL but it wouldn't be my first choice of distro for it - IMO, Ubuntu and Fedora are both better-suited for that task.

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?

Post reply on HN