Feuerfest

For a few months now, I've been regularly coming back to this point where I ask myself whether I want to continue using Bludit. The latest version dates from August 2024, and there are issues with IT security-related bugs open and unresolved on GitHub.

Sure, Bludit is open source. Anyone can fork it. But Jürgen Greuter (alias: Tante) wrote back in 2013: "Host your own is cynical". In this text, he discusses why not everyone can set up and operate software "just like that" when a service is discontinued or its business model changes fundamentally.

And in this sense, I would like to note: "Fork your own is cynical"

I want to blog. I want to write down and publish my thoughts. I don't want to programme PHP or deal with problems in dozens of different browser versions. In some cases, I would also have to acquire a lot of knowledge (again) first. And the time spent for maintaining the fork? No, thank you.

I just want to be a user. Period.

And well, as can be read in the Bludit forum, the only developer (Diego) is not working on Bludit until further notice. There are apparently only minimal adjustments. Too bad. Also because security-related bugs are obviously not included.

But just as I simply want to be a user, I can understand that Diego also has a life and needs to pay his bills.

So I did a little research and came across the blogging software Kirby. Also a FlatFile CMS. You do have to buy a licence for Kirby, but at 99€ for three years, it's more than fair. And the source code is available on GitHub. So if I want to, I can dig through the code myself and see what's going on or whether there's already an issue for my problem.

What's more, the software has been on the market for over 10 years and is used by several well-known magazines and projects (e.g. OBS and Katapult Magazine). That also speaks for its reliability.

Well, I think I'll spend a weekend or so with the trial version and see how Kirby feels. The demo was nice, anyway, and didn't leave me wanting anything.

HomeOffice was big during the Covid-19 pandemic. And it still is. Especially in industries where the place of performance can differ from the company's headquarters without having to fear a loss of productivity.

Ironically, these sectors were subject to numerous "return to office" (RTO) initiatives from companies that had previously praised themselves for enabling all their employees to work from home full-time. Admittedly, many of these RTO strategies were actually disguised job cuts. As, for example, not everyone who moved out of high-cost of living (HCOL) areas can or is willing to move back.

Naturally "thought-leaders" and other people voice opinions on why work-from-home is bad. Despite science showing the opposite pretty obvious. But recently I encountered the first argument I can understand and support completely.

It is about the training of apprentices.

The trainer said: "Normally, we would send the apprentices to various teams for six months. This allows them to learn about networks, databases and system administration for Linux and/or Windows. Some teams had to be visited as part of the training; for others, the apprentice could choose according to their own preference and desired area of specialisation. Nowadays, however, we are having problems finding teams where enough people are present each day to actually train our trainees. Training remotely is possible (§ 28 (2) BBiG (Vocational Training Act) in German law allows remote training "to a reasonable extent", not 100%), but it isn't nearly as effective. This is especially the case since many people in IT choose to isolate themselves and don't communicate proactively enough. Hence, opportunities are lost. For example, there are fewer opportunities to provide ad hoc support for complex maintenance work on failed mission-critical systems. If you are in the office, you can recognise these situations even without access rights to monitoring and can ask to sit nearby and observe or support. But remotely? Not always."

For me, this is the first genuinely compelling argument against working from home full-time.

A microwave can definitely be useful in the kitchen. I don't doubt that. Even if it does nothing more than an oven, it does it faster. However, you can't prepare all dishes with a microwave. For those, you still need an oven. I don't currently own a microwave and gave mine away years ago. I realised that the microwave was causing me to develop unhealthy eating habits. That's why I started cooking. My sister once gave me a wok pan for my birthday. It's by far my favourite kitchen appliance since.

Huh? You don't know what I'm talking about?

Then feel free to read this wonderful analogy written by Colin Cornaby:

In the Future All Food Will Be Cooked in a Microwave, and if You Can’t Deal With That Then You Need to Get Out of the Kitchen

Via Mastodon I learned that there is a monospaced version of the one font we all love: Comic Sans.

It's called Comic Mono, is available on GitHub: https://dtinth.github.io/comic-mono-font/ and does look somewhat good. 😆

Have fun!

"Bye Bye" is a loose series of articles in which I explain why I no longer use the aforementioned provider and its services.

mthie wrote a short blog post in which he linked to the following XDA Developers article: https://www.xda-developers.com/brave-most-overrated-browser-dont-recommend/.

For me, personally, this article was a real eye-opener. I only knew about roughly half of the things that Brave has done over the years. I was especially unaware of the "Accepting donations for creators - who don't know anything about the Brave program" or the Honey-like "Let's replace referral codes in links and cookies with our own to steal the commission".

If a company pulls such stunts, it is not acting in good faith. Not acting in good faith makes you a bad actor.

Do you really want to use software from a bad actor? Yet alone have it installed on your mobile? It's the most private piece of technical equipment we own in these days.

