20 ms·

Never update anything

319 points by cesarb 5y ago

throwaway984393 5y ago
I use a 5 year old Linux distribution and I never update it except for important security patches. Works great. Nothing changes so nothing breaks. I ran into a problem once with trying to run some Go binary that wasn't actually static (pretty common apparently) but got it working in a Docker container.
benburton 5y ago
> Docker Desktop doesn't let you decide whether you want updates or not, unless you pay them This made me uninstall Docker Desktop.
- travisd 5y ago
  They actually just reverted this change within the last week (of course with accompanying “we love listening to your feedback!!!1!” eyeroll inducing messaging).
  - Brian_K_White 5y ago
    What I always say about this kind of thing is not "It's ok now because they un-did it." but "It's still not ok because they tried." If they are the kind of people who would try something, then they are still the same people and that problem did not go away. They will try something else again, and may in fact already be failing to work to my advantage right now in ways I just can't see. Once you know that, I prefer to just live without whatever the awesome thing is, somehow I will survive.
    - Negitivefrags 5y ago
      So basically you must be 100% perfect all the time and are never allowed to make any mistakes. This is one of the attitudes that makes the internet so toxic IMHO.
      - ekianjo 5y ago
        on the individual level you can make mistakes. on an organizational level allowing this kind of mistakes means they discussed it and nobody found a problem with it. its a sign of disfunction.
        virtue3 5y ago
        It's a sign of docker desperately trying to find out a way to make money and survive.
        Brian_K_White 5y ago
        Not my problem, and not a valid problem in the first place, and not the charge against them. There are an infinite number of ways to make enough money to survive. You can sell your work honestly without artificially witholding work that is already done so you can sell it a million times over, and get people to do it by artificially creating or at least artificially preserving a pain point and randsoming the salve. That is not simply doing work and paying for that work. If a thing is at all useful enough that anyone even wants to use it, then there are a million businesses that would love to pay you for expert installation and training and support of perfectly free software. Ahh but that doesn't scale. You can sell your time to a few people and live very very well, but you can't sell your time to a billion people. No one is "trying to survive" in this story. What a strange and incredible thing to even try to say.
        bavell 5y ago
        It's almost like they probably should have figured out something so important by now. I guess they didn't have a plan B after they didn't get bought out. Sucks to suck.
      - Brian_K_White 5y ago
        "So basically you must be 100% perfect" Yes. That is exactly what I said.
      - bavell 5y ago
        > This is one of the attitudes that makes the internet so toxic IMHO. Right up there with removing all nuance from a discussion and attacking a strawman...
  - pieix 5y ago
    That’s great to hear, I’m one of the people who complained loudly about that unacceptable behavior. Guess I’ll be reinstalling.
  - strictfp 5y ago
    Welcome to Docker, I love you
  - eutropia 5y ago
    The auto update “feature” was only ever required so they could get everyone on to a version that they could remotely shut down to force subscription revenue. Makes perfect sense that it was a paid “pro” feature before to not be forced: you were already doing what they wanted. Now everyone is on 4.0 and they can turn it off again.
- quickthrower2 5y ago
  That was so lol I had to post it to our #random and probably should have to r/assholedesign
- d0gsg0w00f 5y ago
  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.
02020202 5y ago
if it works, don't try to fix it. for sure. the problem is with security updates which can trigger a massive dependency hell.
encryptluks2 5y ago
Better yet, if you don't want updated software, then why are you installing it? Just use a versioned Linux distro be done with it.
- catlikesshrimp 5y ago
  Because many times security updates are tied to fancy changes nobody asked for but consumers are expecting.
  - TeMPOraL 5y ago
    Worse, they're often tied to changes nobody asked for or wanted, including the customers in particular, and importantly, you can't tell which kind of update you'll get.
  - encryptluks2 5y ago
    Don't package maintainers for Debian and what not often backport changes without breaking things? I agree that the mental complexity of understanding so many components of software and staying relevant is near impossible, and that is specifically why I try to avoid JavaScript development altogether.
    - watermelon0 5y ago
      Yesterday, a package (redis-server) for Debian Stretch in non-backports repository was updated, and now relies on a package not present for Stretch (libjemalloc2). https://packages.debian.org/stretch/redis-server https://packages.debian.org/stretch/redis-server So much about not breaking things.
mt42or 5y ago
I'm not sure if this is a joke or not.
- emef 5y ago
  > Here's a fair warning: this article is reductio ad absurdum, literally the first sentence...
- hutzlibu 5y ago
  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.
  - deleted 5y ago
    [deleted]
- catlikesshrimp 5y ago
  Windows xp works fine when airgapped. In a more serious note: it is a rant
- xet7 5y ago
  It is not a joke. Upgrading dependencies is a lot of work in many programming languages, many web frameworks, etc.
