chousuke

I think "core" kubernetes is actually pretty easy to understand. You have the kubelet, which just cares about getting pods running, which it does by using pretty standard container tech. You bootstrap a cluster by reading the specs for the cluster control plane pods from disk, after which the kubelet will start polling the API it just started for more of the same. The control plane then takes care of scheduling more pods to the kubelets that have joined the cluster. Pods can run controllers that watch the API for other kinds of resources, but one way or another, most of those get eventually turned into Pod specs that get assigned to a kubelet to run.

Cluster networking can sometimes get pretty mind-bending, but honestly that's true of just containers on their own.

I think just that ability to schedule pods on its own requires about that level of complexity; you're not going to get a much simpler system if you try to implement things yourself. Most of the complexity in k8s comes from components layered on top of that core, but then again, once you start adding features, any custom solution will also grow more complex.

If there's one legitimate complaint when it comes to k8s complexity, it's the ad-hoc way annotations get used to control behaviour in a way that isn't discoverable or type-checked like API objects are, and you just have to be aware that they could exist and affect how things behave. A huge benefit of k8s for me is its built-in discoverability, and annotations hurt that quite a bit.

Things can be simple to fix but actually getting people to implement the fix won't be there are incentives against it.

They are two different problems.

I like abstractions when they are transparent enough that it's easy to tell how it could be implemented one layer down.

There might be many implementation details that you hide under the abstraction, but if the interface is so abstract that I can't envision a straightforward implementation of it just based on the interface, there's probably something wrong with the abstraction.

Additionally, if the behaviour of the implementation conflicts with the simplified model communicated by the interface, that'll also cause issues.

The problem is that a secure, verifiable computing environment is also important for your privacy.

If you use this system with free software components, the dystopia won't materialize. It's the lack of transparency with proprietary components that causes problems.

I've learned that sometimes, there's literally nothing you can do to directly solve a problem; you might not even know what the problem is, so how could you come up with solutions to it.

In those cases it helps me to then think that maybe there's something in my circumstances that is creating my problem, rather than it being a problem with me directly.

For example, if your problem is that it's difficult to get out of the house for a daily walk, a solution to "just do it" will not accomplish anything. It's extremely difficult to just start wanting something out of thin air.

However, if instead of focusing on "how do I go for a walk" you think about "what am I doing when I go for a walk", you immediately open up questions that are very easy to act on: Are you dressed comfortably? Is the path you take for your walk enjoyable, or do you have options? Is there too much noise? Maybe headphones would help.

These are things that are easy to try and change, and free you from having to blame yourself for lacking some ill-defined quality of "having willpower" that no-one can even measure.

If there's something you can easily change, but don't want to, then you know it's a problem with you, and you need to deal with it accordingly. But many things are not a problem with you.

I use the walking example because I literally solved my own "I don't want to go for walks" problem by realizing that I was habitually walking along a noisy road and I hated that and not the walking itself; once I found a more pleasant path, the "chore" became something that I could enjoy instead. My problem wasn't "I'm lazy and I hate walking", it was "cars are noisy and the environment is too grey"

I'd say that if you have a tight-knit team, you are already doing the very opposite of treating people as tools. There's nothing wrong with having a shared understanding of a goal and then assuming a specific role in the effort to accomplish that goal; people are very good at that.

The problem is when you think of people the same way you think of a hammer when you use it to hit nails: The hammer doesn't matter, only that the nail goes in.

"Best practices" are just a summary of what someone (or a group of someones) thinks is something that is broadly applicable, allowing you to skip much of the research required to figure out what options there are even available.

Of course, dogmatic adherence to any principle is a problem (including this one). Tools can be misused, but that doesn't really affect how useful they can be; though I think better tools are generally the kind that people will naturally use correctly, that's not a requirement.

it's not that "best practices" or any of those things are what causes trouble; it's failing to recognize that they're just tools, and people will still be the ones doing the work. And people should never be treated as merely tools.

You can use all of those things as to enable people to do things better and with less friction, but you also need to keep in mind that if a tool becomes more of a hindrance than a help, you should go looking for a new one.

If there's one thing that is true in this world, it's that you can't rely on people not fucking up.

All you can do is try making fuckups difficult by figuring out how to implement systems where doing the right thing is the path of least resistance. You won't stop fuckups, but a system where people will do the right thing 90% of the time instead of 50% is so much better.

It's a bit difficult to disagree with "not everything", because that's obviously true; not everything even can be perfectly analyzed.

However, I think you can (and should) try to at least maintain awareness of your behaviour and its effects, but only because if you don't, you may actually end up acting in ways that contradict your values; or if your values are ill-defined or vague, you might end up not understanding what it is that really matters to you. I think rationality is a necessary part of having a well-defined value system, even if the axioms are arbitrary. "Letting people enjoy things that aren't harming anyone" is a rational decision based on my value system.

What I can use rationality for, really, is figuring out if there's something I'm doing that's actually in conflict with my own values, or if there's something I can do to nudge the world (or at least my own life) to have more of the things I value.

Oh, I didn't really read it as a critique; mostly just the phrasing of "giving another commercial advantage" made me want to comment since it can be read as if that's the (or even just a) purpose of the rule.

I don't really see it as "giving" a commercial advantage to anyone if the new rule's purpose is to prevent something harmful and someone happens to benefit because they're already not doing that harmful thing.

In my view it's really a separate issue if SpaceX has too many advantages and that levelling the playing field somehow would be useful; allowing companies to grow too powerful does cause problems, and I don't think there's a moral requirement for regulators to be "fair" when dealing with corporations. They are not humans.

The need for that sort of intervention should not keep us from instating otherwise beneficial rules, though.

Steampipe is pretty much "just" PostgreSQL with a foreign data wrapper and some fancy extras on top. The data is in tables from the database's perspective, so pretty much everything you can do with PostgreSQL, you can do with steampipe, including creating your own tables, views, functions and whatnot.

the fun part of that query is that it'll search across all regions that you have configured steampipe to use. If you did that in Python, you at the very least have to manually iterate over each region, handle pagination yourself and combine the results.

It gets much more convenient when you want to ask more complicated questions like "What is the most used instance type per region" or "How much EBS capacity do instances use across all regions, grouped by environment tag and disk type?"

Steampipe is unbeliveably powerful.

Writing custom scripts for even the simplest of queries comes nowhere near the convenience of using PostgreSQL to get what you want. If you wanted to find and report all instances in an AWS account across all regions, with steampipe it's just:

   SELECT * FROM aws_ec2_instance;

Even the simplest implementation with a Python script won't be nearly as nice, and once you start combining tables and doing more complicated queries, there's just no competition.