2018-04-08
The interesting question of whether Ubuntu 20.04 LTS will include Python 2
It's 2018, which means that 2020's end of Python 2 support is only two years away. Two years seems like a long time, but it's not really, especially if you're not a full time developer or Python person, which is our situation. One of the questions about what we have to do about our current set of Python programs boils down to the question of whether Ubuntu's very likely April 2020 Long Term Support release (Ubuntu 20.04) will include Python 2.
So far, Ubuntu has done LTS releases every two years in April; 10.04, 14.04, 16.04, and now the impending 18.04. If they follow this pattern, they will release the next LTS in April of 2020, after Python 2's end of life (which the Python people say is January 1st 2020), and if we follow our usual practices, we'll begin using Ubuntu 20.04 on some systems that summer and autumn. These systems will need to run our Python system management tools, which means that if Ubuntu 20.04 doesn't include Python 2, we need to have our tools running on Python 3 before then.
(Of course it might be a good idea to port our tools to Python 3 now, but there's a difference between being prepared and being forced. This is especially important when you have to prioritize various things you could be working on, which is generally our situation.)
Since Ubuntu 20.04 will be released after the Python 2 cutoff date, in theory it could drop Python 2 on the grounds that it's no longer supported by the upstream developers. However, in practice there are two issues. First, it seems very likely that Python 2 will be supported by other people if problems emerge, because there are other long term Linux distributions that are already committed to supporting systems with Python 2 past 2020 (for example, Red Hat Enterprise Linux 7, which will be supported through 2024, and then there's Ubuntu 18.04 itself, which will be supported through 2023). Second, it's not clear that all packages that currently use Python 2 will be updated to Python 3 in time for 2020 (see eg). Ubuntu could choose to throw Python 2 out anyway and to hell with any packages that this forces out, but that might not be very popular with people.
The current state of Ubuntu 18.04 is that Python 2.7 will be available in the 'main' package repository, directly supported by Ubuntu. One possible option for 20.04 is that Python 2.7 would be available but would be demoted to the community supported 'universe' package repository, which theoretically gives you lower expectations of bug and security fixes. This would give Ubuntu an option to shrug their shoulders if some serious issue comes up after 2020 and no one steps forward to fix it.
Probably the safest option for us is to begin moving our tools to Python 3, but likely not until 2019. If we started now, I'd have to make them compatible with Ubuntu 14.04's Python 3.4.3; if I wait until we've migrated all of our 14.04 machines to 18.04, I get to base everything on Ubuntu 16.04's somewhat more recent 3.5.2.
(Using 3.5 as the base could be potentially important, since the
3.5 changes brought
in formatting for bytes and better handling for character encoding
issues with sys.stdin and sys.stdout, both of which might be
handy for our sysadmin-focused uses of Python.)
Sidebar: Red Hat Enterprise Linux 8 and Python 2
Unlike Ubuntu, Red Hat hasn't officially announced any timing or formal plans for RHEL 8. However, a new version of RHEL is due (based on RH's traditional timing) and there are some signs that one is in preparation, probably for release this summer. I can't imagine such a version not including Python 2, which means that Red Hat would likely be committed to supporting it through 2028.
This isn't necessarily a big burden, because it's my opinion that we're unlikely to find any serious issues in Python 2.7 after 2020. This is especially so if people like Red Hat make a concerted effort to find any remaining 2.7 problems before the official end of support, for example by extensively running fuzzing tools against 2.7 or by paying for some security auditing of Python's SSL code (or doing it themselves).
A learning experience with iOS's fingerprint recognition
I have both an iPhone and an iPad, both of which have fingerprint based unlocking, which I use. I interact with the iPhone sufficiently often that I generally unlock it multiple times a day, but for various reasons I use the iPad much less frequently and can even go for a couple of days before I dig it out and poke at it.
It's been winter around here for the past while, and Toronto's winter is dry. These days that dryness is hard on my fingers, especially the fingers of my right hand (I'm right handed, which may contribute to this); my fingertips get chapped and cracked and generally a bit beaten up despite some effort to take care of them by slathering moisturizer on and so on.
(The problem with using moisturizer, especially on your fingertips, is that I generally want to do something with my hands and don't want to get moisturizer all over what I'll be typing on or holding or whatever.)
Over the course of this winter, I gradually noticed that my iPad was getting harder and harder to unlock. I'd have to wiggle my right thumb around to get it to like it, and sometimes it just wouldn't and I'd wind up typing my unlock password. If I remembered to try my left thumb, often that would work, and my iPhone had no problems at all; I'd tap it and pretty much it'd always unlock. For most of the winter, when this happened I'd wipe the sensor clean on the iPad and mutter to myself and just live with it. It had to be a little glitch on the iPad, right? But every so often I'd stare at my roughed-up and increasingly hard to make out right thumb fingerprint and wonder.
When I couldn't unlock the iPad recently, I gave in to frustration and tried something just to see if it would help: I enrolled my right thumb's fingerprint again (as a new fingerprint). The difference was night and day. Suddenly the iPad was unlocking just like my iPhone, like it was supposed to and as I remembered it doing in the beginning; tap the sensor and it unlocked instantly without fuss or problems.
My best guess is the obvious guess; not only does the iOS fingerprint system have some margin for error, but it updates its recognition model over time. Because I unlocked my iPhone often enough, its recognition model could follow along as my right thumb's fingerprint got more and more roughed up over the course of the winter. However I didn't unlock my iPad often enough for these updates to kick in (or they couldn't or didn't move the model fast enough), so as the model and my fingerprint drifted further and further apart it got harder and harder to get it to match up with my cracked-skin fingerprint. Re-enrolling my thumb again added a new recognition model that worked on the current, beaten up state.
(This time around I've actually named that fingerprint, so I can easily remove it later. I may try the experiment of removing it in the summer when my right thumb's fingerprint is all recovered and has good skin condition again. In theory the original enrollment should be good enough at that point.)
Next winter I'm going to try to use my iPad more often or at least unlock it more regularly. Probably I'll aim to unlock it a couple of times every day, even if I'm not going to do anything more than tell it to check for various sorts of updates.
(Or I could start reading books on it. I did recently get pulled into reading a great SF novella on it, which was a pretty good experience, and I certainly have more books I could read there.)