musicmatzes blog

Once in a while I find issues on github, mails on mailinglists or even questions in IRC/Matrix/whateverelse that always end with the same phrase:

Should I send a patch for this?

One recent example is this very well drafted mail on the mailinglist (*).

The answer to this question is (almost) always: YES PLEASE! Even moreso, the answer to this question is a question itself: “Why didn't you in the first place?”.

Sending a patch vs asking

Most of the time (and with the mail linked above) the overhead between asking whether a patch would be appropriate and just sending the patch is minimal. The effort crafting the patch is something in the lower minute range, nothing that takes a few hours. Plus, the rationale why the patch was created serves perfectly as a commit message!

Consider this: The patch is trivial, the rationale is rather long. Having the rationale as commit message and sending the patch with the rationale as commit message results in several benefits for everyone:

  • If the maintainer of the project wants to apply the patch right away, they can. This is actually huge: it saves everyone one roundtrip!
  • The commit message is there right away and it is very detailed and good
  • If the maintainer does not want to take the patch as-is, there's still one roundtrip saved because they can craft inline comments in the patch on what should be changed

If the patch is declined, very minimal effort was wasted. The ratio between effort saved if the patch is applied and effort wasted if it is not applied is actually very low. Plus, most projects would love to have more contributions, so getting a “No” right away is not that common!

Of course, there's also cases where you'd want to ask before actually working on a patch. That's the case if there needs to be serious effort be involved. If you'd need to refactor a large portion of the codebase, for example, you might want to get in touch with the maintainers first, whether such a change would be accepted.

I'd argue, though, that most of the time you can just fire away with your patches. That's certainly the way I handle it and most of the time they are applied right away without any back-and-forth!

(*): This mail just serves as an example here because it sparked my inspiration for writing this article. I do not want to attack the author in any way, neither do I either agree or disagree with the changes proposed in the mail.

“Thoughts” is (will be) a weekly roll-up of my mastodon feed with some notable thoughts collected into a long-form blog post. “Long form” is relative here, as I will only expand a little on some selected subjects, not write screens and screens of text on each of these subjects.

If you think I toot too much to follow, this is an alternative to follow some of my thoughts.

This week (2021-05-15 – 2021-05-21) I started thinking about hiking. Besides from that, not much happened, to be honest.


I started (german) thinking about #hiking a lot more recently because I don't think the pandemic will end soon and even if it does (it won't, srsly!), I cannot go on vacation anyways because my prefered way would be with a camper and I do not (yet) own one, plus, prices are high up in the sky, so I cannot afford one either. So the idea of hiking a lot more came up and I started planning hikes around my hometown and nearby (southern Germany).

I also started thinking about multi-day hikes (3 to 10 days) and am currently thinking whether this would be a plan for the next (approx.) two years, to be able to do the NST (german) in 2023 over the course of 6 months.

I'm not particularly fit at the moment, but a 15-20km hike with a light backpack is nothing I am scared of, so I guess that's a good start for training. Still, having approximately 1.5 years for training shouldn't be a bad idea. Starting slow with lower two-figure-km hikes and going up to 25 or even 30km, adding more and more baggage along the way, including (of course) a tent and sleeping bag, to be able to do multi-day hikes. Also, some of the gear has to be bought, of course.

Maybe this develops into a real plan.

Logging with rsyslog

Another thing I thought a lot about is how to log from several services (distributed over a network) to one central place, in one file per process. A friend suggested #rsyslog and I was investigating the possibilities with that. It certainly can do what I want.

For my particular problem, rsyslog would suffice. Still, I was able to solve it even less complicated, without the need for an additional service.

Per-Process Resource restriction

I also messed around with the idea of restricting resources per process on my notebook. The idea came up because of high RAM usage of #firefox and dolphin, slowing down other things. Putting these two into a resource-restricted environment, only giving them access to 16 GB RAM maximum for example, could solve that minor inconvenience (I have 32GB installed in the device).


