embik

Note: this does not appear to be a Kubernetes-based solution, the "pod" part just heavily sounds like it.

I seriously wonder what HN thinks is a valid business model for writing open source software. Everyone here seems to insinuate that people want to create a business and use open source as a growth hack. But how do you differentiate those from people who want to write open source (because they believe in it) and have to have a business to support their livelihood?

This is a team of eight people that tried to do everything „right“ by changing to a FOSS license (which happened four years ago) and the changes announced here sound very reasonable (changing branding and removing undocumented APIs). But all comments are dunking on them as if they haven’t even read the article.

Why do tech companies keep using dystopian stories as manuals? The flirty tone, the voice being awfully similar to the lead actress of Her.

Next we are getting Ex Machina?

I am really sad that jsonnet / ksonnet never really took off. It’s a great way to template, but has a bit of a learning curve in my experience. I suspect that is why it’s niche.

If you like what is presented in this article, take a look at Grafana Tanka (https://tanka.dev).

My experience is that the Hoff transcends company, language and country boundaries.

> The A/B upgrade sounds a bit overkill, you can always just pop up a live distro or install a recovery system (on an old version) in a partition in case something goes wrong.

You and I can, the overwhelming majority of computer users cannot. Valve clearly focuses on building for the average person, something that Linux distributions (as much as I love them) still don’t really do (well).

The system automatically recovering from a failed upgrade is essential in a low-maintenance OS at this point.

I (recently) created kubeconfig-bikeshed, a small CLI application to manage the high number of kubeconfigs (configuration/credential files to access Kubernetes clusters) that I have to deal with on a daily basis. It was also a nice learning experience with Rust, and I have to say I was much more productive with it than I was expecting to.

https://github.com/embik/kubeconfig-bikeshed

Not everyone can look back at a 10 year long career in the industry to draw inspiration from. Especially for junior engineers, pointing out alternatives (that feel obvious to you) would be important.

It would be helpful if the post not only told you what to _not_ do (especially when it is a frequently done thing) but offered any sort of alternative.

Joke‘s on them when the EU cracks those lockdowns wide open.

Can you elaborate on that? What kind of introspection do you think the author is missing?

The post you are responding to is making the point that even though we have QA, dedicated jobs or even departments for these things … We, as a profession, still fail in releasing bug-free software. And that’s 100% correct.

Is that really something you are challenging? Which pieces of popular software you can think of are bug-free? And are you thinking of more than a handful?

> Suggesting that emergency brakes are inadequate due to one passenger failing to locate one is kinda cheap.

That’s not what I wanted to say at all - the op talked about the willingness to pull the emergency brake, but my understanding is that he was willing to but due to human error failed to find it. I didn’t mean to suggest in any way that emergency brakes are not important.

> We could also easily construe your argument as "engineers would never design a flaw"

Another thing I didn’t say. The whole original link is proof that engineers make mistakes all the time.

Not entirely true:

> Dittmann could not find an emergency brake in the corridor and had not noticed that there was an emergency brake handle in his own compartment.

The learning from that should maybe instead be to keep non-technical management out of engineering decisions. The Wikipedia article fails to mention there was a specific manager who pushed the new wheel design into production and then went on to have a long successful career.

This seems to be a very common sentiment that is not stated that clearly often, but it makes me very sad to read it.

The magic of the internet, once upon a time, was discovering content in your own time. You stumbled into that cool niche forum, found someone’s personal blog, a flash game page. It didn’t need big centralised services to be fun.

Internet users have become consumers and want to be fed content. I do not understand this sentiment at all. It feels like we are all addicted to the easy dopamine kicks of scrolling Reddit/Facebook/Twitter now.

I assume that’s for professional workstations? There were complaints about the „low“ maximum RAM with previous Apple Silicon generations if I remember correctly.

Most autoscaling functionality is implemented on top of the upstream cluster-autoscaler component, and GKE documentation claims to remove nodes when pods fit onto other nodes as well[1], so it does have the same "defragging" functionality. It might not be configured aggressive enough for their liking though (but even then, GKE has a more aggressive autoscaling profile that might do the trick).

My point is that while the original post is reporting problems with autoscaling in Kubernetes without enough details to go by, cluster-autoscaler is fairly good at its job of downsizing clusters if you take the time to a) optimize its configuration and b) make sure your workloads are configured in a way that allows downsizing clusters.

[1] https://cloud.google.com/kubernetes-engine/docs/concepts/clu...

This might be true for "stock" Kubernetes, but it seems likely that the grandparent post is using cluster autoscaling (since they mention "auto-scaled up"), for which this post is not accurate.

