Thoughts on Konsole 19.04

I write way too many articles that focus on the negatives of my work and of open source projects. To change things up, I’m going to review Konsole’s newest release, 19.04.0.

The first thing I noticed when I opened Konsole 19.04 is that the weird bug with line heights is gone. I can use Liberation Mono again without having a ridiculous amount of space between each line! While I do enjoy using Fira Code in Kate, it doesn’t lend itself very much to being a general purpose terminal font, and that was the only one that gave a reasonable line height in 18.12.

The new profile editor is very nice, and gives a little more control over some tweaks and settings that were previously difficult to find (or even not there, such as margins). There also appear to be more settings about controlling mouse behaviour; I can’t recall if they may have been there before, but they are definitely more accessible and more discoverable now.

Konsole 19.04
Editing a Konsole profile, with an active Konsole tab in the background display VIM 8.

The tab bar takes up slightly less vertical room, leaving more for terminal output. Additionally, a Terminal.app-style close button is now present on all tabs by default.

Overall I am very happy with Konsole 19.04 and I look forward to many productive days hacking on code with it!

The state of FLOSS and the tech industry

I’ve read an article today, in ZDnet, mourning how desktop distributions seem to wax and wane. It really made me think about how to properly convey what I feel to be the root issues with desktop adoption of Linux (and the wider CS industry), and why I think most people are very, very wrong about it.

Most people, normal people, they do not care about shiny. They don’t care if their email client or word processor is written in C++, Rust, JavaScript, Python, Ruby, or FORTRAN. They just want something that is simple to use and allows them to accomplish their tasks. It feels like most programmers and designers have lost that concept. I’ve met people in this industry who thought that they could sell people their products based on metrics like memory usage and number of packets transferred. Very excited people tell me how they use MapReduce and AngularJS and MongoDB and MariaDB (sometimes all four at once), like they deserve an award for Most Use of All Available Frameworks And Patterns Released This Decade. There’s a great article I read recently that puts in no uncertain terms: You are not Google. Even Google isn’t Google. Following these “trends” may make your product seem “trendy” to other developers, but all you are doing is wasting your time while leaving your users under-satisfied. Focus more on your software and how it can help people, and less on how it can help your résumé.

Meanwhile, I’ve seen libre software developers put up on their homepages that they now offer Flatpak images and are very excited to tell you that. Nobody knows what that means outside of developer circles! Do you think your grandparents care that your word processor is available in Flatpak or Snap? Do they even know what that means? In addition to this, Flatpak and Snap are anti-solutions. They don’t solve any real problems; they only serve to create new ones. What if a user or distribution wants to use ALSA instead of PulseAudio? What if a user or distribution uses an alternative to systemd? What if a user wants to use sound from their existing session at all? What about CPU architectures that aren’t supported by all developers, like ARM, POWER, or RISC-V? Focus more on your software and how it can help people, and less on following the trendy new shiny.

My personal hope for this industry is that we gain stronger distributions with better focus, and that developers leave packaging to the distribution packagers. This would allow us to have a few different desktop distributions. Distributions could be working together on a common frameworks, like KDE, while having specific plans and goals in mind. Gentoo and Arch for the tinkerers; Gentoo with more focus on source building, Arch with more focus on a tightly integrated system. Adélie and Fedora for the general public; Adélie with more focus on stability and portability (X11, PPC/ARM), Fedora with more focus on incubating new systems. Obviously there would be distributions that would pop up with unique goals; their work could be integrated later in to a main distribution that is aligned with it.

I feel like this could really be a way forward towards more wide adoption of Linux, on the desktop and beyond. I hope we can work together towards it.

(As a small aside that I wanted to note: I hope “The Year of the Linux Desktop” never comes. I hope that we usher in an Era of the Linux Desktop.)

Speaking with authority

I’ve just spent the better part of three hours arguing on IRC about Let’s Encrypt clients. After speaking with two others, I realised that nobody who I spoke with before knew their facts were facts.

Different people all told me various incorrect information, such as:

  • No ACME client supports doing a manual DNS TXT record for verification bootstrapping until you have an httpd up. (acme.sh, dehydrated, and certbot all support this.)
  • LE needs IPv4 for the HTTP challenge. (It worked fine for me with an IPv6-only host. I’m not sure which it would prefer if it had the choice between v6 and v4, or if it’d use Happy Eyeballs and connect to whichever responded first.)
  • It isn’t possible to step through the process manually as a debugging aid; you have to rely on your ACME client’s debugging facilities. (https://gethttpsforfree.com/ helped a tonne.)
  • You have to be listening for the HTTP challenge on port 80. (The TLS-ALPN-01 challenge type exists which will only ever use port 443 for the challenge.)
  • Critique of how I isolated each service on a separate VM so that they would be more secure, saying it was “over-convoluted”.

All of these people spoke with an air of authority. They sounded like they genuinely knew what they were talking about, and were trying to inform me of the limitations of ACME clients / Let’s Encrypt. Nobody actually knew the answer, but they thought they were right because it fit their experience.

When I speak to people about technology, whether in real life, on IRC, or on a mailing list, I always try to make the limitations of my knowledge clear. Many is the time I have said “I’m not sure if you can do that”, or “I don’t know if X supports Y“. And sure, on occasion I will say “I have never done Y and last I knew X couldn’t do that”. Note, however, that all of these are presented as statements from my hive of knowledge, and not presented as plain facts. The art of communication seems to be lost on far too many in the technology field.

There is no shame in not knowing the answer to something. It is certainly more helpful to say “I’m not sure you can do that”, instead of “you can’t do that”. I almost gave up on Let’s Encrypt and wrote another article on how useless it is, because I was told by people who used Let’s Encrypt that it had all of these limitations that made it seem useless, arbitrary, and ridiculous to me. (Thanks to Rich Felker of musl, and Freeyorp, for setting the record straight.)

Maybe we need a new term for this. “Organic FUD”, since it comes from the community itself? At any rate, I hope that in the future, more people note the limitations of their knowledge up-front rather than sounding authoritative about a subject they know little about.

GitHub and IPv6, three years later

Three years ago, I wrote Going IPv6 native without IPv4, which noted all the services I couldn’t access over IPv6. After all this time, there is some good news, and bad news.

First, the good news: BitBucket, Savannah, and Launchpad all support IPv6 now!

Now, the bad news: GitHub still does not. This has actually prevented me from setting up a trial run of acme.sh on a server. The server I was going to test LE on is only connected to the public Internet via IPv6. Yes, I was actually trying to see if Let’s Encrypt has gotten any better, and I was prevented from doing it because GitHub does not support IPv6.

Authors of ACME clients, especially ones that are only available via GitHub: find a mirror that supports IPv6! At this point, now I’m going to have to set up acme.sh on my workstation, and then scp the certificates over to the server every 60 days. Thanks GitHub.