I recently came to think about how to enforce good commit messages without enforcing a commit message style such as conventional commits (read more about my passionate hate for conventional commits here).

Disclaimer: This article does not provide a solution, as I don't have one yet.

The Why

We all know know what a good commit message is.

You didn't believe this, did you?

It is more like some of the developers out there and how to write one, but most kiddies out there don't. And these commits from last night are only the ones containing swear-words. We all know projects where the developers just don't care about good commit messages and things like “implement #1241” is “considered” a “good enough” commit for a 1200 lines-of-code change that touches 15 files.

I do not really have to reiterate what others have already stated numerous times, do I?

The How

In my post about my hate for conventional commits I already wrote why I think automating these kind of things is bad idea. But to reiterate this shortly: Enforcing a certain “style” of commit messages, such as common prefixes, certain trailers and so on, makes people resort to only fullfill the automatically tested things.

So if you enforce that a commit message subject should start with one of fix, change or doc, people will no longer write "Implement JSON backend" as commit message, but "change: Implement JSON backend". What have you gained? Nothing.

Instead, I want people to write commit messages that tell me why a change was made. Something in the lines of

Implement JSON backend

This patch implements the JSON backend using the JSONFOO library. Note that content is currently not read in a zero-copy fashion with this patch, to keep the diff small.

Zero-copy JSON handling will be implemented in a seperate patch once we confirmed that JSON is working as expected

Signed-off-by: Ned Stark ned@nohead.email

Manual commit message review

In my opinion, commit message review should be part of every normal code review. What I think, though, is that interfaces such as githubs review interface do not particularly encourage this. Also, I feel like requesting commit messages changes is socially not as accepted as code change requests are. Asking a developer to change a function name is (at least from my perspective) seen as a normal request. Asking a developer to rewrite their commit messages is not.

I don't know why this is or how I got to this impression, but I feel this way and it concerns me. It really should be as socially acceptable as requesting a code change, because it is equally (or maybe even more) important as the code itself.

Today I was notified by a dear friend of mine about a fact that lead me to think about the Rust project a lot. I came to the conclusion that the whole project, including but not limited to its most famous contributors such as Graydon Hoare, Alex Crichton and Niko Matsakis.

This plot has been on-going for a long, long time. In fact, it started even before Rust 1.0 was released in May 2015! I suspect that the plot was even started before the Roadmap planning of Rust 1.0 in 2014, but this is only a (probably good) guess. I do not have any proof of it, and of course the people that were involved with the process of bringing Rust 1.0 to live would deny anything I claim here (I guess).

But I think this guess is a rather good one. In the mentioned Roadmap it was planned to release every 6 weeks, and this is what I base that guess on. They made it fix right there. When Rust 1.0 came out on 15th of May in 2015 – which is a rather odd date, to be honest: 2015-05-15, or 5/15/15 in US notation, the plot must have been made fix already. Maybe I'm on another trace there with this date, as 51515 almost looks like 666, but this is something I will dig into in another blog post.

So when they made it fix, the already had said plot in the back of their heads. What that ominous plot is, you ask? Well... it is as simple as this:

Rust 1.60.0 came out on 7th of April 2022. Thinking forward for 9 releases, we can easily calculate that Rust 1.69.0 will be released on 20th of April 2023, or rather: 4/20 of 2023.

That's it, there it is! They have planned it all along! We've been fooled and tricked for years!

Now that I've shown that all these maintainers, hard thinkers and these hours and hours of effort put into planning, preparation of talks, discussions on various channels all over the internet but also in real-world (“offline”) were just spent to fool us into a conspiracy of putting together funny numbers on some release note, I can go back to my quiet chamber and think a bit more about that 5/15/15.

---

Of course this article is a joke and nothing here is meant serious, except that all these people indeed this a very good job and put numberless hours into making Rust awesome!

Also note that if you use the original date for the calculation, everything falls apart, sadly.

Mother/Android is a 2021 American post-apocalyptic science fiction thriller film.

