Presumably because those markets are difficult to break into whereas Germany can sell defense equipment to allied countries pretty easily (they don’t need to compete with China because Germany’s allies largely don’t want to be dependent on China militarily for geopolitical reasons).
> The machine is a beast and I can serve a lot of users with it. In fact, and quite funnily, I already serve much more users with it than a lot of my older clients do with their software running on expensive k8s setup because „scale“ :-)
Honestly even if you have a single server, running k8s (or maybe Docker Compose for really simple cases) on it is still the simplest way to manage it (assuming you have more than 1 service, anyway). One configuration file format, one CLI tool, zero special paths to memorize, no filesystem permissions to configure, pretty good security out of the box, access to a whole bunch of helm charts and operators (for example, cert-manager, external-dns, prometheus, alert-manager, some logging operator for centralized logging with a decent UI and search, and a postgres operator for backups / replication / failover), etc.
I don’t disagree. What you know matters, but I think it’s a lot easier to learn Kubernetes than it is to learn all of the disparate tools that you need to know to cobble together something similar. Moreover, because Kubernetes is somewhat standardized, you are much more likely to be able to find quality sources on the Internet (or LLLMs, nowadays) and similarly you’re much more likely to be able to find personnel who are familiar with it compared to some bespoke alternative.
It’s also worth noting that Kubernetes is conceptually quite simple—once you realize that it’s just a database of resources that are being watched by controllers, things start to click into place and it feels much simpler.
In some sense Kubernetes is a bit like democracy or capitalism—it’s the worst in its class except for everything else that has been tried. :)
> Capitalism winning does not show it is better as there are a lot more factors. ... Google could have built something else and they still would have succeeded at doing what they did.
Maybe Google could have built something better than Kubernetes, but my point was that this doesn't do me any good. I can't _use_ the hypothetical better-than-Kubernetes product because it's hypothetical. So in the world of things that actually exist, Kubernetes is best in class despite the many valid criticisms of it.
> In my opinion, everything you wrote are opinions
Yes, my comment was my opinion.
> Installing and managing rke on bare metal was more difficult than doing the same with nomad for me.
Maybe Nomad is better. I haven't used it. I'm skeptical that it has the ecosystem breadth that Kubernetes has, but I'm happy to be wrong.
> Or another example, installing clickhouse using apt was easier and worked better than doing it with docker.
That's not really a useful comparison because (1) a system typically involves a lot more than just a singular database and (2) running a system involves a lot more than getting the software onto the machine. If you want to make a meaningful comparison, you need something like Ansible or Cloud Init to invoke apt and to wire everything together and at that point Kubernetes is _likely_ already easier. Especially when you consider logs, metrics, certificates, DNS, etc.
At my company, the executives have been saying things like "AI will let us do more with less", so they preemptively encourage attrition. Now the people with the skills to potentially automate away work (including via AI) can't get to it because they are now backlogged by doing the manual work themselves that they might otherwise be automating away. What's more: the way they "force attrition" aren't directly via layoffs which might let them target the lowest performers, but rather they give shitty pay raises across the board, which means the top performers leave as they have the most incentive to leave (they're the most able to get higher paying jobs elsewhere).
I'm not one to invoke "incompetence" willy-nilly, but I'm having a hard time explaining these policies apart from it.
Anyway, I bring this up because it didn't quite fit into your 3.5 rubric.
I am seeing this first hand. A light year for layoffs (below 5 percent), a couple of months after a universally unpopular end of year comp, where exceeding expectations meant you get a raise right around inflation (3 ish percent).
Good people are leaving, people who can't, don't. It's hard not too see how it dilutes talent.
One of the consequences of having bean counters run tech companies.
Yep, this is the way. Linux is just a platform for running services on one or more computers without needing to know about those computers individually, and even if your scale is 1, it's often easier to install k3s and manage your services with it rather than memorizing a bunch of disparate tools with their own configuration languages, filepath conventions, etc. It's just a lot easier to use k3s than it is to cobble together stuff with traditional linux tools. It's a standard, scalable pane of glass and as much as I may dislike kubectl, it's worlds better than systemctl and journalctl and the like.
Even if using just one VM, I'll probably slap k3s on it and manage my application using manifests. It's just so much easier than dealing with puppet or chef or vanilla cloud-init. Docker compose works too, but at that point it's just easier to stick with k3s and then I can have nice things like background jobs, a straightforward path to HA, access to an ecosystem of existing software, and a nicer CLI.
1. People expect k8s to be an opinionated platform and it's very happy to let you make a mess
2. People think k8s is supposed to be a cross platform portability layer and ... it maybe can be if you're very careful, but it's mostly not that
3. People compare k8s/cloud/etc to some monolithic application with admin permissions to everything and they compare that to the "difficulty" of dealing with RBAC/IAM/networking/secrets management
4. People don't realize how much more complicated vanilla Linux tooling and how much more accidental complexity is involved
This feels like the microservices versus monolith problem. You can use cloud services or not, and that's orthogonal to running your app in Kubernetes or in a VM.
Similarly, I suspect (based on your "hardening" grievance) that a lot of your tedium is just that cloud APIs generally push you toward least-privileges with IAM, which is tedious but more secure. And if you implement a comparably secure system on your single VM (isolating different processes and ensuring they each have minimal permissions, firewall rules, etc) then you will probably have strictly more incidents and debugging effort. But you could go the other way and make a god role for all of your services to share and you will spend much less time debugging or dealing with incidents.
Even with a single VM, you could throw k3s on it and get many of the benefits of Kubernetes (a single, unified, standardized, extensible control plane that lots of software already supports) rather than having to memorize dozens of different CLI utilities, their configuration file formats, their path preferences, their logging locations, etc. And as a nice bonus, you have a pretty easy path toward high availability if you decide you ever want your software to run when Google decides to upgrade the underlying hardware.
For what it's worth, text selection has been badly broken on iOS for at least a decade and autocorrect has been steadily getting worse for probably the same amount of time, and these are features that affect the mainstream segment of Apple users on a daily basis. Apple seems generally happy to let bugs go unaddressed for years and years regardless of how many people they affect or how often.
It’s really really inconsistent. Sometimes select all is available, sometimes not. Sometimes the handles don’t work. Selecting text in a scrollable region is fiddly, etc.
I’ve seen an insane drop in the quality of swipe typing recently as well. To the point where I’ll often go back to regular typing. I’ve made maybe six or more corrections just to this paragraph alone.
I think swipe typing suggests words inconsistent with any higher level language model, like word tuples, when proposing words which are possible matches for letter sequences swiped.
and it drives me crazy too.
I've just had good luck it seems with text select.
Have you found any way to do a Find within a span of text on iOS? That would be very useful, but I haven't seen it.
I generally agree, but I had the misfortune of having a tiny grain of something (it was truly microscopic) wedged between my screen and the tiny rubber gasket around the edge and that completely disabled my screen and cost $800 to repair. I'm glad they moved away from the thin obsession, and I generally agree that the new design gives the impression of robustness even if that wasn't my experience. :)
> management would have no way of regulating or maintaining such a bizarre setup
What kind of regulation is needed? What about this is bizarre? If you’re concerned that these systems might be a fire hazard, that’s already a problem (space heaters, heating blankets, hot plates, etc). If you’re concerned that these systems won’t play nicely on a shared AC line, that’s already a problem (e.g., motors). I don’t see anything “bizarre” here.
They provide a supply that bypasses the circuit's fuse. A malfunctioning device (not a dead short) might draw more current than its plug is rated for. E.g. a NEMA 5-15 plug is rated for 15A, it needs to be installed with 14AWG (minimum) wire, rated for 15A at +30°C temperature rise over ambient, and a 15A breaker. Loads on the circuit must not draw more than 80% of the circuit's rated current continuously, 0.8 * 15A * 120V = 1,440W (12A). US devices aren't required to be fused, it's possible for one to malfunction and draw more than the 12A max, without being a "dead short". If that happens and it draws, say, 16A, and you've got a 4A solar panel on the circuit then the breaker will see 12A, the solar panel will see 4A, and the wires in the circuit will see 16A, exceeding their rating & posing a fire hazard.
reply