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.

I like it just because it's a single file (most of the time). I can put pretty much anything in it without having to think about how to store data on disk in a sane manner, and SQLite can handle a lot of data. You get so many good things for free: transactionality, durability, concurrent access, and an easy consistent backup mechanism.

Even if JSON blobs happen to be the most convenient way to represent your data, you can still just put those blobs in an SQLite database and maybe worry about converting them into something relational later.

I think with that wording it's easy to slip into thinking that a person's lineage has anything to do with their suitability to be educated for a specific role or how well they may perform in that role.

Nothing arises "naturally"; It's the education and access to vast support resources that creates exceptional people, and if you want more of those, you should want to ensure that the greatest number of people have access to enough resources that anyone can have a chance to make the most of their inborn advantages (whatever they may be) regardless of the circumstances of their birth.

I'd go so far as to say that integrity of state is a requirement to build robust software. If your state is ill-defined, it's pretty much impossible to write software that behaves correctly.

Sure, you can guard against some forms of bad data and fix it as it comes in (or abort with errors if your system can handle that), but in order to do anything interesting, you need to make assumptions about the data. the only operation you can perform without assumptions is the identity function, and most software requires much more than that.

You're engaging in the same sort of "fearmongering" though, by lumping everything together as if they all have the same incentives and goals.

Depending on which part of "the media" you look at, you'll get very different takes on various issues, some with significantly more substance behind them than others.

Nope. Even better: Many dialects of Finnish use "it" for everything in informal speech, so we're not just ahead in gender equality, but animal rights as well.

I can't comment on Podman specifically, but Red Hat's approach to the projects that they choose to focus on in the "Red Hat ecosystem" seems to be to just do development in upstream first and then whoever is working on the distros packages it for Fedora and/or RHEL. I don't see why they should put resources into packaging in their upstream projects; it doesn't seem to me that they're hostile to other distros packaging their software.

Packaging is a distro problem, not an upstream one, though upstreams should of course work with distro maintainers to make packaging frictionless.

Red Hat introduced modules with RHEL8, meaning they can easily make available more up-to-date versions of software if necessary. It's still not bleeding edge, but eg. PostgreSQL 13 was released on 2020-09-24 and that's available with support in RHEL 8 as a module. Similarly, you have eg. PHP 8, Ruby 3.0 and other software released after RHEL 8's initial release.

Modules are much nicer to use than the previous software collection system because they actually replace the "original" package, so it's just a straight version upgrade without having to worry about fixing configuration files etc. if it's compatible.

For me, it's about having a stable platform for something; not all (or even most) components in a software system benefit at all from following the latest releases, and what "stable" distributions give me is the ability to keep those components up-to-date security-wise very easily and without having to worry that everything could explode due to major changes when I run "dnf update" (breakage does happens, but it's rare). I can have hundreds of hosts auto-patching themselves and still sleep soundly.

Something also needs to run your Kubernetes, and that can't always be AWS.

Libraries are where unsafe belongs. Having unsafe be an explicit feature is immeasurably better compared to every line in the entire program potentially being unsafe.

Opting out of safety is fine, but safety must be opt-out to be effective, not opt-in. A standard, enforced way to tell readers where the dragons lie is super helpful.

One trick that makes SELinux on RHEL much less of a bother is to always use the system-provided default paths for data and logs, and just mount additional volumes for data at these paths.

The vast majority of SELinux trouble I've seen stems from people customizing things needlessly and then they need to adjust the default policies.

Another common problem is not separating the OS / application binaries, configuration / data and log directories, which is just bad hygiene even without SELinux. I've seen many installs where people have just dropped their stuff in /home/ec2-user and then the whole server breaks at some point because / gets filled by a sudden burst of log entries.

I have diagnosed ADD and most of your list is very familiar.

The way I things I usually end up binging through the entire book (or series) over several days. If, however, my reading spree is interrupted for whatever reason, I can just forget about what I was reading to the point where I return to it a year or two later to realize that I don't remember anything about it and have to restart.

The same effect tends to happen with any other project or habit I have. Painstakingly form a swimming habit and stick to it religiously for half a year? Doable, though extremely vexing. Then skip swimming for a week for some reason and the routine is just gone. I've had the opposite happen too though, where I just started doing workouts one day and consistently stuck to it for over 2 months with 0 effort (by which I mean I didn't have to struggle with choosing to do it. The actual physical exercise itself is a minor hurdle in comparison). Unfortunately, this habit also evaporated at some point.

If the database schema for Jira on the cloud is anything like the Datacenter version, I'm not surprised they're having a hard time restoring data. I once tried to figure out how to find duplicate / redundant project schemas by querying the database (the required APIs are cloud-only) and could not even find which tables stored half the data, never mind how they referred to each other.

Beyond trivial scale, you need good processes so that individuals can do their jobs. If you have no processes, change and development becomes extremely difficult because people will be hunting for documentation all the time, stepping on each other's toes, and making mistakes that they should not be making because they forgot a trivial procedure that was a prerequisite to solving their actual problem.

I work with a variety of different environments, and depending on the environment I can either solve my problem in minutes and get it deployed in another few minutes or solve the problem in minutes and spend hours figuring out how to safely deploy it without breaking everything. JIRA is terrible if you do anything that it offers by default, but when used properly it can absolutely help with this.

Are people's desires and aversions really something they can control? The thought feels alien to me. It's very difficult for me to even tell what I really want, let alone intentionally channel effort towards achieving any such thing.

The largest obstacles I face when it comes to achieving things is really that the things I want to do and the things I feel motivated to do are very rarely the same. Often I am extremely motivated to do things that I really don't want to be doing; I can spend hours fixated on something irrelevant and afterwards feel exhausted and annoyed because I really would rather have done something else, but my brain disagreed.

"Don't be afraid" is something that doesn't really work as advice. If I could just not have fear, what's left is just work.

I feel like the majority of the effort I have to put into things is overcoming my own brain. Whenever I get my brain to agree with what I want to do and that doing it it is worthwhile, the rest is easy. It's ignoring the billion stupid reasons my brain generates why I should not do something I want to do that is exhausting and difficult.