I think this is likely the reality. I don't think this is necessarily a community problem so much as it is the reality of software development today. Most developers given the time and resources would probably enjoy making their libraries and applications as portable and flexible as possible -- who doesn't love to see their work reused? That being said, on a typical software delivery cycle you optimize for what you think _most_ people are using, and likely what you yourself are using -- standard flavors of Linux operating systems running in one of the big cloud providers. This is not to say Go doesnt have applications outside of this space -- it clearly does.
Health care isn't scarce in most of the first world. Many first world societies offer health care to all of their citizens, and those visiting their country. Much as we view education as a fundamental human right in the United States and no longer treat it as scarce, most other societies view healthcare as a fundamental human right. As a society and political system the United States has actively made the choice to pursue a profit-based, insurance-centered care model that is purposefully scarce.
Which is to say, I completely disagree that there is no other option.
And yet in nations like Japan, where there are proportionately a greater number of elderly than in the US, their healthcare delivers at a much lower cost (by half!) as well as a higher life expectancy. This despite a decades long economic stagnation, as opposed to the curious economic "good times" in the US which seems to decrease our life expectancy and increase our health care costs.
Many first world societies have unreasonably long waiting periods to receive specialist attention and care. For example, Canada's average wait from referral to specialist appointment was 10.2 weeks in 2017, up from 3.7 in 1993. The average wait period for treatment was 10.9, up from 5.6 in 1993. 4.1 weeks for a CT Scan, 10.8 for an MRI. Some types of treatment require almost a year of waiting. Hope you aren't in a hurry to get your health issues resolved.
It IS scarce in the short term. Not everyone can get treatment right away, someone will have to wait. And the wait times seem to gradually trend upward, which would indicate (at first glance at least) that it cannot keep up. There's no magical solution to getting everyone timely care.
"Hope you aren't in a hurry to get your health issues resolved."
You make it sound so scary, but you make no mention of health outcomes. I don't care if an appointment happens in 10 minutes or 10 weeks, so long as the outcomes are positive. Wait times alone are not a meaningful metric to me.
Well, the parent is illustrating a basic point of freshman economics. We ration scarcity with cost (money) or time. In this case Canada chose to be "fair" and ration scarcity of medical care with lines.
Your comment belies a belief that peoples time or comfort are worth nothing. Should my children wait a year or more to have a specialist examine a chronic skin condition that thus far cannot be treated and causes severe itching? In Canada the answer is yes. Ever dealt with a toddler that can't sleep and you can't help?
Acute care here is the same. People die waiting at emergency. 24 hour waits for patients not bleeding out on the floor happen (but usually we can keep it down to 12).
"Your comment belies a belief that peoples time or comfort are worth nothing"
You mention nothing about comfort, just wait times, which is essentially my point. Are people being left in extreme discomfort? If so, that is a problem. Health outcomes help paint that picture, and in most first world systems outcomes are good.
Should my children wait a year or more to have a specialist examine a chronic skin condition that thus far cannot be treated and causes severe itching?
That sucks for there to be long waits, but the alternative being evaluated (the USA's system) has lots of people not ever getting treatment.
I think this is a great summary. C++11 is a huge leap forward if you can start fresh and/or only target C++11 compatible systems. Personally, I've also been down the road of trying to get older systems (also RHEL6) to run C++11 code via a hand-built compiler and it was an exercise in absolute frustration. And yes, Boost was the answer to some of this. Another thing you can try if you're in a well-abstracted code-base is to write wrappers around some of this functionality. Eg, if C++11 or greater is available, use the STL functionality, else use Boost and/or whatever legacy thing we hand-built. The obviously crappy part of this is that your functionality can/will diverge on multiple platforms.
Have we seen similar levels of damage in other cars that carry large battery packs and have been in head-on-collisions?
I dont really have any commentary one way or another about autopilot or the safety of batteries, I'm just thinking there are probably other accidents that have happened in the industry in similar conditions to this.
For example, the Prius and Volt have been on the road for quite some time, and both cars carry relatively large batteries (though certainly not as large as that on a Model X). When involved in head-on collisions do they see such drastic damage/fires?
Just curious. I don't know that its even fair to compare those types of vehicles given the difference in the size of battery.
I think the old prius used lead-acid batteries, IE conventional automotive batteries. This significantly reduced the risk of fire, though I don't think that was the main reason for choosing them
Having built programs that used the ffmpeg libraries (as well as x264) I have to say that a tutorial that is up to date and recent like this would have been very helpful at the time. Glad to see somebody is undertaking this effort.
I agree. ffmpeg can be inscrutable sometimes. Understanding the internal concepts is a big boost when using it. For example I've used "-avcodec" hundreds of times in the command line but I just now understood where that fit in.
I think its very exciting they were able to get the number of discrete modules up to 26. That's extremely impressive to me given the age and complexity of Java! I went to a talk a few years back from one of the contributors to this project (forget the name, sorry!) and I think if my memory serves me they had significantly fewer discrete modules at that time -- perhaps 6?
Anyhow, I think this is a great step forward for Java.
I agree with this assessment. We decided to do "kubernetes the 'sorta' hard way" by leveraging the Saltbase installer with some level of customization and full control via terraform of how our infrastructure was being allocated. I think its valuable to learn what the tool is doing if you have to maintain it. When something breaks, an upgrade has issues, or you need to better understand the system to make a decision, I feel that you gain a lot in setting up a system yourself. I think you'll be more likely to know precisely where to look to debug things. You also get closer to the tool which makes it easier to contribute back into the community. You also get the benefit of making your own infrastructure decisions. Yes k8s can provision ELBs and EBS volumes (and their equivalents in Google Cloud, Azure, etc) as well as autoscale nodes via a cluster addon, but the big moving pieces, such as instances, VPCs, Networking, etc, remain well-defined in Terraform or some other infra-as-code. That means that you can decide how to deploy that etcd cluster, how it gets backed up, whether or not its encrypted at rest, etc. Generally speaking, we just value the level of control and insight that we get out of controlling the stack definition ourselves. To some extent that may be antithetical to the purpose of k8s, since the goal of the project overall seems to be simplification and centralization of best practices of deployment.
With all that being said, kops is an incredible tool (as are others) and we used it to learn about the system and test some of the functionality for ourselves. Can't recommend it enough.
Great set of resources -- I just went through the process of defining a terraform cluster in AWS over the past few weeks, though I'm leveraging the k8s Saltbase installer for the master and nodes.
I'm curious, why no mention of AWS as a provider for roll-your-own? Is this a cost thing?
Also, I get the feeling that Ubuntu is _not_ a first class citizen of the k8s ecosystem, but perhaps my newness to the ecosystem is to blame here. The Saltbase installer, for example, only supports Debian and RHEL distros, `kops` prefers Debian, and the documentation for cluster deployments on kubernetes.io and elsewhere also seems to be somewhat suggestive of Debian and Core OS. Perhaps thats just a mistaken interpretation on my part. I'm curious what other peoples thoughts on this topic are!
Ubuntu is absolutely a 1st class citizen in the K8s Ecosystem!
The front page of https://kubernetes.io/docs/ has a bullet that links to a super simple way to deploy Kubernetes to Ubuntu on any of [localhost, baremetal cluster, public cloud, private cloud]!
See:
* Installing Kubernetes on Ubuntu: Deploy a Kubernetes cluster on-premise, baremetal, cloud providers, or localhost with Charms and conjure-up.
kops doesn't necessarily prefer debian - we support Ubuntu, Debian, CentOS/RHEL, CoreOS and Google's Container OS. One of the outputs of the Kubernetes-on-AWS efforts is an AMI that is "Kubernetes Optimized" - a 4.4 kernel, Docker pre-installed, lots of inodes etc. That AMI _is_ based on Debian, hence the suggestion is that if you don't otherwise care (and my hope is that eventually you won't), that you should probably just use that AMI. But if you do have a preference, by all means use your distro of choice.
This may be a silly question to ask, but forgive me, I dont know much about EE or battery technology:
Its my understanding that current batteries found in mobile phones, laptops, etc make use of rare earth minerals which are limited and expensive and only available from big players like China. Does anybody know if this technology also makes use of rare earth minerals?
NiMH batteries used lanthanum, but we don't use NiMH any more. Li-ion batteries use heavy metals, specifically cobalt, of which China is the largest buyer. Almost all cobalt comes from Congo though.
Cobalt is widely available everywhere, as are rare earths. Congo just happens to have a freakishly high amount of it plus cheap everything, so it is widely mined there. Unlike other technology mining easily transfers and it doesn't take much time (a few years) or money to open new mines. This battery doesn't use cobalt at all, and most newer batteries use significantly less cobalt or none at all (LiFePO4). Phones and batteries still use a lot of cobalt, and are major consumers, but the biggest consumer is machine tools.
