Things n' Stuff Thoughts about the universe in general

This post was originally written in response to The Linux Experiment’s “Redis ditches FOSS” item, where Nick, the presenter, was critical of the recent Redis license change where they moved from the original BSD license to MongoDB’s SSPL, a change that was portrayed (and I’m paraphrasing a bit) as “the company taking the code the open source volunteers have given them and closing it in order to monetize the volunteers’ work”.

TL;DR – the fact that OSI labels SSPL as “not open source” is nothing more than FUD by the major cloud providers, as the only meaningful difference between that and the GPL is section 13 that makes life harder for cloud providers.

The 2023 Stack Overflow developer survey results are in, and here’s my (likely controversial) take:

Rust developers are the most self-centered, with Go developers close seconds.

Here are screenshots of the very nice “Worked with vs. want to work with” graphics for programming languages, with Rust and Go highlighted:

This – this is the reason:

Unlike other software packages (which includes, I believe, Flatpak) Snap packages will not update if the application is already running. Instead you get this annoying popup “Oh boy, you have 13 days to close your app otherwise nasty things will happen!” Which wouldn’t be such a bad idea in and by itself, except that if you close the application – it doesn’t update. Even the notification doesn’t go away.

I’m starting a new thing on this (otherwise quite dead) blog, mostly as a service to myself: “Imported Rants”. Its going to be basically copies (sometimes maybe better edited) of rants I posted as comments in other places (mostly YouTube), that have grown long enough to almost be an article in and of themselves.

Today, in response to Brodie Robertson’s question – Should Linux Users Hate Apple As Much As Microsoft? here’s the rant from my comments:

Most people who have been involved in Linux development/administration/advocacy already know that Linux operating systems are in the middle of a big shift (or actually, almost at the end of it) in the graphics stack used in Linux desktops – from the old and gnarly X11 protocol to the new hotness: Wayland compositing. And it sucks.

Don’t do this:

Do this:

This is a public response to Johan Thelin’s post “The API wars – 16 years later. His blog commenting system looks a bit broken and regardless – I think its an important enough discussion to publish here. The main premise of the article is that the web APIs have won the “API war” in the context of Joel’s Spolsky’s “How Microsoft lost the API war” article from 2014 but the main winner is the globally domineering Google and we should subvert their victory by moving to the new runtime – the WebAssembly, that is better in every way.

Here’s what I had to say about that:

I often say that one of the main reasons I use KDE Plasma as my default graphical workspace is that some of the KDE specific software is the best at what it does, and specifically – as a lot of my computer time is spent using a console – the KDE terminal emulator software Konsole is the best in the world.

Microsoft recently demoed a Windows Subsystem for Linux¹ feature where they can run commands on a Linux shell under WSL from the Windows CMD shell – which, according to the demo that pipes the output of ipconfig to Linux grep, they need becuase the CMD shell is a 30 year old joke shell that can’t even do grep properly.

1. stupid reverse WINE : its a Linux system call translator for Windows, like WINE does for Linux, but doesn’t handle X or OpenGL and does a piss-poor job of file IO [↩]

Yesterday night, GitLab’s hosted service (gitlab.com) suffered a database crash and the service went down for a day¹.

I’m not going to discuss the technicalities of the down-time (which is covered extensively in the blog post linked above), except to note that “shit happens” – my main take-aways from that are basically two:

1. Don’t let tired people handle critical system issues, and if you ever find yourself juggling the third production issue at midnight after a full day of work – just say: “no, I’m not going to fix this – some one else must step in or we leave the system down for tomorrow”.
2. The GitLab process for handling the failure was nothing short of amazing, and they deserve all the kudus for that: After figuring out how deep in shit they are, and posting a “sorry we’re down” page on the main web site, they:

• Posted frequent updates on their tweeter status account (to the point of posting restore percentages progress)
• Published the technical root cause analysis Google Document as it was being developed
• Streamed the operations team ongoing restoration work on a live YouTube channel (!!) The operations people even responded live to comments on the chat, commented on the process and their architecture and were generally being awesome.

I think this should be the standard from now on how to handle system crashes on your public facing application – 1000% transparency should be how these things are handled if you have any hope of recovering the trust of the community in your service.

1. at the time of writing, the service is still not up, but its not yet even 24 hours since the crash happened [↩]