bottlerocket VS polkadot

According to this discussion - starting with Bottlerocket 1.13.0 (Mar 2023) new distributions will default to using Cgroups v2 interface for process organization and enforcing resource limits.

Well, the link I provided references the Bottlerocket docs which explains the control container and the admin container and also how you can configure Bottlerocket via the User Data field when launching it as an AMI. All the information appears to be in the docs

https://github.com/bottlerocket-os/bottlerocket/blob/develop...

On the server-side, there's Bottlerocket OS [1] (Amazon). They use A/B partitions for upgrades, and the idea is that you just run containers for anything non-base. Boot containers are used to do custom configuration at boot, and host-container (or DaemonSet, if you run K8S) is used for long-running services.

[1] https://github.com/bottlerocket-os/bottlerocket

Bottlerocket OS.

To add to the other excellent answers, I would recommend adding Bottlerocket to your reading list: https://github.com/bottlerocket-os/bottlerocket#readme

I'm also aware of (but haven't used) https://github.com/siderolabs/talos#readme

I just realized your question may have implied a desktop os, whereas Bottlerocket, Flatcar, and likely the others in this specific thread are server-side. I don't have much experience with trying to solve that problem on the desktop except for the horror-show that is snap

https://github.com/bottlerocket-os/bottlerocket/issues/2855 soon for bottlerocket, maybe you’ll see Amazon Linux 2023 for eks nodes soon too?

I think open sourcing for free labor is a common misconception. Most corporate led open source projects (eg, https://github.com/bottlerocket-os/bottlerocket from AWS or https://github.com/facebook/relay from Facebook) still require a team of employees.

Bottlerocket might be worth a look. https://github.com/bottlerocket-os/bottlerocket

Polkadot (6400 GitHub Stars) https://github.com/paritytech/polkadot

I don't think asynchronous backing has any direct effect on the number of parachains, no (I mean, there likely is an effect, but it's not the goal and my understanding is that any effect on that would be minimal, although I'm not involved in the deep engineering here). It increases throughput, correct, by decreasing the time between blocks by not needing to do a "roundtrip" to the relay chain to build new blocks. See https://github.com/paritytech/polkadot/issues/3779 for an overview.

"The 27 waiting day is unavoidable and a very important security measure to protect against certain attacks and vulnerabilities of PoS. I totally understand that it is annoying, but arguably it is for the benefit+security of the overall network, which includes you as well at the end of the day as DOT-holder." - from this GitHub discussion.

Ref: Kianenigma @ https://github.com/paritytech/polkadot/issues/2418

Polkadot 0.9.37 has been released with MEDIUM upgrade priority. https://github.com/paritytech/polkadot/releases/tag/v0.9.37

Specifically, it was this PR that changed it: https://github.com/paritytech/polkadot/pull/6230

Actually it looks like you can! It's just not recommended. This is from the official documentation: "Starting with runtime version v23 natively included in the client version 0.8.23, payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that setting an exchange address as the recipient of the staking rewards is extremely unsafe.*

A particular validator sent out a LOT of dispute reports (i.e., saying that other validators did something incorrectly) last night (for reasons unknown). It looks like other nodes "choked" reading all of these disputes, and one subsystem died, stalling nodes but NOT killing the process. It's still being investigated, but you can look at the issue on Github to see it being discussed here: https://github.com/paritytech/polkadot/issues/6412