The cluster-autoscaler component does remove nodes with low utilization and Pods fitting onto other nodes, effectively defragging the cluster. There's just plenty of reasons for it to not drain a node (as per its FAQ[1]).

But it's highly configurable, so I wonder if the grandparent post just needed some configuration changes to suit their scenario better.

[1] https://github.com/kubernetes/autoscaler/blob/master/cluster...

Maybe that is just corporate language, but the way this is worded („distortion of truth“, „selective presentation“) seems to suggest that the quite detailed post from Gordon is truthful in its key details and Bethesda seems to be claiming that there is additional context that warranted their executive‘s behaviour. Which is … an interesting perspective, to say at least.

For what it’s worth, the subthread you are commenting on specifically talks about GKE. GKE is removing docker support, period. That’s not plainly wrong, it’s in their support document.

For most users, using docker through a CRI compatibility layer is not an option as they use some sort of Managed Kubernetes, and I am curious to hear which of those keeps supporting docker as container runtime.

> The question was did they remove support for docker. They have not.

Have they not? Note that the GP asked for GKE specifically. The support page I linked to literally says so:

> GKE will stop supporting node images that use Docker as the runtime in GKE version 1.24 and later

Removing dockershim removed the existing support for docker, because docker does not support CRI (Container Runtime Interface), the API required by Kubernetes. You can go through a third-party solution that adds CRI support on top of docker, but most managed Kubernetes offerings simply removed docker support.

I don't see any argument supporting the claim that docker is the "best word" to describe containers. I am also not aware of ambiguity for the term "(Linux) container" when it comes to operating/deploying software. What else does it mean in that context?

They have, with 1.24[1], following Kubernetes upstream. If you are an end user nothing is really going to change from this though, because docker produces container images that can be used in other container runtimes (and in fact, containerd is what powers docker underneath today anyway). But that's why it's so important to explain that containers != docker, otherwise "removing docker support" seems really scary.

[1] https://cloud.google.com/kubernetes-engine/docs/deprecations...

I am very much aware of this, but that's exactly what I am arguing. Articles setting out to explain Kubernetes should not perpetuate the false equality of docker and containers.

> Kubernetes x Docker: Best Friends Forever

> Whenever you hear Kubernetes, you’re probably going to hear Docker in the same sentence. Kubernetes and Docker are like peanut butter and jelly—they’re a perfect pair.

For what it's worth, this article was originally written in October 2021, but even at that point it was clear that Kubernetes would remove support for docker. In fact it has already with Kubernetes 1.24. Not exactly "Best Friends Forever". I wish people writing this kind of introductory blog posts would take the time and just quickly explain container runtimes instead of just mentioning docker and be done with it.

I know copying from Stackoverflow is like a running gag for programmers at this point, but how does this extension deal with the fact that snippets on Stackoverflow do have a license (https://stackoverflow.com/help/licensing)? It seems it should add attribution automatically given it is copying results verbatim.

Unrelated to that, I’m concerned that people use Stackoverflow this way. It’s not the code on its own but the context and explanation that usually help me figure out my problem.

I disagree with this, at least on moral grounds, for at least one specific reason: social media is super aggressive when it comes to pushing advertisements into your feeds. LinkedIn, Twitter, probably Facebook and others (I don’t have FB so I don’t know how it looks exactly) mask advertisements as posts. They want these to get past your mental barrier, to look like they were endorsed by someone you know. That’s gotta be result of careful psychological research.

If you are A/B testing your users to get past their defenses, you should be at least somewhat responsible for not selling them total bullshit.

> Apple TV otherwise feels superficial and fake in a way to me. Shows like For all Mankind and another one. They feel sterile.

I never found For All Mankind or any other Apple TV+ show to be sterile (well, maybe apart from Severance, but that is deliberately done) - to me, they have an unparalleled production value. Nothing comes even close in the streaming landscape. I wonder if that is creating that feeling for you.

I‘ll add a comment to reflect my own experience: I’m quite happy with Apple Music, both on iOS and macOS. Sometimes I get „not authorised“ errors when playing something new and that is annoying, but other than that it just works for me as a casual user.

In comparison, Spotify has grown overly complex and feels weird in terms of UI responsiveness to me.

I am pretty sure that OP is looking for this: https://en.wikipedia.org/wiki/Cooperative - so a tech startup that is owned by its employees, a worker cooperative.

> no data collection (besides google analytics)

No offense but this made me chuckle. „No data collection except a hook for the largest data collection machine on earth“