Never update anything

I’m not a TS, JS, or node fan. But if you really believe that it takes 80% of a dev’s time, week after week, to wrangle dependencies etc in ANY stack, you are either incredibly naive or really bad at math. And if developers at your company got away with that, I’d be leaving that company ASAP.

This is why I can’t use anything too complicated. I’m just not smart enough to wrangle complex configurations and dependencies.

So I keep producing Rails apps that get the job done without the bells and whistles and without much polish.

I wish I could hire a config expert for half an hour and have them create the setup I want. Because I will never get my masters in webpack/rollup/postcss/stimulusjs/mystery sauce working config du jour.

Having always been fullstack even in my current large traditional bank, I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need), and yarn/npm frontend projects that cant be even rebuilt two weeks later, everyone insanely writing auto updating version descriptor (^2.0.4 with the ^).

I cannot understand what idiot thought it d be fancy cutting everything into mini dependencies that update every day without you knowing made by amateurish hipsters who transitive depend on each other like their life depended on it. Yes you can lock but every build script I ve seen forgot this detail and resolve anew the dependencies !! Why !?!?

Yes it s a pain to move up a version sometimes in Java, but we decide to do it for a reason, spend a few days tops fighting it if we must and it's done. You re right that in JS I cant even teach my more backend colleagues how the fuck it works and how I can navigate it. And I m very against transpilers and linters which I try to avoid for sanity but sometimes you inherit a hero's code and you re like omfg a vue js to typescript to js hacky build chain that worked 2 years ago on bower and now bower is gone and yarn wont build it. And you re 2 weeks well into it before you start building and discussing what you actually wanted to change :D

What kills me the most is when someone in management calls the java backend that is ultra optimized, instant to change, a dream to deploy "legacy" and the yarn soup that is coded by 200 successively burnt out juniors, does 40k binding function calls on a non moving DOM (you know, to "hydrate" it with whatever framework du jour was fancy 5 months ago), and we cant redeploy without a full budget proposal, that people do everything to be assigned out of "modern" grrr

I kid you not we have an entire team in charge of one small frontent management tool for a pretrade backend, they literally spend 99% of their time justifying why they wont change it, and 1% begging me to join for a week to reorder their column or put a new button... and THEY re in charge of it argl, and I cannot for the life of me spend more than 30 minutes teaching them before they snooze "I dont get it, let s pick our battles and change that one thing with you and promised it s the last time" ...

I'm still building new frontend UI with Typescript 2.x, Bootstrap 4 alpha, Pixijs 3.x. I don't particularly care about flags in code dependencies, and if they're a problem to upgrade I'll use the old version too. Does it matter? A UI just needs to work, ideally forever, and it's all javascript in the end anyway. It'll work the exact same 10 years from now. Serverside code is a different beast and you can't avoid upgrading Node or PHP, or migrating to MySQL 8. But only very occasionally does this present the opportunity or sufficient reason to upgrade frontend code.

As a full stack dev who leans heavily towards the frontend... yes, honestly, some weeks 80% is a realistic number and WOW is it exhausting to fix Webpack or Babel or some random npm package for the nth time. I do feel like I run into issues less often today than I did about five years ago, there are really only a few packages where upgrades are a massive pain. TypeScript makes these upgrades a lot easier.

That being said, I still have way more fun writing TypeScript and React code _when it works_ than I do writing yet another Java API. Might just be personal preference but the amount of fun that I have doing it makes dealing with the tooling hell all the more worth it.

In .NET I've spent maximum 1 hour updating major versions. Usually is almost nothing to be done.

I do both java and node backend dev and I wrestle way more with maven and java dependencies than with node and npm. The project lead also always wants to try the latest java stuff (quarkus when it just came out, latest java versions, ...) which has lead to many days of obscure bug tracing. So it's really more of developer attitude then about the stack

> I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually make a node program run.

Like they say - a cushy job if you can get it.

Where I work, its quite the opposite, every microservice is built with js/ts and we have a big monolith built in java.

The java service releases every month or so, the microservice, on average, release every week, sometimes more.

