Unpopular because it's so flagrantly ignorant. How much do you know about the "egregious" expenditures by rank-and-file federal employees just doing their jobs?
Maybe it is, but also maybe it's actually really expensive to run a country as big as the United States, and maybe people offering simple truisms and simple solutions to complicated problems are just full of shit.
$2 trillion is all of the discretionary spending including defense. Are you saying the whole federal government except for entitlements should be eliminated?
Anyone who worries about spending without talking about taxes is not serious or being deceptive. The cause of the current deficit is mostly Trump tax cuts. Plus all of the temporary spending to get out of the pandemic recession. The solution is to remove the Trump tax cuts.
> A butler has always been a person of authority, expertise, and responsibility. Why "houseboy"? Because he's Asian?
facepalm
The author describes Marc Andreessen's Gilded Age slash Roaring 20s lifestyle and attitudes, and then suggests that a hundred years ago, this person may have been referred to as "houseboy".
Marc Andreessen is the hypothetical person from a hundred years ago. It's a scathing criticism of Marc Andreessen.
Yes, I took all that from the article as well, which after all is not so subtle. Implying that Andreessen would have been a British Empire-style racist is indeed a scathing criticism.
But a hundred years ago, a houseboy and a butler were still very different people. To say that a hundred years ago this highly competent professional would have been a houseboy is, in effect, to call him one now: a no less scathing (and unintended) criticism of the butler.
No, it is bad advice, and it is absolutely not idiomatic Python. The language specification reserves them to ensure new ones can be added in the future.
This has been in the specification since, at latest, Python 2.0, and perhaps earlier.
Any you see defined outside the Python data model are entirely historical, written in contradiction to the spec. Many of them also can't be changed because there is so much code in the wild that depends on them.
Until you need to update it, or apply it to multiple environments, or any number of tasks where the concepts of configuration parameters and dependencies become important.
Edit: I'm not saying Ansible is an appropriate substitute (it absolutely isn't), rather that `kubectl -f` is not a scalable solution.
The lesson is that shockingly few people have realized is that the problem space is not, nor has it ever been, served by declarative solutions. You can describe the state you want a system to be in but there will inevitably be procedures involved to do some of the work. It is unavoidable. At the point people began developing templating around their configuration, ah, templates... which themselves have imperative language constructs awkwardly (and badly, cough Golang) embedded in them, it should have been clear to everyone with a shred of talent that it wasn't a good solution.
Declarative configuration is wholly expressible by imperative languages. The converse is not true. Declarative configuration is appropriate for declaring state (i.e., values), and not for describing procedures.
Stop using half-baked YAML crap and start using real tools.
I think the root of the issue is not that we need imperative languages for configuring cluster workloads - declarative state as an API contract between clients of the cluster and the cluster itself is a good thing. The reconciliation model is what makes kubernetes work, and that should be preserved.
But I do think we need better tools to generate said declarative state, regardless of its serialization format (yaml, JSON or other). Hand editing the raw declarative state is clearly untenable, hence the development of the various templating solutions. But I don't see an issue with using an imperative program to generate the declarative state either, as long as the declarative state is what forms the substance of the API to the cluster.
Imperative isn't really unavoidable, all imperative programs can be expressed as functional declarative programs which is much more natural to something that should be declarative in nature (I don't want to know everything you did to get/maintain your network.)
The problem is that people want to express functions as extensions to declarations in yaml, XML, etc, instead of in a functional language that is heavy on declaration.
Do you have any examples of deploying to Kubernetes with something you consider real tools? I agree with what you are saying but have found very few real world companies using real languages for this.
At work we use typescript to generate yaml files which are then synced to their respective clusters via Gitops.
It works fairly well. All cluster/namespace differences are encoded into our typescript code base, so we can take advantage of a real programming language to generate cluster specific yaml all sharing a common “base”.
Ruby/RoR values form over function. Over the past few (five or so?) years, as teams went through the transition from aggressive feature development to devoting more effort to maintenance and operations, they realized that relying on conventions as a guiding principle has a substantial cost burden that you don't pay when prefer rigor and specification.
https://www.pbs.org/kenburns/the-west/