Hacker News Reader

Comment by pksadiq | Hacker News Reader

Release notes here: https://access.redhat.com/documentation/en-us/red_hat_enterp...

For those that matters, MongoDB is not included because it uses Server Side Public License: https://access.redhat.com/documentation/en-us/red_hat_enterp...

View on HN

Interesting takeaways for me: They still use yum (instead of dnf) for managing packages, and default to nftables as the firewalld backend, while even Fedora (afaik) is still using iptables.

yum is now based on dnf

https://access.redhat.com/documentation/en-us/red_hat_enterp...

Yeah, but why not switch to dnf entirely since this is a major release? Fedora dropped yum some time ago.

I would imagine because it will break lot of scripts that use yum tooling. Just changing binary name could be painful.

Even on Fedora yum is still available

No, not really. You can install yum, but by default, any yum commands are translated to their dnf counterpart.

(Many don't need translation other than `alias yum dnf` sort of thing)

On my fedora 29 box:

[root@laptop ~]# which yum

/usr/bin/yum

[root@laptop ~]# ls -l /usr/bin/yum

lrwxrwxrwx. 1 root root 5 Oct 15 12:47 /usr/bin/yum -> dnf-3

Pretty sure "yum" in rhel8 will actually be dnf as well, but keeping the name for backwards compatability

You can type either ‘yum’ or ‘dnf’, but they decided to keep ‘yum’ to avoid a lot of scripts/documentation from breaking. ‘yum’ is a compatibility layer over dnf that keeps the old command line syntax but uses the fast depsolver, weak dependencies and other new features from dnf.

It is dnf, they just didn't want to change the name, so they call it yum.

Enterprises are babies when it comes to change and would have been mad if they needed to update their scripts.

Also, KDE is removed and GNOME + Wayland is default.

> Also, KDE is removed and GNOME + Wayland is default.

Yeah, and the important part is that migrating from RHEL 7 with KDE to RHEL 8 is not supported: https://access.redhat.com/documentation/en-us/red_hat_enterp...

Upgrading from RHEL 6 with GNOME to RHEL 7 was not and still is not supported either ;-)

Too bad it doesn't come with Python 3.7, only 3.6. Fedora 29 managed to switch to 3.7, although it was released just two weeks ago.

Later versions of Python will be supplied as modules. So will Python 2. They are parallel installable with "system-python" which remains at 3.6 for the lifetime of RHEL 8. (Note that in general modules are not parallel installable, but in this one case it is).

As a module will it have as many libraries available as the system Python? For example does it come with scipy packages, twisted, pyserial, xlrd/xlwt/openpyxl, gobject (for GTK+ apps), etc?

AIUI the plan is to build everything for each Python module (plus system-python).

However there are two things that mean it's not quite as good as you would like:

(1) Base RHEL 8 will only have a fairly minimal set of Python packages (indeed, packages in general).

(2) Products on top - things like OpenStack - will settle on a particular Python version (ie. module) and only be built against that version, and will require the corresponding Python module to be enabled.

I'm more surprised by the fact that no Python is installed by default on a Red Hat distribution

https://access.redhat.com/documentation/en-us/red_hat_enterp...

I think Perl and Python were only ever installed by default because there were management utilities (GUI and console) written in them, so they were prerequisites for what was considered a minimal system. RHEL has been pretty good the last few years at paring down the base minimal install to actual essentials. I view getting to the point that Python is not required for a base install an achievement.

Me as well, since someone had the clever idea to create GUI distribution management tools in Python, it is a pain to use them, given how slow some of them are.

It's unlikely Python is to blame for that, unless they implemented something very CPU bound in it. I wrote wxPython apps in 2000 or so and they were very responsive.

Well the previous generations written in C used to perform quite well.

It is likely a combo of Python + someone not good at using Python with networking. When working with anything that talks a lot over networks you need to use threads or separate processes to keep things feeling responsive during network delays. Python doesn't make this easy, so lots of devs skip it and it makes the programs feel sluggish.

Hmm, that might make sense on a server, but this is talking about a GUI client. Also, Python has trouble with CPU-bound threads but not those IO-bound.

A huge amount of work was done to minimize the base set of packages (called "BaseOS"). Including rewriting parts of dnf from Python to C++.

Wasn't python required for YUM to function correctly? Or has DNF been written in something other than python?

yes. https://rpm-software-management.github.io/page4/ (some of the specific posts seem to be unavilable)

Platform python see comment above

Actually there is a default python and it’s called platform python. That one lives on purpose in /usr/libexec however is mainly supposed to be used by platform tooling like dnf/yum etc

Reply on news.ycombinator.com