sluongng

TiKV mainly runs on top of RocksDB in most scenarios.

I started a series recently https://sluongng.hashnode.dev/series/bazel-in-ci with focus on setting up Bazel in CI. But I has been trying to write more about CI and the culture around DevX more than Bazel to provide the context for future posts.

I think its simply a reselling of GCP storage services with overhead cost of their backup redundancy and SRE on-call.

But even with all that, 6GB per year definitely make you question the value of using Gitlab Container Registry vs Your Cloud of choice similar offering.

My current brown switch keyboard has lost all tactile bumps after 3+ years.

In the past, with starcraft apm spams, i definitely have experienced switches defects(dust collect over years, hard to repair) and keycaps defects on some of the more frequently used keys.

I think this skipped out on the downside of using Firecracker: the host underneath needs to be either Baremetal(AWS) or VM with nested virt support(GCP). This creates additional complexity to manage such a setup in production. Moreover, since both nested-virt VM / baremetal both comes at a very high spec by default, the economic would only make sense if you are at a scale that could saturate(or over-saturated like the article hinted at) these resources.

Very interesting blog post nevertheless. Looking forward to read more!

It's might be worth to note that Apple is now using Bazel internally and have an active engineering team working on Bazel-related projects. So I would hope if they were to have any bone to pick with usage of `sandbox-exec` in Bazel, they would be able to introduce an alternative upstream.