schaefer 5y ago
DOS 5.2 ftw
- snerbles 5y ago
  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.
  - toast0 5y ago
    My Tandy 1000 (TL/2) had a EEPROM you could configure for booting from rom (dos 3.3) or the hard drive (originally also dos 3.3, but IIRC dos 6 ran fine too.
  - marcosdumay 5y ago
    > just honest-to-goodness-blown-fuse ROM Well, blown-fuse ROM is called PROM. Real ROM is made from hard metal VLSI masks or old ladies weaving copper wires.
paxys 5y ago
Semantic versioning is a curse. It makes perfect logical sense until you are a few iterations in and quickly run into dependency hell as shown in the diagrams in the article. My solution to this isn't "never update anything", but rather "never version anything". People can choose to stick to the bits they originally got, which is perfectly fine, or they can switch to the current "live" one. As a developer I'm only ever building and maintaining the latest source.
- HWR_14 5y ago
  Versioning things helps with bug reports. Oh, this was introduced in 3.144.42? Great, let's look at the changes to that build.
  - SkeuomorphicBee 5y ago
    You don't need semantic versioning for that. "Oh, this was introduced in build 22456" works just as well.
    - nameisname 5y ago
      Except that using a build number in the way you're describing is just a worse semantic version. You now have no way to indicate if your changes are breaking. Separation of your pipelines also just got a lot more hectic because you could have a situation where you don't know what happened when you're missing "versions" (builds) because it's failing but still incrementing... Using build numbers for versioning doesn't really work in a large ecosystem and often relies on picking the latest of a branch or having to sift through builds when deploying to find the right one.
      - treis 5y ago
        I think the concept of a breaking change is part of the mistake. If you want to change something you should introduce the new way and support it side by side with the old for a while while going through a depreciation cycle. I'm with the GP on this. Pinning to a specific version is a code smell. You should have enough confidence in your regression suite to always use the latest version. And hopefully enough confidence in your vendors that they're not going to break a bunch of stuff.
HWR_14 5y ago
I tend to agree with the premise that in general updates aren't something to race out and apply. Security updates, yes. Updates that are required because of API changes, yes. Other ones are often more trouble then they are worth.
- moonchrome 5y ago
  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.
  - TeMPOraL 5y ago
    Conversely, not updating until you can't not update anymore is often the optimal approach, because when you're eventually forced to update, you deal with potential breakage just once. The amount of hassle around updating does not scale with the amount of updates you missed.
    - dudeman13 5y ago
      You deal with it just once, but you'll still have to more or less deal with every major breaks that would have been easily detected if the patch wasn't huge. Sauce: had to deal with that recently. It was not pleasant. I'd rather deal with 50 points of failure spread over 5 years than 50 points of failure once. Far less stressful, far easier to diagnose.
      - nijave 5y ago
        The counter point is, new releases come with new bugs you may now hit and waiting could mean someone else hits them Besides your points, it also sucks if you hit an old bug that's been fixed yyy versions down the line and you can't get there reasonably (I tend to agree with many small chunks than a couple huge ones)
dtoznayxvf 5y ago
If the software you are using auto-updates and you lose business or esteem of peers -- it's YOUR fault. Allowing most software companies to update anything on an running functioning work-related machine that you use to make $$, is ASKING FOR IT. WHEN it breaks something that is your fault for being so stupid. I update software in most cases by installing it on another machine/device and then once it is confirmed to work, switching devices and wiping the former-work-device. Yes I have more than 2 of everything critical for making $$. Yes I filter all my inbound and outbound network traffic and default deny, at home and on the road Software that prevents you from disabling auto-updates is a virus.
- ch4s3 5y ago
  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.
- mwaitjmp 5y ago
  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.
  - endymi0n 5y ago
    Having two servers with an unpatched CVE 10/10 vuln will get both pwned in short to no time. Or just one, exposing your data in a ransom attack. Dependency and update management is hard. Welcome to IT. From my experience, extreme viewpoints and religions are convenient in the way they have answers to all hard questions in life that are simple, clear and wrong. If you like simple and correct answers, you're usually better off choosing simple questions instead.
repomies69 5y ago
In one company there were quite old linux boxes that were never updated. They never caused any problems, the software in them kept chugging along just nicely.
ssklash 5y ago
As a red teamer/pentester, this is an attacker's dream. This has to be a joke.
- freeflight 5y ago
  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"
  - LogonType10 5y ago
    > Auto-updates are an attacker's dream too. Why?
    - freeflight 5y ago
      The attacker only needs to compromise the update-infrastructure to be able push a malicious updates to everybody who runs the software [0] [1] [0] https://blog.malwarebytes.com/android/2021/04/pre-installed-auto-installer-threat-found-on-android-mobile-devices-in-germany/ https://blog.malwarebytes.com/android/2021/04/pre-installed-... [1] https://www.businessinsider.com/asus-acknowledges-computers-infected-by-auto-update-virus-2019-3 https://www.businessinsider.com/asus-acknowledges-computers-...
- hdjjhhvvhga 5y ago
  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.
- catlikesshrimp 5y ago
  Yes, totally the reason why healthcare is more vulnerable to ransomware.
Waterluvian 5y ago
AWS: “Postgres 9.6 is old. On January 22 we will forcibly update your instances to 12. We hope you noticed this alert. We certainly didn’t email you about this. You’d better get off your ass and test/fix your clients for any potential issues.”
- mikeklaas 5y ago
  whoa, do you have a link?
  - Waterluvian 5y ago
    https://imgur.com/dCxh2Dd https://imgur.com/dCxh2Dd (sorry. Looks terrible on phones) https://forums.aws.amazon.com/ann.jspa?annID=8499 https://forums.aws.amazon.com/ann.jspa?annID=8499 So obviously I was embellishing the language, but the sentiment remains the same. I found this because I checked the RDS admin panel, which I rarely do. I didn't get an email. It was very alarming to discover and makes me anxious about what other forced upgrades I'll miss. I appreciate the point of this, but I think forcing upgrades is absolutely the wrong way to do it. Scream at me all you want, but don't force my stack to mutate and potentially break services.
    - merrywhether 5y ago
      At some point the alternatives are force-updating your DB or shutting it down. One of those at least has a chance of keeping your service online. I agree the lack of communication is pretty bad though.
    - scoopertrooper 5y ago
      Easy to blame AWS, but as the post you linked said, Postgres 9.6 is no longer going to be receiving updates from 11 November. What do you want AWS to do here? Keep running software that won't get security updates? That seems a bit wild to me. Communication could have been better, but there is no universe in which a managed database provider should be expected to continue to maintain instances with discontinued versions of software. Why were you still running 9.6 anyway? https://www.postgresql.org/support/versioning/ https://www.postgresql.org/support/versioning/
theptip 5y ago
There’s something to be said for being on the oldest minor version that still receives patch releases (usually the LTS if there is such a thing). Unfortunately most FOSS libraries don’t have the luxury/resources to support parallel releases. So to get security fixes you need to keep somewhat up to date with other changes. The worst place to be is having to fix a CVE in a hurry, but first having to upgrade your framework a few major versions including fixing some breaking API changes. I’d rather pay a small tax every month than have to risk those late nights. Dependabot is great here, you can get updates for free, or at least preview if they are going to pass all your tests.
- m4rtink 5y ago
  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.
  - dsr_ 5y ago
    Sure, or if you prefer: the price of Debian Stable is that you only get security updates and bug fixes until the next Stable release. It's wonderful.
    - m4rtink 5y ago
      Oh right, yeah, that should also work fine. :)
    - romero-jk 5y ago
      Except for chromium.
      - ArclightMat 5y ago
        Chromium's a hard one for Debian. It is a big software that often suffers from security issues due to its size but it is hard to package according to Debian's policies. Its upstream ships with forked dependencies included, and this goes against Debian's policy, however Debian doesn't have enough manpower to untangle this mess while keeping up with Chromium's upstream. I wish they would just drop it from their repos and suggest users to use flatpaks (or Nix?) or the proprietary variant Chrome (which is what most likely want due to sync), it is a big liability to keep an insecure browser around.
michaelt 5y ago
I've got some sympathy for this perspective. It's frustrating when you update in order to get the latest security updates - and you get forced to do a bunch of pointless busywork because some asshole has made some arbitrary change like deciding that 'which' is deprecated now.
- Taywee 5y ago
  > 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.
  - tux3 5y ago
    The Technical Committee had to step in and vote, so in that sense the last resort worked. But a good migration is a quiet migration. When internal Debian discussions reach the user's stderr and causes builds to fail, the system has failed. There's only two ways to remember this sort of kerfuffle. Not at all, or as a lesson in deprecating things smoothly.
    - Taywee 5y ago
      Didn't that only happen in testing? Isn't that the point of a testing release?
  - ericbarrett 5y ago
    I'm still bitter about ifconfig.
    - pigeons 5y ago
      When I finally got over that, I got to mourn netstat and learn ss.
