timost's comments

Thank you for your answer !

I'm trying not to pick sides but here are a few arguments they oppose to these key points :

- Technological advancement : Although it does play a role, they measure power in long climbs to limit that bias. Speeds are lower so aero plays less of a role. Bikes were already as light or even lighter in the 2000s. They also calibrate their power predictions against riders of the peloton who publish their power on strava.

- Nutrition has indeed changed, it helps producing near max power efforts at the end of long stages (aka durability) but doesn't play a direct role on pure max power (VO2 max related) which is what they are worried about.

- Regarding training, I'm not really sure, I think the pro peloton already had access to power meters in the 2000s.

- Regarding testing, it's indeed quite frequent but it's not bullet proof.

- I think the history of the sport is so bad it's hard to see the half full glass.

There is this french website[0] which (among other things) analyses TdF performances over the years.

They compute power metrics based on climbing times in the mountain stages. The trend these last few years is quite worrying, reaching and going above peak doping-era performances [1].

The website is maintained by a former pro-level coach of the festina era.

[0] https://www.cyclisme-dopage.com/

[1] https://www.cyclisme-dopage.com/actualite/2025-07-26-cyclism...

It's now possible to use triple back quotes to create blocks in MS Teams

I'm curious about the switch from boltdb to SQLite. How should one handle migrating existing podman environments ?

Fixed in release 5.0.0

main changes: - new podman db will be SQLite, existing boltdb db remain supported. - podman machine has seen many rewrites - deprecated cgroupsv1 will raise warnings

Annonced in the 2.2.0 release. Chained assignments will also no longer work.

There is a migration guide [0].

0: https://pandas.pydata.org/pandas-docs/version/2.2.0/user_gui...

Nice video, thank you. It's interesting to see how each technology behaves depending on the scale of the dataset. Duckdb is definitely killing it.

I'm not affiliated or anything but The Great Courses' "Bach and the High Baroque" [0] course is a great Series on Bach (Robert Greenbert's courses are great overall).

0: https://www.thegreatcourses.com/courses/bach-and-the-high-ba...

Using rootless podman limits the blast radius of a container escape.

Also many of the cappabilities described in this article aren't compatible with a rootless user deployment scénario.

The changelog mentions "Detect when init is terminated (solves #10802)"

This is a pre-release but it can be installed using `wsl --update --pre-release`

Pyarrow from 0.14.0 to 14.0.0 allows for arbitrary code execution

IMHO `--fixup` commits and `--autosquash` rebases make rebase much easier.

Interestingly, Dask runs out of memory on many of the tasks of the benchmark.

I see, interesting. I guess you are saying that systemd service wouldn't work because it's not available inside the container.

FWIW it's possible to run a rootless podman container with a working systemd inside the container. I've near tried running podman in podman using systemd though.

I agree with you on the state of podman compose.

I just wanted to clarify that you can run docker-compose with podman in _rootless_ mode. This can be done by running podman's systemd user service.

You can use docker-compose with podman using podman's docker compatibility API.

See my other comment in a recent thread [0]

[0] : https://news.ycombinator.com/item?id=37661056

A trick I have used sucessfully is to use docker-compose with podman as the engine.

The way I do it is by starting podman's systemd service which exposes a docker compatible API over a Unix socket.

Then export DOCKER_HOST pointing to the socket and you can run docker-compose with podman transparently.

I think it's this bug https://github.com/microsoft/WSL/issues/8696

A real nightmare.