When using Claude Code, it's possible to opt out of having one's sessions be used for training. But is that opt out for everything? Or only message content, such that there could remain sufficient metadata to derive useful insight from?
It's not setting an example if you shift responsibility to someone else.
Setting an example would be just doing without the things he doesn't agree with. Need to make a call but only other people's cell phones are available? Well, you don't make the call. Need wifi but no open networks are available? Well, you don't get wifi. Is this even more inconvenient than the already-inconvenient use of other people's cell phones or wifi logins? Absolutely. But it's actually sticking to your principles.
Live like the Amish in 2026 (though I assume they have phones now).
It's not setting an example. We have a word for it and it's called being a mooch.
The attitude is consistent with that famous video where RMS explains that he's "never installed GNU/Linux" because he could just ask someone else to do it for him, and suggest others should do the same.
For that matter, why own a car if we can borrow someone else's? Especially with license plate readers and traffic cameras everywhere, who wants to be tracked? Let your friend be tracked instead. That is the level of logic here.
First people call him "outside the boundaries of reality" then demand he lives like Amish... Look who is removed from reality now. How would he even work for the FSF's goals, if he were to follow silly advice like that? Apparently, whatever he does, he can't do right by every naysayer's standards. What many people miss is, that even Stallman admits, that you don't have to go cold turkey free/libre only, but it is already a step in the right direction to do what you can, accepting an inconvenience in exchange. Many people will rather bury their head in the sand than to accept any inconvenience at all.
I used kinesis advantage for 15 years, switched to a glove80 for the past 2, but recently went back to kinesis with an advantage2. The glove80 is very nice, but my hands are big enough that the kinesis thumb cluster works better for me and the cherry mx brown switches are much more satisfying than the low profile chocs.
So ymmv, but for those with larger hands, it may make sense to try a kinesis.
Have you heard of OpenShift 4? Self-hosted Kubernetes by Red Hat. Every little piece of the control plane is its own 'operator' (basically a microservice) and every operator is developed in its own repo.
A github search for 'operator' in the openshift org has 178 results:
It's just as easy? When you have a monorepo with 5 million lines of code, you're only going to focus on the part of the code you care about and forget the rest. Same with 50 repos of 100,000 loc.
Enforcing standards means actually having org level mandates around acceptable development standards, and it's enforced using tools. Those tools should be just as easily run on one monorepo than 50+ distributed repositories, nay?
Even in the best case of what you are describing, how are these tools configured and their configuration maintained except via PRs to the repos in question? For every such change, N PRs having to be proposed, reviewed and merged. And all this without considering the common need (in a healthy project at least) to make cross-cutting changes with similar friction around landing a change across repos.
If you wanted to, sure, applying enough time and money could make it work. I like to think that those resources might be better spent, though.
Kozliks' Triple Crunch is superb to make salad dressings as it adds a lot of texture and flavour. Their maple mustard is also very good for this purpose.
Not sure why you’re being downvoted. OpenAPI schema generation is one of the most challenging elements of developing with CRDs. Anyone who is not an apimachinery SME is likely to struggle at some point to get their schema generated as expected.
tl;dr If you’re operating with CRDs at trivial scale, you probably having nothing to worry about. But operating with CRDs at scale is a different story and suggests careful testing with the specific applications involved.
——-
The usage patterns of native k8s types and the implications those patterns have on the scalability and reliability of etcd and the apiserver are relatively well-understood. CRDs can be a wild-card, though, and afaik testing efforts thus far have not investigated worst-case usage of CRD-based applications.
As commonly deployed, CRDs are served from the same apiservers and etcd cluster that serves the native types for a k8s cluster. That can result in contention between the CRDs supporting 3rd party additions to a cluster and the native types critical to the health of a cluster. This kind of contention has the potential to bring a cluster to its knees.
Efforts like priority and fairness seek to ensure that the apiserver can prioritize at the level of the API call. But that won’t prevent watch caches from OOM’ing the apiserver if excessive numbers of CRDs are present. The judicious use of quotas could head off the creation of an excessive number of objects, but it’s not just count that matters - the size of each resource is also a factor.
In theory, CRDs could be isolated from native types by serving them from an aggregated apiserver backed by a separate etcd cluster. afaik this not a supported configuration today, and even if it were the additional resources required to support it (especially the separate etcd cluster) may be prohibitive for many use cases.
I agree with all of this, with one nitpick intended to self-aggrandise.
You can actually nominate particular types be stored in particular etcd servers -- GKE does this to put Events into a separate etcd from everything else.
However, it still has problems. Firstly, you can only define it for inbuilt types. Secondly, it's common for different objects to cross reference each other through objectRefs and the like, which behave badly when you effectively perform a join in the API server over multiple etcds.
>"You can actually nominate particular types be stored in particular etcd servers -- GKE does this to put Events into a separate etcd from everything else."
The --etcd-servers-overrides flag can do it. I could swear I'd seen a proper writeup in the Kubernetes docs, but couldn't find it again.
What I said was slightly wrong. It's not that you nominate Kinds, it's that you nominate which etcd servers get which etcd key paths. You can essentially work it out because the path structure is consistent.
Thanks for the insights. I was curious about this however:
>"But operating with CRDs at scale is a different story and suggests careful testing with the specific applications involved."
Do you mean the number of different CRDs deployed here or just the number of custom resources created? Or is it the same concern with either? I'd be curious what you are defining as "scale" as well?
The number of deployed CRDs is not likely to be an issue. The number and size of custom resources (CRs - instances of CRDs) is potentially an issue.
Scalability is relative, and depends on many factors including but not limited to:
- the resources available on the hosts running apiservers and etcd members
- the number and size of resources (custom and native) that controllers will maintain
Relatively speaking, a cluster of a given size might be perfectly capable of handling on the order of many thousands of resources . Push that an order of magnitude and the overhead of serving LIST calls - marshaling json from etcd to golang structs for apimachinery and back again for sending over the wire - could exhaust an apiserver’s memory allocation. And since the impact of resources is cumulative, any one application relying on lots of CRDs might not destabilize a cluster on its own but might well contribute to an unhealthy cluster when running alongside similarly CRD-heavy applications.
The key takeaway is that the kube api is best thought of as a specialized operational store rather than a general-purpose database. Anyone wanting to rely on CRDs at non-trivial scale would be well-advised to test carefully.
