I believe you are understanding the opposite of what was said.
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.
> The reason is entirely technical and I think it has been formulated clearly [..]
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.
There is a large difference between "I do not think this is a good idea" vs "do not do this", in particular given the position Hellwig has in the kernel as a listed maintainer of the DMA mapping helpers.
No single technical reason was given besides a non-specific opinion on the "messiness" of multi-language projects.
If you search for "concurrent hash table <language>" or "concurrent map <language>" (being <language> Rust or C++) you get a number of open source libraries written using different techniques. I consider "exotic" a matter of opinion.
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 would want this over docker and docker-compose any day.
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.
I don't see how this reasoning makes any sense: you just need to look at the actual clock time to find out if the alarm went off or not.
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.
Algebraic effects are going to put OCaml on a next level in terms of expressivity, abstraction and decoupling capabilities of separate tasks. It would be like going from a type system like C, with only concrete types, to parametric polymorphism and/or generics.
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.
Any language with a large enough lexical set or enough meta-programming capabilities can be classified as "write-only" from the point of view of non-experienced users. It's the everlasting battle between learning curve and expressiveness.
This looks like someone trying to build a story with snarky comments and funny observations to get audience interested. The parts about C sound amateurish indeed.
I've been using Zim [1] as a knowledge database for around 2 years. I don't like depending on online solutions which may suddenly disappear.
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.
The queue is a single contention point which will have a considerable overhead unless the work takes a long time to execute (ie, enqueue is infrequent).
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.
Updated version: https://archive.is/TpsUW