forgotmypw17 5y ago
I literally never update anything unless it is not working. Quite happy here with Firefox 66.x on Ubuntu LXDE 14.x, which is what happened to come with this particular device. I have an iPad running iOS 8.x, which I'm also happy with, especially when I do testing on the clusterfucks that are later iOS and Firefox releases. Browsing a handful of reputable text-based websites from behind a NAT, I don't see the problem. (And I feel the same way about HTTP, which is faster, more compatible, and more accessible.)
- yuliyp 5y ago
  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.
  - forgotmypw17 5y ago
    Yeah, anything at scale I build with a bare minimum toolkit, and only use conservative tools in the process. By conservative, I mean something which would still work today if I wrote a script for it 10 or 20 years go.
- lwouis 5y ago
  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
  - 5y ago
AzzieElbab 5y ago
Never updating and always updating are just two different ways of sticking your head in the sand
- Igelau 5y ago
  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...
shimonabi 5y ago
I upgraded my Ubuntu distribution last week and my old Xerox Phaser laser printer stopped working over the network. Something like this should never happen. I hate spending my weekends troubleshooting the Samba configuration. Maybe I will connect the printer to a Windows VM.
- johnisgood 5y ago
  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.
- onionisafruit 5y ago
  I ran “brew upgrade coreutils” on Wednesday and my dog has had diarrhea ever since. This definitely should not happen.
- ReactiveJelly 5y ago
  This is why I badly want all updates and rollbacks to be as declarative and simple as Git commands. "Be on this version. Now."
  - Brian_K_White 5y ago
    Heaven!
  - AshamedCaptain 5y ago
    For workstation use I most definitely don't. Linux 5.13 has several regressions that make it unbootable on my system. Sure, i can btrfs/nix/ehatever rollback to 5.12 pretty easily.... and then what? Stuck in 5.12 for thr rest of my life? Hope that someone fixes it by chance? What i mean is that I value decent changelogs, ability to diff changes between package versions, etc. much more. When a package regresses on my desktop, my next task is sadly to try to debug it.
    - 5y ago
muttantt 5y ago
I run a very successful SaaS on Angular 1.8. No need for shiny Angular v659, or React, or Svelte, Vue, whatever. Angular 1.x, Python, and Flask is all you need to build a business with 7 figure ARR.
- thrower123 5y ago
  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.
catlikesshrimp 5y ago
What about trying "planned obsolescence"? Hopefully every 5 years for production, and once a year for consumer. With this in mind, it is possible to plan ahead and allocate resources. There will be a major update in xx.xx.20xx date, it will break many things, so plan accordingly. And there won't be any more security updates one month after that. Meanwhile, security updates are pushed in realtime.
- naniwaduni 5y ago
  Yeah, there's a reason users have always perceived planned obsolescence as hostile action.
deleted 5y ago
[deleted]
k__ 5y ago
Android: We update your system until it's too slow to use. Also, Android: One day we will stop giving you updates, so your apps can't talk to new versions of online services anymore.
- nijave 5y ago
  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)
- quickthrower2 5y ago
  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)
- xet7 5y ago
  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
  - kaba0 5y ago
    I am anything but an apple fan, but newest ios and mac do work on even 5-10 years old hardware as well.
taylodl 5y ago
I couldn't help but notice the author's using of i and i'm (note the lower case 'i'). I think i like it! Oh, and pascal is cool too!
- mackrevinack 5y ago
  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'
wetpaws 5y ago
>Use maintenance mode software: >Angular over React author lost me at this point
htpn38 5y ago
Hah... I was bored and decided to just press the update button on all of my dependencies. I spend 2 hours changing things pointlessly and then deleted the branch and read why any of these updates were necessary. React Router - "wow, we have an amazing new v6"... *reads the "why upgrade"... "it has hooks now", ok they are already in the version I am using (5.2). "it has some changes to how you specify routes and you will have to rewrite them all. Just wait for automated rewriter". I couldn't really see any advantage to them at all but supposedly "something in the future!". ok delete that one. Material UI - we changed everything.... here is 10 page long how to upgrade guide. Also no date picker in core anymore. ok delete.... delete delete. I will not upgrade this project again. Lesson learnt.
- mikewhy 5y ago
  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.
- deleted 5y ago
  [deleted]
deeblering4 5y ago
This is why I like running LTS distributions where versions are fixed and security patches are backported. Unless you install from 3rd party repos chances are very good that updates will be seamless.
snowl 5y ago
Here, use this opinionated software to set up a react project and be frustrated about the amount of dependencies instead of just setting up a project myself! I just tested a base typescript react project, and you only need 14 packages on its own (typescript, react, react-dom) to build the project. Wow!
skybrian 5y ago
"Java over Go" seems kind of weird. Go has been around for a decade and it seems like code built on 1.0 should still work, if you're not too crazy about dependencies?
- grey-area 5y ago
  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.
  - empthought 5y ago
    Pretty sure that decision is based on the standard library size and package repository culture, not language updates.
    - grey-area 5y ago
      Again, those are reasons not to use Java vs Go. The Java standard library is a bit of a mess and far too large for human comprehension and personally I prefer the Go package culture of never breaking HEAD it has led to very stable builds IME.
    - grey-area 5y ago
      IMO the Go libraries are less extensive but more focussed than Java and the Stalin covers most of the bases for web apps very well.
- Joeri 5y ago
  “Angular over react” is also a bad example because in my experience angular upgrades take more work and are necessary more often.
habeebtc 5y ago
Timely. I was recently force upgraded to Win11. Today in fact. Last week I force-downgraded after I got an exception because it is my busy time of year. That exception was not respected and I realized fighting it weekly would be the same time investment as fixing compatibility issues. "What compatibility issues? Win11 is fine, I have had no problems." My coworkers say. Well on Day 1, 2 pretty important pieces of software crashed and exited on first run. And then the screen snipping tool failed to take a snapshot and helpfully suggested I reinstall the OS. I actually really like the MSFT stack, but I know enough to avoid any totally new release for a while. I actually feel confident enough that I no longer try and skip major releases (like I skipped Vista, 8).
- forgotmypw17 5y ago
  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.
  - jart 5y ago
    Mac and Linux do the same thing. I know people who still prefer the OSX 10.3 and the GNOME2 GUIs, or for instance the way nytimes.com looked back in 2010. That's the problem with making GUIs the thing you love. Some goons stop by your home every few years and toss up the furniture. Apple is the gold standard since it pretty much looks the same as it did in the 80's and each major version tunes subtle things. Microsoft makes big changes to look, but at the end of the day its substance is the same. Then there's Linux where each GUI update is a radical break with tradition that continually reinvents its own identity.
    - saghm 5y ago
      > Mac and Linux do the same thing The earlier responses in the thread were talking about forced upgrades. I'm not sure about MacOS since I don't use it much, but most Linux distros do not forcibly apply upgrades like Windows does; you can continue to use old packages and even reboot the machine indefinitely. Sure, you might not get security fixes or keep unrelated packages up to date beyond a certain point, but that's not at all the same thing as updates being applied without actually being invoked by the user.
