Live data from Hacker News

Never Update Anything

blog.kronis.dev

101–110 of 121 posts

Re: Never Update Anything

#101

The world is not static and software these days is very interconnected. Dreams of not updating only work in a unchanging world. Sadly, this world is still to be found.

Funny you're saying that. In context of the stricken crowds I've read that FedEx, UPS and SouthWest had no problems at all, because many systems run on Windows95, or even something based on Win3.1x :-) Seems they are well isolated, but networked nonetheless. Or do you think they use bush-drums and smoke signs to conduct their businesses?

That probably has more to do with not jumping on the latest fad* and installing an unattended unrestricted automatically-globally-updating rootkit on all of your critical machines.

That is generally recognizable as stupidity. And the ones that did so are now paying the price.

* compliance tactics are very prone to fads. just look at cookie banners.

Re: Never Update Anything

#102
post #87

Earlier quoted context omitted.

“static files” are nothing more than no-TTL caching strategy with manual eviction.

You’re not wrong… but “static files” ultimately are infinitely less complex than any dynamic CMS, and require no effort or brain power to migrate between (even bottom-of-the-barrel) providers

I sort of not understand why we are not using static Files more often now.

In the old days we need CMS mostly because generating links and update to certain pages were expensive. Hard Disk were slow and memory were expensive. Now we have SSDs that eliminate 99.9999% of the problem.

Re: Never Update Anything

#103

"In my eyes it could be pretty nice to have a framework version that's supported for 10-20 years and is so stable that it can be used with little to no changes for the entire expected lifetime of a system." This is what applications used to be like, before the web and internet hit and regular or even push updating became easy. It was simply so difficult and expensive to provide updates once the software was in the cu…

Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too.

> Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too.

Back in the 80s and 90s if you had bad QA you'd ship very buggy software and customers hated you because they had to live with it for months and months until the company managed to do another release. And then it was costly to ship off those floppies to every customer. So there was a very real price to pay, in money and reputation.

Then it became possible to do updates online. Initially it was a nice way to deliver an emergency fix if necessary, but you mostly continued to do nice QA'd releases every now and then.

But as with everything, when something becomes too easy it gets abused. So companies realized why do much QA (or any QA in extreme cases). Just push updates all the time and hope for the best, if customers (who are now QA) scream, push another update tomorrow. Break quick, fix quick.

It's mostly unsatisfactory if one values stable quality software.

Re: Never Update Anything

#105
There's an alternative solution: update everything, but limit your dependencies.

Example: for my (personal) projects, I only use whatever is available in the debian repositories. If it's not in there, it's not on my dependency list.

Then enable unattended upgrades, and forget about all that mess.

Re: Never Update Anything

#106
When I was the sole IT guy for a small consulting company, once I got everything working, I never updated it.

We used Microsoft office 2000 for 12 years. Never had to retrain people, deal with the weird ribbon toolbar, etc.

It's only the deranged use of OSs with ambient authority that gums up what would otherwise be stable systems.

Re: Never Update Anything

#107

Oh hey, I was wondering why the VPS suddenly had over 100 load average, restarted Docker since the containers were struggling, now I know why (should be back now for a bit). Won't necessarily fix it, might need to migrate over to something else for the blog, with a proper cache, alongside actually writing better articles in the future. I don't think the article itself holds up that well, it's just that updates are of…

For contrast, I recently had a no 1. HN hit and my Pi4 never had a core beyond 20% Yes, it’s a static website. It’s amazing how little performance you actually need to survive a HN avalanche

Yeah, I've had a few HN frontpages with sites running Django and recently Phoenix with essentially no caching or optimization running on a 256MB fly.io free tier instance with barely a noticable increase in load (just big spikes in the network/traffic graphs).

Re: Never Update Anything

#108
post #85
post #78

Earlier quoted context omitted.

> For the most part, you bought software, installed it, and used it. That was it. It never changed, unless you bought it again in a newer version And it was much better than the current situation, if you ask me.

That software did a lot less, however, and you just had to live with bugs. I knew people who just learned that they couldn’t use a feature without crashing, or had to disconnect from the internet to print, had to write their own math formula because a built in function was wrong, etc. and just worked around it for years. The first company I worked for in the 90s had a C codebase which seemed like it was half #ifdef o…

