When I read an old novel, written two centuries ago in England, the little differences to modern English are part of the charm, and I certainly don't want any Americanism mixed in. For one of my favorite novels, The Forsyte saga, the author deliberately used some rare forms of words, which SE replaced with the mainstream forms.

BTW, most Debian packages have reproducible builds. Those which have not (I'd say 5%) are shown in orange in the graph there: https://wiki.debian.org/ReproducibleBuilds

After reading "composer.json", I thought that the tests used a custom framework. I'm glad the project does not suffer from NIH syndrome, but the dev dependency on PHPUnit should be declared.

There should a warning that it's only meant for some Western Latin languages. The normalization of the input is built on a character table for a handful of cases. That's not enough for some Latin languages, e.g. Turkish. And any input with Cyrillic, Arabic, CJK and so on, will be ignored.

There is no Unicode normalization or cleanup. Real-life input have many corner cases, e.g. diacritics next to the characters, or invisible characters inside a word to prevent hyphenation. Unless I'm mistaken, this engine would treat the NFD form "fête" as "fe te", instead of the expected "fete", which the NFKD form "fête" produces. I suggest using ext-intl for Unicode normalization, at least as an option.

Lastly, I can't think of a use case for this library. I've always had access to some external service (MySQL, Postgresql, Manticore Search, Solr, etc.) or to a PHP extension for a local Sqlite with FTS. Even for hobby projects, I haven't deployed to a shared hosting for more than two decades.

I use Koreader: after experimenting with various configuration parameters for a few days, the UI is now stable and tailored to my taste. Once in a while, I switch to another app: Plato is better at handling huge PDF files.

Another bonus point is that I can mount my ereader as a USB mass-storage and rsync the git repository of my ebooks onto it.

That does not cover the whole usage: the hardware, the bots that collect learning data, the prompts, etc. And there are now many models of this size, and thousands and thousands at smaller sizes. And some of this parameters are increasing.

AI is estimated to emit more than 80e6 tons of CO2-equivalent this year. Much more than whole countries like Austria or Israel. Is that trivial?

1. The French government announces its digital agency is to write a plan, by the end of the year, so that France could reduce its extra-European dependencies. The communiqué is wrapped up with minor facts (e.g. the digital agency is to switch to Linux on dozens of computers) and big promises from Ministers.

2. Various news sites state that "France is ditching Windows", at least in their titles.

3. On new aggregators, most people react to the titles. Some do read the articles. Very few realize it's about promises to act toward a vague goal, with an unknown calendar, and many political uncertainties.

I would have hoped for more cautious reactions. It's not a leading act, not a reason to be proud, not a example to follow. It's just words.

The French government already made similar promises in the past. Sometimes, it did happen, like the Gendarmerie (rural police) switching to a Linux distribution. Sometimes, it didn't, like the pact signed by the Army Ministry with Microsoft in 2022: many clauses are still secret, even the prices.

The French government announced that its digital agency will switch to Linux during this year. This is about a few hundreds of computers owned by the agency.

The second statement is that this agency is expected to publish, by the end of the year, a plan to reduce the digital dependency on the US. It's not "France to ditch Windows", it should be "French government promises to plan soon for possible ways to decrease digital dependencies, but calendar unknown". Also note that the government (and president) will change next year, so even if the present drive was real, a political u-turn could come soon.

Overall, this statement could be the presage of a major upturn in a few years, but I think it far more probable that the policy change will be minor. There's already a small tendency toward Linux and Free Software in the public sector.

The nuclear share (red) is reducing during the 200Os. The wind and solar (light blue and yellow) went over the max nuclear share at the end of the period — it seems there is much more wind than sun in Germany ;-). The fossil fuels (dark colors below red) are still very high.

An open standard is even more very relevant in public administrations where the process follows legal constraints and ISO standards. The Document Foundation's article reacts to an German institutional decision.

As a programmer, finding decent ODF libraries is far from certain. Last year I had to output some spreadsheets from a Go program, but I could not find any maintained library for ODS, so I had to output XLSX files. Recently, I was luckier while programming in Rust.

With zsh, I prefer to use alt-q which does this automatically (store the current line, display a new prompt, then, after the new command is sent, restore the stored line). It can also stack the paused commands, e.g.:

$ cp foo/bar dest/

$ wcurl -o foo/bar "$URL"

$ mkdir foo

I knew that once a benchmark is famous, people start optimising for it or even gaming it, but I didn't realise how much it made the benchmarks meaningless. Some frameworks were just not production ready, or had shortcuts made just for a benchmark case. Some implementations were supposed to use a framework, but the code was skewed in an unrealistic way. And sometimes the algorithm was different (IIRC, some implementation converted the "multiple sql updates" requirements into a single complex update using CASE).

I would ignore the results for most cases, especially the emerging software, but at least the benchmarks suggested orders of magnitudes in a few cases. I.e. the speed of JSON serialization in different languages, or that PHP Laravel was more or less twice slower than PHP Symfony which could be twice slower than Rails.

Suppose a file contains a list of unique strings, one by line. A commit on a feature branch adds an element to the list. Later on, the branch is rebased on the main branch and pushed.

But the main branch had added the same element at another position in the list. Since there was a wide gap between the two positions, there was no conflict in Git's rebase. So the commit in the feature branch breaks the unicity constraint of the list.

For someone that pulled the feature branch, the commit seems stupid. But initial commit was fine, and the final (rebased) commit is a lie: nobody created a duplicate item.

I think some of the books on this list had very few readers, but were selected because of their relative fame among a list of 200 books. For instance, how many people have read the full "Gulag archipelago"? Or writings by Lacan or Barthes? Or the "Journal" by Jules Renard?

How is a list spanning over the last 40 centuries deserving of the tile "Books of the Century by Le Monde"? Why would the "Epic of Gilgamesh" or the "Book of Job" be on a list of 20th century books?

> ... it starts with one of my favorite.

From that same Wikipedia page: “The books selected by this process and listed here are not ranked or categorized in any way;”

The list is sorted by authors' name.

For instance, searching in recent FreeBSD issues, some hardware is compatible but 3× slower, as in "NFS is much too slow at 10GbaseT"[^1]. Or a FreeBSD upgrade to v14 could sink the NFS performance, as in "Write performance to NFS share is ~4x slower than on 13.2". Of course, these bugs happen with Linux, but there are vastly more resources to detect and fix these problems in the Linux world.

[^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277197

[^2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276299

> bzip might be suboptimal as a general-purpose compression format, but it’s great for text and code. One might even say the b in bzip stands for “best”.

I've just checked again with a 1GB SQL file. `bzip2 -9` shrinks it to 83MB. `zstd -19 --long` to 52MB.

Others have compressed the Linux kernel and found that bzip2's is about 15% larger than zstd's.

For instance, deploying a complex Python application was hell, for lack of proper packaging. Using Vagrant was easy, but the image was huge (full system) and the software slow (full virtualization), among other problems. Containers like LXC and Docker were a bit easier to setup, much smaller, almost as performant as native packaging, and with a larger spectrum of features for sharing things with the host (e.g. overlay mounts).