idoubtit

Couldn't LE have a branch in Europe or anywhere outside the USA and its minions?

Because they're betraying their own goals, as stated in their About page: “It is a service run for the public’s benefit. [...] Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost. [...] Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.” Now they own they are under the control of a political organization.

Here is the paragraph Let's Encrypt added to their Subscription Agreement on 2026-06-04:

> You are not a person or entity that is:

> (a) located in, organized under the laws of, or ordinarily resident in any country or territory that is the target of comprehensive U.S. sanctions;

> (b) a prohibited or restricted party under U.S. or other applicable sanctions and export control laws and regulations;

> or (c) owned or controlled by or acting on behalf of anyone described in (a) or (b).

> You agree to use Let’s Encrypt Certificates and any services provided by or on behalf of ISRG in compliance with applicable U.S. export control and sanctions laws and regulations.

The problem with this article is that the benchmark method they use is flawed. The documentation of zshbench explains why: https://github.com/romkatv/zsh-bench

Even with a low grade laptop, my zsh config grants me a sub 5ms prompt and a sub 1ms input lag, and that's far more important than the exit time.

     ./zsh-bench
    ==> benchmarking login shell of user XYZ ...
    creates_tty=0
    has_compsys=1
    has_syntax_highlighting=0
    has_autosuggestions=0
    has_git_prompt=1
    first_prompt_lag_ms=54.942
    first_command_lag_ms=57.069
    command_lag_ms=4.275
    input_lag_ms=0.669
    exit_time_ms=26.522

     hyperfine --warmup 3 'zsh -i -c exit'
    Benchmark 1: zsh -i -c exit
      Time (mean ± σ):      26.5 ms ±   0.5 ms
      Range (min … max):    25.5 ms …  27.6 ms

Not too bad? A hidden procedure with ten clicks, which the user has to repeat for each web browser. And it may break at any time if the browser changes some details. Or if KDE changes. And it's specific to KDE, with no alternatives in most Wayland WMs.

All that for _one_ feature which works out-of-the-box with Xorg, and which Wayland removed for security reasons. From what I've seen, sharing the screen is another common feature which was broken with Wayland and is still painful.

I don't think Wayland's security model is very relevant to me since I have faith in Debian for filtering out rogue applications. So I have to reason to drop my smooth UX for a world of "not too bad" workarounds.

No, more like:

    git rebase -i
    # squash all the commits (e.g. in vim with ctrl-v)
    git reset HEAD^
    git add -p
    # interactively pickup the RED hunks
    git ci -m RED

The main difference to jj is that the RED commit is created later with git.

There's one problem with arrays that I haven't seen mentioned here or by the OP: when inserting a key-value, the type of the key may change. For instance ["4" => "four"] === [4 => "Four"]

This can lead to some unexpected behaviors. For example, I've already been bitten by `array_merge()` whose result is different if its parameters are arrays with numeric indexes.

    array_merge(["4 " => "four"], ["5 " => "five"])
    // ["4 " => "four", "5 " => "five"]

    array_merge(["4" => "four"], ["5" => "five"])
    // [0 => "four", 1 => "five"]

You can do that. Of course, PHP's native types are quite limited, but a phpdoc syntax should work with static analysis tools. For instance:

    /** @psalm-type MyobjType = object{mystring: string} */

    /**
     * @param MyobjType $myobj
     */
    function (object $myobj): void

Here are some documentation and examples:

- For Psalm, see https://psalm.dev/docs/annotating_code/type_syntax/utility_t...

- For PHPstan, see https://phpstan.org/writing-php-code/phpdoc-types

It may work in your IDE (autocompletion, etc.) but there is no standard on this side. Some IDE have their own parsers, others use one of the LSPs for PHP.

What is the open standard?

As far as I know, the ISO standard for zip only specifies two compression methods: "store" (no compression) and "deflate". If I follow that, when I create a zip file, I know it's not performant, but at least it's almost universal (except for file ownership, permissions, character encoding and anything modern).

The corporate PKWARE has added other compressions to their original zip software, but those are not in the standard. They will not work for an EPUB, a LibreOffice file, etc. If I want a good compression, I reach for zstd (often through `tar`) or 7z if I want more portability.

I had no heard of ECT, but I'm not impressed. I've just benchmarked it against two others PNG optimizers, and here are the file sizes for default and max levels:

    1985457 oxipng-o6.png
    2030036 oxipng-o2.png
    2125459 ect-o9.png
    2144598 ect-o3.png
    2169351 optipng-o7.png
    2215086 optipng-o2.png
    2218326 original.png

    oxipng 9.1.5
    OptiPNG version 7.9.1
    Efficient Compression Tool Version 0.9.5