Holy crap, I can only say. This was probably one of the most gripping movies I have seen in the last 12 months!

Plot

Androids, which were mere servants but then became evil, try to kill all humans.

That's the plot, yes. It is nothing spectacular, even boring maybe. But the execution of this simple setting is so good, that I was clinging to everything I got hold on.

Reception

On rottentomatoes, the movie got only a weak 4.9/10, whereas I would give it a strong 8.5/10 actually.

So some of you already know from my last article “KDE is love” that I got a new device from my employer. I was allowed to select this device on my own and install my preferred Linux distribution on it.

Now I want to give some feedback on the device itself.

Build quality

The device is a 15,6 inch notebook with measurements 35,6cm width, 1,7cm height and 23,4cm depth. It weights about 1,5 kg with battery (all manufacturer specs). It also comes with a nice and large 114,5 x 70 mm touchpad and without a numblock, which was really important for me as I think numblocks are just a waste of space.

The build is very solid. I really like touching the device, it feels very well done and even compact, although it is the biggest form factor in a notebook that I owned to date.

The fans blow hot air out to the back of the device, which makes working on your lap possible without burning your thights. The power switch is next to the keyboard, not on the side of the device as it is on my previous/private tuxedo (a InfinityBook 14 Pro v4). That, I assume, resulted directly from the feedback TuxedoComputers got about this... the power button on the side was not that practical.

On the left side of the device there is the Kensington lock, one USB 3.2 (Gen1) and one USB 2.0 slot as well as your headphone jack and a micro SD card reader. On the right side, there's another USB 3.2 (Gen1) slot as well as a USB 3.2 (Gen 1) type C slot next to your power plug and the HDMI out plug.

Hardware Specs

My device came with a 1 TB Samsung NVMe SSD, 32 GiB of DDR4 3200 MHz Samsung memory and a AMD Ryzen 7 4800H which runs 8 cores from 2.9 to 4.2 GHz with 16 threads and 12 MB L3 Cache.

I really have to say, this beast is a powerhouse.

Battery

Still, I get very decent battery lifetime out of it. That's because there's a 91,25 Wh battery built in, which can even be replaced. How crazy is that? TuxedoComputers advertises this beast with 20 hours of battery life under absolutely optimal conditions (lowest screen brightness and so on)... we all know that this is never true for a real world usage. Still, they advertise 11 hours of battery life with moderate usage (Screen half bright, WLAN on). I must say that this might be about right. Right now I am using this device on the third day without having it plugged in. I only did a bit of browsing during that time, with screen between 5% and 35% of brightness. I only compiled once for about 5 minutes. So there's that.

If I run out of battery, though, I have got a power bank from TuxedoComputers as well, so I can make sure that I have a full workday of battery power with me when working somewhere outdoors!

Screen

The screen is “only” a HD screen. Yes, but it is completely enough for me. Your milage may differ, of course. What strikes me is that you get a crazy view angle out of that screen. And, you may have guessed, even with 5% of screen brightness, I can work without issues. 35% screen brightness are totally fine for everyday work.

I am looking forward trying out this device outside under sunlight. Right now it is too cold for me to sit outside, though.

Keyboard

The keyboard is the only point that could be a bit better. Maybe I am spoiled by the InfinityBook, where the keyboard is really good (IMO, of course) or even my old X220 Thinkpad.

Don't get me wrong, the keyboard is not bad. The pressure points are decent, the keys are of course large enough. But as they are embedded into the case, I cannot feel them properly when sliding over the keyboard with my fingers. So I have to look down from time to time. Could be much worse, yes.

Conclusion

So, to conclude this: The device is a powerhouse, the build quality is really nice and the keyboard could be a bit better. I don't know how, though. The specs are phenomenal (for me).

Of course, I had absolutely no problems getting Linux (NixOS) running on it, since it comes from a Linux manufacturer. My KDE Plasma 5 setup runs as smooth as I could wish on it.

