I think diplomacy itself can help gear a country to defend itself by creating powerful allies who will come in a time of need.
At the same time, I do not think there is any justification for war or harming others non-defensively.
The amount of money and human power we piss away with wars and conflict is so sad. Humans are the most advanced and capable complex adaptive systems in the world. Why waste such a precious resource?
Stupidly flippant but likely somewhat accurate answer: x-thousand years of tribal evolution.
With all our intelligence we're still programmed to behave in particular ways, and it takes a lot of effort to even try to break out of it, and that's only possible if you're aware of it - which most people aren't.
Hmm, I think you are correct, and from my perspective, speaking to the idea of human heuristics and biases.
Ironically, I think societies and cultures need long periods of peace (not in an extreme sense, but rather enough peace to allow for safer conflict) to have the time and ability to introspect on their heuristics and biases, as well as integrate other people's perspectives.
Having something to lose, makes it a lot more likely to bring you to reason.
It takes seconds to destroy what it took decades to build.
If someone is pointing a mortar at your house, you want to get rid of the mortar, but you also want to keep your house, so it's likely that you will look for ways to remove the mortar, that don't include it being fired.
Run me through Australia's strategic outlook if the US decides to invade us. Or if they decide Australia needs to go and starts supporting one of our neighbors in fighting us.
1) The subs are certainly not for fighting China. By the time they're delivered, assuming all else equal, China will be in a position to ignore them. People are talking about deliveries in the 2050s vs a country that can basically build an entire economy in a few decades; it'll never work out in our favour. And we can't afford to be in a war with an Asian power under any circumstances anyway, we'd probably be better off surrendering immediately rather than fighting back against China if the US's deterrence fails. Ironically we'd probably end up with better infrastructure.
Fighting China with those submarines is a similar idea to fighting the US with those same subs. The plan is not to do that. It won't work out well for us.
2) Keep going with your thought, you haven't gone far enough. If diplomacy works because you have the means to defend yourself, why aren't we fighting the US? We can't possibly defend ourselves from them, and realistically we'd probably struggle to annoy them if they attacked us via a proxy war. And yet there is no realistic scenario where they fight us. Why is that, hm?
Here’s my view of why countries don’t attack each other: The downside for the attacker has to be larger than the upside, that’s when diplomacy becomes interesting. The downside doesn’t just have to be the defense of the attacked country but also the relation with other countries. The US won’t invade Australia because they wouldn’t gain much, compared to the loss of trust by other countries. Defense from china is more important than from the US for Australia, because the “public stage” deterrent is smaller for china than the US. That’s why you need to increase the deterrent by increasing your defense capabilities. You can correct me if you disagree though.
Electrolyzing water would also give hydrogen which would make the transpiration of materials easier. I’m guessing that it would require a large amount of electricity to get enough hydrogen/oxygen from the water (they really would need a miniature nuclear reactor).
Edit: for my last comment (which I can’t edit now) I meant to say that hydrogen has a high energy content by mass but not by volume. So 1kg of the stuff has a huge amount of energy but also takes up a lot of physical space.
Adding significant BOM cost, growing physical volume, reducing battery life, creating lots of complexity to get certain apps to run on one CPU or the other and the associated cache coherency issues? So that iOS developers can test their apps on a native CPU (But still plenty of differences like screen size, no cell radio, no GPS, accelerometers, etc) Seems dubious.
But that’s specifically for Secure Enclave work (disk encryption, biometric data). I don’t think they’d want to risk someone running arbitrary code there and breaking the sandbox. (The SEP is also separate from the A-series chip in the iPhone for a similar reason, IIRC).
All images are still available on the web even delivers everything as JSON. Plenty tools like JDownlaoder can scrap everything in a seconds.
they sure have other measurements in place to stop people form doing that large scale.
At the low end it’s worth considering Fargate distinct from EKS. You don’t need to provision a whole cluster (generally 3 machines minimum) and can just run as little as a single Pod.
I tried Fargate and found it to be crappy. It is very hard to use. It is proprietary, so your app will not be portable, and your knowledge and experience will not be portable either. If you use Kubernetes there is tons of tutorials, your app becomes portable across clouds and your knowledge is portable from cloud to cloud too. GKE only costs around $60 per month for a single-machine "cluster".
I use fargate and pretty happy with it. Don't need big scale out - it supports $1M/year revenue so not huge, but LOVE the simplicity.
I just have the CLI commands in my dockerfiles as comments, so once I get things sorted locally using docker I update the task with some copy / paste. I only update occasionally when I need to make some changes (locally do a lot more).
The one thing I'd love to get my DOCKER image sizes down - they seem way too big for what they do but it's just easier to start with full fat images. I tried alpine images and couldn't get stuff to install / compile etc.
You should look into multistage docker builds, that lets you still use a full fat image for your build but then leave all the build tools out of your final image
Someone else suggested the same thing actually. Easy to get lazy when it "just works" and internet is 1gig home and office - you can see how bloat just builds up.
What is proprietary about Fargate? It's containers. I did not find any experience/knowledge (other than the basic knowledge of navigating the AWS console) that wouldn't transfer to any other container service.
For contrast, you can manage a Kubernetes deployment using standardized yaml and kubectl commands, regardless of whether the application is running on localhost (minikube), on Azure or on GKE.
BTW, AWS Lightsail has decent GUI. Alas, it doesn't support containers out of the box. The best support for Docker image-based deployment is Azure App Service.
I'm still not seeing the difference. As pointed out, what you linked is for ECS. That has nothing to do with Kubernetes, so I'm not sure why you're comparing the things on that page to kubectl commands on GKE or Azure. Of course you cannot use kubectl on ECS, because ECS has nothing to do with kube.
When you are using actual EKS (with or without Fargate), you certainly can use standardized kubectl commands.
The only "proprietary" things I see in your link is the specific AWS CLI commands used to set up the cluster before you can use kubectl, but both Azure and GCP require using the Azure CLI and gcloud CLI for cluster deployment, too. There's also setting up AWS-specific security groups and IAM roles, but you have to do those same things on GCP or Azure, too, and both of those have their own "proprietary" ways of setting up networking and security, so I don't see the differentiating factor.
> For contrast, you can manage a Kubernetes deployment using standardized yaml and kubectl commands, regardless of whether the application is running on localhost (minikube), on Azure or on GKE.
Right, and you linked to the documentation for ECS on Fargate rather than the documentation for Kubernetes Fargate, which is what was being talked about. Again, two different products.
My joke is that the unrealistic thing about Star Trek is not the faster than light travel or the matter transmitters it’s that their videoconferencing always works.
Before we sold, we had WeWork offices in Denver and NY and used a similar competitor in Austin. They worked great and we were happy with them. But they were also a commodity and we chose based on price and lack of lock-in.