bawolff 5y ago
> Here's a fair warning: this article is reductio ad absurdum, therefore you shouldn't take it as gospel. Yeah, i'm pretty sure the author doesn't know what that phrase means.
abraxas 5y ago
"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. 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. Meanwhile the geezers that worked on Java services reliably pushed new versions of their code sprint after sprint, no heroics, no drama required. What the fuck happened to those "modern stacks" that babysitting them takes the vast majority of developers time? It's a nightmare.
- sul_tasto 5y ago
  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.
- auslegung 5y ago
  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.
  - abraxas 5y ago
    I'm no longer with that company and it's possible that those devs were incompetent or always chased the next shiny framework or possibly both. But irregardless their output on the whole was about 20% that of those devs who used uncool old tech like Java/Spring and dotNET.
- andrei_says_ 5y ago
  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.
TheRealNGenius 5y ago
Twitter agrees, with regards to tweets and their business model
EastSmith 5y ago
I feel the pain, seeing non-trivial updates for Ruby, Elasticsearch and Postgres (thanks AWS) this year. Can not agree with the React part though. They keep so many things backward compatible. React 16 is 3, 4 years old now? I've updated pretty big code base from early 16 to latest 16 version painlessly - like in a day. Used some of the available code-modes for some really old part of the project. It worked flawlessly. Currently there are console warnings to fix certain things and that is it. No breaking changes, no nothing. Now, React 17 will be a problem - there are a lots of 3rd party UI libs that will not work with it. But I think we are pretty well set to use react 16 for the next couple of years, making it work for 6, 7 years total. I think that is a century in terms of FE and is great. Also, "...React pulling a sneaky on everyone and introducing hooks, which was a pretty bad move, especially if you needed to migrate to them" - just don't use hooks then - no problem.
- torben-friis 5y ago
  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?
  - ljoshua 5y ago
    Tbh, I think the tutorial on React’s site itself is pretty good at making an introduction to the framework and the React way of thinking. It’s the one here: https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html As for changes during its lifetime, I would say that it is fairly on par for most web-focused frameworks, both front and backend. You could look at how ASP.NET has changed over the last few versions for example and see it being similar to React’s changes. The largest changes in React recently have been a greater focus on moving from syntactic sugar JS classes to pure functions, and React Hooks that go along with that. There’s definitely a shiny things syndrome you get if you just google for React tutorials, which is a bit annoying, but the official docs are pretty solid, and a few of the core devs are great to follow from a philosophical standpoint (like @dan_abramov). Hope that helps!
web007 5y ago
Corollary: Do hard things more often, per Martin Fowler - https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht... Upgrade everything all the time and it will never be hard. You'll have full context for breaking changes, and the diff from A to B is always smaller than from A to Q, and less likely to break in strange and confusing ways.
- rewgs 5y ago
  Absolutely agree with this. Find the rest within staying in motion.
- snorkel 5y ago
  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.
  - naasking 5y ago
    Keeping up to date also has issues in the JS ecosystem. There were a couple of recent examples of npm packages that were hijacked and new versions released with embedded malware.
- Igelau 5y ago
  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.
  - nlitened 5y ago
    Dedicate 20% of developers’ time on constant updates of all components for a decade just in case you might need one drop-in security module ten years after now (if the company ever lives to see that day)? Does not sound like a good illustrative argument to me, I am afraid.
prirai 5y ago
Use NixOS.
duncan-donuts 5y ago
I identify heavily with this but also the inverse —- always update everything (all the time). I don’t run arch anymore but one thing I did enjoy as a daily driver was that I was constantly updating my software. The pain is in the middle where you update things once every year or two (or when forced) and there’s hundreds or thousands of new changes that break your stuff.
jml7c5 5y ago
This is only somewhat related, but I wish semantic versioning had settled on four fields instead of three. A transition from 13.1.2 -> 14.0.0 could be a major update that revamps the API, or a tiny incompatible change. Another field at the front would fix this: major.breaking.feature.bugfix. It would help with the "zero-based versioning" problem where projects sit at 0.y.z forever because there's an aversion to frequently bumping the first number.
- lwouis 5y ago
  "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.
  - GrumpySloth 5y ago
    > "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. You confused XKCD with reality: <https://xkcd.com/1172/ https://xkcd.com/1172/>
nhoughto 5y ago
Few interesting areas: - JS dependencies are a problem because of the sheer number, which is really because of all the authors of the dependencies and how they update, backwards compat or not etc. if you had 10 big things by 10 authors they would coordinate better than 1500. - The Lazarus example is interesting but “trusted components” also means walled gardens, who gets to choose? Is there competition? How is that decided in vs out? Logical conclusion to much of this ends up with a central community package manager like maven central..
angarg12 5y ago
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 worked in such a project who never upgraded once. And then Specter/Meltdown hit, and we had the mandate to patch all our systems (and the threat was very real). Welcome to a hellish mess of outdated deps that took weeks to sort out. But is not only me. I watched a talk from a Principal Engineer from Amazon builder tools, and one of their biggest mistakes was not to upgrade often enough, which made each upgrade more painful. So what do we do now working in multiple, large, multi-year projects? First, we set tools that tell us when deps are outdated, and alarm when vulnerabilities are found. Second, upgrading deps is part of the regular dev process. When you make a change, take the chance to upgrade the deps. Vulnerabilities are addressed proactively. The vast majority of times upgrades require no code changes. Third, we regularly upgrade deps of inactive packages. Lastly, if a dependency upgrade requires significant work, we create a ticket for it and address it as a new feature. In practice this happens very rarely, so it doesn't disrupt the development process much. As other's said, the key is to upgrade often, and then it wont be as painful.
- KronisLV 5y ago
  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.