All in all, after working with it for about one week I cannot complain at all and I am really looking forward working with this device long-term.

Some of you might know that I am using KDE Plasma for some time now and that I am really in love with it. Lately, I've been even more in love with it.

Here's why.

A new device

As I recently switched my job, I had the opportunity to get my hands on a new device (thank you, employer)! I opted for a Tuxedo Pulse 15 Gen 1 which is a wonderful device. I might be writing about that in another article.

Naturally, I installed my favourite linux distribution on it (which is NixOS) and KDE Plasma. After updating the device and all my other installations to the latest release of NixOS (which is 21.11), I was greeted by the brand new KDE Plasma 5.23 welcome screen.

KDE Plasma has been running absolutely smooth on my old device (which I still use), which was a Tuxedo InfinityBook 14 Pro v4. Still, I was even more amazed that on the new device, it ran even smoother. There are no glitches, no screen flickering even while plugging in an external display, not the slightest stuttering while moving around. Don't get me wrong, there hasn't been any of these things with my old Tuxedo, too! Still, it felt so new and refreshing on the new installation that I absolutely had to write about it.

Initial setup

The initial setup of my KDE experience involves some work. The default configuration of the KDE desktop experience is really nice, but I need some custom shortcuts to be as productive as I want to be. For example, I want to use the HJKL keys for some tiling stuff. KWin, the KDE window manager, is not a tiling window manager. Still, you can get some basic layouting to work with it (top-right-corner, right, lower-right-corner and so on). Also I need key bindings for fullscreen, switching virtual desktops and bringing up Krunner, KDEs app launcher/search tool/... whatever you call that awesome piece of software!

Krunner

Krunner is awesome. It is much more than just an app launcher. With the (firefox) browser integration, you can search bookmarks, history, open tabs (and switch right to them), you can search windows, passwords (password-store anyone?) and of course you can launch applications from it. It just integrates so nicely with KDE, it is amazing.

Plasma-browser integration and kdeconnect

