Diary

Previous: 2026-10, 2026-09

2026-11-14

Trying to write my own library to work with files I suddenly realized that using the same API for text and binary files is a mistake. Initially it was Windows, or even MS-DOS who poisoned my neural network with b option, and later on this damage was finally cemented by Python.

The truth is no one (except true hackers who mainly generate technical debt) write text in the middle of file. Text files are either read sequentially, line by line, or written sequentially in pure append mode. seek does not make sense. The number of bytes written does not make sense. How am I supposed to handle that? Write operation either succeeds or fails. What can be simpler?

So I'm adding TextFile type and TextReader and TextWriter interfaces. Actually, TextFile can be a mixin for anything that uses file descriptor. This could be Socket, for example.

Hm, TextSocket could be perfect for HTTP/1 client.

No, this can't be a mixin because it must extends read, write, seek, and possibly other methods to synchronize binary reader/writer state with text reader/writer.

♡♡♡

Each time I look at Zig it scares me with allocator argument. I haven't grown up yet for such kind of things.

This morning I read yet another post how defer is better than goto. Either the author is the same or AI model is the same.

Well, I'm okay with goto. I rarely use it, I prefer short functions, early returns, and gnu::cleanup attribute.

All the rest... well, with my own C library I don't need Zig.

Yet.

♡♡♡

Damn, I need to finish a closet for my equipment. XMPP and web can wait, but when the backup server is down it's a little bit frightening.

2026-11-11

Watching this thread https://lobste.rs/s/odnnzh/searching_for_pedagogical_materials_on and don't see much information people could share on memory models. This looks like a sacred knowledge worth studying. Because of high connitive load this studying is never ending.

Another link caught my attention https://fingerprinting.study

And https://lobste.rs/s/nld6x3/what_are_some_no_ai_apps_companies which includes https://codeberg.org/ethical-foss/ai-free-foss-alternatives I mentioned on 2026-10-28. What I think is luddits is a wrong term for anti-AI people if we stick to open source principles. It's same if windows users called linux or *BSD users luddits simply because they refuse using proprietary things and try writing/maintaining the whole OS by themselves.

But using proprietary AI agents for open source projects is totally wrong. If you're so proud AI vibecoder, well, reveal your skills, create an open source model, train it, and then okay, use it! I have nothing against.

Otherwise, you're look just like a stupid user to me. Very likely more clever than me, but still stupid.

Just stupid thoughts.

♡♡♡

Put almost all my home network infrastructure down. No XMPP, no web site, nothing is available.

Need to move all these noisy spinning things to a proper location but I don't know yet where exactly. They could not work outside anymore because it's getting really cold.

♡♡♡

It's funny, but the best info on HDMI I dug from linux docs:

2026-11-08

Added rate limiting for a legacy website from past life. Surprisingly, Nginx started to log IP addresses that hit that limit. They are all bots, so I wrote a script in Python to add them to a netfilter-based blocklist.

I promised myself not to write anything in Python, but given that the web site is entirely in Python, that's a sensible excuse.

Well, I must write something on a real python I have to feed with mice and hamsters. That's a challenge. I'll try that, I promise myself.

♡♡♡

'You should try the modern tech! Let me buy you an AI subscription', my daughter told me yesterday.

'Fuck NO!', I said, 'I need to keep my brain working. What you're suggesting is like if you'd say let me buy you Windows, how long you fucking retard are going tinkering with that stupid Linux?!'

But then I realized they all, together with their Linus, are already subscribed to that fucking Windows.

Well, let leave all those old men alone. In ten years, if not already, I'll catch them up and my neural network will probably need all that assistive tech too.

New generation, that's who is frightening me. Yes, you can heavily drink and smoke in 20s and 30s without noticeable harm, but later you have to be more careful. Same with AI.

NetBSD, they look nice. Probably they even really are. Although, I don't trust them, but I must try it.

♡♡♡