rurban 5y ago
Hilarious post as expected from this camp. But there is some truth to it. Eg we explicitly do the equivalent of apt update -y: apt upgrade -y on our test builds to see update errors early. Only then our work dockers can be upgraded. Of course those folks don't have these luxuries. npm upgrades without testing, dependency tracking in XML, closed source deps, no symbol versioning, loose dll hell. But even with simple glibc binaries I have to maintain up-to-date and lts (ie outdated) versions for the recent fstat and time64_t changes. Then you start appreciating go. And podman.
cadamsau 5y ago
Interesting read, personally I disagree with the author on the risk-benefit tradeoff of having lots of updates. Something work calling out though - the author appears to have completely unironically updated their own post.
franga2000 5y ago
> Actually, i don't have enough time to do my day job, learn new technologies [...] > > Ergo, i cannot update. Ergo, companies cannot ship features AND handle all of the updates [...] Your time is limited and you can't get more of it. That isn't the case for a company. There, time == money, because if their employees don't have enough time to do all the work, they can just hire more to do the rest. But because they're only interested in growth and not sustainability, most of that money goes into developing new features, not keeping up with security updates. The vast majority of large companies could very easily hire one engineer and task them exclusively with updating legacy dependencies. And the smaller ones could instead re-task half their dev team for a month each year.
DeathArrow 5y ago
It is so wrong to desire to return to handwritten Javascript and libraries like jQuery? I don't do much fronted today and the reason are the frameworks. I still do it but I use Blazor to generate web assembly.
user234220 5y ago
Anyone care to comment on how [Deno](https://deno.land/ https://deno.land/) might address some of the issues shared in this thread?
gondo 5y ago
What an irony: the article about never updating anything has an update.

319 points by cesarb 5y ago

I use a 5 year old Linux distribution and I never update it except for important security patches. Works great. Nothing changes so nothing breaks. I ran into a problem once with trying to run some Go binary that wasn't actually static (pretty common apparently) but got it working in a Docker container.

benburton 5y ago

> Docker Desktop doesn't let you decide whether you want updates or not, unless you pay them This made me uninstall Docker Desktop.

travisd 5y ago
They actually just reverted this change within the last week (of course with accompanying “we love listening to your feedback!!!1!” eyeroll inducing messaging).
- Brian_K_White 5y ago
  What I always say about this kind of thing is not "It's ok now because they un-did it." but "It's still not ok because they tried." If they are the kind of people who would try something, then they are still the same people and that problem did not go away. They will try something else again, and may in fact already be failing to work to my advantage right now in ways I just can't see. Once you know that, I prefer to just live without whatever the awesome thing is, somehow I will survive.
  - Negitivefrags 5y ago
    So basically you must be 100% perfect all the time and are never allowed to make any mistakes. This is one of the attitudes that makes the internet so toxic IMHO.
    - ekianjo 5y ago
      on the individual level you can make mistakes. on an organizational level allowing this kind of mistakes means they discussed it and nobody found a problem with it. its a sign of disfunction.
      - virtue3 5y ago
        It's a sign of docker desperately trying to find out a way to make money and survive.
        Brian_K_White 5y ago
        Not my problem, and not a valid problem in the first place, and not the charge against them. There are an infinite number of ways to make enough money to survive. You can sell your work honestly without artificially witholding work that is already done so you can sell it a million times over, and get people to do it by artificially creating or at least artificially preserving a pain point and randsoming the salve. That is not simply doing work and paying for that work. If a thing is at all useful enough that anyone even wants to use it, then there are a million businesses that would love to pay you for expert installation and training and support of perfectly free software. Ahh but that doesn't scale. You can sell your time to a few people and live very very well, but you can't sell your time to a billion people. No one is "trying to survive" in this story. What a strange and incredible thing to even try to say.
        bavell 5y ago
        It's almost like they probably should have figured out something so important by now. I guess they didn't have a plan B after they didn't get bought out. Sucks to suck.
    - Brian_K_White 5y ago
      "So basically you must be 100% perfect" Yes. That is exactly what I said.
    - bavell 5y ago
      > This is one of the attitudes that makes the internet so toxic IMHO. Right up there with removing all nuance from a discussion and attacking a strawman...
- pieix 5y ago
  That’s great to hear, I’m one of the people who complained loudly about that unacceptable behavior. Guess I’ll be reinstalling.
- strictfp 5y ago
  Welcome to Docker, I love you
- eutropia 5y ago
  The auto update “feature” was only ever required so they could get everyone on to a version that they could remotely shut down to force subscription revenue. Makes perfect sense that it was a paid “pro” feature before to not be forced: you were already doing what they wanted. Now everyone is on 4.0 and they can turn it off again.
quickthrower2 5y ago
That was so lol I had to post it to our #random and probably should have to r/assholedesign
d0gsg0w00f 5y ago
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.

02020202 5y ago

if it works, don't try to fix it. for sure. the problem is with security updates which can trigger a massive dependency hell.

encryptluks2 5y ago

Better yet, if you don't want updated software, then why are you installing it? Just use a versioned Linux distro be done with it.

catlikesshrimp 5y ago
Because many times security updates are tied to fancy changes nobody asked for but consumers are expecting.
- TeMPOraL 5y ago
  Worse, they're often tied to changes nobody asked for or wanted, including the customers in particular, and importantly, you can't tell which kind of update you'll get.
- encryptluks2 5y ago
  Don't package maintainers for Debian and what not often backport changes without breaking things? I agree that the mental complexity of understanding so many components of software and staying relevant is near impossible, and that is specifically why I try to avoid JavaScript development altogether.
  - watermelon0 5y ago
    Yesterday, a package (redis-server) for Debian Stretch in non-backports repository was updated, and now relies on a package not present for Stretch (libjemalloc2). https://packages.debian.org/stretch/redis-server https://packages.debian.org/stretch/redis-server So much about not breaking things.

mt42or 5y ago

I'm not sure if this is a joke or not.

emef 5y ago
> Here's a fair warning: this article is reductio ad absurdum, literally the first sentence...
hutzlibu 5y ago
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.
- deleted 5y ago
  [deleted]
catlikesshrimp 5y ago
Windows xp works fine when airgapped. In a more serious note: it is a rant
xet7 5y ago
It is not a joke. Upgrading dependencies is a lot of work in many programming languages, many web frameworks, etc.

schaefer 5y ago

DOS 5.2 ftw

snerbles 5y ago
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.
- toast0 5y ago
  My Tandy 1000 (TL/2) had a EEPROM you could configure for booting from rom (dos 3.3) or the hard drive (originally also dos 3.3, but IIRC dos 6 ran fine too.
- marcosdumay 5y ago
  > just honest-to-goodness-blown-fuse ROM Well, blown-fuse ROM is called PROM. Real ROM is made from hard metal VLSI masks or old ladies weaving copper wires.

paxys 5y ago

Semantic versioning is a curse. It makes perfect logical sense until you are a few iterations in and quickly run into dependency hell as shown in the diagrams in the article. My solution to this isn't "never update anything", but rather "never version anything". People can choose to stick to the bits they originally got, which is perfectly fine, or they can switch to the current "live" one. As a developer I'm only ever building and maintaining the latest source.

HWR_14 5y ago
Versioning things helps with bug reports. Oh, this was introduced in 3.144.42? Great, let's look at the changes to that build.
- SkeuomorphicBee 5y ago
  You don't need semantic versioning for that. "Oh, this was introduced in build 22456" works just as well.
  - nameisname 5y ago
    Except that using a build number in the way you're describing is just a worse semantic version. You now have no way to indicate if your changes are breaking. Separation of your pipelines also just got a lot more hectic because you could have a situation where you don't know what happened when you're missing "versions" (builds) because it's failing but still incrementing... Using build numbers for versioning doesn't really work in a large ecosystem and often relies on picking the latest of a branch or having to sift through builds when deploying to find the right one.
    - treis 5y ago
      I think the concept of a breaking change is part of the mistake. If you want to change something you should introduce the new way and support it side by side with the old for a while while going through a depreciation cycle. I'm with the GP on this. Pinning to a specific version is a code smell. You should have enough confidence in your regression suite to always use the latest version. And hopefully enough confidence in your vendors that they're not going to break a bunch of stuff.

HWR_14 5y ago

I tend to agree with the premise that in general updates aren't something to race out and apply. Security updates, yes. Updates that are required because of API changes, yes. Other ones are often more trouble then they are worth.

moonchrome 5y ago
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.
- TeMPOraL 5y ago
  Conversely, not updating until you can't not update anymore is often the optimal approach, because when you're eventually forced to update, you deal with potential breakage just once. The amount of hassle around updating does not scale with the amount of updates you missed.
  - dudeman13 5y ago
    You deal with it just once, but you'll still have to more or less deal with every major breaks that would have been easily detected if the patch wasn't huge. Sauce: had to deal with that recently. It was not pleasant. I'd rather deal with 50 points of failure spread over 5 years than 50 points of failure once. Far less stressful, far easier to diagnose.
    - nijave 5y ago
      The counter point is, new releases come with new bugs you may now hit and waiting could mean someone else hits them Besides your points, it also sucks if you hit an old bug that's been fixed yyy versions down the line and you can't get there reasonably (I tend to agree with many small chunks than a couple huge ones)

dtoznayxvf 5y ago

If the software you are using auto-updates and you lose business or esteem of peers -- it's YOUR fault. Allowing most software companies to update anything on an running functioning work-related machine that you use to make $$, is ASKING FOR IT. WHEN it breaks something that is your fault for being so stupid. I update software in most cases by installing it on another machine/device and then once it is confirmed to work, switching devices and wiping the former-work-device. Yes I have more than 2 of everything critical for making $$. Yes I filter all my inbound and outbound network traffic and default deny, at home and on the road Software that prevents you from disabling auto-updates is a virus.

ch4s3 5y ago
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.
mwaitjmp 5y ago
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.
- endymi0n 5y ago
  Having two servers with an unpatched CVE 10/10 vuln will get both pwned in short to no time. Or just one, exposing your data in a ransom attack. Dependency and update management is hard. Welcome to IT. From my experience, extreme viewpoints and religions are convenient in the way they have answers to all hard questions in life that are simple, clear and wrong. If you like simple and correct answers, you're usually better off choosing simple questions instead.

repomies69 5y ago

In one company there were quite old linux boxes that were never updated. They never caused any problems, the software in them kept chugging along just nicely.

ssklash 5y ago

As a red teamer/pentester, this is an attacker's dream. This has to be a joke.

freeflight 5y ago
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"
- LogonType10 5y ago
  > Auto-updates are an attacker's dream too. Why?
  - freeflight 5y ago
    The attacker only needs to compromise the update-infrastructure to be able push a malicious updates to everybody who runs the software [0] [1] [0] https://blog.malwarebytes.com/android/2021/04/pre-installed-auto-installer-threat-found-on-android-mobile-devices-in-germany/ https://blog.malwarebytes.com/android/2021/04/pre-installed-... [1] https://www.businessinsider.com/asus-acknowledges-computers-infected-by-auto-update-virus-2019-3 https://www.businessinsider.com/asus-acknowledges-computers-...
hdjjhhvvhga 5y ago
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.
catlikesshrimp 5y ago
Yes, totally the reason why healthcare is more vulnerable to ransomware.

Waterluvian 5y ago

AWS: “Postgres 9.6 is old. On January 22 we will forcibly update your instances to 12. We hope you noticed this alert. We certainly didn’t email you about this. You’d better get off your ass and test/fix your clients for any potential issues.”

mikeklaas 5y ago
whoa, do you have a link?
- Waterluvian 5y ago
  https://imgur.com/dCxh2Dd https://imgur.com/dCxh2Dd (sorry. Looks terrible on phones) https://forums.aws.amazon.com/ann.jspa?annID=8499 https://forums.aws.amazon.com/ann.jspa?annID=8499 So obviously I was embellishing the language, but the sentiment remains the same. I found this because I checked the RDS admin panel, which I rarely do. I didn't get an email. It was very alarming to discover and makes me anxious about what other forced upgrades I'll miss. I appreciate the point of this, but I think forcing upgrades is absolutely the wrong way to do it. Scream at me all you want, but don't force my stack to mutate and potentially break services.
  - merrywhether 5y ago
    At some point the alternatives are force-updating your DB or shutting it down. One of those at least has a chance of keeping your service online. I agree the lack of communication is pretty bad though.
  - scoopertrooper 5y ago
    Easy to blame AWS, but as the post you linked said, Postgres 9.6 is no longer going to be receiving updates from 11 November. What do you want AWS to do here? Keep running software that won't get security updates? That seems a bit wild to me. Communication could have been better, but there is no universe in which a managed database provider should be expected to continue to maintain instances with discontinued versions of software. Why were you still running 9.6 anyway? https://www.postgresql.org/support/versioning/ https://www.postgresql.org/support/versioning/

theptip 5y ago

There’s something to be said for being on the oldest minor version that still receives patch releases (usually the LTS if there is such a thing). Unfortunately most FOSS libraries don’t have the luxury/resources to support parallel releases. So to get security fixes you need to keep somewhat up to date with other changes. The worst place to be is having to fix a CVE in a hurry, but first having to upgrade your framework a few major versions including fixing some breaking API changes. I’d rather pay a small tax every month than have to risk those late nights. Dependabot is great here, you can get updates for free, or at least preview if they are going to pass all your tests.

m4rtink 5y ago
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.
- dsr_ 5y ago
  Sure, or if you prefer: the price of Debian Stable is that you only get security updates and bug fixes until the next Stable release. It's wonderful.
  - m4rtink 5y ago
    Oh right, yeah, that should also work fine. :)
  - romero-jk 5y ago
    Except for chromium.
    - ArclightMat 5y ago
      Chromium's a hard one for Debian. It is a big software that often suffers from security issues due to its size but it is hard to package according to Debian's policies. Its upstream ships with forked dependencies included, and this goes against Debian's policy, however Debian doesn't have enough manpower to untangle this mess while keeping up with Chromium's upstream. I wish they would just drop it from their repos and suggest users to use flatpaks (or Nix?) or the proprietary variant Chrome (which is what most likely want due to sync), it is a big liability to keep an insecure browser around.

michaelt 5y ago

I've got some sympathy for this perspective. It's frustrating when you update in order to get the latest security updates - and you get forced to do a bunch of pointless busywork because some asshole has made some arbitrary change like deciding that 'which' is deprecated now.

Taywee 5y ago
> 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.
- tux3 5y ago
  The Technical Committee had to step in and vote, so in that sense the last resort worked. But a good migration is a quiet migration. When internal Debian discussions reach the user's stderr and causes builds to fail, the system has failed. There's only two ways to remember this sort of kerfuffle. Not at all, or as a lesson in deprecating things smoothly.
  - Taywee 5y ago
    Didn't that only happen in testing? Isn't that the point of a testing release?
- ericbarrett 5y ago
  I'm still bitter about ifconfig.
  - pigeons 5y ago
    When I finally got over that, I got to mourn netstat and learn ss.

forgotmypw17 5y ago

I literally never update anything unless it is not working. Quite happy here with Firefox 66.x on Ubuntu LXDE 14.x, which is what happened to come with this particular device. I have an iPad running iOS 8.x, which I'm also happy with, especially when I do testing on the clusterfucks that are later iOS and Firefox releases. Browsing a handful of reputable text-based websites from behind a NAT, I don't see the problem. (And I feel the same way about HTTP, which is faster, more compatible, and more accessible.)

yuliyp 5y ago
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.
- forgotmypw17 5y ago
  Yeah, anything at scale I build with a bare minimum toolkit, and only use conservative tools in the process. By conservative, I mean something which would still work today if I wrote a script for it 10 or 20 years go.
lwouis 5y ago
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
- 5y ago

AzzieElbab 5y ago

Never updating and always updating are just two different ways of sticking your head in the sand

Igelau 5y ago
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...

shimonabi 5y ago

I upgraded my Ubuntu distribution last week and my old Xerox Phaser laser printer stopped working over the network. Something like this should never happen. I hate spending my weekends troubleshooting the Samba configuration. Maybe I will connect the printer to a Windows VM.

johnisgood 5y ago
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.
onionisafruit 5y ago
I ran “brew upgrade coreutils” on Wednesday and my dog has had diarrhea ever since. This definitely should not happen.
ReactiveJelly 5y ago
This is why I badly want all updates and rollbacks to be as declarative and simple as Git commands. "Be on this version. Now."
- Brian_K_White 5y ago
  Heaven!
- AshamedCaptain 5y ago
  For workstation use I most definitely don't. Linux 5.13 has several regressions that make it unbootable on my system. Sure, i can btrfs/nix/ehatever rollback to 5.12 pretty easily.... and then what? Stuck in 5.12 for thr rest of my life? Hope that someone fixes it by chance? What i mean is that I value decent changelogs, ability to diff changes between package versions, etc. much more. When a package regresses on my desktop, my next task is sadly to try to debug it.
  - 5y ago

muttantt 5y ago

I run a very successful SaaS on Angular 1.8. No need for shiny Angular v659, or React, or Svelte, Vue, whatever. Angular 1.x, Python, and Flask is all you need to build a business with 7 figure ARR.

thrower123 5y ago
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.

catlikesshrimp 5y ago

What about trying "planned obsolescence"? Hopefully every 5 years for production, and once a year for consumer. With this in mind, it is possible to plan ahead and allocate resources. There will be a major update in xx.xx.20xx date, it will break many things, so plan accordingly. And there won't be any more security updates one month after that. Meanwhile, security updates are pushed in realtime.

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

deleted 5y ago

[deleted]

k__ 5y ago

Android: We update your system until it's too slow to use. Also, Android: One day we will stop giving you updates, so your apps can't talk to new versions of online services anymore.

nijave 5y ago
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)
quickthrower2 5y ago
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)
xet7 5y ago
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
- kaba0 5y ago
  I am anything but an apple fan, but newest ios and mac do work on even 5-10 years old hardware as well.

