Category: Programmer’s digest

The pinnacle of enshittification, or Large Language Models

Honestly, I hate that I read about LLMs all the time. I hate all the marketing bullshit, but also all the critical pieces. Not because the criticism is wrong. I hate them precisely because they’re right. And I hate the feeling that I have to write yet another piece on that same topic, to collect some of the thoughts I have had over the recent months.

Machine learning isn’t anything new. Neither is calling it “artificial intelligence”. Not only pop science writers and journalists, but even more technical folk have been using the term, and I never complained. I didn’t complain about games having “AI” either. It was always clear that this is a special use of “intelligence”, one far from what animals truly possess. This changed recently.

When LLMs enabled chatbots to use human language, the misuse of the term exploded. Obviously, the marketing people loved calling it “artificial intelligence”. The media, the users and the whole IT industry followed. Even people who knew better stopped bothering. On top of that, anthropomorphisms became commonplace. LLMs could be said to be “thinking”, “lying”, “hallucinating”, to “approve” or “disapprove”, “like” or “dislike”…

Perhaps it wouldn’t be so bad if not for the fact that LLMs are so good at imitating human intelligence. The problem is not really how people call them. The problem is that there is a number of people who start actually believing that their chatbots are conscious. And I can see why that would be happening…
Continue reading “The pinnacle of enshittification, or Large Language Models”

Money isn’t going to solve the burnout problem

The xz-utils backdoor situation brought the problem of FLOSS maintained burnout into the daylight. This in turn lead to numerous discussion on how to solve the problem, and the recurring theme was funding maintenance work.

While I’m definitely not opposed to giving people money for their FLOSS work, if you think that throwing some bucks will actually solve the problem, and especially if you think that you can just throw them once and then forget, I have bad news for you: it won’t. Surely, money is a big part of the problem, but it’s not the only reason people are getting burned out. It’s a systemic problem, and it’s in need of systemic solution, and that’s involves a lot of hard work to undo everything that’s happened in the last, say, 20 years.

But let’s start at the beginning and ask the important question: why do people make free software?

Continue reading “Money isn’t going to solve the burnout problem”

Poetry(-core), or the ultimate footgun

I’ve been complaining about the Poetry project a lot, in particular about its use (or more precisely, the use of poetry-core) as a build system. In fact, it pretty much became a synonym of a footgun for me — and whenever I’m about to package some project using poetry-core, or switching to it, I’ve learned to expect some predictable mistake. I suppose the time has come to note all these pitfalls in a single blog post.

Continue reading “Poetry(-core), or the ultimate footgun”

Testing the safe time64 transition path

Recently I’ve been elaborating on the perils of transition to 64-bit time_t, following the debate within Gentoo. Within these deliberations, I have also envisioned potential solutions to ensure that production systems could be migrated safely.

My initial ideas involved treating time64 as a completely new ABI, with a new libdir and forced incompatibility between binaries. This ambitious plan faced two disadvantages. Firstly, it required major modification to various toolchains, and secondly, it raised compatibility concerns between Gentoo (and other distributions that followed this plan) and distributions that switched before or were going to switch without making similar changes. Effectively, it would not only require a lot of effort from us, but also a lot of convincing other people, many of whom probably don’t want to spend any more time on doing extra work for 32-bit architectures. This made me consider alternative ideas.

One of them was to limit the changes to the transition period — use a libt32 temporary library directory to prevent existing programs from breaking while rebuilds were performed, and then simply remove them, and be left with plain lib like other distributions that switched already. In this post, I’d like to elaborate how I went about testing the feasibility of this solution. Please note that this is not a migration guide — it includes steps that are meant to detect problems with the approach, and are not suitable for production systems.
Continue reading “Testing the safe time64 transition path”

The perils of transition to 64-bit time_t

(please note that there’s a correction at the bottom)

In the Overview of cross-architecture portability problems, I have dedicated a section to the problems resulting from use of 32-bit time_t type. This design decision, still affecting Gentoo systems using glibc, means that 32-bit applications will suddenly start failing in horrible ways in 2038: they will be getting -1 error instead of the current time, they won’t be able to stat() files. In one word: complete mayhem will emerge.

There is a general agreement that the way forward is to change time_t to a 64-bit type. Musl has already switched to that, glibc supports it as an option. A number of other distributions such as Debian have taken the leap and switched. Unfortunately, source-based distributions such as Gentoo don’t have it that easy. So we are still debating the issue and experimenting, trying to figure out a maximally safe upgrade path for our users.

Unfortunately, that’s nowhere near trivial. Above all, we are talking about a breaking ABI change. It’s all-or-nothing. If a library uses time_t in its API, everything linking to it needs to use the same type width. In this post, I’d like to explore the issue in detail — why is it so bad, and what we can do to make it safer.
Continue reading “The perils of transition to 64-bit time_t”