Yeah, me neither. Hence Brave has been officially uninstalled from all my devices as of 20 minutes ago.

And I doubt I will miss it much, as Firefox on Android officially supports all extensions since end of 2023/beginning of 2024. Therefore extensions like uBlock Origin and uMatrix work perfectly fine. The fact that those were not supported back then was the main reason for choosing Brave in the first place.

Now with this reason being gone, so too is the crypto- and scam-infested Brave browser.

The following log message would only sporadically be logged on my Pi-hole. Not every hour, and not even every day. Just... sometimes. When the stars aligned... When, 52 years ago, Monday fell on a full moon and a 12th-generation carpenter was born... You get the idea.  😄

The error message was:

"No valid NTP replies received, check server and network connectivity"

Strange. NTP works. Despite Pi-hole sometimes fancy otherwise.

Inspecting the Pi-hole configuration

pihole-FTL returned the following NTP configuration:

user@host:~$ pihole-FTL --config ntp
ntp.ipv4.active = true
ntp.ipv4.address =
ntp.ipv6.active = true
ntp.ipv6.address =
ntp.sync.active = true
ntp.sync.server = 1.de.pool.ntp.org
ntp.sync.interval = 3600
ntp.sync.count = 8
ntp.sync.rtc.set = false
ntp.sync.rtc.device =
ntp.sync.rtc.utc = true

That looked good to me.

It was here that I had my suspicions: Wait, does the NTP Pool Project already offer IPv6? I have never knowingly used public NTP pools with IPv6. In customer networks, NTP servers are usually only reachable via IPv4. I don't have an NTP server in my home network. Sadly, many services are still not IPv6 ready.

Some companies even remove IPv6 support, like DigiCert (a commercial certificate authority!), who removed IPv6 support when they switched to a new CDN provider. This left me speechless. Read https://knowledge.digicert.com/alerts/digicert-certificate-status-ip-address if you want to know more.

NTP & IPv6? Only with pools that start with a 2

A short search for IPv6 support in NTP-Pools and https://www.ntppool.org/en/use.html provided the answer:

Please also note that the system currently only provides IPv6 addresses for a zone in addition to IPv4 addresses if the zone name is prefixed by the number 2, e.g. 2.pool.ntp.org (provided there are any IPv6 NTP servers in the respective zone). Zone names not prefixed by a number, or prefixed with any of 0, 1 or 3, currently provide IPv4 addresses only.

It turns out that the problem lies in my dual-stack setup, since I use IPv4 and IPv6 in parallel. Or rather... It's with the NTP pools. I checked with dig to see if any AAAA records were returned for 1.de.pool.ntp.org. The pool I was using.

dig aaaa 1.de.pool.ntp.org returns no AAAA-Records.

user@host:~$ dig aaaa 1.de.pool.ntp.org

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> aaaa 1.de.pool.ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43230
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
;; QUESTION SECTION:
;1.de.pool.ntp.org.             IN      AAAA

;; AUTHORITY SECTION:
pool.ntp.org.           0       IN      SOA     d.ntpns.org. hostmaster.pool.ntp.org. 1749216969 5400 5400 1209600 3600

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Jun 06 16:10:31 CEST 2025
;; MSG SIZE  rcvd: 134

And surely enough a dig aaaa 2.de.pool.ntp.org returns AAAA-Records.

user@host:~$ dig aaaa 2.de.pool.ntp.org

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> aaaa 2.de.pool.ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47906
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;2.de.pool.ntp.org.             IN      AAAA

;; ANSWER SECTION:
2.de.pool.ntp.org.      130     IN      AAAA    2a0f:85c1:b73:62:123:123:123:123
2.de.pool.ntp.org.      130     IN      AAAA    2a01:239:2a6:d500::1
2.de.pool.ntp.org.      130     IN      AAAA    2606:4700:f1::1
2.de.pool.ntp.org.      130     IN      AAAA    2a01:4f8:141:282::5:1

;; Query time: 656 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Jun 06 16:33:32 CEST 2025
;; MSG SIZE  rcvd: 158

My new Pi-hole configuration

The fix was easy, just configure 2.de.pool.ntp.org instead of 1.de.pool.ntp.org. Done.

user@host:~$ pihole-FTL --config ntp
ntp.ipv4.active = true
ntp.ipv4.address =
ntp.ipv6.active = true
ntp.ipv6.address =
ntp.sync.active = true
ntp.sync.server = 2.de.pool.ntp.org
ntp.sync.interval = 3600
ntp.sync.count = 8
ntp.sync.rtc.set = false
ntp.sync.rtc.device =
ntp.sync.rtc.utc = true

Now my Pi-hole instances aren't running long enough to really verify that the error is gone but I suspect so.

Some weeks later: The error is gone. It didn't re-appear.