Many useful patches are posted to the upstream pass mailing list. They're rarely responded to. I don't know if that specifically drove the creation of this fork, but it's absolutely a frustration as a pass user
I've seen CPU throttling occur when limits aren't exhausted even on 5.4 kernels, so I don't believe the underlying kernel bug is fixed.
One option not mentioned in the post is to enable k8s' static CPU scheduler policy. With this option in place workloads in the "guaranteed" quality of service class that are allocated an integer CPU limit will be given exclusive use of their CPUs. I've found this also avoids the CFS bugs and eliminates CPU throttling, without removing CPU limits.
One thing to keep in mind is that this bug mostly impacts workloads that spin up more threads then they have allocated CPUs. For golang workloads you can set GOMAXPROCS to be equal to your CPU allocation and eliminate most throttling that way too, without messing with limits or the static scheduler policy
Enabling the static CPU scheduler policy currently requires setting a Kubelet flag, and that puts it out of reach of most people running managed Kubernetes distributions.
Because EKS supports custom launch templates? Good luck trying to finagle that into supporting the exact Kubelet flags that you want to enable, while staying abreast of upstream updates so that your cluster doesn't break when AWS tries to keep it up-to-date. Not anywhere close to a simple "extra_kubelet_flags: array[text]" kind of field.
I wonder what actor library the author is using with Rust. Given the status of github issues like https://github.com/rust-lang/rust/issues/3573 I thought there weren't any real options.
The first part of today's keynote had a strong emphasis on multitouch and gestures being integrated into the OS. As a BTT user myself I'm very curious to see if BTT has been obsoleted by Apple.