Cyber Security, Flaticon, GS1, SSH/HTTPS, Btrfs

1. Cyber security pre-war reality check (@ berthub.eu) - That's what I've said se well. If services "barely work" and often have downtime, those are really brittle. It's unlikely that those can withstand any kind of purposeful attacks, when the basic operation is already so so.

2. Flaticon's - I somehow had completely missed this amazing library. Lots of great icons, just what I needed for one web project.

3. Reminded myself again about GS1 (@ Wikipedia) EAN-128 and Data Matrix and "Blue Print Initiative" & "Sunrise 2027". Yet as expected, I didn't find out anything new about the topic, because I already master it. - As example: A21 - Batch Lot - Serial - For simple external article information lookups.

4. Standards for Agentic AI API, allowing easy AI operations... Lots of tinkering with AI related scripting, automation, local hosting, etc. This field is progressing fast.

5. Git Gitea Auth issues bad documentation and recommendations and examples. Amount of lost time and effort, because key information is missing or wrong. Well, this is way common with software. User hostile, it works, if you'll do is exactly correct... But many of the recommendations and suggestions are just wrong and brittle.

6. Why can't git use SSH keys over HTTPS... When you think about it more carefully, there would be so many ways to make this work much smarter and more efficiently. That's true, but it's also incorrectly documented in Gitea. These problems stem from the system telling you to use certain values and settings, but then they're wrong. Of course, one can always debate whether it's actually an error or not... - An eternal discussion in the software industry. The translation maintains the slightly frustrated tone of the original text while discussing Git's authentication limitations. The speaker appears to be lamenting how Git handles authentication methods, specifically that SSH keys can't be used over HTTPS connections, and noting documentation inconsistencies in Gitea.

7. It's like an obstacle course mentality. 20 things in the documentation where 5 are wrong and 8 are completely missing. But when everything is right, it works. If you had read the source and gone through the entire use case, you'd know it works exactly as intended, you just don't know how it's supposed to work.

8. Sometimes I've actually thought that there shouldn't be any documentation at all. Because it's so common and happens easily that the documentation conflicts with reality when nobody bothers to maintain it. And then just causes more confusion that there would be without the documentation. Horrible, isn't it?

9. And one good question is why can't the authentication keys already be included in the user-specific repository URL? Hmm, it doesn't seem like it should be technically too difficult. This question is asking why authentication credentials can't be directly embedded in repository URLs for individual users, suggesting that it shouldn't be technically challenging to implement such a feature.

10. But of course it has its own 'level of performance' in that it's so over-engineered and poorly made that it doesn't even work, even though it would have been super simple to make a solution that definitely works and is easy... - Classic.

11. Tested Python Tabulate library, for markdown tables. Actually quite nice. But it also generates other nice human readable tables as well. I've utilized it now for some logs as example, where the output was earlier "bit more technical", because it's there only for debug reasons. But if reading experience can be easily improved, why not?

12. Btrfs - Most curious case, is this flaw or not. Can't really tell. - I've got lots of scattered data in dirty write buffers to disk, due to scattered writes and high system memory. I've also got long commit interval to allow efficient flushing (as contiguous as possible) when that scattered data is finally written to disk. It all works fine, if I sync before shutdown. But if I just shutdown the system, the flush process takes longer than the maximum allowed file system unmount time is. Even worse, some of the data is written to SSD and some to HDD (SMR, very slow flush!) having two different file systems working together to maintaining full state. I often use that design. The state data is on SSD and actual data is on HDD. When the flush timeout is encountered, the system shuts down in state where state file says that this data is written to disk, and the data actually isn't on disk yet. - Flaw or not? - Of course this requires this curious combination of things to trigger, but the problem is very real.

2025-11-23