It's all true but they have one advantage over everything from the last two decades or so: latency. Obviously it's double lost if you try to reconstruct just the aesthetics.

> And don't let me get started with Sam Altman.

Why not? That's one of the reasons I visit HN instead of some random forum after all.

Are the differences between Google Books and LibGen documented anywhere? I believe most models outside of Google are trained on the latter.

I believe the GP doesn't believe trains have a future in a country that has a long tradition of automobile industry and its lobby is particularly strong.

I'd like to offer an alternate perspective: good public transportation network may decrease the number of vehicles sold in the (very) long run but creates another market that is quite stable - all this infrastructure of busses, trams, trains needs not only new units but also reliable maintenance. This is always a business opportunity and direct us towards a more sustainable future instead of just "produce more new cars no matter what".

It doesn't bother me that much really but if we want to be pedantic the literal rendering would be be "train at great speed" - this would make your point more pronounced.

If you want to be pedantic, the preposition à serves about twenty different roles (per the dictionary), so even a literal translation will have to pick the right word, not just one of its homonyms.

At is not the right word, even if you're translating word by word.

I just wanted to reply how wrong you are and that the OP's version would be literal if "de" was used instead of "à" but just writing that made me realize that I'm completely wrong and you are totally right. That's a rare moment and I decided to celebrate it by making this comment. Thank you!

Not always and I'm not sure if usually, but in this particular case it's both.

Everybody is different. When I visit the office sometimes, I do it to socialize and talk about things not related to work mainly. And then I get back to do the actual work. If I need to communicate with someone, I simply ask them for their time - they can get back to me whenever they are free. This system serves me and my coworkers well but it's obvious there are many people who prefer synchronous in-person communication for most tasks.

I don't prefer the in-person communication personally, but I know it's more productive for me, so I do it and end up preferring it. The same way I prefer clean code; it makes my and the companies life easier. Makes more money. I'm German, and it's painfully obvious.

But how else do they get the cure to the market?

(Provided it works, there are several such announcements every year but the actual progress is mediocre.)

Actual progress in biopharma is mediocre until it isn’t. Just look at weight loss drugs for an example.

I share the same feeling. Heck, even some books from the 70s and 80s are similar with this respect.

I believe those of us who can should try to do our best so that this art is not forgotten. It's extremely difficult to do today as the incentives are mostly opposite, but I believe the long term benefit to humanity is higher.

I'd be curious to know what prompt was used to generate this article. I don't mean any offence, most content on the web is generated by LLMs these days one way or another anyway, I'm just curious about the exact prompt used in this case.

I think something around those lines:

Write a comprehensive technical blog post targeting small and medium-sized businesses that use Hetzner Cloud and are evaluating lightweight Kubernetes alternatives. Compare and analyze the following solutions: k3s, MicroK8s, Docker Swarm, and Minikube.

Structure:

Start with a title and abstract introducing the comparative scope.

Provide sections such as:

Architectural Requirements, Deployment & Lifecycle, Management, Cost Analysis, Security & Compliance, Developer Experience, Strategic Recommendations and end with a clear conclusion and deployment advice.

Style:

Technical but accessible to DevOps engineers or small startup CTOs.

Use citation-style references for data (e.g., [1], [2], etc.).

Incorporate code examples (Terraform, Helm, CLI snippets).

Use tables for cost comparisons or benchmarks where appropriate.

Mention open-source tools specific to Hetzner (e.g., hetzner-k3s, hcloud Terraform provider).

Tone:

Professional, analytical, and informative. No marketing fluff.