BTW, I could not compile ECT on my Linux system, because its CMake config was too old. I used the Windows release through Wine, but it shouldn't change the results above.

I tried to apply ECT to a few .gz files, but it complained it was not compatible, and I did not dig further.

[edited for a typo s/I/it/]

Not the GP, but I also have mixed feelings about Standard Ebooks. They modernise texts for American readers. This means changing the punctuation, merging some words, altering the syntax, etc.

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.

As pointed in your link, NetBSD achieved this with some help from Debian. If I understand correctly, it's not that NetBSD tried harder, it's that their problem was easier: fewer packages which change less (they still use CVS, "stability" is an understatement!).

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

I expected a toy project, but it is a usable library, which required a lot of work. Good job on delivering. A few comments:

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.

If you have trouble with the default software on a Kobo ereader, you can install other applications aside it, then switch to them after boot. In my experience, the installation process is innocuous and straightforward.

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.

The training of one LLM requires as much emissions as 17,000 people over a year. Which, according to the article, is 8 times more than last year, and may be underestimated by a factor 2.

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?

The chain of facts makes me sad:

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 title is very far from the actual public statement that is linked in the article.

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.

Here is an histogram of the energy mix 1990-2020 that illustrates your answer. https://en.wikipedia.org/wiki/File:Energymix_Germany.svg

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.

The media (web or desktop) is irrelevant: a file format must exists for backup and interoperability. I barely use office documents myself, but I work on software that produce and parse many spreadsheets every day.

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.

I hope that Germany mandating ODF over OOXML will enhance the whole ecosystem.

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.

You missed an easier alternative that was in the article: ctrl-u saves and clears the current line, then you can input new commands, then use ctrl-y to yank the saved command.

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/ <alt-q>

$ wcurl -o foo/bar "$URL" <alt-q>

$ mkdir foo <enter> <enter> <enter>

I've contributed a few optimisations to some implementations in these benchmarks, but as I read the code of many other implementations (and some frameworks) I lost most of the trust I had in these benchmarks.

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.

I'm not the GP, but I've seen "rebase lies" in the wild.

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.

The canonical website is https://pijul.org. The homepage has a link to the pijul source repository.

I agree, though the list contains "L'œuvre au noir", another wonderful novel by Marguerite Yourcenar.

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?

> I find this other list more deserving of this title

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.

All this would be true if Linux and FreeBSD had similar exposition. But there's obviously less users and less hardware in the BSD world, so we must expect a higher variance.

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

My experience does not match theirs when compressing text and code:

> 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.

Before cutting a service, OVH sends several warnings. In my opinion, the worrying point is not that OVH made a mistake, it's that important messages to the "infrastructure mailing list" of Pandas were ignored for weeks... until the post-mortem.

Vagrant was a layer over virtualization, with hypervisors like virtualbox, kvm or vmware. The article mention virtualization and virtual machines several times, e.g. "unlike the virtual machine experience (which involved installing an entire operating system)".

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).

Precise info about the PHP foundation is hard to find. They have an annual budget of ≈500k USD, half of it assigned to developers[^1]. From a 2024 presentation video, they claim that the foundation has a "language impact" of 43% on the PHP core, with 57% for "other developers" ; but the graph does not state the metric used[^2].

But I could not find an answer to the most obvious questions:

What did they do last year? There is no annual public report of their activity.

Do they pay developers to work on whatever they want on the PHP core? Or does the foundation have an internal roadmap and assign tasks to developers?

[^1]: https://opencollective.com/phpfoundation#category-BUDGET

[^2]: https://www.youtube.com/watch?v=XE4g1Tl6RQw at 06:45

I'm not the GP, but I do remember why I rejected Kitty when I tried several terminal emulators last years: it broke quite a few of my workflows.

For instance, in vim the F3 key was broken[^1]. It was very surprising and weird, and a portable workaround required some arcane vim configuration.

Another important pain point was that the font rendering was different in Kitty to any other app, and very dependent on the screen DPI. IIRC, for a DPI around 100, I had to switch to "legacy rendering" because the default rendering was barely readable.

I also remember issues with SSH. And Kitty crashed at least once. And I wasn't a fan of Kitty's mix of C and Python. After a week or two of usage, my Kitty config file was big, with an extra hundred lines of Python for the tabbar. Despite some nice features (like the shortcut to put the output of the last command into a file), I got uneasy with all this mess. I tried Ghostty, which was as good as Kitty with much less oddities.

[^1]: https://github.com/vim/vim/issues/13328