You can build bad software with any tool, it all depends on how you use it.

Do your Java geezers work with Maven? Give me NPM (well, yarn, or pnpm) any day of the week.

At some point, there is an irreducible level of complexity. At this point, adding tools simply results in pushing complexity around like an air bubble trapped under a plastic film.

Am I doing typescript wrong?

Setting up a new project is a 5 minutes task. Npm init, then install express, typescript and some useful middleware. Install eslint then eslint --init and choose airbnb style guide, and I'm off to go.

And if I take over an existing codebase it just takes npm install then npm run dev <script name> and I can start adding bugs.

With react and vuejs it's even easier with nextjs/nuxtjs.

I never fight dependencies.

Yet I sometimes read stories like yours while typescript/nodejs has only been the smoothest experience I've ever had.

This is why I don’t understand the approach of golang and rust to keep their APIs so lean and rely on 3rd party dependency management for (IMO) basic enterprise functionality.

This is not "modern stack", this is frontend frameworks niche.

The best experience I ever had with js was on an api that didn't use anything special.

No typescript. No import syntax. Nothing extra.

It was magical. The entire build stage was npm install && node app.js

Admittedly, once or twice a quarter, we'd update the dependencies and we'd spend a few hours fighting it, but the rest of the time it just worked.

> the key is to upgrade often

* and have a very good test suite

> but this sounds like words of wisdom from someone who doesn't have much real world experience

Did you read the part in the first paragraph where the author complains about people shutting down the idea without even giving it any discussion?

I mean you just dismissed the idea entirely and went off on a "have you tried jQuery" tangent.

> one of their biggest mistakes was not to upgrade often enough, which made each upgrade more painful.

The mistake isn't not updating frequently enough. The mistake is that the industry thinks maintaining backwards compatibility is a waste of time.

Updating more frequently doesn't magically make updating less painful, it just spreads the pain out over longer timeframes.

There is some benefit given that you won't be building on top of more and more stuff that may eventually be rug pulled by something that may already be released, but again, this isn't about update frequency, it's about a lack of respect for backward compatibility.

If everyone maintained backwards compat indefinitely we wouldn't have so many damn problems and updating would be nearly painless at whatever frequency you like.

Maintaining backwards compat isn't actually all that hard. There is two types of change. Breaking and non breaking. Most changes can be done without breakage. Want to make a breaking change to that function? Make a new function, put a 2 on the end. Problems solved. How often does leaving that old function actually cause you problems? Technically it's tech debt, but tbh it's the most benign tech debt you'll ever see.

So anyway, my point isn't that we should update frequently or not at all, it shouldn't matter. My point is that semver gives inexperienced devs a pass for lazy development practices that cost everyone instead of eating the cost themselves.

Want to release a major version change? Go for itz but understand it's a fork and not everyone needs your special new features you think is so important.

Hello there, i'm the author of the article.

> I appreciate the contrarian point of view, and I don't want to pick on the author, but this sounds like words of wisdom from someone who doesn't have much real world experience.

I see why you'd say this, but what i'm mostly advocating for in the article is that breaking changes often being the only option for updates (which may be forced upon you because you NEED the security updates that are included) is a problem, since no one wants to (or even feasibly can) keep a maintenance branch of their software around forever, for every single version.

A pretty good example of software that doesn't cause many problems in this regard would be something like MySQL 5.7, which was released in 2015 and will be supported until 2023. Personally, 8 or more years seems like a pretty good amount of time to support a software product for, as opposed to forcing you to update to something newer after just a few years if you want security updates and bug fixes, especially if you don't have the proper amount of resources at your disposal to properly migrate over and test everything.