taylodl 5y ago

I couldn't help but notice the author's using of i and i'm (note the lower case 'i'). I think i like it! Oh, and pascal is cool too!

mackrevinack 5y ago
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'

wetpaws 5y ago

>Use maintenance mode software: >Angular over React author lost me at this point

htpn38 5y ago

Hah... I was bored and decided to just press the update button on all of my dependencies. I spend 2 hours changing things pointlessly and then deleted the branch and read why any of these updates were necessary. React Router - "wow, we have an amazing new v6"... *reads the "why upgrade"... "it has hooks now", ok they are already in the version I am using (5.2). "it has some changes to how you specify routes and you will have to rewrite them all. Just wait for automated rewriter". I couldn't really see any advantage to them at all but supposedly "something in the future!". ok delete that one. Material UI - we changed everything.... here is 10 page long how to upgrade guide. Also no date picker in core anymore. ok delete.... delete delete. I will not upgrade this project again. Lesson learnt.

mikewhy 5y ago
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.
deleted 5y ago
[deleted]

deeblering4 5y ago

This is why I like running LTS distributions where versions are fixed and security patches are backported. Unless you install from 3rd party repos chances are very good that updates will be seamless.

snowl 5y ago

Here, use this opinionated software to set up a react project and be frustrated about the amount of dependencies instead of just setting up a project myself! I just tested a base typescript react project, and you only need 14 packages on its own (typescript, react, react-dom) to build the project. Wow!