> I think the automatic update world is better on the whole

I think that we went to another extreme. Because it's so easy to update, we just ship bad software saying "we'll fix it later". And we don't.

Re: Never Update Anything

#109
I know it's this is a rather long tangent and not the main point of the article, but regarding "Docker Swarm over Kubernetes", I've had a ton of bad experiences at my employer running a production Swarm cluster. Among them:

- Docker Swarm and Docker Compose use different parsers for `docker-compose.yaml` files, which may lead to the same file working with Compose but not with Swarm ([1]).

- A Docker network only supports up to 128 joined containers (at least when using Swarm). This is due to the default address space for a Docker network using a /24 network (which the documentation only mentions in passing). But, Docker Swarm may not always show error message indicating that it's a network problem. Sometimes services would just stay in "New" state forever without any indictation what's wrong (see e.g. [2]).

- When looking a up a service name, Docker Swarm will use the IP from the first network (sorted lexically) where the service name exists. In a multi-tenant setup, where a lot of services are connected to an ingress network (i.e. Taefik), this may lead to a service connecting to a container from a different network than expected. The only solution is to always append the network name to the service name (e.g. service.customer-network; see [3]).

- Due to some reason I still wasn't able to figure out, the cluster will sometimes just break. The leader loses its connection to the other manager nodes, which in turn do NOT elect a new leader. The only solution is to force-recreate the whole cluster and then redeploy all workloads (see [4]).

Sure, our use case is somewhat special (running a cluster used by a lot of tenants), and we were able to find workarounds (some more dirty than others) to most of our issues with Docker Swarm. But what annoys me is that for almost all of the issues we had, there was a GitHub ticket that didn't get any official response for years. And in many cases, the reporters just give up waiting and migrate to K8s out of despair or frustration. Just a few quotes from the linked issues:

> We, too, started out with Docker Swarm and quickly saw all our production clusters crashing every few days because of this bug. […] This was well over two years (!) ago. This was when I made the hard decision to migrate to K3s. We never looked back.

> We recently entirely gave up on Docker Swarm. Our new cluster runs on Kubernetes, and we've written scripts and templates for ourselves to reduce the network-stack management complexities to a manageable level for us. […] In our opinion, Docker Swarm is not a production-ready containerization environment and never will be. […] Years of waiting and hoping have proved fruitless, and we finally had to go to something reliable (albeit harder to deal with).

> IMO, Docker Swarm is just not ready for prime-time as an enterprise-grade cluster/container approach. The fact that it is possible to trivially (through no apparent fault of your own) have your management cluster suddenly go brainless is an outrage. And "fixing" the problem by recreating your management cluster is NOT a FIX! It's a forced recreation of your entire enterprise almost from scratch. This should never need to happen. But if you run Docker Swarm long enough, it WILL happen to you. And you WILL plunge into a Hell the scope of which is precisely defined by the size and scope of your containerization empire. In our case, this was half a night in Hell. […] This event was the last straw for us. Moving to Kubernetes. Good luck to you hardy souls staying on Docker Swarm!

Sorry, if this seems like like Docker Swarm bashing. K8s has it's own issues, for sure! But at least there is a big community to turn to for help, if things to sideways.

[1]: https://github.com/docker/cli/issues/2527 [2]: https://github.com/moby/moby/issues/37338 [3]: https://github.com/docker/compose/issues/8561#issuecomment-1... [4]: https://github.com/moby/moby/issues/34384

Re: Never Update Anything

#110
post #85
post #78

Earlier quoted context omitted.

> For the most part, you bought software, installed it, and used it. That was it. It never changed, unless you bought it again in a newer version And it was much better than the current situation, if you ask me.

That software did a lot less, however, and you just had to live with bugs. I knew people who just learned that they couldn’t use a feature without crashing, or had to disconnect from the internet to print, had to write their own math formula because a built in function was wrong, etc. and just worked around it for years. The first company I worked for in the 90s had a C codebase which seemed like it was half #ifdef o…

We still have to find workarounds for crappy software. But with a continuous update model, we waste more time fighting with bugs because the bugs are constantly changing. Every week you have to waste figuring out what broke now. No thanks.
Post reply on HN