For example, for the past few months at my dayjob i've been:

  - working to migrate about 7 Java services over from Java 8 to Java 11
  - this also necessitated not only the migration of minor framework versions, but also major versions in some case (Java 8 --> 9 was a generational shift of sorts)
  - furthermore, the decision was made to also abandon Spring and migrate over to Spring Boot, both because it historically "won" and also because some of the services already ran with it, so this should increase consistency across the board
  - the decision to utilize containers also was made, after much deliberation and problems with the environments not being consistent otherwise
  - the decision to also use Ansible was made, because historically changes to the server configuration weren't entirely traceable easily and diverged otherwise
  - the decision to reorganize all of the servers with modern and up to date OS versions was also made, as well as the tools to manage the container clusters, as opposed to having systemd in one environment, sysvinit in another and manually run scripts in yet another environment (about 5 of those environments in total, each with all of the apps, though previously sometimes strewn across multiple servers for historical reasons, e.g. temporary environments that became permanent)
  - tack on a few topology changes, introducing a proper ingress, as opposed to sometimes managing SSL/TLS through Tomcat, but not always
  - if the scope creep doesn't sound bad enough, throw in some load tests that needed to be made due to issues in productions with performance, that had to be addressed in parallel
  - oh and since AngularJS is essentially a dead technology, some of those systems needed to be split up into proper separate front ends and back ends for the eventual migration to something else
  - besides all of that, i've also been working on introducing proper CI for all of that IaC and app builds within Docker containers, as well as any and all package repositories (Maven, npm, Docker) that we may need, both to avoid rate limits and improve performance, as well as cache dependencies in case the main source goes down

It's as if "the business" looked at everything they should have been doing in the past years and decided to put it all on my plate, only very good prioritization can avoid situations like this turning into an utter failure. Is that too much for one person to do successfully? Quite possibly. Have i also been mostly successful in all of the above and have learnt a lot? Most certainly. But does something like that possibly lead to burnout? I'd say that yes, in most cases. It's not healthy.

Now, i agree with you that updating often would have noticeably lessened my pain, yet when your department isn't seen as a profit center or you cannot sell your clients (assuming consulting) on the idea of things like SRE and constant updates, at most people will bump smaller versions every couple of months to tick a checkbox somewhere, because they cannot feasibly do what i'm attempting now.

Not only that, but most of your suggestions simply wouldn't be seen worth the time and effort, unless you'd prefer to ask for forgiveness rather than permission, which is hard to do when you're also expected to deliver features and fixes:

  - you won't have much automation or automatic scanning of outdated packages with proper alerts in place; i only recently sorted out the package management with proper caching registries myself
  - you won't care about vulnerabilities (unless very high impact or incidence), at least not to the level of being able to react to them proactively (ITSEC teams often viewing the services as a black box, which doesn't tell them much about a whole class of issues)
  - you won't care about upgrading dependencies regularly, because you probably won't want to be the person who breaks something with 0 perceptible benefit to anyone
  - most importantly, you probably won't have an all encompassing test suite that'd do both unit tests, integration tests, performance tests and would also check everything from end to end, to make sure that everything would indeed work in a browser (or if you do, they're probably not updated regularly and don't have good enough coverage to matter)

Furthermore, if you need to do a generational shift, like i had to Java 8 --> 11 and how we'll soon have to do with AngularJS to something else, you can't just go to whoever writes your checks and say: "Okay, i'll need the next 3-12 months to work on this migration to do basically a full rewrite," unless they're really on board with your past incentives and are aware of the need for keeping up with the current technologies. Any such incentive, no matter how important would generate pushback and long discussions, worst of all, you wouldn't even know if any of that is even feasible.

Would you want to be to known as the person who spent 9 months migrating an enterprise monolith, just to fail in the end and deliver absolutely nothing? In most cases that's a hard sell and almost impossible to put a positive spin on it.

For example, one of the systems that i haven't been able to split up and by far the largest one has the following:

  - i can't update from Java 8 to 11 because the version of Spring doesn't support it
  - if i attempt to migrate over to Java 11 alongside newer versions of Spring (Boot), the old web.xml configuration no longer works
  - some other configuration is randomly ignored and isn't loaded at all, whereas other needs refactoring because certain classes no longer exist
  - speaking of classes, there are now class path conflicts and i need to scan through the pom.xml and figure out which of the hundred dependencies are misbehaving
  - not only that, but about 50 of them are out of date and thus need updates, given that many of them are also incompatible with Java 11
  - worst of those are the classes that just break at runtime, like class loader functionality at app startup
  - after all of that, i discover that many of the configuration values have been changed and need updating
  - some of the servlets also aren't loaded properly and thus i cannot figure out how to get the app responding to requests properly
  - since the back end also bundles JSP/JSF/PrimeFaces, all of those also provide further challenges, as does Java EL
  - there are also scheduled processes within the app that break
  - there are also services that deal with file uploads that break
  - there are also services that deal with reports and PDF export that break
  - there are also services that deal with database migrations that break
  - there are also Maven plugins that break so certain front end resources cannot be built
  - there are other things too, but sadly i don't keep a full list of everything that broke...