After freenode vanishing from the face of the earth, I think the time of IRC is finally over.

The time of #irc is over. Join #matrix now!


I'm not saying that there won't be #IRC channels anymore, but #freenode was the one big network in IRC-land. The takeover was no surprise but a question of “when” instead of “if”.

Still, alternatives exist today and I promote Matrix because I think it is a good thing. Don't tell me it is bloated, don't tell me it is slow, don't tell me the clients suck (go write one that fits your needs, instead of bragging about these things), don't tell me what I know (or what I have experience with that differs from your claims)!

Matrix is here today, has advantages over other communication protocols and works.

I am known for not being the biggest fan of horror movies. In fact, I avoid them like crazy. Now, “The Covenant” is not necessarily a real horror movie, but wikipedia titles it “supernatural action horror film” and I agree wholeheartedly.

Is there a #database of #movies that show #spiders? Because I'd LOVE to have a database on this so I can avoid these movies!


Either way, the movie is exciting!

The Plot

As always, I do not give away too much of the plot here, even less than the wikipedia article on the movie!

In “The Covenant”, four teenagers, the descendants of colonial witch families, have magical abilities. At the age of 18, they ascend and their powers become massive. At their school, they meet a new student: Chase. Though, she starts to experience strange things, as do the boys.

Things go strange and downhill faster and faster, with a malicious (magical) actor revealing later in the plot.

My opinion

I already wrote that I'm not that fond of spiders in movies, especially if they are part of the plot. Still, the movie was great and I liked it a lot. The music is very well suited for that kind of movie and I loved the Metalish/Hardrockish atmosphere.

The movie is pretty dark overall, which is not that surprising, given its genre. Still, what really bothered me is that it rains constantly in the movie, except for the scenes where the main character drives his car – because they always drive open-top. It's really a goof, in my opinion!

I must say, though, that the movie was not very well recepted in media. It has only an approval rate of disillusioning 4 % on rottentomatoes, and an average score of 2.84/10!

The Covenant plays out like a teen soap opera, full of pretty faces, wooden acting, laughable dialogue, and little suspense.


I agree, but the characters are still well-played and it clearly did not fail to entertain me.

#movie #horror #action #supernatural

“Fate: The Winx Saga” is a teen drama series released on #Netflix which I would put into the “Fantasy” genre.

I was not yet able to see the second season, as it is not out on german Netflix just yet, I can only say something about the first one. I like it a lot, to be honest. It is sometimes a bit scary, dark and definitively has some tension to it! It does not fail to entertain, despite having only a 5.33/10 on rottentomatoes!


Because there's not much in the Wikipedia article on the plot, I quote it here for simplicity:

Bloom, a fairy with fire powers, enrolls at a magical boarding school in the Otherworld called Alfea College. There, she shares a suite with Stella (a light fairy), Aisha (a water fairy), Terra (an earth fairy), and Musa (a mind fairy). With the help of her four new friends, Bloom starts to learn more about her past. Meanwhile, ancient creatures called the Burned Ones return to the Otherworld and threaten everyone at Alfea.

Because it has some dark scenes, the show might be not appropriate for young children, although it is about fairies and from its description seems to be targeting children!

#fantasy #teen #series #drama #movie

When I write about Enders Game, I mean the movie published in 2013 based on the science fiction book series that was written by Orson Scott Card. That series started with a short story “Ender's Game” which was published in 1977 by the same author.

I have not read any of these books nor have I read the comic books which were published by Marvel. But I have seen the movie and I want to write about it here, because I really liked it.


As always, I do not want to spoiler any of you by giving away too many details of the plot.

For a long version of the following, please refer to the wikipedia article on the movie, which is about 700 words. I do not want to give away that much details here, though.

As this is a science-fiction movie, it takes place in the future. In that future, humans want to attack an alien race that previously attacked earth and killed millions. For that attack, the best and most promising individuals are trained from young age, so they can lead the attack as efficiently as possible. “Ender” (Asa Butterfield), which is the main character, is a gifted young student in the battle school. He starts the training more or less as an outsider, although working hard gets him far.


