I have a bunch of volumes that I'd like to get automatically attached and mounted to nodes on which their respective workload runs (which are automatically scheduled) who automatically fetch and mount their config files and secrets from a HA DB on demand. I also need some internal loadbalancing and integrations with something like certbot for all of my web workloads. Id also like to make sure that I get metrics and logs from every workload in some form.
Thats basically it for starters, what non-technical solution do you propose?
So you propose to just let Ops personnel handle attaching volumes and renewing certificates, that these arent technical problems but just one of team structure?
Please, do describe your solution for the concerns above. So far Ive only seen equivalents of Greenspun's tenth rule
> if you are a reasonable person and integrate you will be treated as one of their own.
You won't, even if you were born and raised here - 3rd generation Turks get treated worse after 60 years than Ukranians after 4, let alone someone with an arab name, all else being equal[1]. This is natural in almost all nations for its humans in all of them, but the rampant arrogance and hypocrisy is exceptional and one does no good reinforcing it.
My hot take about Turks struggling to integrate: The didn't try hard enough. They held on to too much of their Islamic religion and culture. It didn't mix well with the primarily Christian religion and culture of Germany. The Ukranians have much more culturally in common with Germans which is why they have integrated so much faster.
You are describing assimilation, not integration, also disproven by the fact that the name alone is the only differentiator in this example. Plenty of justifications will be found ex-facto in any case, all are excuses.
I'm not claiming any nation to be above racism, in fact globally most are worse, but this one is really high on its own supply.
They are not excuses. If you move to a foreign country but 100% keep your own culture without taking up the culture of the host country then you have not integrated and the locals are right to not want you there.
"3rd generation Turks"
Because they are famously a case of not having assimilated to Germany but instead over-assimilated to an islamist-conservative Turkey.
"Q: Where would you live if you were a hyper-nationalist Turk?
A: Germany"
It has nothing to do with interpreters or JIT, it has nothing to do with npm at all. All package managers have the insane security model of "arbitrary code execution with no constraints".
It just so happens that all of those languages share the worst design points, such as the need for a package manager at all and the classic "eval and equivalents run arbitrary code".
>All package managers have the insane security model of "arbitrary code execution with no constraints".
Not all of them, just the most popular ones for these highly sophisticated, well thought-out bunch of absolute languages.
I tend to agree but think npms post install hook is a degree worse. Triggering during install, silently because npm didn't like someone using the feature to ask for donations, is worse than requiring you to load and run the package code.
> The kraken known as Kubernetes might never have been needed if Plan9s features were adopted.
Which Plan9 features exactly give me a unified API layer to handle workload scheduling incl. fault tolerance, flat networking across a cluster or service discovery?
Containers are an implementation detail and not what Kubernetes is fundamentally about.
Let’s be clear about one thing: Kubernetes is an operating system on top of Linux which exists solely because operating systems don’t provide what it needs already. I’m saying that operating systems should provide scalable ways to launch applications securely across many physical machines natively. Plan9 offers that, and it has for 30 flippin years.
Plan9 has those things out of the box if you configure them. Fault tolerance, flat networking across a cluster, and service discovery. And if I’m wrong about that (my knowledge of both Plan9 and kubernetes is incomplete) then it would almost be trivial to implement given what plan9 has out of the box. In fact, I think the built-in network database can do all of these things if you put the relevant data in and use it. It was designed for these exact things.
Plan9 is designed to be deployed as lots of physical systems all working cooperatively. User systems and servers in a server room, both. A program that lives on computer A can run using the CPU of computer B and the networking of computer C. Natively. It can look up the address of any service via the network database (provided that info is put into the database when that service is started) and all of it. Note that I am not talking about DNS. That is separate from the network database.
Plan9 is different and it is superior in many ways.
Unix was built with the assumption that end users had terminals and that computing was centralized at the server. That assumption is no longer even remotely true. Yet we still cling to it as if it is ideal. It is not.
Plan9 was built with the assumption that everyone had capable computers at their desks and that people seated together often worked on things together. Closer to where we are today, but not quite. Today we have near-supercomputers at our desks in the form of development machines and servers of all descriptions in the server room, both more powerful and less powerful than our local machines.
If Plan9 were designed today it would be different, but the core features would remain.
And if you look at the source for Plan9 you’ll see that they got a hell of a lot done with very few lines of code. They were very, very “pro-simplicity”. Go read it and see how they did it. Then count the lines of code in Kubernetes and see which is bigger and more complex and then ponder that for a bit. It would have been easier to write an operating system to handle those workloads natively than it was to write Kubernetes.
I read your comment as in, comparing to node, my bad.
With regards to Rust, crates are packages which may include opaque binaries, e.g. serde_derive, and the stdlib is weak, so imports of thousands of lines of code are basically necessary for otherwise fundamental features like async.
It's probably easier to add dependencies in Go, but in the end people/projects don't.
Thats basically it for starters, what non-technical solution do you propose?