I have no illusions about the fact that too much was put on my plate, but surely you can understand why 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?

Either that, or you have to do updates often, keep your individual services small so they're easier to rewrite (maybe divided by functionality within a bounded context, e.g. PDF service, file upload service, migration service) so that 5% of "dead end code" doesn't keep the rest 95% from being kept up to date. Essentially, you'd have to constantly invest time into this and not pretend that code doesn't rust.

Knowing how little "the business" can care about these finer points in many industries, it doesn't surprise me that you see numerous neglected projects out there and i don't believe that it'll change - thus, we should slow down, if possible, and consider building solutions for the next decade, not just the next monthly iteration of our CVs.

Maybe that's a bit of a rant, but i felt like i needed to elaborate on my point of view. Now i'll probably go write my own little tool that alerts me when a new article of mine gets posted on HN, so i can provide comments in a timely manner.

This. Version pinning is just piling on the risk, and when a CVE is announced on the no-longer-supported version you’ve been pinned to for way too long then it’ll be a reactive emergency.

I'm in this camp. I ran into a recent situation where I could have used a drop-in security module if the project had updated the framework in the past decade. Instead we rolled our own, which is janky and took longer than it should have.

Debts have a way of compounding. Tech debt is no exception. Tech debt begets tech debt begets tech debt, and it will hang on your velocity like a ball and chain.

Absolutely agree with this. Find the rest within staying in motion.

In my experience, upgrade everything all the time only works if you can keep your dependencies to a minimum, which can be harder in JS/TS land, but not impossible. I used to think every line of code you write is a liability, but have come to realize that every dependency is also a liability. So it’s about balancing the two.

Everything being on fire all the time makes your firefighting skills very valuable.

I guess enterprise Linux subscriptions are such a tax, right ?

It pays for Red Hat/SUSE/Canonical to maintain and old stable version CVE free for you, so you don't have to update so often.

I lived and suffered this tension between stability and security for years running a tech team. Staying on the upgrade treadmill while delivering actually important product features for the business. Hopping from LTS to LTS is a solid default strategy when you can use it.

So pardon the plug, but finding a happy middle-ground to exactly this problem for Django based projects is what I now work on with https://www.codestasis.com/

Projects that can't upgrade, because of the ensuing cascade of breaking changes and dev time needed, subscribe to CodeStasis to minimally update Django to new non-breaking patch versions.

So you can keep your trusty old version yet also stay patched and secure if you find someone to do the heavy lifting for you at reasonable cost, which I think we deliver.

I loved and lived Windows for a decade and felt so cozy and at home in it, but when the first force-upgrade happened, I knew it was time to move along.

Just cannot accept things changing without my consent on my workstation.

Why not just get LTSC? You get zero feature updates (ie. the breaking kind) pushed on you, but you still get security updates for up to 10 years.

I hate updates with the fire of a thousand suns. I'm still on Windows 7 and will stay on it for as long as possible. Parts of my PC are from 2010, the case from 1990, the screen from 2007. And you know what? It works.

Might come in useful to others on Win11:

To get the snipping tool working, close the snipping tool, manually set the date to around the start of October. Reopen the snipping tool and it should be working. The date can now be set back.

I upgraded to Windows 11 and the volume bar simply does not show when left clicking on the sound icon on the lower right of the task bar.

No amount of things I've tried makes it work, so to change the volume I have to either use keyboard shortcuts or open the volume mixer in the control panel.

whoa, do you have a link?

