Indeed, it doesn’t matter too much, as long as it is consistent.

People running their own formatting or changes re-adding spaces, sorting attributes in xml tags, etc. All leading to churn. By codifying the formatting rules the formatting will always be the same and diffs will contain only the essence.

> > programmers care way too much about consistency.

> Indeed, it doesn’t matter too much, as long as it is consistent.

Um, I think you may have missed my point. Why does it always need to be consistent?

The problems you're talking about only show up when someone runs a formatter over the entire file. One answer is, just don't do that.

Not all. CachyOS has specific builds for v3, v4, and AMD Zen4/5: https://wiki.cachyos.org/features/optimized_repos/

By running more tasks in parallel across different cores they can each run at lower clock speed and potentially still finish before a single core at higher clock speeds can execute them sequentially.

At least from what I’ve seen around me professionally, the issue with most Scala projects was that developers started new projects in Scala while also still learning Scala through a Coursera course, without having a FP background and therefore lacking intuition/experience on which technique to apply when and where. The result was that you could see “more advanced” Scala (as per the course progression) being used in newer code of the projects. Then older code was never refactored resulting in a hodgepodge of different techniques.

This can happen in any language and is more indicative of not having a strong lead safeguarding the consistency of the codebase. Now Scala has had the added handicap of being able to express the same thing in multiple ways, all made possible in later iterations of Scala, and finally homogenised in Scala 3.

Raw performance, in the sense of single core performance, is still one of the most important factors for us. Yes, we have parallelised tests, in different modules, etc. But there are still many single threaded operations in the build server. Also, especially in the cloud, IO is a bottleneck you can almost only get around by provisioning a bigger CPU.

Our CI run smaller PR checks during the day when devs make changes. In the “downtime” we run longer/more complex tests such as resilience and performance tests. So typically a machine is utilised 20-22/7.

Which OSS PaaS are there that are noteworthy? Or do you mean something like Kubernetes?

Coolify is usually loved by the community.

Dokploy is another good one.

Kubero seems nice for more kubernetes oriented tasks.

But I feel like if someone is having a single piece of hardware as the OP did. Kubernetes might not be of as much help and Coolify/Dokploy are so much simpler in that regards.

Thanks. I will look into those.

I suppose kubernetes with the right operators installed and the right node labels applied could almost work as a self service control plane. But then VMs have to run in kubevirt. There is crossplane but that needs another IaaS to do its thing.

There are many Isaacs and Alberts. How many notable Galileo(s, not to use Galilei) do we have?

Regarding the less than ideal audio conditions, there are also already models that have impressive noise cancellation. Like this https://github.com/Rikorose/DeepFilterNet one. If you put them in serial, maybe you get better results?

So the biggest difference I see with the new Air is that you get sRGB only in the display, with less brightness. Also it is has 8GiB of RAM, which shouldn’t be an issue for the intended use.

Same weight. You lose a bit on the speakers, microphone, and webcam. Not sure how noticeable this will be.

In this case the CPU wasn’t really saturated with work but with contention on global locks. The contention is lessened by removing the amount of concurrent mounts that are being done.

I wonder if simply setting a maximum number of concurrent mounts in the code or by letting containerd think there are only half the amount of cores, would have solved the contention to the same amount.