I understood it as "there cannot be trust anymore" - mostly because different people are at risk of becoming a victim in different ways: from a crime itself, or from being falsely accused of committing a crime.

Individuals will act in a way that makes sense for them. Asking them to "just trust more" does not solve the problem - it needs to be addressed at the root (education, communities), which goes far beyond the individual level.

Using it, solving problems with it, and building a real community around it tend to make a much greater impact in the long run.

Care to elaborate?

I had the same impression as well, in particular due to his wording:

> "No rust code in kernel/dma, please"

When, in fact, the code is in "rust/kernel/dma" not "kernel/dma".

It seems like he missed this and then doubled down on his stance when questioned.

He clearly expressed a technical opinion based on his own beliefs, and that’s all. There was no reasoning.

He did not even acknowledge the fact that it is going to be maintained separately from the actual generic kernel code (rust/kernel/dma vs kernel/dma).

Anyone can easily formulate a sentence that seems coherent and correct, but it can be proven completely false in 15 seconds with actual data.

IOW: just because someone calls it a technical argument it doesn’t make it one.

This is a matter of opinion - specifically, the opinion of a single person.

> If there's a single most reason why Rust-in-Linux will fail it is going to be because of the immaturity and entitlement of individuals in Rust community.

Indeed there was immaturity from several individuals.

One question: if you act immaturely towards someone and they react immaturely, who's fault is it? The person who reacted or you?

I do not believe there is a widespread issue of entitlement: if you follow the discussions on the ML and observe how the R4L project has progressed so far, the only "entitlement" that individuals in the R4L project may seem to have in common is the desire to be treated with respect and for discussions to focus on technical arguments.

For me, this is the bare minimum to be expected.

No single technical reason was given besides a non-specific opinion on the "messiness" of multi-language projects.

I don't see any reasoning besides "I think it's not really needed".

The reasoning in the original article is shallow at best, and the presented alternatives are not discussed in the depth I was expecting for an article questioning the whole architectural basis of a very popular IaC stack.

On the second article, I don't see a self critique of the actual points raised during the original article.

The two articles sound much like a collection of statements based on personal opinion.

I see the value in an article like this for starting a discussion but not into taking any sort of conclusion.

I've been using docker compose in production for a couple of years now and it adds another layer on top of systemd that is a continuous source of headache, especially during updates.

Podman gets it right: no central daemon, can automatically generate systemd services for a whole pod. Updates are seamless.

This by itself is enough of a reason to me.

Even if the punishment is not that severe, a high probability of being caught is a much greater deterrent.

For instance: alarm set for 8 AM.

You wake up, look at the clock: if it says 7:59AM or earlier, you woke up before it had a chance to ring. If it says 8:00AM or anything past that, it already went off.

Unless, of course, you have an alarm that does not show you the current time. Otherwise, it's pretty easy to figure out what's happening.

Multicore is a very nice addition, but the fact that it is going to be coupled with an effect system is a game changer for the language as a whole.

Together with some plugins for managing tasks, git and some script for synchronizing repositories, it has been working great.

There are some limitations on this approach (ie, two persons editing the same page concurrently is a no-no), but for my use-case it works perfectly.

I find it much more intuitive than org-mode, and the fact that it auto-generates a "global" task list based on items spread across the whole notebook makes it much easier to prioritize things.

[1] https://zim-wiki.org/

This kind of approach is usually not what you want: either you want to spawn threads as new work arrives (when each work unit is independent of each other), or you want to have a static number of threads each doing some predefined work (ideally one per core).

Scheduling pieces of work like this is going to be terrible for cache locality and will probably result in a number of threads waiting for each other and result in underutilization of the available cores.

I can think of a number of other languages that would probably easily surpass these, especially on latency.

The simple solution would be for the network providers to validate the caller ID numbers for its subscribers, but that requires changes to punish the ones that don't do it.

I've worked with telephony for 15 years and I know the big providers do this for most common telecom protocols, but VoIP providers tend to be more lax. But that's where they shouldn't, and the ones that break this shouldn't be allowed on the network.