I think they email account owner, because in our case he forwarded it to tech team. So if he would have chosen to not forward it to us, then we could have been in the same situation as you. Just wanted to mention that they actually sent an email about that issue. At least to somebody :D

We did our upgrades few months back (9.6 -> 13) and luckily in our case it wasn't big of a hassle. Just finding out correct upgrade path with Postgis took some investigation, but overall the upgrade documentation was good.

> arbitrary change like deciding that 'which' is deprecated now.

I kind of hate that this is going to live on as some example when the actual event was somebody proposing it, it failing in some builds on testing, and then a vote deciding against it. It was an example of good project governing preventing breakage, but for some reason it's already being remembered as the opposite.

They actually just reverted this change within the last week (of course with accompanying “we love listening to your feedback!!!1!” eyeroll inducing messaging).

That was so lol I had to post it to our #random and probably should have to r/assholedesign

Most of my experience with Docker Desktop is on a Mac behind a corporate proxy. I swear with every update they either removed my proxy settings or changed the behavior of how docker build and docker runtime inherited the proxy settings. It was maddening because inevitably everyone on the team had different versions and therefore different behaviors. Took away the whole point of having a common tooling container.

This is why I badly want all updates and rollbacks to be as declarative and simple as Git commands.

"Be on this version. Now."

Sorry, newest Windows also has printing broken. No luck there.

I have had much better luck exposing printers over smb from Linux than from Windows. My in-laws were visiting and couldn’t print to our network printers directly from Windows, so I had to add them to CUPS and smb, which was painless.

I noticed my wifi router had an "update firmware" option. Hmm, I said, that sounds cool. Go to the trouble of looking up the manufacturer's support page for my model, download the file, poke it into the update box, click go.

Now all my IOT devices on the 2.4ghz now fall off the network after ten minutes and have to be manually restarted. I'm sure if I spend the time to look into it I'll find some fascinating difference of opinion regarding a detail of the 802.11b spec between the manufacturer of my very cheap wifi router and the manufacturer of the very very cheap wifi radios in my internet-connected thermometer.

Instead of doing that, I factory reset the router, and spent fifteen minutes restoring various configuration details from memory.

Ubuntu upgrades are often a mess, even with LTS versions. Some issues I've encountered: 1) system lost its default route after an upgrade 2) network interface names changed, all connectivity was lost 3) system became unbootable (UEFI boot order changed.) This was all on a physical machine, and loss of connectivity meant having to to go the console.

This sort of thing makes me want to give GNU Guix or NixOS a try. Not sure which yet though. Last time I checked both, they were limited with regarding to disk encryption and partitioning and such. I came up with a possible solution for GNU Guix, but I never put it to a test.

This works at small scale (read: a small startup or for your own machine). It begins to fall apart once you have dozens of services each deployed at some time in the past 5 years, and no clue whether any of them are safe to update, or even validate.

I really appreciate people like you reminding most everyone that new != better. I live in Japan which people usually mock for still using fax machines, or keeping "the old ways" in many aspect of society.

There are important positive things that people don't realize are lost as we "modernize" society.

For example, these days the TV spies on my usage and sends that data back to the maker company; they will then sell it to advertisers. Every update is aggressively pushed to me, and after i accept it, i notice more ads (rebranded "you may enjoy" or "now trending") on the home screen.

Another example would be how awesome paper is. It displays information without requiring an energy source. It can be folded and unfolded. May not impress you until your phone battery dies on a trip or at the airport/stadium where you need to present your e-ticket

Jesus, you are technically illiterate if you use that old version of a web browser, I’m sorry.

How do you make sure these are the reputable websites and not some interceptor, when using plaintext protocol?

It's more like sticking your head in a river.

No updates: ignorance is bliss. Until you need to breathe -- then you die.

All updates: maybe I can just drink the whole thing...

"Breaking" is undefinable. I remember reading about some user complaining that a small bugfix broke their work setup because it fixed a bug that used to make the CPU go 100% when the spacebar was held. The user would hold it with a weight and get the CPU to make heat that way. The small fix broke his experience.

