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.
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.
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).
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.
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.
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.
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.
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.
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.
The concept only makes sense in the context of APIs. I don't know if that's obvious; I've seen people use semantic versioning with software that didn't have public interfaces.
Even if you go through a deprecation cycle, you're still going to eventually have a build N with feature X, and build N+1 without feature X. That's a breaking change.
That's true in the sense that a bullet flying at you and steam roller running you down both represent mortal threats. But practically a reasonable depreciation cycle isn't going to be a breaking change because everyone will have plenty of time to upgrade.
I'm guessing they're referring to conflicting transitive dependencies. Everything works fine when you use version 1 on date A. A couple years down the road, all those depends have matured at different rates and the top level packages all specify different versions of the same transitive packages so you have to try to line them all up.
On the other hand, the longer you wait to update, the worse it gets. Updating more frequently you can suss out packages moving quickly vs slowly vs not at all and address the problem before you're in update paralysis
> As a developer I'm only ever building and maintaining the latest source.
That's valid under semver.
The crazy diagrams show what happens when you want to support lots of old versions.
I have semver stuff at work where I only maintain the latest version. Bugfixes bump the patch version, adding a feature bumps minor, removing a feature bumps major.
I don't make any special effort to bump or avoid bumping anything. It gives me a rough idea of whether a given version has new stuff in it (x.1.0 or x.2.0) or is just a bugfix (x.0.1 or x.1.1)
Dependency hell has nothing to do with how you label your versions and everything to do with how much you want to annoy users by breaking whatever you like vs annoy yourself by taking the time to set stable APIs and hold compatibility backwards and forwards.
Semver vs. Git commit hashes vs. "just one number" vs. web browser versioning vs. "just timestamp" is all just different labels on the same soupcans.
I 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.
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.
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.
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.
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.
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.
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.
This resonates with me for a LOT of reasons but I take a very different approach. I try to keep just a few dependencies and keep them all up to date. For most updates I can read every line of updated code. I learn a lot, get all of the security patches, and sometimes I realize I don’t need a dependency and I remove it. I’m always trying to take small calculated risks. I have great monitoring and rollbacks are easy.
If you're running software maintained by someone else and you don't let them do that, and there's a security or major bug fix and you lose business or esteem of peers -- it's YOUR fault.
Ignoring upstream security fixes on a work-related machine that you use to make $$, is ASKING FOR IT. WHEN it breaks something that is your fault for being so stupid.
Neither of these extremisms are helpful. It's clearly more nuanced than any of this.
Of course it is. Context matters. I was trying to keep with the spirit of the article: 'Here's a fair warning: this article is reductio ad absurdum, therefore you shouldn't take it as gospel. ' Usually though in my experience, if you also control the network, then most security updates can wait to be tested on a non-production machine. Also it helps to Never ever use Windows.
> WHEN it breaks something that is your fault for being so stupid.
Sorry, this one raises my hackles. It's exactly such a user-hostile worldview that makes everything suck. It's just more victim-blaming and elitist tongue clicking that helps absolutely no one.
Everyone is stupid when it comes to software. There are hundreds of millions, if not billions, of lines of code, written by tens of thousands of different people, with myriad internal and external complexity, all breaking and falling apart at the same time. It is literally beyond human comprehension all the niggling details that could go wrong.
I whole-fist pushback against this "oh you should know what you are doing with metric asstons of other people's code". Uh, no. That's the attitude of unserious people who want to ship garbage and make it users' problem.
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.
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.
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.”
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.
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.
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.
> What do you want AWS to do here? Keep running software that won't get security updates? That seems a bit wild to me.
PostgreSQL is open source, so they could keep patching the old version with security fixes.
Or... they could keep using just the community-supplied free-of-charge version and pocket all the money from not maintaining security patches themselves.
They are providing easier maintenance and monitoring for open source DBs. You can always avoid RDS and install Postgres manually on EC2, if you so desire.
I'm not saying RDS couldn't be better, but I wouldn't expect them to maintain unsupported versions of 3rd party software.
I agree AWS should be contributing back to the open source projects and they are listed as a 'sponsor' (though not a major one) on the Postgres website.
But AWS should not have to take responsibility for providing indefinite updates to every version of every managed open source project it operates. The only way I could see this working would be if AWS charged the holdouts the cost of keeping them supported.
However, performing RDS Postgres upgrades is relatively quick and painless process. If a company doesn't have the capacity to do that every five years, then it shouldn't be running its own infrastructure.
> The only way I could see this working would be if AWS charged the holdouts the cost of keeping them supported.
That actually sounds like a great idea. They could charge more for use of older versions, so that people could calculate their tradeoffs, and migrate when they decide themselves.
I think they email account owner, because in our case he forwarded it to tech team. So if he would have chosen to not forward it to us, then we could have been in the same situation as you. Just wanted to mention that they actually sent an email about that issue. At least to somebody :D
We did our upgrades few months back (9.6 -> 13) and luckily in our case it wasn't big of a hassle. Just finding out correct upgrade path with Postgis took some investigation, but overall the upgrade documentation was good.
They actually just reverted this change within the last week (of course with accompanying “we love listening to your feedback!!!1!” eyeroll inducing messaging).
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.
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.
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.
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.
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.
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.
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.
I lived and suffered this tension between stability and security for years running a tech team. Staying on the upgrade treadmill while delivering actually important product features for the business. Hopping from LTS to LTS is a solid default strategy when you can use it.
So pardon the plug, but finding a happy middle-ground to exactly this problem for Django based projects is what I now work on with https://www.codestasis.com/
Projects that can't upgrade, because of the ensuing cascade of breaking changes and dev time needed, subscribe to CodeStasis to minimally update Django to new non-breaking patch versions.
So you can keep your trusty old version yet also stay patched and secure if you find someone to do the heavy lifting for you at reasonable cost, which I think we deliver.
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.
> 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.
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.)
This works at small scale (read: a small startup or for your own machine). It begins to fall apart once you have dozens of services each deployed at some time in the past 5 years, and no clue whether any of them are safe to update, or even validate.
I really appreciate people like you reminding most everyone that new != better. I live in Japan which people usually mock for still using fax machines, or keeping "the old ways" in many aspect of society.
There are important positive things that people don't realize are lost as we "modernize" society.
For example, these days the TV spies on my usage and sends that data back to the maker company; they will then sell it to advertisers. Every update is aggressively pushed to me, and after i accept it, i notice more ads (rebranded "you may enjoy" or "now trending") on the home screen.
Another example would be how awesome paper is. It displays information without requiring an energy source. It can be folded and unfolded. May not impress you until your phone battery dies on a trip or at the airport/stadium where you need to present your e-ticket
>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.
Have you considered getting rid of that TV and TV in general?
The thing is, it’s not that old to be so obsolete to not be a pile of vulnerabilities/lack of advanced feature that actually provide an attack surface, but it is old enough that one should simply not run it.
I have nothing against running lynx where you don’t even have js support.
Copying my previous answer to a similarly bad idea:
“ Browsers run untrusted code 0-24, which get JIT compiled to machine code through a very complex and bug-prone process. Add to that that desktop OSs are quite lacking when it comes to sandboxes, so even with browser sandboxes, the potential for serious damage is quire big.
So, staying ahead of bugs is a must.”
It's impossible to stay ahead of the bugs, because they appear ahead of the patches, and there are undoubtedly many unpatched bugs out there.
But if I only visit sites where this is unlikely (and don't allow JavaScript, which you seem to have missed) I am much safer than when browsing willy-nilly with the latest patches.
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.
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.
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.
I have had much better luck exposing printers over smb from Linux than from Windows. My in-laws were visiting and couldn’t print to our network printers directly from Windows, so I had to add them to CUPS and smb, which was painless.
I noticed my wifi router had an "update firmware" option. Hmm, I said, that sounds cool. Go to the trouble of looking up the manufacturer's support page for my model, download the file, poke it into the update box, click go.
Now all my IOT devices on the 2.4ghz now fall off the network after ten minutes and have to be manually restarted. I'm sure if I spend the time to look into it I'll find some fascinating difference of opinion regarding a detail of the 802.11b spec between the manufacturer of my very cheap wifi router and the manufacturer of the very very cheap wifi radios in my internet-connected thermometer.
Instead of doing that, I factory reset the router, and spent fifteen minutes restoring various configuration details from memory.
Ubuntu upgrades are often a mess, even with LTS versions.
Some issues I've encountered: 1) system lost its default route after an upgrade 2) network interface names changed, all connectivity was lost 3) system became unbootable (UEFI boot order changed.) This was all on a physical machine, and loss of connectivity meant having to to go the console.
This sort of thing makes me want to give GNU Guix or NixOS a try. Not sure which yet though. Last time I checked both, they were limited with regarding to disk encryption and partitioning and such. I came up with a possible solution for GNU Guix, but I never put it to a test.
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.
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.
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.
The second is not so much a problem with Android but the horrible intersection for OEMs with no reason to support old devices, Linux baking drivers into the kernel, and hardware manufacturers releasing closed source blobs instead of OSS drivers.
Newer versions of Android have done a lot to decouple the device tree from the rest of the OS so you can update without OEM involvement.
Google also moved a lot of functionality into Google Play Services that updates over the air (but that's a negative for some people)
Android: if you have a hobby app in the play store we’re gonna make you jump through stupid hoops to keep it alive every year or so (I just let mine die)
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'
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.
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.
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.
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!
287 comments
[ 2.9 ms ] story [ 267 ms ] threadhttps://packages.debian.org/stretch/redis-server
So much about not breaking things.
literally the first sentence...
"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.
In a more serious note: it is a rant
Boots immediately too.
Well, blown-fuse ROM is called PROM. Real ROM is made from hard metal VLSI masks or old ladies weaving copper wires.
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.
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.
Even if you go through a deprecation cycle, you're still going to eventually have a build N with feature X, and build N+1 without feature X. That's a breaking change.
You now have no way to indicate that you know your changes are breaking.
On the other hand, the longer you wait to update, the worse it gets. Updating more frequently you can suss out packages moving quickly vs slowly vs not at all and address the problem before you're in update paralysis
That's valid under semver.
The crazy diagrams show what happens when you want to support lots of old versions.
I have semver stuff at work where I only maintain the latest version. Bugfixes bump the patch version, adding a feature bumps minor, removing a feature bumps major.
I don't make any special effort to bump or avoid bumping anything. It gives me a rough idea of whether a given version has new stuff in it (x.1.0 or x.2.0) or is just a bugfix (x.0.1 or x.1.1)
Dependency hell has nothing to do with how you label your versions and everything to do with how much you want to annoy users by breaking whatever you like vs annoy yourself by taking the time to set stable APIs and hold compatibility backwards and forwards.
Semver vs. Git commit hashes vs. "just one number" vs. web browser versioning vs. "just timestamp" is all just different labels on the same soupcans.
I've noticed (more frequently) npm packages quickly climbing in versions (1-17 in a couple years) but at least it's painfully obvious.
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.
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)
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.
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.
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.
Unpatched and unmitigated? Yes.
Taking the time to build “defense in depth” into the architecture has saved my ass on many occasions.
Ignoring upstream security fixes on a work-related machine that you use to make $$, is ASKING FOR IT. WHEN it breaks something that is your fault for being so stupid.
Neither of these extremisms are helpful. It's clearly more nuanced than any of this.
Sorry, this one raises my hackles. It's exactly such a user-hostile worldview that makes everything suck. It's just more victim-blaming and elitist tongue clicking that helps absolutely no one.
Everyone is stupid when it comes to software. There are hundreds of millions, if not billions, of lines of code, written by tens of thousands of different people, with myriad internal and external complexity, all breaking and falling apart at the same time. It is literally beyond human comprehension all the niggling details that could go wrong.
I whole-fist pushback against this "oh you should know what you are doing with metric asstons of other people's code". Uh, no. That's the attitude of unserious people who want to ship garbage and make it users' problem.
Also, this disclaimer in the very first sentence of the article:
> "Here's a fair warning: this article is reductio ad absurdum"
Why?
[0] https://blog.malwarebytes.com/android/2021/04/pre-installed-...
[1] https://www.businessinsider.com/asus-acknowledges-computers-...
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.
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/
PostgreSQL is open source, so they could keep patching the old version with security fixes.
Or... they could keep using just the community-supplied free-of-charge version and pocket all the money from not maintaining security patches themselves.
I'm not saying RDS couldn't be better, but I wouldn't expect them to maintain unsupported versions of 3rd party software.
https://www.postgresql.org/about/policies/sponsorship/
But AWS should not have to take responsibility for providing indefinite updates to every version of every managed open source project it operates. The only way I could see this working would be if AWS charged the holdouts the cost of keeping them supported.
However, performing RDS Postgres upgrades is relatively quick and painless process. If a company doesn't have the capacity to do that every five years, then it shouldn't be running its own infrastructure.
That actually sounds like a great idea. They could charge more for use of older versions, so that people could calculate their tradeoffs, and migrate when they decide themselves.
We did our upgrades few months back (9.6 -> 13) and luckily in our case it wasn't big of a hassle. Just finding out correct upgrade path with Postgis took some investigation, but overall the upgrade documentation was good.
This made me uninstall Docker Desktop.
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.
This is one of the attitudes that makes the internet so toxic IMHO.
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.
Yes. That is exactly what I said.
Right up there with removing all nuance from a discussion and attacking a strawman...
Dealing with a normal mistake isn't a problem because I can just opt out. They removed that ability here.
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.
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.
It's wonderful.
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.
So pardon the plug, but finding a happy middle-ground to exactly this problem for Django based projects is what I now work on with https://www.codestasis.com/
Projects that can't upgrade, because of the ensuing cascade of breaking changes and dev time needed, subscribe to CodeStasis to minimally update Django to new non-breaking patch versions.
So you can keep your trusty old version yet also stay patched and secure if you find someone to do the heavy lifting for you at reasonable cost, which I think we deliver.
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.
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.
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.
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.)
By conservative, I mean something which would still work today if I wrote a script for it 10 or 20 years go.
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
Have you considered getting rid of that TV and TV in general?
Greetings from Germany as well...
I have nothing against running lynx where you don’t even have js support.
“ Browsers run untrusted code 0-24, which get JIT compiled to machine code through a very complex and bug-prone process. Add to that that desktop OSs are quite lacking when it comes to sandboxes, so even with browser sandboxes, the potential for serious damage is quire big. So, staying ahead of bugs is a must.”
But if I only visit sites where this is unlikely (and don't allow JavaScript, which you seem to have missed) I am much safer than when browsing willy-nilly with the latest patches.
No updates: ignorance is bliss. Until you need to breathe -- then you die.
All updates: maybe I can just drink the whole thing...
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.
"Be on this version. Now."
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.
Well if you wanna debug it, go back to 5.13. I just mean I want Nix or Guix style declarative systems.
Now all my IOT devices on the 2.4ghz now fall off the network after ten minutes and have to be manually restarted. I'm sure if I spend the time to look into it I'll find some fascinating difference of opinion regarding a detail of the 802.11b spec between the manufacturer of my very cheap wifi router and the manufacturer of the very very cheap wifi radios in my internet-connected thermometer.
Instead of doing that, I factory reset the router, and spent fifteen minutes restoring various configuration details from memory.
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.
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.
Also, Android: One day we will stop giving you updates, so your apps can't talk to new versions of online services anymore.
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)
So, for old hardware:
- Install Linux to desktop/laptop computers
- Install Ubuntu Touch to smartphone, if available
im not sure i agree with the accident theory though because 'i' looks a lot more deliberate that 'I'
author lost me at this point
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.