Wandering Thoughts archives

Some thoughts on Red Hat Enterprise 8 including Python 2 and what it means

Red Hat Enterprise 8 was released the other day, and now Red Hat has published an article on Python 2 (and 3) in RHEL 8 (via). The short version is that they aren't providing a package called 'python' but instead two packages called 'python3' and 'python2' (or two 'application streams' for Python 2 and 3, which come with additional packages). Although it's not entirely clear, Red Hat is apparently not going to have a /usr/bin/python symlink by default, leaving it up you to set one up through their alternatives system. Red Hat is recommending that you explicitly use 'python2' or 'python3' as the name of the script interpreter in '#!' lines, instead of relying on just the 'python' name.

(The presence of a 'python2' binary name is not new in RHEL 8; one was present at least as far back as RHEL 6. Also, this may or may not backtrack on things Red Hat said a year ago.)

In a way, the big news here is that RHEL 8 includes Python 2 at all as an official package, since RHEL 8 will be supported for probably somewhere around a decade (and they'd previously sort of suggested that they weren't going to). Unless Red Hat officially abandons doing any updates for Python 2 at some point, this means that they'll be supporting it (at least as far as fixing any security issues that are discovered) for much of that decade, and since their work here is open source, other people can take advantage of it. I suspect that Red Hat is not entirely happy with this, but I also suspect that they felt they had no choice for various reasons.

(I rather expect Python 2 to not be included in a future Red Hat Enterprise 9, which might be released somewhere around 2023 or 2024 based on past history. Unless Red Hat gets a lot of push back from customers, I suspect that RHEL 8 will be the only dual-Python RHEL release.)

I suspect that this makes it somewhat more likely than it already was that Ubuntu 20.04 LTS will include Python 2. At the moment, Python 2 is currently part of the bleeding edge Ubuntu rolling version and is still apparently part of the 'main' package repository. That could change before 20.04 LTS freezes and branches, but Ubuntu is running out of time to do that and, more importantly, they're running out of pre-LTS releases to do it in; there would normally only be 19.10, due out in October. Since RHEL 8 includes Python 2, including Python 2 in Ubuntu is safer in that Ubuntu can probably rely on copying Red Hat's fixes, if any are needed.

(Also, per this 2018 LWN article, Debian will be shipping Python 2 with their next distribution, which they're in the process of trying to release at the moment. I believe that Debian wants to strip out Python 2 after that, but I wouldn't necessarily expect fast movement on that, and Ubuntu probably won't be more aggressive than Debian here.)

None of this means that people using Python 2 are completely safe. For a start, Python based packages and systems have been moving away from supporting Python 2 for some time. For an example that's relevant to us, the last Django version that supports Python 2 is 1.11, which itself will only be supported until April 2020 (cf). Unless we want to count on Ubuntu 18.04's packaging of Django (and we don't), the presence of Python 2 in Ubuntu 20.04 will be not too relevant for our Django web application. These days, we also install some popular Python packages for GPU computation and so on, and they're very likely to be Python 3 only soon if they aren't already (I haven't checked the current state of things like Tensorflow). And even if Ubuntu 20.04 includes Python 2, Ubuntu 22.04 might not, and that's not all that far away.

I also suspect that even when Python 2 is available in some form, more future distributions will follow RHEL 8's model and try not to provide a /usr/bin/python that points to it, especially on completely new installs (which is our usual case). We can try to fight this, but I suspect that we're better off changing our Python (2) programs to use '#!/usr/bin/python2'. Our users may force our hands, though, if they object strongly enough to there not being a 'python'.

(Slowly making that change may give us a chance to inventory just how many Python programs we actually have rattling around this place. The answer is probably 'more than I thought we did', since we've been writing various random things in Python for quite a while now.)

Firefox versus Chrome (my 2019 view)

On Twitter, I said:

I continue to believe that Firefox is your best browser option, despite the addons screwup. Mozilla at least tries to be good (and usually is), while Chrome is straight up one tentacle of the giant, privacy invading, advertising company giant vampire squid of Google.

I'm sure there are plenty of good, passionate, well-intended people who work on Chrome, and they care a lot about privacy, user choice, and so on. But existing within the giant vampire squid of Google drastically constrains and distorts what outcomes they can possibly obtain.

Mozilla is absolutely not perfect; they have committed technical screwups, made decisions in the aftermath of that that I feel are wrong, and especially they've made trust-betraying policy decisions, which are the worst problem because they infect everything. But fundamentally, Mozilla is trying to be good and I do believe that it still has a general organizational culture that supports that.

Chrome and the people behind it absolutely can do good, especially when they take advantage of their position as a very popular browser to drive beneficial changes. That Chrome is strongly committed to Certificate Transparency is one big reason that it's moving forward, for example, and I have hopes that their recently announced future cookie changes will be a net positive. But Chrome is a mask that Google wears, and regardless of what Google says, it's not interested in either privacy or user choice that threatens its business models. Every so often, this shows through Chrome development in an obvious way, but I have to assume that for everything we see, there are hundreds of less visible decisions and influences that we don't. And then there's Google's corporate tactics (alternate).

Much as in my choice of phones and tablets, I know which side of this I come down on when the dust settles. And I'm sticking with that side, even if there are some drawbacks and some screwups every so often, and some things that make me unhappy.

(At one point I thought that the potential for greater scrutiny of Google's activities with Chrome might restrain Google sufficiently in practice. I can no longer believe this, partly because of what got me to walk away from Chrome. Unless the PR and legal environment gets much harsher for Google, I don't think this is going to be any real restraint; Google will just assume that it can get away with whatever it wants to do, and mostly it will be right.)