I really liked that movie. Wikipedia states) that is was a box-office bomb, grossing only $125.5 million on a $110–115 million budget, though. Rotten tomatoes states that

If it isn't quite as thought-provoking as the book, Ender's Game still manages to offer a commendable number of well-acted, solidly written sci-fi thrills.

averaging at 6.07/10. I would rate it at about 7.5/10.

#movie #scifi #sciencefiction

“Thoughts” is (will be) a weekly roll-up of my mastodon feed with some notable thoughts collected into a long-form blog post. “Long form” is relative here, as I will only expand a little on some selected subjects, not write screens and screens of text on each of these subjects.

If you think I toot too much to follow, this is an alternative to follow some of my thoughts.

This week (2021-05-08 – 2021-05-14) I thought about vendor lock once more and played a bit with my raspberry.

Github and Vendor-Lock

My discontent about #github continues but I had to admit that github-actions is very nice and I like it more every time I have to work with it. I'm not sure whether this plays into the vendor-lock thing mentioned earlier.

I also voiced my discomfort... no, lets face it: my anger with people that cannot obey the simplest commit message rules.

Sensor stuff

I was able to boot my old Raspberry Pi (1) with raspbian (german) (unfortunately #nixos failed to boot and I don't know why), which makes my plans for sensors in my flat (last week, german) a little easier. It won't be able to run prometheus and grafana because 512MB of RAM is just not enough for these, I guess. Still, I am one step further towards the goal!


I watched “The Covenant” and asked the fediverse whether there's a database of movies with spiders, so I can avoid them. This would be in fact a really helpful database, and I am sad that no such things exists. I am not actually arachnophobic, but I really don't like them and prefer to watch movies without any spiders or similar creatures (crabs, scorpions, ...).

Idiotic shopping

Well, I had some encounters (german) with overly stressed workers at my local grocery store this week.

The thread linked above tells you everything I guess. I am still baffeled how idiotic some people in our society behave, even though this is not the worst kind of human being running around these days (especially if you consider covid-denialists and so on).

Recently, I voiced my discomfort... no, lets face it: my anger with people that cannot obey the simplest commit message rules:

Why can't people obey these simple #commit message rules?

  • Use an uppercase letter for the start of your subject line
  • EXPLAIN what you did, not “Fixes”



This really bothers me. I (co-)maintain a few crates in the #rust ecosystem. There are contributions rolling in every other week and I love that, because it makes me happy to see that other people care about the same things that I care about. Still, I am constantly asking people to rewrite commit messages or clean up their branches because they did strange things – for example merge the master branch instead of rebasing their pull-request to fix merge conflicts. And sometimes even change things in this merge commit, making a review utterly impossible!

Most of the time I do not bother if people just don't capitalize the first letter of their commit message, but it bothers me to no end, still. That's why I teach others to write proper commit messages when I teach them how to use #git, and I really try to be a pain in their ... youknowwhat, so they are annoyed by me telling them “No, rephrase that!” all the time!

I am not angry if people fail to use git trailers the right way (and yes, these are kernel commit conventions. Does not mean they cannot be applied to other workflows as well)! These rules are, of course, not carved into stone. Still, it is a matter of good behaviour in the community to give attribution to people involved in the process of applying the patch (using “Signed-off-by”, “Acked-by” or “Reviewed-by”), crafting the patch (using “Co-authored-by”, “Suggested-by”, “Signed-off-by”) or others (“CC”, “Reported-by”, ...).

I hope I don't have to repeat that commit messages like “Fixes” or “Refactor” are bullshit!

How to NOT do better

There are projects out there that try to make you a better committer. Most known is conventional commits.

I don't like these things at all. “Why?” you may ask? The answer to that is really simple: It makes you think less about what you've done, and, and that's propably the worst thing, it gives you the ability to auto-generate a changelog from your commit logs. But commit logs are not changelogs. Commit logs are logs of steps how your software was developed. A changelog is a list of things your users need to know about when upgrading from one version to another. They don't need to know the steps that where taken to provide new features, fix bugs or refactor your codebase, they need to know about what changes for them, how using the product has changed!

Luckily I have managed to stay away from projects using conventional commits.

How to do better

There are tons and tons of guides out there how to write proper git commit messages. I leave searching for them as a task for the reader here (one thing I want to link here is Drew DeVault's article on a disciplined git workflow). The very basics are:

  • The subject line must not exceed 50 characters
  • The subject line should be capitalized and must not end in a period (really, who on earth would end it with a period? I mean... do you end your email subjects with a period?)
  • The subject line must be written in imperative mood (“Fix”, not “Fixed” / “Fixes” etc.)
  • The body copy must be wrapped at 72 columns
  • The body copy must only contain explanations as to what and why, never how. The latter belongs in documentation and implementation.

There are, of course tons of great examples out there. And because people get annoyed if I tell them that the best examples can be found in the linux kernel community (“These people are GODs, I cannot compare to them” – why not?), I can only show you some less GODish commits (by me)!

Have a look at my

  • contribution to shiplift. The commit message is not that long and the change is atomic. The subject line is a short summary what the change is about, the body explains why this is/was done. The trailer notes that I submitted this according to the developercertificate.
  • contribution to config-rs. Nobody said that the commit subject has to explain all the things – as long as there is reasonable explanation in the body, the subject can be “Simplify implementation” (like here).
  • commit bringing order to the galaxy. There can be the occasional joke, of course!

These are all rather short commit messages for simple patches. Longer messages with more explanations also exist in my projects! For example in the butido project there are changes like this one, or this one or even this very long one. Or, to go crazy, this enormous one here.

These commits have one thing in common: They explain why things were done.

And you can do that to! One really simple idea that is worth trying out is not to use the -m flag of git-commit at all. This way you are presented with your favourite editor and can pause for a moment to think about what to write.

Don't be that guy that appears on the front page of!

Altered Carbon is a Sci-Fi/Thriller series (wikipedia says “Cyberpunk”) produced by Netflix. Most Sci-Fi movies that were published in the last years were more or less “meh” (at least the ones from Hollywood). But not this one.

It was the first Sci-Fi series in years that really got me. Two seasons of ten and eigth episodes of pure tension, nice cliff-hangers, awesome spins and really, really nice plot twists. Like, not plot twist were you think “they just did this to keep going” – no, plot twist that one could've seen coming if being attentive, but surprising nonetheless.

I really, really hope that there will be a third season and that they continue with the high level of action, emotions, tension and well-crafted story line.

About the plot: I don't want to spoiler too much, because the plot is rather clear after the pilot episode. Just a few things: Takeshi Kovacs, is a former member of an elite military force of futuristic soldiers, part intelligence operative and part shock trooper, trained to adapt quickly to new bodies and new environments. He was in prison for 250 years, but is pulled back into a body because one of the wealthiest and most powerful men of the settled world wants him to solve his murder.

I guess that's not too much spoilered.

I've also been told that the movies differ greatly from the books. I've not read the books, but I liked the movie a lot and I guess others will to, even if they've read the books.

#movie #scifi #sciencefiction #thriller #action

The TV Series “Away” which premiered on Netflix in 2020. Unfortunately the series was canceled after just one season, although the story was completed.

This is another Sci-Fi Series, but the main focus I want to take here is not the fact that it plays on a space ship, because that is only a circumstance. The real deal with this series is that it is about human emotions, fears and hopes. The series does not have the best rating on, for example, rottentomatoes (6.22/10), still:

Away doesn't reach the stratosphere as a spacetime adventure, but emotional earnestness and a strong cast help make this a compelling enough journey to the stars.

And I wholeheartedly agree with that.

The episodes are not that long either (44 to 57 minutes), so you can watch the whole series on either a weathered weekend or as a bedtime movie!

Despite it not being the typical Sci-Fi action thriller, the series does not lack of a certian tension.

#movie #scifi #sciencefiction #emotional #series #netflix

“Thoughts” is (will be) a weekly roll-up of my mastodon feed with some notable thoughts collected into a long-form blog post. “Long form” is relative here, as I will only expand a little on some selected subjects, not write screens and screens of text on each of these subjects.

If you think I toot too much to follow, this is an alternative to follow some of my thoughts.

This week (2021-05-01 – 2021-05-07) I had the idea of a weekly rollup of my thoughts, obviously. There's not too much to say about it, although maybe a bit of a rationale would be nice.

The “Why”

So it happens every other week that I have these “wtf” moments. Some of them are minor, some of them are more in the range of a rage-quit. Most of them are really biased, opinionated, call it what you want. Most of them are also flame-war'ish. Most certainly none of them are true. Or are they?

Either way, I am a human with feelings – strong feelings – about certain things and I most of the time express my discontent about things in toots on my mastodon feed. But because of the limitation of mastodon, or rather, of the medium of a microblog, expressing certain things is difficult, if you don't want to write several toots in a row. Explaining things in a prose/blog post seems to be the right approach. On the other hand, some of these things are not things that I could write a thousand words easily about.

Something between a toot and a blog post would be nice!

So, why not writing a rollup of my thoughts from mastodon in a weekly blog post. Seems like a good idea. So here it is.

The definition of Vendor-Lock

So one thing I tooted this week was a question about

How do you define 'Vendor Lock'?


But I got no reply yet. The reason for this was that I argued with a friend whether using github-actions as a CI tool (exclusively) is vendor-lock. Because all you need to do is put a file into your repository and push that change to your master branch on github. Is that vendor lock already? Migrating away is nothing more than a git rm, actually!

In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.


By that definition, using github-actions is no vendor lock. I agree, though, that using github-actions for CI easily opens the door to using more features of github(-actions) and that results in vendor lock pretty easily.
That's why I disabled issues and pull requests in the repository in question (pull requests via a github-action – yes I see the irony in that – that closes each PR immediately, because github does not offer a way to disable PRs).

Sensor stuff with Arduino

I started (german) fiddling around with an ESP8266 and am planning to build a sensor kit (several actually) that I can use to track temperature, humidity and other things in my rooms, pushing the data to prometheus/grafana via MQTT.

For that I needed to learn what a MOSFET is (toot, german) and thought about (german) buying a Raspberry Pi 4 with 8 GB of RAM, to run prometheus/grafana, an MQTT server and possibly other stuff (german) on it.

This will be an interesting journey for me, because I am known to be a software-person only, not so much a hardware-person. I will most certainly write a dedicated blog post about my experiences!


I also had some thoughts on keyoxide, after I learned about what it is. I did initially not get what it is good for, what problem it solves. Luckily, I know intelligent people that can explain it.

I'm still not convinced that this actually would give me any value. I'm not on keybase for the same reason: I don't see why I would need this or what problem it would solve for me.

Feel free to ping me (on mastodon) with your comments on that.


A constant source of pain and happyness is email related stuff.

But where dark is is also light. For example, the himalaya project aims to write a CLI email client (my toot), doing what I was too lazy to do.

I really hope someone (maybe the himalaya) project will take off with their email client. I am a long-term mutt user, but I wouldn't decline experimenting with something else, as long as it has support for notmuch as a backend, and himalaya has an open issue for that. I know about aerc though I didn't like it too much when I tried it – maybe because it expects you to stay inside the email client while working with your git repositories, which is not that Unixy, in my opinion. I might be mistaken by this, though.

git workflows

My biggest source of pain right now is git workflows. People have weird opinions on some things, for example that squash merges are okay.

Or that rewriting commit messages is actually a good idea. And by that I do not mean rebasing a public branch, but rather rewriting the commit message of a patch before applying it. That's one of these rage-quit WTF moments actually.

I also think that bots should (in general) not write commit messages.