skybrian 5y ago

"Java over Go" seems kind of weird. Go has been around for a decade and it seems like code built on 1.0 should still work, if you're not too crazy about dependencies?

grey-area 5y ago
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.
- empthought 5y ago
  Pretty sure that decision is based on the standard library size and package repository culture, not language updates.
  - grey-area 5y ago
    Again, those are reasons not to use Java vs Go. The Java standard library is a bit of a mess and far too large for human comprehension and personally I prefer the Go package culture of never breaking HEAD it has led to very stable builds IME.
  - grey-area 5y ago
    IMO the Go libraries are less extensive but more focussed than Java and the Stalin covers most of the bases for web apps very well.
Joeri 5y ago
“Angular over react” is also a bad example because in my experience angular upgrades take more work and are necessary more often.

habeebtc 5y ago

Timely. I was recently force upgraded to Win11. Today in fact. Last week I force-downgraded after I got an exception because it is my busy time of year. That exception was not respected and I realized fighting it weekly would be the same time investment as fixing compatibility issues. "What compatibility issues? Win11 is fine, I have had no problems." My coworkers say. Well on Day 1, 2 pretty important pieces of software crashed and exited on first run. And then the screen snipping tool failed to take a snapshot and helpfully suggested I reinstall the OS. I actually really like the MSFT stack, but I know enough to avoid any totally new release for a while. I actually feel confident enough that I no longer try and skip major releases (like I skipped Vista, 8).

forgotmypw17 5y ago
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.
- jart 5y ago
  Mac and Linux do the same thing. I know people who still prefer the OSX 10.3 and the GNOME2 GUIs, or for instance the way nytimes.com looked back in 2010. That's the problem with making GUIs the thing you love. Some goons stop by your home every few years and toss up the furniture. Apple is the gold standard since it pretty much looks the same as it did in the 80's and each major version tunes subtle things. Microsoft makes big changes to look, but at the end of the day its substance is the same. Then there's Linux where each GUI update is a radical break with tradition that continually reinvents its own identity.
  - saghm 5y ago
    > Mac and Linux do the same thing The earlier responses in the thread were talking about forced upgrades. I'm not sure about MacOS since I don't use it much, but most Linux distros do not forcibly apply upgrades like Windows does; you can continue to use old packages and even reboot the machine indefinitely. Sure, you might not get security fixes or keep unrelated packages up to date beyond a certain point, but that's not at all the same thing as updates being applied without actually being invoked by the user.

bawolff 5y ago

> Here's a fair warning: this article is reductio ad absurdum, therefore you shouldn't take it as gospel. Yeah, i'm pretty sure the author doesn't know what that phrase means.

abraxas 5y ago

