idoubtit

Not the Grand Poster, but we use the Debian package "unattended-upgrades" to install security updates automatically on our servers, and send an email if a reboot is required to complete the process (kernel upgrade).

Unattended upgrades could be configured to install more than the security release. Even with the stable release, one can add the official APT source for the Debian backports.

I wanted to find users that loved the same kinds of classical novels. The core of my list was each famous work of famous classical writers like Dostoievsky, Tolstoi, Huxley and Borges. I added a few excellent authors, still famous but to a lesser degree, like Italo Calvino or Marguerite Yourcenar. I know there are many readers of the whole list I wrote, I could name a few among my friends and family.

So I think the problem was not in the existence of similar readers, but in the way to reach them. Few people that read classical books log in Goodreads (I don't) and even fewer input what they've read over the past decades.

The "Intersect" page was useless for me. I added 15 books, but got no matching user. I entered a cycle of removing-searching, and at 10 books I had 2 users: one had read 41353 books, and the other 85363, with no ratings...

To be useful, the "Intersect" page should have:

- find near matches when there is no exact match with every book,

- ignore fake users (can any human read 80k books in many languages?),

- do not ignore users' votes (my input was books I liked, I expected to find users that rated them highly).

With the "Recommend" page I had the same problem as the GP, and all the recommendations were useless. To fix that, I think some features are needed:

- do not list books by authors from my list (I don't need recommendations for them),

- add a button for marking a suggested book as "disliked" (at the bare minimum, it should remove it from the suggestion, and ideally it should influence le suggestions as much as a "liked" book),

- do not suggest several books by the same author,

- add a button to hide a suggestion or show more suggestions (there were dozens of books I'd read but wouldn't rate high).

Is that really a good article? I thought it was average. It had some big flaws but was probably still informative for readers with no mathematical knowledge in the domain.

For instance, consider the only concrete example in the article: the space of all possible configurations of a double pendulum is a manifold. The author claims it's useful to see it in a manifold, but why? Precisely, why more as a manifold than as a square [O,2π[²?

I also expected more talk about atlases. In simple cases, it's easy to think of a surface as a deformation of a flat shape, so a natural idea is to think of having a map from the plan to the surface. But, even for a simple sphere, most surfaces can't map to a single flat part of the plan, and you need several maps. But how do you handle the parts where the maps overlap? What Riemmann did was defining properties on this relationship between manifold points and maps (which can be countless).

BTW, I know just enough about relativity to deny that "space-time [is] a four-dimensional manifold", at least a Riemmannian manifold. IIRC, the usual term is Minkowski-spacetime.

No, the situation about image compression has not changed. The Grand Poster you were replying to was writing about typical web usage, that is "medium-to-heavily compressed images", while your benchmark is about lossless compression.

BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393

I've read 3 out of those 5 books, and I see our preferences differ. For instance, I've a few books from Van Vogt, and I can't imagine I could like anything he wrote.

- "A voyage to Arcturus" tried hard at being strange and philosophical, but it seemed shallow and I did not feel interested.

- "The worm Ouroboros" was better, with a very unusual epic style, both in writing style and in the story. But some points made me cringe, e.g. the focus on nobles and the despise of common people, even heroic characters. Then it got repetitive, with a final trick that felt like a mockery of the whole story.

- "The dying Earth" was a good book, but it is far from my favorites. I prefer continuous novels to collections of short stories, even when they share a common setting. The book sometimes felt like a poetic tale, with nature and nostalgia as strong themes, though it was also quite brutal.

Since anonymous suggestions aren't very useful without any context, I'll match little-known books with famous books:

- If you thought that "1984" had good ideas, but also many stupid parts that spoiled the whole book, then try two older books. "We", by Zamiatin, is a bit old and naive but enjoyable. It was a source of inspiration for "Brave new world" and "1984". The Swede "Kollocain" (1940), by Karin Boye, is excellent, and much more subtle than the latter.

- If you like collections of related short stories, like "The dying Earth", then "The carpet makers" (1995) by Andreas Eschbach is a must. I remember the joy when I finally had a global understanding of the whole situation.

- If you wish for bizarre fantasy, not the epic Tolkien style, not even the dark saga of Ouroboros, but something more gothic and unsettling, then Mervyn Peake's "Titus groans" is perfect.

- I think "Brain twister" (1961) is the only funny book I've read in SF-Fantasy-supernatural.

That's not how I remember the event. The fact that "people still largely depended on edited, gatekept outlets for their reading and viewing" played no role, as far as I know. Newspapers wrote about the Sokal-Bricmont story, not because they were concerned as gatekeepers, but because it was a spectacular hoax. I was in academia at the time, and it was widely discussed.

The hoax intended to show two facts:

- Philosophy and social studies sometimes have an unsuitable fascination for science, with a tendency to wrongly apply scientific concepts they don't understand. Some impostors had perfect fame in their academic domain, despite writing this pseudo-scientific gibberish.

- Scientific journals were supposed to publish provable or reproducible articles, so when a flawed article went through the publishing process, there was hope the errors would be detected and other articles would fix it. And a publication in a top-tier journal would bring intense scrutiny. In philosophy and social science, nonsense could get published, widely accepted, and even studied.

BTW, I remember Jean Bricmont telling how much he liked good philosophy, and how he was pained when reading fraudulent philosophy.

When I compile LaTeX files, I use tectonic¹ which automatically download dependencies, compiles in one pass, and hides temporary files. But the regulars users of LaTeX I know all use a web interface — IIRC, it's an instance of Overleaf² installed by their university, with real-time rendering.

So when I read your list, I had these tools in mind, and the only items that made sense to me were:

2. (minor compared to Overleaf) typst compiles faster.

3. Diagnostics are better.

4. (minor and arguable) Lists have 2 simpler syntaxes.

The other points were irrelevant (dependencies), wrong (macros) or really dubious (margins, Git, bibliography). I think Typst has many more interesting features over LaTeX.

¹: https://tectonic-typesetting.github.io/

²: https://docs.overleaf.com/on-premises/installation/using-the...

Other examples where native features are better than these self-made scripts...

> vim [...] I select a region and then run :'<,'>!markdownquote

Just select the first column with ctrl-v, then "i> " then escape. That's 4 keys after the selection, instead of 20.

> u+ 2025 returns ñ, LATIN SMALL LETTER N WITH TILDE

`unicode` is widely available, has a good default search, and many options. BTW, I wonder why "2025" matched "ñ".

     unicode ñ
    U+00F1 LATIN SMALL LETTER N WITH TILDE
    UTF-8: c3 b1 UTF-16BE: 00f1 Decimal: ñ Octal: \0361

> catbin foo is basically cat "$(which foo)"

Since the author is using zsh, `cat =foo` is shorter and more powerful. It's also much less error-prone with long commands, since zsh can smartly complete after =.

I use it often, e.g. `file =firefox` or `vim =myscript.sh`.

The important rule is that this works for you, but everyone has to discover their own rules.

Most days, I drink 5 to 7 expressos, though there are days I don't drink any coffee, e.g. when not at home. I often drink one (sometimes two) expressos in the hour before going to bed. I'm almost always asleep in a couple of minutes after switching off the lights.

I think this focus on the default configuration of Caddy is a poor incentive, in a professional context. Here is the same config for nginx on a Debian box:

    server {
        server_name example.com;
        root /var/www/wordpress;
        location ~ \.php(/|$) {
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/run/php/php-version-fpm.sock;
        }
        ssl_certificate /etc/ssl/local/service.pem;
        ssl_certificate_key /etc/ssl/local/service-key.pem;
    }

It's very similar to Caddy's, except for the explicit cert.

No professional should care about a handful of extra lines. Anyway, in many real life situations, the config will be long and complex, whatever tool you use.

In the case above, the cert was created offline with the excellent mkcert from mkcert.dev, which is perfect for a developer machine. In other cases, I've had to use a certificate provided by my client. For the remaining cases, cerbot automates all, including nginx's config. Or if one installs the latest nginx, ACME cert retrieval is now included, so the difference to Caddy is shrinking.

I don't deny that Caddy is a worthy tool, but I don't care if it makes me write a few lines less in configuration files that I rarely write or update. Praise should focus on more important features. [edit] The excellent leadership shown in this post seems more important!

We can only hope that she will not behave like the previous career politicians that got the Nobel Peace Prize in recent years.

Abiy Ahmed (2019), from Ethiopia, ended the cold war with Eritrea. Then he launched a war against the region of Tigray, with mass rapes and mass civilian killings. He harassed the free press, and turned the country into an autocracy.

Juan Manuel Santos (2016) from Colombia and Ellen Johnson Sirleaf (2011) from Liberia later appeared in Paradise Papers because they had secret offshore companies in Panama and Barbades. Their political activity was more tame after the prize than before. Both ended their presidential tenures with plummeting approval rates, especially because of corruption allegations.

Barack Obama (2009) received the Prize for his generous discourses on foreign policy, just after being elected. Then he lead the USA to more war in Afghanistan, and a new war in Libya. He helped Saudi Arabia invade Yemen (UN states this war killed 300,000 people). He helped the Egyptian army with its coup, that killed thousands of opponents and sent 60,000 in jails (including the elected president who died there).

In my opinion, this prize is, most of the time, a dark and heavily political joke.

Among the famous writers that I know through their writings, I'd expect Jorge Luis Borges and Umberto Eco to have read many thousands of books, because that wide culture was a major element of their fictions. The later did have 50,000 books at home, but the former became blind and probably didn't own many books.

With simple math, reading 2 books each week leads to at most 7,000 over a lifetime. If Denny McCarthy's guess is right (read 85% of 20k), his older brother read about 4 to 5 books a week, every week, from teenager to his old age.

> Our PISA reading scores were worse than Canada, Ireland, Estonia, and the rich Asian countries, but higher than everyone else in Europe.

Wrong.

In the article, the nearest link that was supposed to prove that claim points to a blog post that uses the 2019 PISA data. And in that post, there's not just Ireland and Estonia in Europe that do better than USA, but also Finland, Poland and Sweden. US-Americans have a reputation of knowing little of the world geography, maybe that's why these countries were forgotten ;-)

The article also has a link to a blog about 2021 PISA data, but with a very limited sample: e.g. Estonia is missing. And Poland still does better than the USA.

Other significant issues I've had with `pass`:

- Important processes are undocumented. E.g. sharing the pass repository with another computer is not obvious: you need to copy more than the `.password-store/` directory...

- Hard to install if not packaged. I tried to install `pass` on a headless NAS, but it required gpg, which looked hard to cross-compile to aarch64.

- `pass` is a light interface over `gpg`. So it has all the problems of GPG – I've had a few annoyances with `gpg-agent`. Many organizations are trying to ditch GnuPG and switch to simpler and better cryptography tools, like age. https://github.com/FiloSottile/age

- Android with `pass` was a bad experience. The official package was unmaintained. The fork was not packaged in F-Droid. The UI was cumbersome.

I still use pass, for lack of an obviously better universal solution. There's FiloSottile/passage for minimal change, just replacing gpg with age, but no Android. A better alternative would be gopass, which is portable across all unixes, is compatible with `pass` and has an age plugin. But still no Android packaging. https://www.gopass.pw

Thanks for explaining your goal and some of the context.

I suggest that stating them prominently would help the project. When I read Mago's home page, I downloaded the latest release, followed the "Getting started" process on a local repository, then nearly lost interest when I saw the amount of false errors. If I had first read "here is our goal, with this roadmap, this kind of validation on real projects, and this position toward existing well-known tools", I would have been much more willing to follow the project and accept its false positives.

As a side note, for my first try with Mago, I think its lack of parsing `@property` was a major source of false errors, because the source code it analyzed had a few omnipresent classes that used it. BTW, Mago panicked when I tried to lint another repository... I'll open a issue.

The README is quite ahead of reality: it never mention that Mago is still beta software. A roadmap to a first release was created 5 days ago, https://github.com/carthage-software/mago/issues/405.

I've just tried to apply it to a medium-sized project, and it spitted tens of thousands of errors where phpstan and psalm don't see any. At first glance, it's because Mago does not parse phpdoc. In its current beta state, Mago is meaningless for all the big PHP projects, which are its main target.

Mago might succeed, but I wouldn't bet on it. Its main selling point is that it promises to be faster than the usual static analysers-linters (phpstan and psalm). But if it does not reach feature parity with them, the speed gain probably won't convince PHP projects to drop the standard tools. Since phpstan and Co keep evolving, keeping feature parity will require constant work. And PHP is more niche than Python or JS, so contributors mastering Rust and PHP will be fewer, compared to phpstan/psalm which are written in PHP.

I don't understand why they didn't try to alter the ON condition. Instead of moving the JOIN into a per-field-subquery or a preliminary query, why not replace

    LEFT JOIN event_chunks as ec
      ON ec.chunk_id = lc.id

with

    LEFT JOIN event_chunks as ec
      ON case lc.type
        WHEN 'E' THEN ec.chunked_id = lc.id
        ELSE 0
        END

I don't know if it more performant with Sqlite's query planner (and it may depend on many conditions, e.g. strict tables), but it looked like the obvious fix to the initial query. And it's 100% SQL, no need for a Rust hashmap.

I also ditched docker when I could. In my experience...

Podman with pods is a better experience than docker-compose. It's easy to interactively create a pod and add containers to it. The containers ports will behave as if they were on the same machine. Then `podman generate kube` and you have a yaml file that you can run with `podman kube play`.

Rootless networking is very slow unless you install `passt`. With Debian, you probably should install every optional package that podman recommends.

The documentation is lacking. Officially, it's mostly man pages, with a few blog posts announcing features, though the posts are often out of date.

Podman with its docker socket is often compatible with Docker. Even docker-compose can (usually) work with podman. I've had a few failures, though.

Gitlab-runner can use podman instead of docker, but in this case the is no network aliases. So it's useless if the runner needs to orchestrate several images (e.g. code and db).

> I also wish that the world would settle on a sane date-time format like the ISO 8601

IIRC, in most countries the native format is D-M-Y (with varying separators), but some Asian countries use Y-M-D. Since those formats are easy to distinguish, that's no problem. That's why Y-M-D is spreading in Europe for official or technical documents.

There's mainly one country which messes things up...

I've now seen a dozen of articles that explain that jj is wonderful and better than Git for everything. This tutorial is of the same kind. Now that I've read extensively about the good part, I'd be more interested by the bad and the ugly. Because my experience with jj was more balanced.

When I tried jj, I found a few pain points that made me return to Git. For instance, I was sharing a branch with a co-worker where we were just piling commits as soon as they were ready (after `pull --rebase` if necessary). Since jj doesn't have names branches, that workflow was easy with git and tedious with jj – even with the `tug` alias. The process in the "Tracking remote bookmarks" chapter of this tutorial still doesn't look nice to me.

Another pain point was that jj could not colocate with light clones, like `git clone --filter=blob:none`. Maybe that's fixed now.

Even when I don't use directly ffmpeg, I often use tools that embed ffmpeg. For instance, I've recently upscaled an old anime, ripped from a low quality DVD. I used k4yt3x/video2x, which was good enough for what I wanted, and was easy to install. It embedded libffmpeg, so I could use the same arguments for encoding:

    Video2X-x86_64.AppImage -i "$f" \
     -c libvpx-vp9 -e crf=34 -o "${f/480p/480p_upscale2x}" \
     -p realcugan -s 2 --noise-level 1

To find the best arguments for upscaling (last line from above), I first used ffmpeg to extract a short scene that I encoded with various parameter sets. Then I used ffmpeg to capture still images so that I could find the best set.

Findings: US children’s health and mortality has worsened from 2007 to 2023. Many health indicators are significantly worse than in other high-income countries.

This optional module makes simple cases simpler.

Having distinct tools for serving content and handling certs is not a problem, and nothing changes on this side. Moreover, the module won't cover every need.

BTW, cerbot is rather a "fat tool" compared to other acme tools like lego. I've had bad experiences with certbot in the past because it tried to do too much automatically and it's hard to diagnose – though I think certbot has been rewritten since then, since it has no more dependency on python zope.

A little mistake with this release: they packaged the ngx_http_acme_module for many Linux distributions, but "forgot" Debian stable. Oldstable and oldoldstable are listed in https://nginx.org/en/linux_packages.html (packages built today) but Debian 13 Trixie (released 4 days ago) is not there.

This paper repeatedly asserts that the formations they studied have a practical impact for professional cycling. They claim that, to bring back a leader into the peloton, the teammates could use formation different from the usual single line. For example, 2 riders upfront shielding 1 protected rider behind them. Or a diamond of 4 riders, with the protected one in the back.

I doubt this practical value exists. The paper completely forgets one important element¹: having a single rider at the front saves the energy of the teammates. If a team was to put two riders upfront and then the chase takes more time than expected, they have no backup. And even if the strategy was to succeed and the leader gets back into the peloton, he/she will have two tired teammates instead of one, which means a reduced help for the remaining of the stage.

I also suppose pro teams already know all of this, even if they didn't have the precise benchmarks of this paper. It's just unpractical most of the time. For a diamond shape, the aerodynamic gain is pretty obvious, but with a high price to pay in order to protect a rider.

As a side note, the paper authors should learn about PDF metadata. It's quite ugly that the file's title is "Microsoft Word - 2025_Preprint_Formations_V2".

[¹]: Except when they quote a cycling specialist about the goal to "reduce the leader's effort without sacrificing too many team members".

MDN is obviously an important reference. They've done a great job, because documenting the complex mess of modern web technologies is hard.

I have 2 small complaints:

- I sometimes read some dubious content on MDN. For instance [JavaScript frameworks and libraries]^1. I don't think these tutorials for 5 frameworks provide any value over the respective official tutorials. Even more so with outdated tutorials: the Svelte one is 5 years old, and there have been major changes since then. ^1: https://developer.mozilla.org/en-US/docs/Learn_web_developme...

- The quality of the webextension doc is low. A clear problem is that it's mostly for manifest v2, with a few incomplete pages mentioning a transition to v3 or the compatibility with Chrome. In practise, I started developing an webextension with this doc, then had to switch to Chrome's, though Firefox was my primary target.

> Given that it comes with issues, I assume the benefits outweigh the downsides.

Any change can introduce regressions or break habits. The move toward socket activation for sshd is part of a larger change in Debian. I don't think the Debian maintainers changed that just for the fun of it. I can think of two benefits:

+ A service can restart without interruption, since the socket will buffer the requests during the restart.

+ Dependencies are simpler and faster (waiting for a service to start and accept requests is costly).

My experience is that these points largely outweigh the downsides (the only one I can think of is that the socket could be written in two places).

> 2) OpenSSH server was installed as systemd socket activated and so ignored /etc/ssh/sshd_config.

sshd still reads /etc/ssh/sshd_config at startup. As far as I know, this is hard-coded in the executable.

What Debian has changed happens before the daemon is launched: the service is socket activated. So, _if you change the default port of sshd_ in its config, then you have to change the activation:

- either enable the sshd@service without socket activation,

- or modify the sshd.socket file (`systemctl edit sshd.socket`) which has the port 22 by default.

Since Debian already have a environment file (/etc/default/ssh), which is loaded by this service, the port could be set in a variable there and loaded by the socket activation. But then it would conflict with OpenSSH's own files. This is why I've always disliked /etc/default/ as a second level of configuration in Debian.

I think that comparison is unclear and unfair. The core is that instead of:

    jj rebase -r @ -B abc

the recommended Git alternative is:

    git rebase -i abcd1234
    # move the last line to the desired position

This is a process I use heavily, and one of the rare cases where I prefer the Git way: less cognitive load (I don't need to memorise options b/s/r/d/A/B for `jj rebase`) and the interactive editing of the history feels simpler (especially if I move several commits).

I've used jj for a few weeks, but switched back to git. I'm fluent enough with Git so I never struggle any more. jj mostly felt nice, but the added value was not enough to replace years of expertise.