Good for you. There is plenty of hardware out there without TPM 2.0, that is not allowed to upgrade, even if they in every other aspect are more than capable enough.
And there are many windows insiders publishing ways to bypass secure boot checks in order to install (or create check free installers) Win 11 on Win 10 capable hardware that lacks secure boot or Trusted Platform Module 2.0
It also shows that these machines are going to be rendered obsolete for no particular technical reason, other than presumably to sell more machines. Line must go up.
Yeah. I can't get the amount of hate seen here either. It's super natural to read and has very few concepts to learn. Just resources, lists, sets, dictionaries, variables, ternary operator, function calls and templates. Paired with a LSP and syntax highlighting it gets even easier to see the boundaries between code and variables. The two different ways to write dicts are a bit strange and foreach has some gotchas but honestly not a big deal. Especially not when put in comparison to YAML which has nothing even close and even more invisible footguns. Seeing comments like "it does not have if-statements". Duh, it's not imperative, for many good reasons. Not understanding that yeah it's clearly a skills issue.
You can be declarative and still have imperative constructs hidden behind pure functions let's say. That's how Ansible does it - it is super useful to define a custom filter that's called like "{{ myvariable | my_filter }}" but underneath there is a bunch of imperative Python datastructure wrangling (without visible side effects, of course - just in memory stuff), with arbitrary code. Doing the same in HCL is I believe impossible in general case.
You could have sane defaults for something running locally. Take Jenkins as example, all you do is start it up and give your agents an SSH key. That's it, you get a distributed execution environment. Not saying Jenkins does what K8s does, but from an operational standpoint, it shouldn't have to be much different.
I invite anyone to try reading https://kubernetes.io/docs/setup/production-environment/. It starts with "there are many options". Inside every option there are even more options and considerations, half of which nobody cares about. Why would i ever care which container runtime or network stack that is used. It's unnecessary complexity. Those are edge cases, give something sane out of the box.
Say what? Protobuf may be type safe but it is far from a configuration language, can you even refer to variables or do loops. Unless you are thinking about serializing it with builders in code, which takes away the benefit of declarative configuration. It's also not readable without tooling. As parent said, this really sounds like refusal to learn something new.
Helm supports typing the values passed to the Chart but most charts aren't providing it. Most fields within out-of-the-box Kubernetes resources are using well-defined typed.
As much as Helm is prone to some type of errors, it will validate the schema before doing an install or upgrade so `version: 1.30` won't apply but `version: "1.30"` will.
I don't have any strong opinions about etcd, but man... can we please just have one solution, neatly packaged and easy to deploy.
When your documentation is just a list of abstract interfaces, conditions or "please refer to your distribution", no wonder that nobody wants to maintain a cluster on-prem.
Yeah, that was Brian Cantrill's realization when for the sake of learning he rewrote a part of dtrace in Rust and was shocked when he saw his naive reimplementation being significantly faster than his original code, and the answer boiled down to “I used a BTreeMap" in Rust because it's in std”.
hmm.. i wonder how it would compare then with clang+linux, clang+stl or hotspot+j2ee.
reminds me a bit of the days when perl programs would often outrun native c/c++ for common tasks because ultimately they had the most efficient string processing libraries baked into the language built-ins.
how is space efficiency? last i checked, because of big libraries and ease of adding them to projects, a lot of rust binaries tend to be much larger than their traditional counterparts. how might this impact overall system performance if this trade-off is made en-masse? (even if more ram is added to counteract loss of vm page cache, does it also start to impact locality and cache utilitization?)
i'd be curious how something like redox benchmarks against traditional linux for real world workloads and interactivity measures.
pretty cool! in isolation looks awesome! i'm still a little curious about the impacts increased executable image size, especially in a complete system.
if all the binaries are big, does it start to crowd out cache space? does static linking make sense for full systems?
Good for you. There is plenty of hardware out there without TPM 2.0, that is not allowed to upgrade, even if they in every other aspect are more than capable enough.
reply