Plasma browser integration (for firefox) is god-sent. Combined with kdeconnect, which is another god-sent tool, it makes the experience perfect. Notifications from my mobile phone can be synced to the desktop and the other way round (although I disabled this specific setting because I tend to get a lot of notifications on my mobile phone that just annoy me on my desktop, especially when in a call with co-workers). Whenever someone calls, my music or netflix stream (this is made possible via the plasma browser integration) is automatically paused and (of course) resumed as soon as I hang up. I can send websites from my browser to my phone when I want to continue to read while in the bathroom (we all do that, don't laugh!) and of course also the other way round. And so on and so forth...

All the details

The details of course matter. For example: I just found the setting to disable the touchpad while typing. I toggled it and it just works like a charm. I added a script that executes ssh-add on my ssh keys to the autostart scripts and it justs works, asking me for the password of my ssh key to add it to ssh-agent after login. Enabling the integrated redshift for KDE was literally one click in the settings, now I get a redish (is that a word?) screen in the evening, which is more eye-friendly.

Conclusion

My conclusion is clear and obvious: Love! I don't know why I would ever switch away from KDE again. It is the same as with my NixOS experience, that started in 2014. I just don't see why I would switch away from something that is so good.

Maybe this article was a bit annoying to you now, me fanboying about KDE. I don't know. It's just something that I wanted to share.

Enola Homes is a 2020 (netflix) mystery film.

I have to say that I am a big fan of Sherlock Homes, the Benedict Cumberbatch version. So I was a bit skeptical whether “Enola Homes” would entertain me. Though, my fears were proven unfounded, as the movie was fun and exciting!

Plot

Enola Holmes is the youngest sibling in the famous Holmes family. She is extremely intelligent, observant, and insightful, defying the social norms for women of the time. Her mother, Eudoria, has taught her everything from chess to jujitsu and encouraged her to be strong-willed and to think independently.

wikipedia

... one day, her mother goes missing. Naturally, Enola tries to find her.

I won't share more here, as always. Giving away too much of the plot just reduces the entertainment if you, dear reader, watch the movie.

Reception

The movie has a 7.1/10 rating on rottentomatoes, according to wikipedia, which is quite good.

I would rate it with 8/10. Also, a sequel was announced in May 2021!

I am co-maintaining a few crates in the Rust ecosystem. Some very passively, some (config-rs) more actively. From time to time, and lately more frequently, I see more and more “conventional commits”. I hate them with a passion and for the repositories I frequently ask people to rewrite their commit message. I even went as far as picking their commits to my local repository and rewriting the commit messages by hand (yes, FOR THEM even though it is not my job).

What “Conventional Commits” are

Conventional commits is a (pseudo)standard. Its tagline is

A specification for adding human and machine readable meaning to commit messages

and it advertises itself as a “lightweight convention on top of commit messages” (source).

The idea behind conventional commits is that one can write tools to parse commit messages and process the found data, for example to generate changelogs. Other uses come to mind, for example for gathering statistics (“who writes the most 'feature' commits?”).

The Premise is wrong!

The premise that generating a changelog from git commits is a good idea is utterly wrong, though.

First of all, commit messages are there for developers of a software to understand why you did what to achive what goal (see also: 1, 2, 3). Generating changelogs from commits results in not very much more than git shortlog lastrelease..currentrelease. Changelogs are mainly for the users of the software. These users might be developers, if the project is a library, but the point stands. A user of a software should never have to concern themselves with stuff that happened during the development of the next release of that software. They are concerned about what changed for them. These things might overlap, yes, but they are never equal!

Conventional Commits hurt!

From the real world out there – from maintaining a few software projects – I can tell you this: Not ONE SINGLE conventional commit message I've seen in recent years did actually a good job. None, yes I say it again: NONE, has actually described what the commit was about!

That's of course not necessarily a fault of the idea of having machine-readable commits, but a direct result. Why? Because people start thinking that now that they're writing a “machine readable” format in their commit message, they provide more value in the commit message than before. This results in shorter commit messages with fewer details.

Fun is, that the website for conventional commits actually markets this:

feat: allow provided config object to extend other configs

BREAKING CHANGE: extends key in config file is now used for extending other config files

That's the first example on the website. What does this commit message actually tell us? It tells us that in the software project at hand, there is a “config object” and that now this object can be used to extend other configs.

Fine.

It does not tell us why this change was made (other than that it is a new feature now) and it does not tell us what was done for this to become possible. It tells us that there is a breaking change, but it does not tell us why there was this breaking change, whom this may concern, why this might be a problem even, or how users should react to this breaking change.

Further, I deduct that this change might be a complex one. Of course, nobody can tell from the commit message alone, but lets just assume for one minute that introducing this change actually entailed a few hundret lines of code added to the codebase of the project and another few tens of lines changed.

I can almost guarantee you (haha, you may think... guarantee with a fictional software project – yes! Please stay with me here), that implementing this change in not one commit but maybe three or more seperate commits, one atomic change after another, would result in a way better history! Way better discoverability for developers!

After the change was accepted, the cover-letter, pull/merge request description or merge commit itself can of course contain a detailed description that later might end up in a CHANGELOG.md file (although some argue that having such a file is not beneficial in any way).

How to do better

It is so easy to do better than conventional commits! Actually, there are only seven rules you must follow for nice commit messages! Just read this article – or, if you're lazy, I copy them for you here:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

It's as simple as that.

I would even add another rule: Use --signoff when committing for using the Developer Certificate of Origin (see also 1, 2).

I didn't post a movie review for a long time. So let's have one again. This time I want to write about “Outside the Wire” which is an 2021 Action movie.

Plot

As always, only a short teaser from the Wikipedia page of the movie:

In 2036, a civil war between pro-Russian insurgents and local resistances in Ukraine leads the US to deploy peacekeeping forces. During an operation, a team of United States Marines and robotic soldiers are ambushed. Disobeying an order, drone pilot 1st Lt. Harp deploys a Hellfire missile in a drone strike against a suspected enemy launcher, killing two Marines caught in the killzone but saving the 38 Marines who would have been killed by the launcher. As punishment, Harp is sent to Camp Nathaniel, the US base of operations in Ukraine.

The plot is nothing usual, but also nothing special in the end. I liked it a lot, though!

Reception

I cannot agree with the rottentomatoes reviews on this one! On rottentomatoes, this movie has a 4.9/10, but I would rate a solid 7/10. There is a lot of action, not too much emotion, which is good for this genre, and a fair bit of “race against time”, but nothing too heavy.

I can recommend this one.

With the end of the year, I will be changing jobs. This was not an easy decision to make for me, but in the end I guess it turned out to be the right decision for my career path.

First of all, I would like to stop for a moment and thank my (soon to be ex) colleagues at science+computing ag for the last (almost) three years! During my time at science+computing I learned a lot, not only about technical things, but also about how things work in the industry and related topics, and I was able to grow a lot (as far as I can tell). The problems we solved were challenging and gave me the opportunities I needed to enhance my skills in the field of Linux, packaging, programming and development, but also in negotiating with colleagues or customers on both technical and social issues!

I especially want to thank my team for these fun times, awesome team-dynamics and a team lead that was always there when needed, easy to talk to and for the freedom they gave the team in making their own decisions!

Next...

Starting next year, I will be joining a new company (I am not yet sure whether I am allowed to talk about details) which will give me even more options to grow my development skills, especially in the Rust ecosystem – which is I am really looking forward to! I am intrigued about what challenges I will be asked to solve and am really looking forward to meeting my new colleagues.

If I am allowed to talk about details of my work (which might actually be allowed), I will post here and, of course, on my mastodon account!

I have been playing with functional languages a few times now. I have tried Haskell, Elm and Elixir so far, but also played a bit with a LISP-like language that is implemented in Rust for being easily embeddable into Rust programs.

Lately, I also played with “roc” (https://www.roc-lang.org/), which is a new approach for a functional programming language that can compile to binary (using LLVM) that also has some new ideas.

One of these ideas, that I quite like to be honest, is the idea of “platforms”. A developer has to write a minimal platform the program they want to write runs on. This platform is nothing more and nothing less than the interface between roc and the outside world – which is stateful! So the platform deals with allocation and deallocation, talks to the operating system to, for example, read from the commandline or handle incoming network traffic. The platform has to be very minimal, and must ensure that there is no state leaked through to the roc program!

roc itself has a syntax that is rather nice, although I think there can be improvements. The idea of the authors is that roc should be easy to use, like Elixir or Elm, spark joy in the programmer and still be fast. In fact, it has been shown (in a very unscientific benchmark IIRC, but that's more due to the fact that roc is in very early development as in due to other reasons) that roc can in fact outperform imperative languages in some cases! Leveraging the power of LLVM is one of the reasons for that, but also that roc enables performance optimizations that are not possible or very hard in other circumstances.

To conclude, I am really looking forward to roc and hope that it will be more “you can play with this”-ready than it is today. Right now, compiling everything from source all the time (roc is written in Rust) and having only very few pieces of documentation available, makes playing with roc hard. I hope that will improve soon.

To quote myself:

So my ideal #functional #language #programminglanguage would be a pure functional language with traits/interfaces, ergonomics like #ruby or #elm or #elixir, performance like #rust because it compiles to binary with #llvm, with the “platform” approach #roc #roclang currently has, so one can provide minimal interfaces to the OS ...

Which would make it a perfect language for #containers and #microservices but also #CLI tooling and even websites via #wasm (if it can compile to wasm)!

... and I think roc can be that language!

---

Please note that roc is not released as opensource codebase at the time of writing this article, but it will be as soon as the author thinks it is time. I wrote “roc” in lowercase letters in this article because – and only because – I think that's how it is intended.