"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. 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. Meanwhile the geezers that worked on Java services reliably pushed new versions of their code sprint after sprint, no heroics, no drama required. What the fuck happened to those "modern stacks" that babysitting them takes the vast majority of developers time? It's a nightmare.

sul_tasto 5y ago
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.
auslegung 5y ago
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.
- abraxas 5y ago
  I'm no longer with that company and it's possible that those devs were incompetent or always chased the next shiny framework or possibly both. But irregardless their output on the whole was about 20% that of those devs who used uncool old tech like Java/Spring and dotNET.
andrei_says_ 5y ago
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.

TheRealNGenius 5y ago

Twitter agrees, with regards to tweets and their business model

EastSmith 5y ago

I feel the pain, seeing non-trivial updates for Ruby, Elasticsearch and Postgres (thanks AWS) this year. Can not agree with the React part though. They keep so many things backward compatible. React 16 is 3, 4 years old now? I've updated pretty big code base from early 16 to latest 16 version painlessly - like in a day. Used some of the available code-modes for some really old part of the project. It worked flawlessly. Currently there are console warnings to fix certain things and that is it. No breaking changes, no nothing. Now, React 17 will be a problem - there are a lots of 3rd party UI libs that will not work with it. But I think we are pretty well set to use react 16 for the next couple of years, making it work for 6, 7 years total. I think that is a century in terms of FE and is great. Also, "...React pulling a sneaky on everyone and introducing hooks, which was a pretty bad move, especially if you needed to migrate to them" - just don't use hooks then - no problem.

torben-friis 5y ago
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?
- ljoshua 5y ago
  Tbh, I think the tutorial on React’s site itself is pretty good at making an introduction to the framework and the React way of thinking. It’s the one here: https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html As for changes during its lifetime, I would say that it is fairly on par for most web-focused frameworks, both front and backend. You could look at how ASP.NET has changed over the last few versions for example and see it being similar to React’s changes. The largest changes in React recently have been a greater focus on moving from syntactic sugar JS classes to pure functions, and React Hooks that go along with that. There’s definitely a shiny things syndrome you get if you just google for React tutorials, which is a bit annoying, but the official docs are pretty solid, and a few of the core devs are great to follow from a philosophical standpoint (like @dan_abramov). Hope that helps!

web007 5y ago

Corollary: Do hard things more often, per Martin Fowler - https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht... Upgrade everything all the time and it will never be hard. You'll have full context for breaking changes, and the diff from A to B is always smaller than from A to Q, and less likely to break in strange and confusing ways.

rewgs 5y ago
Absolutely agree with this. Find the rest within staying in motion.
snorkel 5y ago
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.
- naasking 5y ago
  Keeping up to date also has issues in the JS ecosystem. There were a couple of recent examples of npm packages that were hijacked and new versions released with embedded malware.
Igelau 5y ago
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.
- nlitened 5y ago
  Dedicate 20% of developers’ time on constant updates of all components for a decade just in case you might need one drop-in security module ten years after now (if the company ever lives to see that day)? Does not sound like a good illustrative argument to me, I am afraid.

prirai 5y ago

Use NixOS.

duncan-donuts 5y ago

I identify heavily with this but also the inverse —- always update everything (all the time). I don’t run arch anymore but one thing I did enjoy as a daily driver was that I was constantly updating my software. The pain is in the middle where you update things once every year or two (or when forced) and there’s hundreds or thousands of new changes that break your stuff.

jml7c5 5y ago

This is only somewhat related, but I wish semantic versioning had settled on four fields instead of three. A transition from 13.1.2 -> 14.0.0 could be a major update that revamps the API, or a tiny incompatible change. Another field at the front would fix this: major.breaking.feature.bugfix. It would help with the "zero-based versioning" problem where projects sit at 0.y.z forever because there's an aversion to frequently bumping the first number.

lwouis 5y ago
"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.
- GrumpySloth 5y ago
  > "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. You confused XKCD with reality: <https://xkcd.com/1172/ https://xkcd.com/1172/>

nhoughto 5y ago

Few interesting areas: - JS dependencies are a problem because of the sheer number, which is really because of all the authors of the dependencies and how they update, backwards compat or not etc. if you had 10 big things by 10 authors they would coordinate better than 1500. - The Lazarus example is interesting but “trusted components” also means walled gardens, who gets to choose? Is there competition? How is that decided in vs out? Logical conclusion to much of this ends up with a central community package manager like maven central..

angarg12 5y ago

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 worked in such a project who never upgraded once. And then Specter/Meltdown hit, and we had the mandate to patch all our systems (and the threat was very real). Welcome to a hellish mess of outdated deps that took weeks to sort out. But is not only me. I watched a talk from a Principal Engineer from Amazon builder tools, and one of their biggest mistakes was not to upgrade often enough, which made each upgrade more painful. So what do we do now working in multiple, large, multi-year projects? First, we set tools that tell us when deps are outdated, and alarm when vulnerabilities are found. Second, upgrading deps is part of the regular dev process. When you make a change, take the chance to upgrade the deps. Vulnerabilities are addressed proactively. The vast majority of times upgrades require no code changes. Third, we regularly upgrade deps of inactive packages. Lastly, if a dependency upgrade requires significant work, we create a ticket for it and address it as a new feature. In practice this happens very rarely, so it doesn't disrupt the development process much. As other's said, the key is to upgrade often, and then it wont be as painful.

KronisLV 5y ago
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.

rurban 5y ago

Hilarious post as expected from this camp. But there is some truth to it. Eg we explicitly do the equivalent of apt update -y: apt upgrade -y on our test builds to see update errors early. Only then our work dockers can be upgraded. Of course those folks don't have these luxuries. npm upgrades without testing, dependency tracking in XML, closed source deps, no symbol versioning, loose dll hell. But even with simple glibc binaries I have to maintain up-to-date and lts (ie outdated) versions for the recent fstat and time64_t changes. Then you start appreciating go. And podman.

cadamsau 5y ago

Interesting read, personally I disagree with the author on the risk-benefit tradeoff of having lots of updates. Something work calling out though - the author appears to have completely unironically updated their own post.

franga2000 5y ago

> Actually, i don't have enough time to do my day job, learn new technologies [...] > > Ergo, i cannot update. Ergo, companies cannot ship features AND handle all of the updates [...] Your time is limited and you can't get more of it. That isn't the case for a company. There, time == money, because if their employees don't have enough time to do all the work, they can just hire more to do the rest. But because they're only interested in growth and not sustainability, most of that money goes into developing new features, not keeping up with security updates. The vast majority of large companies could very easily hire one engineer and task them exclusively with updating legacy dependencies. And the smaller ones could instead re-task half their dev team for a month each year.

DeathArrow 5y ago

It is so wrong to desire to return to handwritten Javascript and libraries like jQuery? I don't do much fronted today and the reason are the frameworks. I still do it but I use Blazor to generate web assembly.

user234220 5y ago

Anyone care to comment on how [Deno](https://deno.land/ https://deno.land/) might address some of the issues shared in this thread?

gondo 5y ago

What an irony: the article about never updating anything has an update.