EU-Alert, LMDB+MDBX, Data Residency, ROA+RPKI, TLP, Croc   

1. EU-Alert (@ Wikipedia) - Finland doesn't use EU alert. We've got 112 Suomi (@ 112.fi) app instead. Main difference here is that the EU-Alert uses Short Message Service-Cell Broadcast technology (SMS-CB) as defined by European Telecommunications Standards Institute (ETSI) standards which allows regional mass delivery of alerts. But Finland uses application with mobile platforms PUSH features, combining it with database of users locations and in case alerts need to be delivered, those are sent to the geo-fenced region of users. I guess this technology has been selected because many alerts are regional and we don't have such high population. Even in the worst case, of sending nation wide alert, it probably would be a few million push messages. This solution wouldn't work in mega cities immediately notifying everyone, like Japans quake alerts. Studied: emergency alert system, mobile networks, push notifications, public warning system, air raid warning, digital notification systems

2. More testing of LMDB (@ Wikipedia) with Python and how it behaves with Btrfs. Now I feel better that I really could use it when necessary, compared to the older options. Like using key_value SQLite3 table, using mdb.sqlite3 dictionary and or just reading JSON file to Python dictionary processing data and dumping it back to disk (with temp file, fsync and replace) to store state in transactional / crash safe way. Also tested MDBX, because it offers some advanced features, like truncating the database aka auto-shrink, which is generally nice, but not mandatory. But what was the most interesting part for me was the "better error handling". Because database which gets effed up in production, isn't worth of "it is faster" yeah, but it's so fast, it doesn't work at all. Thank you for that! - In reality, SQLite3 just works, and it's very reliable. It's also nice that the GitHub issues mentioned using raw device for the database. I've been often wondering why that's not being used more often. If I've got device which is only for the database, why would I have several layers of overhead there, when I could just directly address the block device or partition on the device. Database is something that should be perfectly suited for that. As example Btrfs copy of write just adds crazy amount of overhead to the LMDBs CoW process. CoW on CoW. Yeah, of course it should be disabled, but in many cases it isn't. As example many programs use SQLite3 with copy on write on Btrfs, which is well, quite horrible IO operation booster. - Also reminded me about LevelDB as well. Yet that's almost well, complete opposite. Good for heavy write stuff.

3. Tired of political discussions. Are "US services" with "EU data residency" European or American services? These endless, tiring political discussions. I'm sick and tired of this. RTFM: "Just because data physically resides in the EU doesn't change the fact that the service provider remains a US-based company potentially subject to US laws and jurisdictions." kw: Data localization (@ Wikipedia), Data sovereignty (@ Wikipedia)

4. More than half of IPv4 & IPv6 routes are now protected using Route Origin Authorizations (ROAs) and Resource Public Key Infrastructure (RPKI) (@ Wikipedia). Which is nice. It makes legendary routing mishaps less likely.

5. It's nice to see that Discord (@ Wikipedia) figured out the benefits of WebP and AVIF. I've seen even new projects opting for the best available image formats, ie PNG, JPEG and GIF. Which are all stone age formats. Ok, PNG is newest of those. But JPEG and GIF should be 100% out, over a decade ago. - I often hear all kind of reasoning why those are the most advanced formats. Yet we should be moving to JPEG XL (@ Wikipedia) soon.

6. Long discussion if Traffic Light Protocol (TLP) (@ Wikipedia) should be used internally ref: [Red, Amber, Green, Clear] - Currently using EU style classifications, where levels are secret, confidential, restricted, internal and public.

7. Croc which is awesome in general, still got broken remote host connectivity setup and requires separate step to check the IPs. That's not a real problem, unless users are noobs. Yet it's still minor annoyance that it doesn't support DNS and requires raw IP addresses. I just tested with operating system DNS and even internal-dns resolver, in both cases it says that localhost not found. - GGF - I'm pretty sure I'm not the only one whom encountered that "problem". You can fix this by running local relay, but oh why is that necessary. To me this very much seems like an intentionally created artificial limitation.

2025-10-05