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.
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).
> 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.
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.
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.
> 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.
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.
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?
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.