There are many other examples of this. Breaking compatibility by fixing bugs people rely on for instance.

Any change can break something for a user downstream. It's a very subjective evaluation for the producer to imagine potential impact to their consumers. It's easier if the relationship is rich and exclusive. In open-source where people do it on their free time and have thousands of consumers with widely different interests, it's pretty much impossible to label the release in a way that's conveying the right message to every user.

Semver, the way i see it, is just a way for the producer to subjectively label the amplitude of changes. The consumer should then ideally be familiar with the producer and get a sense of how they work and what they perceive as big. Still at the end of the day it's a very subjective judgment call system that doesn't offer real guarantees to consumers. If your software needs to be stable, don't upgrade, or spend time to review the changes in the dependencies. The version numbers are no guaranty.

Having two of everything is actually a pretty decent idea.

Part of the fear of updating though is the time sink.

Even if I attempt to update one mac laptop to the new version (of which I believe there is a new one just released, doesn’t seem long since I last updated…) knowing that I have a safe backup, I dread the thought of spending hours knowing something _should_ be working but is now broken. It can be infuriating. Especially when it’s a pattern/way of working you have become so accustomed to.

This resonates with me for a LOT of reasons but I take a very different approach. I try to keep just a few dependencies and keep them all up to date. For most updates I can read every line of updated code. I learn a lot, get all of the security patches, and sometimes I realize I don’t need a dependency and I remove it. I’m always trying to take small calculated risks. I have great monitoring and rollbacks are easy.

If you're running software maintained by someone else and you don't let them do that, and there's a security or major bug fix and you lose business or esteem of peers -- it's YOUR fault.

Ignoring upstream security fixes on a work-related machine that you use to make $$, is ASKING FOR IT. WHEN it breaks something that is your fault for being so stupid.

Neither of these extremisms are helpful. It's clearly more nuanced than any of this.

> WHEN it breaks something that is your fault for being so stupid.

Sorry, this one raises my hackles. It's exactly such a user-hostile worldview that makes everything suck. It's just more victim-blaming and elitist tongue clicking that helps absolutely no one.

Everyone is stupid when it comes to software. There are hundreds of millions, if not billions, of lines of code, written by tens of thousands of different people, with myriad internal and external complexity, all breaking and falling apart at the same time. It is literally beyond human comprehension all the niggling details that could go wrong.

I whole-fist pushback against this "oh you should know what you are doing with metric asstons of other people's code". Uh, no. That's the attitude of unserious people who want to ship garbage and make it users' problem.

Yes it’s a terrible example directly contradicted by the graph he gives above of everyone stuck on Java 8. Go, after 10 years, is still on version 1 and likely to remain so and takes this problem of breaking updates really seriously.

“Angular over react” is also a bad example because in my experience angular upgrades take more work and are necessary more often.

Sort of off topic I guess, but: if I wanted to learn react nowadays (coming from extensive backend experience but not much in the front end) where should I start?

From ignorance, it seems like react has changed a fair amount during its lifetime, in terms of good practices, features available, etc. Where can one find resources that are both complete for a begginer and not outdated?

6 years being like "a century in terms of FE" is the core objection being made in both the article and the comments. You're right in every point, but I can't help but feel like you're accepting a state of affairs that should be unacceptable.

What are the benefits to updating frontend packages. Are there security vulnerabilities that I should be worrying about if most of my npm dependecies dont get updated.

The second is not so much a problem with Android but the horrible intersection for OEMs with no reason to support old devices, Linux baking drivers into the kernel, and hardware manufacturers releasing closed source blobs instead of OSS drivers.

Newer versions of Android have done a lot to decouple the device tree from the rest of the OS so you can update without OEM involvement.

