Live data from Hacker News

Never Update Anything

blog.kronis.dev

111–120 of 121 posts

Re: Never Update Anything

#111
post #34

We're being paid to migrate our hardware boxes programmatically to Windows 10 IoT LTSC so that new boxes ship with 10+ years of security. We're still supporting some XP devices (not connected to the internet.) So to anyone depending on us: You're welcome. But let me tell you something: Long-Term Support software mostly doesn't pay well, and it's not fun either. Meanwhile some Google clown is being paid 200k to fuck u…

The fucking up of Fitbit and the rewriting of Wallet are not the engineers' fault. These kind of projects are mostly decided and planned by PMs: clueless and incompetent PMs. For payments in particular it was not even just an incompetent PM, but an incompetent director that saw the success of the NBU Paisa payment in India and thought the U.S. would be the same. The engineers are at most just complicit. Those who are…

Lead engineers and architects chasing resume-filler projects are absolutely part of the problem

Re: Never Update Anything

#112
post #108
post #85

Earlier quoted context omitted.

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.

Hence the rest of the quoted sentence. I think removing barriers to fixing bugs is good but companies need to feel more pressure to do so.

Re: Never Update Anything

#113
post #104

Or use NixOS/Guix Systems instead of living in the stone age of containers...

I ran into critical issues with some NixOS packages I needed, the maintainer doesn't seem to care about my use case, and I can't for the life of me understand the Nix language enough to fix it myself. Have stopped using NixOS because of that.

If Nix language was replaced with something sensible I'd jump back in excitedly.

Re: Never Update Anything

#114
post #113
post #104

Or use NixOS/Guix Systems instead of living in the stone age of containers...

I ran into critical issues with some NixOS packages I needed, the maintainer doesn't seem to care about my use case, and I can't for the life of me understand the Nix language enough to fix it myself. Have stopped using NixOS because of that. If Nix language was replaced with something sensible I'd jump back in excitedly.

The point is not much the project per se but the concept, Infrastructure as Code, OS as code. So far NixOS is a relatively small ecosystem, in a complex community situation with the main sponsors, a mil-tech company, who have got a wave of backslash for debatable reasons, Guix System on other side it's mostly a French INRIA project focused more on HPC than anything else, so both have their corners, but they show a modern way to develop and deploy OSes as OpenSolaris (since it was before IllumOS fork) show the first integration of storage (zfs) and package system (IPS) and bootloader (with the boot environment concept), somewhat badly copied later by FreeBSD and partially on GNU/Linux with a set of scripts.

ALL OTHER OSes/distro are still stuck in the '80s in that sense and most people seems even unable to understand. On storage alone the famous "rampant layer violation" and the absurdity of btrfs and stratis "against" zfs are really good examples of blind tech reactionary behaviors by high skilled people and their outcomes a showcase of why we damn need to innovate instead of shooting ourselves in the feet switching from something obsolete to something even worse (like the now-almost-finished full stack virtualization on x86 and thereafter the paravirtualization/container mania still current) layering crap on crap with more and more unmanageable infra with enormous attack surfaces.

Another small and relatively known example: Home Assistant project: apart of their design, they choose to distribute a python application as a GNU/Linux entire distro because to the such move seems to be commercially sound and many others choose to follow them instead of simply pip-install HA in a local venv, wasting an immense amount of resources on their system for what?

Such kind of tech evolution must end or we will collapse soon digitally speaking.

Re: Never Update Anything

#115

> And lastly, choose boring technology. Only use software that you're sure will be supported in 10 years. Only use software, which has very few "unknown unknowns". Only use software, where the development pace has slowed down to a reasonable degree. Perl has been stable for a couple of decades.

Perl 6 is incompatible in all sorts of ways. It's so incompatible that people didn't even upgrade! So incompatible that they renamed the language! Even more incompatible than Python 3!

Even Perl 5 is rapidly evolving. They just added try/catch. Added a new isa operator. Added a new __CLASS__ keyword. Added defer blocks.

Re: Never Update Anything

#116
post #84

What the article points to is that most updates are bad updates. We teach people that they should accept all updates for security reasons, but really they should only accept security updates. But they can't, because this is not a possibility that is given to them. All updates are put together, and we as an industry suck at even knowing if our change is backward compatible or not (which is actually some kind of incomp…

For a long while now it's been worse than that. Security updates are an excuse to push out new unwanted features (remote flags) or remove existing features in the process of being monetized.

Re: Never Update Anything

#117
post #112
post #108

Earlier quoted context omitted.

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

Hence the rest of the quoted sentence. I think removing barriers to fixing bugs is good but companies need to feel more pressure to do so.

Companies need to feel more pressure to ship software that doesn't have the bugs to begin with. That's the pressure that was eliminated.

These days, it's just "ship it and we'll fix it later" instead, which is a big part of why (in my opinion) software quality has been declining for years.

Re: Never Update Anything

#118

"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.

See Microsoft and Crowdstrike for details. /s

Re: Never Update Anything

#119
post #103

Earlier quoted context omitted.

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…

> So there was a very real price to pay, in money and reputation.

Microsoft Corp. would like to have a word with you. /s

Re: Never Update Anything

#120
post #84

What the article points to is that most updates are bad updates. We teach people that they should accept all updates for security reasons, but really they should only accept security updates. But they can't, because this is not a possibility that is given to them. All updates are put together, and we as an industry suck at even knowing if our change is backward compatible or not (which is actually some kind of incomp…

> And of course it's hard, because users are not competent enough to distinguish good software from bad software,

There was a time when Windows had a description for updates. Now the only distinction is between KB3587690 and KB67457770.

Post reply on HN