The Cat Fox Life

Keeping libre software accessible to all

Recently, a number of high-profile libre software projects have been either considering, or adopting, proprietary chat systems to be their primary method of communication with their communities. This should cause alarm to everyone who is interested in the libre software movement.

Projects using Discord as an official method of communication include distributions like Fedora, Gentoo, and openSuSE; infrastructure projects like Gitea and Yarn; and libre programming languages including Elixir and Rust.

I was mercifully unable to find many examples of independent libre projects using Slack, other than Elixir (which seems to prefer Discord these days, but still has a Slack community). Most of the projects I found using Slack were run by companies that use Slack internally, and provide contributors access to it.

There are many reasons that libre software should not rely on proprietary communication tools. Of course, there are ideological reasons – we should not, as libre software maintainers, force our users or contributors to use a proprietary system. However, that may not be convincing enough for some projects, especially those that focus more on being “open source” than standing for the rights of their users. Some of the non-ideological reasons include:

No transparency: Most proprietary chat systems contain very long contracts that you must agree to when you sign up for the service. These contracts take away your freedom and allow the companies behind these systems to use your data, including your chat logs, for whatever purposes they want. Quoting the Discord terms of service (as of 27 April 2019):

All of Your Content is your sole responsibility and the Company is not responsible for any material that you upload, post, or otherwise make available. By uploading, distributing, transmitting or otherwise using Your Content with the Service, you grant to us a perpetual, nonexclusive, transferable, royalty-free, sublicensable, and worldwide license to use, host, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform, and display Your Content in connection with operating and providing the Service.
No client choice: If you cannot use the official Discord client, which is a proprietary binary blob using CEF (Google Chrome) that only runs on Intel x86 computers, you must use the Web browser client. The Web browser client is also proprietary, does not contain all features, and has accessibility issues. Creating your own Discord client is against their contract and will result in a permanent ban. Additionally, the official Discord client does not allow user style changes (it is against the terms of service to modify it in any way). This means that people who need assistive technologies to use a computer cannot participate in a Discord community.
Lack of infrastructure control: By using a proprietary chat system, you have no control over the infrastructure. If the service is discontinued, which has happened to many providers over the years, there is no recourse for the community.

Alternatives

Most libre communities turn to Discord or Slack because they are unsatisfied with IRC. There are libre solutions that go far beyond IRC. Some include:

Mattermost: written in Golang and React, has many of the same features as Slack, including a mobile app and integration with many services. Includes IRC and XMPP bridging for those who wish to use it.
Matrix: touted by some as a modern replacement for IRC. Can federate with other communities including an IRC bridge, has a mobile app, somewhat rough around the edges.
Rocket.Chat: aimed more at businesses (including LDAP and SSO support), can also be great for larger libre software communities, includes mobile app.
Zulip: emphasises threaded conversations, putting it somewhere between email and traditional real-time chat. I have heard great things about Zulip, but as I haven’t used it yet, I do not have any opinion on it.

For libre projects, the time is right and the time is now: migrate to a libre communications platform and ensure the rights of your community are respected.

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.

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.