Google also moved a lot of functionality into Google Play Services that updates over the air (but that's a negative for some people)

Android: if you have a hobby app in the play store we’re gonna make you jump through stupid hoops to keep it alive every year or so (I just let mine die)

Android, iOS, macOS, Windows: Newest version only works on newest hardware. Old hardware not supported anymore.

So, for old hardware:

- Install Linux to desktop/laptop computers

- Install Ubuntu Touch to smartphone, if available

I think I'm on 1.4.something

It works, I'm not all that impressed with Angular 47 or whatever they are up to now, nor React, and, to repeat myself, it works.

When you have tens and hundreds of thousands of lines of code and a only handful of people, it ain't worth it to rewrite everything to make it just work the same and look the same.

Like the author mentions in the backporting section, if you don't update you'll fall behind maintained version and then you don't get security updates and upgrading is a huge chunk of work that has to be tackled as a giant step. Depends on your priorities and timeline, not updating is the most straightforward example of creating technical debt.

Yeah, there's a reason users have always perceived planned obsolescence as hostile action.

Auto-updates are an attacker's dream too.

Also, this disclaimer in the very first sentence of the article:

> "Here's a fair warning: this article is reductio ad absurdum"

In general, of course. However, the article describes the ridiculousness of today's update mania. And there are actually systems that I don't update very often (my OpenBSD-based firewall) without losing any sleep over it. Unfortunately, such systems are very few in the real world.

Yes, totally the reason why healthcare is more vulnerable to ransomware.

i's used to be lowercase back in the day. nobody is certain why they changed to being uppercase but there are some theories that its because 'i' on its own could easily look like it had drifted away from another word or that it could have been made by accident. previously 'i' had been 'ic' or 'ich' so it would have been a lot easier to see.

im not sure i agree with the accident theory though because 'i' looks a lot more deliberate that 'I'

Do what my Tandy 1000 did, and burn DOS 3.3 right to ROM. None of this wimpy flash-but-with-a-read-only-bit, no fancy UV-erasable EEPROM...just honest-to-goodness-blown-fuse ROM.

Boots immediately too.

Because many times security updates are tied to fancy changes nobody asked for but consumers are expecting.

Versioning things helps with bug reports. Oh, this was introduced in 3.144.42? Great, let's look at the changes to that build.

100% the way to go. Also people in python land (myself included) Are prone to “emotional” versioning

I'm trying to understand this comment. Do you never use package managers?

> As a developer I'm only ever building and maintaining the latest source.

That's valid under semver.

The crazy diagrams show what happens when you want to support lots of old versions.

I have semver stuff at work where I only maintain the latest version. Bugfixes bump the patch version, adding a feature bumps minor, removing a feature bumps major.

I don't make any special effort to bump or avoid bumping anything. It gives me a rough idea of whether a given version has new stuff in it (x.1.0 or x.2.0) or is just a bugfix (x.0.1 or x.1.1)

Dependency hell has nothing to do with how you label your versions and everything to do with how much you want to annoy users by breaking whatever you like vs annoy yourself by taking the time to set stable APIs and hold compatibility backwards and forwards.

Semver vs. Git commit hashes vs. "just one number" vs. web browser versioning vs. "just timestamp" is all just different labels on the same soupcans.

I think semver is mostly useful for telling, at a glance, how much of the changelog/migration notes to read

I've noticed (more frequently) npm packages quickly climbing in versions (1-17 in a couple years) but at least it's painfully obvious.

> Here's a fair warning: this article is reductio ad absurdum,

literally the first sentence...

It is not a joke, just a very frustrated (clickbaity) hyperbole rant.

"My premise is that updates are a massive waste of time, most of the time. Obviously, someone will jump out and say that "Hey, if you don't update, your Windows XP installation will get added to a botnet in less than a week," and they'll also be right at the same time. "

So my understanding is, when compared to a academical, idealistic point of view, handling of updates is not optimal. Sure thing.

But in reality, you still must patch your WinXP system if you have no better alternative and the author likely agrees. And if you do have a shitty legacy java project that is still needed in production - you still have to patch it, if you have to use it in the wild.

Windows xp works fine when airgapped.

In a more serious note: it is a rant

It is not a joke. Upgrading dependencies is a lot of work in many programming languages, many web frameworks, etc.

IIRC there has never been a date picker in mui, it was in a separate package called pickers, and the recent major version moved it to their labs package.

React Router, however, feels like the one major React package that constantly breaks things on major versions and requires refactoring to get back to where you were.