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!

Tags:

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.

Tags:

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:

registry.redhat.io/openjdk/openjdk-8-rhel8
registry.redhat.io/openjdk/openjdk-11-rhel8

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?

Tags:

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.

Tags:

For better or worse I'm a heavy email user, not least because so much of the traditional workflows in Debian are email based. I use a variety of email clients but my swiss-army knife is mutt, and has been since at least 2005, which is the earliest-dated comment in my mutt configuration files.

I've always used the mutt package as provided by Debian, which means in practice I have been actually been using neomutt since around 2016, when the Debian maintainers imported that patch-set into the mutt package. neomutt is an independent effort to coordinate development of mutt (or on top of mutt) as the upstream maintainer(s) were (for a time) largely dormant. It's meant to be a friendly project, in some cases incubating patches that people are still trying to submit to the upstream project.

Fast forward to 2017 and an upstream mutt maintainer complained that Debian is providing something called "mutt" that is actually "neomutt" and started making pseudo-legal threats. This could have been resolved in a number of ways (my proposal and plea are recorded in that bug), but the decision of the package maintainers was to switch the mutt package back to the mutt source and provide neomutt as a separate Debian package.

We now have a situation where

  • If you were using mutt in Debian from 2016 onwards, you were most likely using neomutt, and your configuration files are most likely tailored to neomutt. If/When you upgrade to the next stable Debian release, you will be moved to real-mutt and your configuration may break.

  • if you filed a bug against the mutt package, depending when you did and what version of Debian you were using, your bug might be assigned to the mutt source package, which is now real-mutt, but might actually relevant only to neomutt. Looking merely at the list of bugs against "mutt" is not enough to be sure it's a bug in mutt, or neomutt, or both.

  • real-mutt and neomutt have not yet co-existed in a Debian release, so you cannot evaluate both side-by-side without introducing packages from testing or unstable, which might mean a libc upgrade.

  • Lots of stuff, especially Debian devscripts, hard-code /usr/bin/mutt as a mailer. The neomutt package does not provide this binary, and it is not mediated by the alternatives system, so if you only install neomutt, you might have integration niggles to solve yourself.

For a short while, I attempted to adjust my configuration files so that they would work in both real-mutt and neomutt, but this proved too messy so I've given up. I did have them co-installed on my main mail-reading host, but I also found myself occasionally confused as to which I was actually running at a given moment, so I've decided to stick to neomutt everywhere going forward: which means neomutt on my main mail host, and the mutt package on my Debian-stable hosts, and I must remember to switch the packages over when I update them to Buster (the next stable release) in a month or two.

The other upshot of this is I've decided to declare "year zero" on my mutt configuration files, rather than try to adapt the mess of mixed mutt and neomutt configuration bits spread across a dozen files that have grown since (at least) 2005, I'm going to start from scratch and only import over something if I feel its absence in daily use.

Tags:

Older posts are available on the all posts page.


Comments