I've been a long tmux user, but I've migrated to Kitty only setup. To make my muscle memory feel at home, I configured Kitty with nearly the same keybindings as tmux. Here is my setup https://blog.funcer.xyz/blog/kitty-terminal/
> This is particularly problematic for hosted Kubernetes services like Google Kubernetes Engine (GKE), which often limit the CPU and memory available to the API server. These services can gracefully scale the API server up when they predict it will require more resources - e.g. when more nodes are created. Unfortunately at the time of writing most don’t factor in more CRDs being created and won’t begin scaling until the API server is repeatedly “OOM killed” (terminated for exceeding its memory budget).
Yeah, that's the limitation of hosted kubernetes services. Internally we used crossplane a lot. Though we haven't reached this limitation yet, we used another approach by deploying a standalone etcd + k8s apiserver as k8s (eks/gke) pods. And register the CRDs into this apiserver. So we can scale the etcd and apiserver easily.
You can debug such containers by running another debugging container to join their corresponding namespaces. For example the most frequently used namespaces are pid and network, with these two namespaces joined the target container, you can see its pid and binary as well as the network traffic.
For docker and k8s, there are two helpful tools which implement what I said with simple and intuitive UI:
If you're familiar with ansible, it'll be quite easy to setup a k8s cluster on bare metal with kubespray. What's more is that it deploys production ready cluster with HA support
https://github.com/pingcap/tikv stores consensus state in RocksDB.
> With the implementation of the Raft consensus algorithm in Rust and consensus state stored in RocksDB, it guarantees data consistency.
Yeah, you're right. But almost all of the community uses indentation which defined as layout in Haskell2010 Language Report instead of semicolons and curly braces
Agreed on dependent type, and I also love ML syntax more than haskell(yes I don't like indentation sensitive language). BTW I suggest you give FStar a try, it has dependent type and OCaml/F# like syntax and support theorem proving
I believe emoji is designed to be expressive, if we need to look it up in a emoji dictionary ,then emoji goes wrong.
The fact is that everybody wants to add their favourite emoji, but more emoji added more confusion it will be make.
Just imagine we lookup an emoji before we send to others, and the receiver has to look it up in a dictionary to know what the sender want to express. Why not just using the normal words we already know very well
I have wrote a playpen-mode for emacs last week with which we can play rust without installing rust and without opening rust playpen in your browser. https://github.com/tennix/playpen-mode