Below are the five most recent posts in my weblog. You can also see a chronological list of all posts, dating back to 1999.

Following the initial release of RHEL8-based OpenJDK OpenShift container images, we have now pushed PPC64LE and Aarch64 architecture variants to the Red Hat Container Registry. This is the first time I've pushed Aarch64 images in particular, and I'm excited to work on Aarch64-related issues, should any crop up!


For my PhD, I'm currently working on my "1st" year Progression Report. The last formal deliverable I produced was my Project Proposal a (calendar) year ago. I've just realised I hadn't shared that here, so here we go, in the hope that this is interesting and/or useful to someone: PhD Proposal - Jon Dowland.pdf

When I started working on that, I cast around to find examples of other people's. I've attempted to do much the same for my Progression Report. In both cases I have been unable to find a great deal of examples of other people's proposals or reports. The exact format of these things is likely specific to your particular institution, or even your academic unit within your institution, and so a document produced for another institution's expectations might not be directly applicable to another. (I didn't want to directly apply such a thing of course.) If you do find a sample, you don't have any idea whether it has been judged to be particularly good or bad one by those who received it (you can make your own judgements). This is true of my own Proposal too.

In a "normal", full-time PhD, you would likely produce a proposal within a few months of starting, and your first Progression Report towards the end of your first academic (not calendar) year: so, a mere 6 months or so later. Since I am doing things part-time, this is all stretched out: I submitted the proposal in March last year, and my Progression Report is due next month, in June. Looking back at the Proposal now (for the first time in a while, I must admit), it's remarkable to me how "far" the formulation of my goals from then is compared to now.

Once I've had my Progression report passed I hope to share it here, too.


I'm pleased to announce that something I've been working on for the last 6 or so months is now public: Red Hat Enterprise Linux 8-based OpenJDK containers, for use with OpenShift. There are two flavours, one with OpenJDK 1.8 (8) and another for OpenJDK 11. These join the existing two RHEL7-based images.

If you have a Red Hat OpenShift subscription, follow the instructions in this Errata to update your image streams. The new images are named:

Last week Red Hat announced the Universal Base Image initiative: RHEL-based container images, intended to be a suitable base for other images to build upon, and available without a Red Hat subscription under a new EULA.

Our new OpenShift OpenJDK RHEL8 containers are built upon the UBI, as are (I believe) any RHEL8-based containers, but are not currently available under the UBI EULA as we incorporate content from the regular RHEL8 repositories not present in the UBI. If a UBI-based OpenJDK image, distributed under the UBI terms, would be interesting to you, please get in touch! What could it look like? Small, or kitchen-sink? Would you want builder content in it, or pure run-time? What environment would you want to use it in: OpenShift, or something else?


The next release of Debian OS (codename "Buster") is due very soon. It's currently in deep freeze, with no new package updates permitted unless they fix Release Critical (RC) bugs. The RC bug count is at 123 at the time of writing: this is towards the low end of the scale, consistent with being at a late stage of the freeze.

As things currently stand, the default graphical desktop in Buster will be GNOME, using the Wayland desktop technology. This will be the first time that Debian has defaulted to Wayland, rather than Xorg.

For major technology switches like this, Debian has traditionally taken a very conservative approach to adoption, with a lot of reasoned debate by lots of developers. The switch to systemd by default is an example of this (and here's one good example of LWN coverage of the process we went through for that decision).

Switching to Wayland, however, has not gone through a process like this. In fact it's happened as a result of two entirely separate decisions:

  1. The decision that the default desktop environment for Debian should be GNOME (here's some notes on this decision being re-evaluated for Jessie, demonstrating how rigorous this was)

  2. The GNOME team's decision that the default GNOME session should be Wayland, not Xorg, consistent with upstream GNOME.

In isolation, decision #2 can be justified in a number of ways: within the limited scope of the GNOME desktop environment, Wayland works well; the GNOME stack has been thoroughly tested, it's the default now upstream.

But in a wider context than just the GNOME community, there are still problems to be worked out. This all came to my attention because for a while the popular Synaptic package manager was to be ejected from Debian for not working under Wayland. That bug has now been worked around to prevent removal (although it's still not functional in a Wayland environment). Tilda was also at risk of removal under the same rationale, and there may be more such packages that I am not aware of.

In the last couple of weeks I switched my desktop over to Wayland in order to get a better idea of how well it worked. It's been a mostly pleasant experience: things are generally very good, and I'm quite excited about some of innovative things that are available in the Wayland ecosystem, such as the Sway compositor/window manager and interesting experiments like a re-implementation of Plan 9's rio called wio. However, in this short time I have hit a few fairly serious bugs, including #928030 (desktop and session manager lock up immediately if the root disk fills and #928002 (Drag and Drop from Firefox to the file manager locks up all X-based desktop applications) that have led me to believe that things are not well integrated enough — yet — to be the default desktop technology in Debian. I believe that a key feature of Debian is that we incorporate tools and technologies from a very wide set of communities, and you can expect to mix and match GNOME apps with KDE ones or esoteric X-based applications, old or new, or terminal-based apps, etc., to get things done. That's at least how I work, and one of the major attractions of Debian as a desktop distribution. I argue this case in #927667.

I think we should default to GNOME/Xorg for Buster, and push to default to Wayland for the next release. If we are clear that this a release goal, hopefully we can get wider project engagement and testing and ensure that the whole Debian ecosystem is more tightly integrated and a solid experience.

If you are running a Buster-based desktop now, please consider trying GNOME/Wayland and seeing whether the things you care about work well in that environment. If you find any problems, please file bugs, so we can improve the experience, no matter the outcome for Buster.


Older posts are available on the all posts page.