IPv6, Web NFC, XMPP, UTF-8, DM-SMR, GS1, JSON, H3, Firefox

1. IPv6 link local addresses (@ APNIC ) - Well, there's nothing new about IPv6 link local address scope zone identifiers / index. Also see RFC 6874 (@ tools.ietf.org ). I've also posted that it would be wonderful if hosts file would support zone identifiers. So it would be possible to configure server fe80::1234%eth0 or something similar.

2. Web NFC - Wow, that's interesting. It can allow many things. What kind of security problems it will create, remains to be seen. Encrypted and or signed payload using NDEF, etc. Includes blocklist and permission controls. kw: WebAPI / WebNFC (@ Mozilla Wiki )

3. XMPP Myths (@ xmpp.org ) - Funny arguments. Really. Phew.

4. UTF-8 everywhere (@ utf8everywhere.org ) - - This is something which I really like. I'm so sick'n'tired of different annoying character encoding problems.

5. Western Digital (WD) and Seagate are caught selling drives using DM-SMR (@ Wikipedia ) technology without telling about it to the customers. Why they wouldn't tell it? Afaik, this is borderline scam. Sure, for most of users it doesn't matter, but there's always the group whom require persistent and constant write performance. Of course it's quite sensible to assume that the systems are using SSD and the HDD is just there for media / archive storage. But you can't be sure about that. In my case, it wouldn't basically make any difference, even if all of my drives (at home work with workstations) would be using SMR technology. All random access and most of writes are handled by the SSD. Only data being archived or persistently is stored to the HDD drives. And that data might not be ever mostly updated and not even read monthly. - But if I use the HDD to restore something like a backup data sets, then suddenly there's high persistent write load which can persist for days for large backup restores. In that case especially if it's critical recovery it would be very annoying to suddenly find out that the drive performance tanks. Ok, if it would be real emergency I probably would restore the data to high capacity SSD server. But If it's not that bad, then I'll prefer on-premise systems.

6. Again, people are talking about GS1-128 (EAN-128) (@ Wikipedia ) and at the same time the format they're proposing, breaks all the GS1 standards in their book. It's good to remember that Code 128 (@ Wikipedia ) code isn't automatically GS1-128 code. I don't get it. I'm pretty sure some larger customer whom really checks the code, is going to reject the solution, because it doesn't follow mutually agreed standards. Yet, as said so many times. There are standards and then you can break the standards, in many cases it works just fine. Yet the standards people might whine, that it's wrong. FYI, EAN-128 isn't GTIN-13 / EAN-13 (@ Wikipedia ) just with extra numbers. And if requires GS1 (@ gs1.org ) does arrange consultation about this topic.

7. Postscript to the previous point. Who said JSON doesn't support full 8bit binary data? At least my implementation does. Fields which starts with ' are 8bit binary and \ is the escape for ending character if required. Example: '8-bit_data_here\'sample_escape' and that's it. Now JSON supports binary data it. Job done, it wasn't that hard, was it? It's not my fault, if you crappy solution doesn't support my extensions. ;) If you're so stuck with some lame parser, I can give you extension, which extends the Python standard json.dumps and loads with that support. No more base64 gunk. - I'm kidding, of course. How about calling the extension JSON+8b?

8. When I enable HTTP/3 (@ Wikipedia ) with Firefox ( settings: network.http.http3.enabled ) some sites start to fail loading. I guess that's the reason why it's disabled by default. Yet because I said only some sites stop working, which doesn't include all the sites supporting HTTP/3, which could mean that it's just compatibility issue with the specific server implementation the site is using.

9. Another Firefox problem. I used tabs and a web site to upload files. It seems that even if the upload is completed, and I've closed the tab. Firefox is still keeping the file handles open for the files that got uploaded. Sigh, so annoying. Well, restarting Firefox fixed the issue. Maybe there's some periodic clean-up of file handles or something, which would have closed the handles, even if those didn't get closed immediately. But why it isn't happening as soon as the upload is completed?

2021-04-18