I'd guess that Discord's storage systems lean towards processing a lot more writes than reads. Postgres and other databases that use B-tree indexing are ideally suited for read heavy workloads. LSM based databases like Cassandra/Scylla are designed for write intensive workloads and have very good horizontal scaling properties built into the system.
When you send a message, afaik it sends to all people looking at it at the time. So there is no read when in a conversation, and maybe the reads are batched when reading multiple.
Read traffic is much higher than write traffic due to mobile clients needing to sync chat history more often as their sessions are much shorter lived. Also search queries execute 1 query per result. And don't forget people doing GDPR data dump requests. It adds up.
In terms of the qualities of the wood, the Asian and European Chestnuts are less dense, less strong and has coarser grain structure compared to the American Chestnut. I might be wrong but I've heard the other Chestnuts don't grow nearly as large or as fast.
The company I work at started with the idea that we would build an orchestration system for Unikernels. Very much in the same space as the NanoVMs folks. I totally applaud their work. We took a different path once our small team worked with unikernels for a bit (mostly OSv). During the early days we noticed that the unikernel landscape had technical shortcomings that would take an incredible amount of engineering effort to overcome and we found convincing users to trade Linux for a (mostly but not totally) compatible unikernel based system was an insurmountable hurdle. It was a fun experiment but, after timeboxing our work and taking stock of the landscape, we fell back to one of our original sentiments: A stripped down Linux is actually a pretty good substitute for a Unikernel for most applications (emphisis on "most).
We ended up pivoting to running a lightweight linux, based on Alpine and orchestrating everything using Kubernetes and Virtual Kubelet [1]. Shameless Plug! Pods are isolated on their own virtual machines that are booted for the pod, the underlying OS is rock solid and gives users all the great tools, bells and whistles you'd expect from a linux based system. Fewer surprises, easier development. We actually open sourced the system today.
Great intel from on the ground. The story arc makes total sense. I also have starry eyes for orchestrated unikernels, but otoh linux is so configurable scaling down the kernel also seems very reasonable. How do the boot times compare? To me, the unikernel's chief appeal is that it could potentially start up in about the same amount of time it takes to load a native binary. Thanks for sharing.
On bare-metal boot times are drastically different. OSv was sub-second while our Alpine images were 3-5 seconds depending on what services we needed. However, we were focused on running our system on cloud VMs, not bare-metal. In the cloud you can't get a VM to start booting in less than 20-30s so that order of magnitude difference turned into, at most a 10% difference in boot times.
In 2017 we measured the restart time in of our unikernel images in AWS to be 22 seconds, all that time was waiting for Zen (2017... no KVM yet) to get around to getting to the place where we could run our image. So for our use case, the boot time didn't actually matter, it was far overshadowed by everything else happening under the hood.
I should say: Unikernels do have their advantages and should be used in areas that can exploit those advantages: Fast boot, low attack surface, way better performance for some workloads. We had trouble finding the specialized customers in the cloud that needed any of a unikernel's positives so badly that they would take on a unikernel's shortcomings.
I don't think etcd was designed with the idea of competing with larger distributed databases. For example, the maximum database size limit in etcd (as of v3.3) 10GB. This works for an application like Kubernetes where you're storing less than a million records but likely isn't something you want backing your wildly successful django application.
I try to spend my time doing things that let me create things, get into a flow state or both of those. I'm also a bit of an introvert. At work that has led me into a career in software. At home, there's a couple things that have been the focus of my free time: hiking, woodworking or music (I have to pick 1 or 2 to focus on... there's just not enough time)
Woodworking has been my kick for the past few years and it's a great hobby if you have a bit of space to make sawdust (basement, back yard/common area, garage, spare room). I find that it's really satisfying to make something tangible. Even after a full day of building software, spending time working with your hands can be incredibly satisfying, refreshing and fulfilling. It's also a very deep art/trade that you continually improve at so, over time you get to see your work improve as you learn more and get better. Things you make will go from clunky to functional to elegant. The cool thing is that you can be proud of it all. You made it!
The exclusion zone is actually resembles a wildlife refuge these days. From reports of the numbers of animals present it seems like human populations are much worse for wildlife than low levels of ionizing radiation and other contaminants from the disaster.
The animals’ populations have rebounded, especially those, like wolves and foxes, who’s habitats are least compatible with humans. Still, mean lifetimes, fertility rates and mean body mass are down, while illness are up. This also applies to some plant species. In no way was Chernobyl a strictly good event for wildlife, just that removing humans took away a very strongly negative factor.
A demonstration power plant based on the Allam cycle [1] is being tested in Texas. In that process the CO2 is captured while achieving efficiencies that come close to conventional power plants. The plant in Texas burns natural gas but the Allam cycle can also run on gassified coal.
TLDR: They needed full tanks (more or less) or an inert layer of nitrogen over the gas in the tanks before hitting Mach 3 or else the fumes in the tank might ignite. At the end you'll see that they had a system for fueling the tanks on the ground in order to hit mach 3 right after takeoff but it was a maintenance nightmare.
If I remember right, the SR71 could fly at Mach 3 for up to 90 minutes between refuelings. That's significantly longer than any jet ever made.
Just in case those IPs are within your AWS account: you can apply a single security group to those machines and then use that security group as the destination in the outbound rule.
If they're outside your account then, you're right, that's a shortcoming in AWS (Azure and GCP both allow multiple destinations in a single rule).
