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".
>having a single rider at the front saves the energy of the teammates
Also (as mentioned briefly in the paper), longer pace lines result in reduced drag for the rider at the front. This can seem counter-intuitive, but it's basic streamlining - the following riders fill in the low-pressure region behind the lead rider, reducing the amount of flow separation. Riding two-abreast is actually slower than riding individually.
A really efficient pace line looks like a team pursuit, with the rider on the front doing very short stints before peeling off and joining the back of the line. This is hugely important for physiological reasons, because it allows the lead rider to briefly exceed their aerobic threshold and then recover.
Yeah, this is how you do it. Everybody pulls but the protected one. I've been in team time trial situations where we had to protect one (it me, but we won), even two, and goddam that pull through could be hard but I made it.
Yeah if you watch crits you can tell from a still image whether it's fast or not by looking at the grouping. It strings out into a line when it's fast.
I watched a lot of the Tour de France and if I had seen the paper before that I would have looked out for any of these formations with two riders in front. Were there any instances where they used these formations? I only remember single leader formations (often lead by Tim Wellens for an impressively long time), but there might have been other formations that I just missed.
> Were there any instances where they used these formations?
Half of it, when in echelon form during crosswinds. Which is pretty much the only situation where any of this will work in practice since as mentioned elsewhere many times you don't burn all your people at once. Energy isn't endless.
To add to sibling comment, in the peleton you generally dont have the luxury of choosing your formation down to such fine detail. Theres lots of other riders fighting for space.
And breakaways are rarely a team affair. You get some towards the end of mountain stages, but uphill all of this maths goes away (everyone is much slower and air drag matters less).
At least with the diamond formation you have the opportunity of rotation but the two in the middle will still tire quickly, and I don’t know how you safely rotate in that configuration. Any beginning serious cyclist can learn to draft. But the pros have got rotating the formation down to a science. You have to go fast without increasing the risk of high speed collision.
In the scenarios mentionned ( getting back to the front ), usually the single line is the easiest to do because of the riders having to navigate between the team cars, road furnitures, dropped riders, etc. It is only really when you are at the front where you can go wherever you want.
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.
Hey, I'm from the MDN team. Thank you for the compliment and the feedback, I really appreciate it! <3
I hear you on the complaints, I'll take this to the team. You might like this, in case you'd still like to learn building Firefox extensions → https://extensionworkshop.com/
While I believe that the tutorials for frameworks do not replace the official ones, I still find great value in having them available on MDN. Perhaps you are not seeing this because you are viewing the problem from the perspective of someone who already knows very well what these frameworks are and how they should be used.
I remember clearly how years ago MDN taught me what libraries and frameworks are and why I should (or not) care about them. I didn't have a CS background nor anyone to teach me. I would probably have been too intimidated to approach them if it weren't for MDN guiding me. I'm very grateful.
> 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).
I also have a hunch that socket activation allows for more predictability around what a not-running/listening-for-activation service's port is doing at the syscall/kernel level, which in turn makes power saving and/or sleep states a little more predictably efficient.
> 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.
to be an excellent improvement over anything git provides, including rerere. It's the first patch queue for git implementation that actually worked for me, which in turn makes github PR UI somewhat bearable.
I occasionally use -r, too, but most of the time it's better to
Just two personal experiences of why the quality of Firefox is far from Chromium's: downloads, and creating an extension.
A few years ago, they changed their interface for downloading. This introduced more than a dozen of bugs. Some were cosmetic, e.g. hover was the same color as foreground. Some were rare but caused a file loss. Some were performance related, e.g. deleting the history of downloads could take a minute with no visible change until the end. Most of these regressions are now fixed, but that made me lose confidence in the quality of Firefox.
This year, I had to develop a cross-platform extension for Chrome and Firefox. I started using Mozilla Documentation Network, but many pages seemed unmaintained. The relationship with extensionworkshop.com is unclear. The status of manifest v3 is poorly documented (most pages are for v2 only). The page about the compatibility with Chrome is incomplete. After a few struggles, I switched to Google's documentation. Then I lost time and energy on a severe bug with the Firefox tool that publishes web-extensions: https://discourse.mozilla.org/t/webexterror-unsupported-file...
> Fun fact: movie sales, in terms of tickets sold, peaked in 2002.
Fun fact: this is completely wrong. The cinema theaters were much more popular in the 1920s and 1930s, with about 3 times more tickets sold in the USA (out of a smaller population).
"In 1930 (the earliest year from which accurate and credible data exists), weekly cinema attendance was 80 million people, approximately 65% of the resident U.S. population (Koszarski 25, Finler 288, U.S. Statistical Abstract). However, in the year 2000, that figure was only 27.3 million people, which was a mere 9.7% of the U.S. population (MPAA, U.S. Statistical Abstract)."
in Pautz, The Decline in Average Weekly Cinema Attendance, Issues in Political Economy, 2002, Vol. 11. https://ecommons.udayton.edu/cgi/viewcontent.cgi?article=102...
I think the programming language is not relevant, especially since startup time plays no role. A different design can have much more impact, and IIRC Garnet is not fully compatible with Redis.
A command without context is not very useful. If anyone wants to run LanguageTool locally, I suggest reading the official documentation page: https://dev.languagetool.org/http-server
Their recommended process is :
1. Install fasttext (it's an official Debian package, but you have to compile it on Windows).
2. Download and uncompress the LanguageTool release.
3. Create a config file.
4. Launch the server with the java command (of course, a JRE must be installed).
5. Connect to the API, e.g. with the browser extension.
Running a ready-made docker image replaces steps 1-4 and removes the need to install Java globally. Some will prefer it this way.
> 2. Download and uncompress the LanguageTool release.
> Running a ready-made docker image replaces steps 1-4
We can go pretty low level in the docker option too.
1. Download a Linux installation image
2. Download a hypervisor
3. Install Linux on the virtual machine
4. Install docker in a virtual Linux machine
5. Launch LanguageTool container
6. Configure networking between the host and the container in the guest
7. Connect to the API, e.g. with the browser extension
Obviously I initially oversimplified by omitting the configuration step. But adding download step to inflate the complexity is not a fair play ;-)
I'd argue that running a platforn-native artifact is both simpler and easier than involving virtualization. Even if steps 1-4 are done by some magical tool like rancher or docker-desktop
"Preislamic" is a common term for near-East history. Islam is well dated, it introduced many changes and unified the region, so it's a powerful marker.
I've never encountered the word "Pre-Arabic" about the Arabic peninsula. It would be hard to define precisely. The word "arab" is probably more than 3000 years old. The Arabic languages may be older ; they're semitic languages like the Akkadian of Mesopotamia. And when did an "Arab" people or culture emerge from the semitic people and culture? I guess between 6000 BP and 3000 BP, but it was probably a long process, and nomad tribes didn't leave many vestiges.
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".
reply