Hacker News new | ask | show | jobs
by rwmj 2595 days ago
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 one time -- it's not parallel install (for that there is still Software Collections). The reason for not having parallel install is basically because people use containers or VMs so they don't really need it, and parallel install brings a lot of complexity.

For Python we tried to remove all the Python dependencies from the base image, didn't quite do it because of dnf (although that is in the works with at least the base dnf 3 being rewritten in C++). So we need a reliable System Python which isn't in a module (else dnf would break if you install modular Python 2.7). Basically don't use System Python unless you're writing base system utilities, instead "yum install python3" should pull in the right module.

Kernel: As usual the version number isn't that interesting, as a lot of work will be done through backports.

ntpd: Can't say I'm very happy about this myself :-(

Network scripts: It's NetworkManager all the way. Again, mixed feelings about this, but I can't say I loved network scripts either.

3 comments

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

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

I guess it's just what I'm used to. I'm also running my own NTP stratum 1 server from a GPS source using ntpd, but that's on Raspbian (https://rwmj.wordpress.com/2015/07/04/stratum-1-ntp-server-p...)
> For Python we tried to remove all the Python dependencies from the base image

Do you know why? I think it would be cool to not have any interpreted languages in the base image and FreeBSD manages to do that but I don't consider it that critical. For me it would be more interesting to not have Perl at all than Python...

I guess the situation with Python 2.7 on RHEL 7 was/is that painful?

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.

what about ansible? how does it fit into the "only system installed python"?
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 FreeBSD and others).

https://docs.ansible.com/ansible/latest/modules/raw_module.h...

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