Thoughts #1
“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'?
(toot)
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!
Keyoxide
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.