All soundbars is shit.

Total shit.

HDMI, the most widespread standard is a proprietary shitty thing.

Where all those sound cards with eARC HDMI inputs like all those soundbars have?

Chinese don't even offer no single eARC module, although I've quickly found a few relevant ICs from Analog Devices and other manufacturers. However, their datasheets aren't openly available.

Okay, I started from a cheapest $7 eARC-S/PDIF converter. Just ordered. Just to see what's inside. If it's really eARC of course. Will see when it arrives.

♡♡♡

The mind grips on the past, chasing things I no longer need. Experience is good, but many, many things need my kiss goodbye.

2026-11-03

A good written history that's here to teach https://tomasp.net/longreads/closing/

Most software we use today is black-box and cannot be easily modified by its users. This article follows the history of information hiding from OS/360 to Free Software and the history of the Web and documents how software becomes opaque through well-intended engineering decisions

And what it teaches me, in particular?

Nothing, as usual.

But as a reading, it is good.

♡♡♡

It's been a long time since I dealt with iconv. So long that I don't even remember how I handled errors. Okay, I open man page and see the following three cases (out of five) where conversion stops because of invalid or unconvertible input:

  1. An invalid multibyte sequence is encountered in the input. In this case it sets errno to EILSEQ and returns (size_t)(−1). *inbuf is left pointing to the beginning of the invalid multibyte sequence.

  2. A multibyte sequence is encountered that is valid but that cannot be translated to the character encoding of the output. This condition depends on the implementation and on the conversion descriptor. In the GNU C library and GNU libiconv, if cd was created without the suffix //TRANSLIT or //IGNORE or //NON_IDENTICAL_DISCARD, the conversion is strict: lossy conversions produce this condition. If the suffix //TRANSLIT was specified, transliteration can avoid this condition in some cases. In the musl C library, this condition cannot occur because a conversion to '*' is used as a fallback. In the FreeBSD, NetBSD, and Solaris implementations of iconv, this condition cannot occur either, because a conversion to '?' is used as a fallback. When this condition is met, the iconv function sets errno to EILSEQ and returns (size_t)(−1). *inbuf is left pointing to the beginning of the unconvertible multibyte sequence.

  3. An incomplete multibyte sequence is encountered in the input, and the input byte sequence terminates after it. In this case it sets errno to EINVAL and returns (size_t)(−1). *inbuf is left pointing to the beginning of the incomplete multibyte sequence.

The third case more or less clear: get more bytes and call again to continue. But the first twos... well, they both set errno to EILSEQ, they both return (size_t) -1, and they both leave *inbuf pointing to the beginning of multibute sequence, either invalid or unconvertible.

Someone tell me how the fuck I distinguish these two cases? Invalid from unconvertible? How do I handle unconvertible case by myself? How???

Okay, as I see in the most mentioned implementations this unconvertible condition cannot occur. But GNU.

This is a part of POSIX:2024. If they write such standards then I do not look this stupid to myself. This reconciles me with the world, a little, but I'm still feeling sad.

I need to waste some time to check the behavior on all those musl and FreeBSDs which I don't have at hand at the moment.

I am also curious whether and how iconv validates UTF-8 input. Do all those implementations use the same '?' and '*' fallback characters if I convert wrong UTF-8 to UTF-32? Not U+FFFD? How do they handle surrogate pairs?

Too many questions not covered on the man page and a lot of TODOs:

2026-11-01

It was a big temptation to use printf-style formatting, but there's a better one. I don't know where exactly it originates from, but it was (and probably still is) used in Python and allows referencing same argument multiple times.

I don't want any mini-language, so let it be simple: mandatory argument index (1-based) surrounded by curly brackets.

Any custom formatting must be done before calling pw_format function.

Wait, pw_format?

It just concatenates args. It must be something like... pw_argscat? No, it looks like scat.

Let it be pw_acat. It's more like in PetWay.