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.
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.
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.
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.
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.
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).
It's mentioned briefly through a single paragraph but not much beyond that.
"He lived through the war under the name Grzegorz Krochmalny and hid in an estate near Lviv and at a manor neat Nowy Sącz. He gave private lessons in exchange for firewood, oil and milk. In his spare time he played chess and worked on designing a solar clock. During the war he resorted to solving serious mathematical equations by post but continuing his research from before the war was out of the question."
In the case of US cities (sorry, I don't know about research that covers Canadian cities) research shows it's a limited supply and failure/inability to grow that makes popular cities expensive: https://www.buildzoom.com/blog/cities-expansion-slowing
Edit: They key section of that study is the section called "Expensive cities and expansive cities"
Well you'll never get your wish if you keep wishing for that!
While it's a small sample size, I keep on hearing of friends who want to buy a house but are waiting for the current "bubble" to deflate a bit. Combine that with a limited supply in popular metro areas, a larger percentage of young (and old!) people renting and you get demand that will likely last a while (yes my personal sample size of N is small). As the renting population ages and sees themselves flushing thousands down the pipe every month, more renters will be saving up war-chest sized nest eggs to make the plunge into home ownership. I suspect that'll prop up prices for a good while.
If you want to buy a house, I don't think you can count on another great downturn to make popular locations more affordable. More likely it'll take an increase in supply or some major change in our lives to push people out of cities.
Certainly! I've never written a line of Java but I had no trouble following the examples in the book. The naming of variables, methods, etc. makes for easy reading without any Java knowledge. You just need to be able to identify a class and the public/private members and variables. That isn't a problem in Java.
Overall, I found that the book taught me a lot about looking for deficiencies in my own designs or what to look out for when weaving new functionality into an existing software project.
I wanted to post this last night but the internet went down in Vientiane (again) so I just went to sleep.
Having spent the last couple of months connecting from various parts of SE Asia, I'm happy to see this getting the attention it deserves. You don't realize how utterly painful or unusable much of the web is until you experience a network that is not only incredibly slow (by US standards) but also incredibly unreliable and prone to 5-20 minute outages many times per hour or day depending on where you are.
Before today, I hadn't clicked on a youtube video in months. The site was unusable.
Most evenings in smaller cities (not villages, that's a different story entirely) the broadband will be OK with downloads averaging around 3-15KB/sec. This allows you to access most sites or check gmail (usually I still opt for HTML mode). However, it's the frequent and intermittent outages that cause the most headaches. In many places I've visited they happen a couple of times per day and in other places, they happen many times per hour. These outages are a larger problem for AJAX heavy sites where clicking a button doesn't give a page saying "This webpage is not available" instead, the site just sits there, waiting for the request to complete, giving the user no indication that the rest of the internet is unreachable.
I have no idea what causes these outages (it's not the local network) but they lead to an awful experience on some sites. Hacker News, Wikipedia and other places do a great job of providing useful info that can be retrieved in a reasonable amount of time, countless others are so fat I've stopped visiting them entirely.
Think about the people and parts of the world you'd like to reach and design your site to have an enjoyable experience in those areas. I'm grateful for features like gmail's HTML only mode. I only wish other heavy sites had an equivalent feature.
Exactly. Where I used to work, anyone without a quant background would be urged to buy a copy of Grinold and Kahn the bible you suggested above or "Quantitative Equity Portfolio Management" by Chincarini and Kim.
I started working through my copy about a month ago and have no regrets about spending a lot of time with it (still have 1 chapter to go). While I might not have felt very enthusiastic about working through all the exercises, they're VERY helpful and a central part of the book.
I found that SICP helped hone my skills in finding elegant solutions to certain problems and improved my coding style. On the downside, I switched back to C++ tonight and found myself putting parenthesis in all the wrong places for the first hour. It's a small price to pay.