Reason #24,329 why modern software ecosystems suck
-
I'm mostly talking about open source ecosystems, although this issue is present to some extent or other in the world of proprietary software as well. It's just that there, it's not as prominent and can actually hurt the bottom line, so corporations rather won't do it.
The issue is as follows.
You have a wildly popular version of tool X, or library Y. At some point, a new version is released. People begrudgingly move to that new version, except those for whom the sheer amount of backward compatibility breakage is too much to afford. They pin the version to the highest version compatible with their product, and live for a while. Until the tool breaks because its fifth-order dependency breaks.
And then it turns out that, per popular opinion, you should either bite the bullet and waste a week bringing your project to work with the new version of X and still expect regressions to fall through the cracks, or basically create your own infrastructure where you can have a properly patched version of X.
"But hey, it's open source, you can make pull requests!", I hear. Well. Good luck getting a pull request for the previous major version getting accepted. And you cannot even haggle for doing it yourself, because the bunch of teenagers running the project grab at the namespace for dear life and won't let it go.
Take, for example, webpack, the go-to tool to roll your javascript and serve it as a single bundle. The webpack guys can't even keep the documentation for the version 3.x afloat, they nuked it the moment 4.0 was released — despite the fact Webpack 4.x had to go through 40 minor revisions before most of the shit got even fixed.
I've tried moving our project over to Webpack 4.x. Turns out we're bad because we have Babel 6.x, and that one doesn't play well with Webpack 4.x... and suddenly you need to shave a herd of yaks. Moving from Babel 6 to Babel 7, if your config is a bit hairy, is not for the faint of heart. Why the hell, if Webpack 3.x just works? Well, its dependencies bit-rot. But the upstream is insistent on not maintaining the previous major version, no matter how little the cost.
This reminds of the practice of selling tied items. To buy a book you really truly crave to read, you also need to buy a book by a graphomanic nobody no one wants to read, but that nobody is buddies with the bookstore chain owner. Or it's a thick book with the sayings of Dear Leader. If you happened to have lived in the Socialist Bloc, you might remember the practice, or tales about it. You know how everyone hated it. And now we have it with software: to get the bugfixes I absolutely need, I also need to buy the dozens of features I don't give a fuck about, and pay for them with my time to fix the BC breakages. All for what? Just so that I don't have to give a shit about my tools for another year.
I'm wondering if the true spirit of open source is having tools that facilitate longer life of older software versions, so you can patch and deploy older libraries which mostly work and integrate with your product perfectly, without the need to haggle with upstream and take up all the extra work of bringing your code to the latest shiniest framework version.
-
tl;dr There ain't no such thing as a free lunch.
-
@wft the one thing I don't quite understand - why won't you just freeze all tools, libraries and dependencies to a particular version? If nothing can change, then nothing will change.
-
@Gąska there are plenty of reasons. One day all browsers may announce that they're dropping the version of tls your packages use. Three months later, something else will come up. The burden of security isn't getting easier to deal with.
-
@Magus those things happen with years of advance notice. Surely updating once every five years must be less painful than updating once every half a year?
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
Surely updating once every five years must be less painful than updating once every half a year?
Yes, but you need to find a collection of versions of everything that actually work together, and you just know that some of them are going to get security alerts randomly sprayed in over time, some of which will be fixed by idiots who force a new major version of the package and which break everything downstream. It's definitely miserable.
I went through this recently with log4j, where using the v1 API — which worked just fine for our application — ceased to be viable earlier this year, and the v2 API was incompatible in enough critical areas that it caused me several days of pain. (The software in question that used log4j wasn't bitten by the security hole anyway, but I don't like to leave any security alerts open as they can conceal real trouble too.)
But at least the Java/Maven ecosystem is excellent at keeping around old packages, at least if they're publicly available.
-
@Gąska some packages will be early, some will be late. You'll have to eat the costs some time. And when you do, it might be worse if over the past six months, twelve new standards have been published and the version from three months ago is the last one with even incomplete documentation.
-
@dkf said in Reason #24,329 why modern software ecosystems suck:
@Gąska said in Reason #24,329 why modern software ecosystems suck:
Surely updating once every five years must be less painful than updating once every half a year?
Yes, but you need to find a collection of versions of everything that actually work together, and you just know that some of them are going to get security alerts randomly sprayed in over time, some of which will be fixed by idiots who force a new major version of the package and which break everything downstream. It's definitely miserable.
By freeze, I meant actually freeze. Local copy of all dependencies, checksum-verify in commit hooks if necessary, and never ever ever touch anything or let any tool touch anything unless you're performing the once-every-five-years update because browsers dropped support for something. Considering the alternatives, this sounds like the most sane (or rather, least insane) way to go.
Also. You have a working product on hand and it's only after an upstream update that something is broken. That implies you've already had a working configuration before. If you never had a working configuration to start with - well, here's your problem.
-
-
@Mason_Wheeler you don't get new security vulnerabilities either.
-
This is one of the eternal discussions here. Developers like deprecating old code and moving on to newer versions that work differently. (Some of) the people that consume their products don't. Well, too bad, the people that own the product get to decide.
In the end this isn't a technical problem, it's an economic problem. The people are not devoting their resources to maintain the "supply chain" you depend on. It's why enterprise software comes with 10 year life cycles and tons of backward compatibility. But you know, free stuff, etc.
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
@Mason_Wheeler you don't get new security vulnerabilities either.
True. But two things:
- Theoretically at least, you should get less new ones than the number of old ones that are fixed.
- It's probably better to have the new ones than to have the old ones, since the new ones are new and are probably not being exploited yet (or at least not as much).
-
@Mason_Wheeler said in Reason #24,329 why modern software ecosystems suck:
- Theoretically at least, you should get less new ones than the number of old ones that are fixed.
With operating systems and web browsers, which is usually the context of such discussions - yes. With JS frameworks that totally break any sort of backward compatibility at least on every major version and very often on minor versions too, that occasionally let completely broken patches that make everything unusable slip through into a stable release - I think I'm sufficiently justified in being extremely skeptical.
- It's probably better to have the new ones than to have the old ones, since the new ones are new and are probably not being exploited yet (or at least not as much).
On the other hand, the old ones were around long enough that the most egregious bugs were all fixed already. New version - especially new version that has zillion incompatibilities with the old - likely contains huge swathes of code that wasn't battle-tested yet and won't be for at least several months, and will take even longer to get patched into shape.
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
JS frameworks
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
JS frameworks
@error_bot giphy cadt
-
Giphy said in https://giphy.com/gifs/sniffing-kvs3VdgdmsLss :
-
-
@dkf Did you really think it would know a word like that?
-
@Mason_Wheeler I thought… well, that something better than that would turn up. But GIS is also highly pathetic on that search term.
-
@Mason_Wheeler said in Reason #24,329 why modern software ecosystems suck:
@Gąska said in Reason #24,329 why modern software ecosystems suck:
JS frameworks
Yes, it is. That's what this topic is about, after all. JS frameworks and their peculiar insistence on making breaking changes every season. While normally I have no problem with updating as soon as possible, the JS ecosystem is so utterly retarded that there's no benefit to it anymore and all the usual arguments don't apply.
Update your dependencies as soon as possible. Unless it's JS, then never update anything ever.
-
@dkf Did you check the ordinary Google search for it? It's got various other meanings than the one that (from the context) you're probably referring to.
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
the one thing I don't quite understand - why won't you just freeze all tools, libraries and dependencies to a particular version? If nothing can change, then nothing will change.
This is how stuff used to work before the Cool™ stuff started making incompatible changes every 4 seconds (and is obviously how the uncool stuff still works).
Unfortunately this is IT where we need to reinvent old problems and then forget we ever had a solution for them.
-
@Mason_Wheeler Yes, I did and it runs into the sand. Only one hit out of the first page was relevant, and that doesn't have any images.
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
@Mason_Wheeler said in Reason #24,329 why modern software ecosystems suck:
@Gąska said in Reason #24,329 why modern software ecosystems suck:
JS frameworks
Yes, it is. That's what this topic is about, after all. JS frameworks and their peculiar insistence on making breaking changes every season. While normally I have no problem with updating as soon as possible, the JS ecosystem is so utterly retarded that there's no benefit to it anymore and all the usual arguments don't apply.
Update your dependencies as soon as possible. Unless it's JS, then never update anything ever.
For this reason I prefer http://vanilla-js.com/
-
@PleegWat said in Reason #24,329 why modern software ecosystems suck:
For this reason I prefer http://vanilla-js.com/
99% of JavaScript developers don't know Vanilla JS though.
-
@error said in Reason #24,329 why modern software ecosystems suck:
@PleegWat said in Reason #24,329 why modern software ecosystems suck:
For this reason I prefer http://vanilla-js.com/
99% of JavaScript developers don't know Vanilla JS though.
87.3% of randomly quoted statistics were made up on the spot.
-
@PleegWat 60% of the time, it works every time.
-
@PleegWat said in Reason #24,329 why modern software ecosystems suck:
For this reason I prefer http://vanilla-js.com/
I prefer http://motherfuckingwebsite.com/
-
@marczellm said in Reason #24,329 why modern software ecosystems suck:
@PleegWat said in Reason #24,329 why modern software ecosystems suck:
For this reason I prefer http://vanilla-js.com/
I prefer http://motherfuckingwebsite.com/
@error_bot giphy not this shit again
-
-
@Gąska said in Reason #24,329 why modern software ecosystems suck:
Yes, it is. That's what this topic is about, after all. JS frameworks and their peculiar insistence on making breaking changes every season. While normally I have no problem with updating as soon as possible, the JS ecosystem is so utterly retarded that there's no benefit to it anymore and all the usual arguments don't apply.
The funny thing is there are dozens of articles written by JS devs saying "why do JS frameworks/tools suck" and coming to the same conclusions. They know what's going on and how it works outside their area, they just can't quit their addiction to new releases.
-
@anonymous234 JS developers aren't a homogenous mass. It's kinda like C++, except totally different - there, you have a widely used language that's used mostly because there are no alternatives, with hundreds of features that spawned millions of blog rants. Makes you wonder why they were created in the first place if everybody hates them.
-
I like JS because I can iterate and prototype rapidly. With the right tooling, I can virtually edit the program while it's running.
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
I use it in my custom tool and it was working well until the update.
What forced you to update?
-
@loopback0 said in Reason #24,329 why modern software ecosystems suck:
@Gąska said in Reason #24,329 why modern software ecosystems suck:
the one thing I don't quite understand - why won't you just freeze all tools, libraries and dependencies to a particular version? If nothing can change, then nothing will change.
This is how stuff used to work before the Cool™ stuff started making incompatible changes every 4 seconds (and is obviously ho myw the uncool stuff still works).
Unfortunately this is IT where we need to reinvent old problems and then forget we ever had a solution for them.
Developing Java backends isn't that bad, considering most libraries being decades old and pretty stable.
But doing JS frontend work? Why the fuck is it still a thing? They keep rolling out whole new frameworks with all the same problems as the last 200 frameworks of last month, all fixing some imaginary problem while ignoring the underlying issue that is JS, and SPAs in a static document viewer.
-
@error_bot said in Reason #24,329 why modern software ecosystems suck:
Giphy said in https://giphy.com/gifs/sniffing-kvs3VdgdmsLss :
"Oh, what's this? A new JS framework?"
-
@Zecc my reaction would be more along the SUDDENLY CUCUMBER reaction.
-
@anonymous234 said in Reason #24,329 why modern software ecosystems suck:
They know what's going on and how it works outside their area, they just can't quit
their addiction to new releasesupdating to fit their own needs better.FTFY
With FOSS, everyone writes the software they need. If it also fills your needs, then that's nice, and they get some street cred. But street cred is not exchangeable for physical consumables, unlike (presumably) their day-job that inspired them to write said FOSS.
For someone to go out of their way to write FOSS without getting anything themselves out of it... I find that unlikely. So, supporting old releases that the authors don't use themselves anymore? You're going to need money.
-
@acrow said in Reason #24,329 why modern software ecosystems suck:
For someone to go out of their way to write FOSS without getting anything themselves out of it... I find that unlikely.
Well, it happens, but those people are usually very opinionated and therefore respond even worse to suggestions.
-
@anonymous234 said in Reason #24,329 why modern software ecosystems suck:
The funny thing is there are dozens of articles written by JS devs saying "why do JS frameworks/tools suck" and coming to the same conclusions. They know what's going on and how it works outside their area, they just can't quit their addiction to new releases.
There's nothing bad about doing new releases. By all means, be my guest and do one every week. As long as you don't do mandatory bundling of the bugfixes everyone wants with your rewrites from scratch nobody gives a shit about, and as long as you keep the documentation for old versions up.
-
@dfdub said in Reason #24,329 why modern software ecosystems suck:
respond even worse to suggestions
When the suggestions are either “rewrite your million-line codebase in
$LANGUAGE_DU_JOUR
by next week” or “run support for my company for nothing”, it's small wonder that the appetite for doing them is zero.
-
@dkf said in Reason #24,329 why modern software ecosystems suck:
When the suggestions are either “rewrite your million-line codebase in $LANGUAGE_DU_JOUR by next week” or “run support for my company for nothing”, it's small wonder that the appetite for doing them is zero.
That's another . There are also enough cases of maintainers refusing to acknowledge bugs and major deficiencies in their hobby projects.
Which they obviously have the right to do, it just makes me prefer open-source projects backed by companies with financial interest in the product over hobby projects.
-
@acrow said in Reason #24,329 why modern software ecosystems suck:
For someone to go out of their way to write FOSS without getting anything themselves out of it... I find that unlikely. So, supporting old releases that the authors don't use themselves anymore? You're going to need money.
Well it's not like webpack is lacking any so far: https://opencollective.com/webpack#section-budget
The primary author of webpack gets a nice $10,500 a month. Not bad for webshit, even in Germany.
-
@dfdub said in Reason #24,329 why modern software ecosystems suck:
it just makes me prefer open-source projects backed by companies with financial interest in the product over hobby projects
Your best bet is probably to find one where there are small businesses with a significant input, as they don't have the financial muscle to afford to pull out on a whim. Big companies can screw things over very easily.
-
@levicki said in Reason #24,329 why modern software ecosystems suck:
we deprecated
Aaargh [not pointing at levicki]... Why do people seem to universally misunderstand the term. Deprecate means "recommend not to use", nothing more, nothing less. Inherently, there is no change in support (or existence).
One of the few places that "got it right" are the on-generic collections in .NET. They were deprecated in 2.0, but still exist (and are supported) today.
-
@TheCPUWizard said in Reason #24,329 why modern software ecosystems suck:
One of the few places that "got it right" are the on-generic collections in .NET. They were deprecated in 2.0, but still exist (and are supported) today.
I'm not sure those are technically "deprecated" (although they should have been). If they were, Microsoft should have been slapped them with an
ObsoleteAttribute
to encourage users to shift to the generic collections. And they shouldn't have been brought into .NET Standard.
-
@Unperverted-Vixen said in Reason #24,329 why modern software ecosystems suck:
I'm not sure those are technically "deprecated" (although they should have been). If they were, Microsoft should have been slapped them with an ObsoleteAttribute to encourage users to shift to the generic collections. And they shouldn't have been brought into .NET Standard.
There have been recommendations to not use these classes. That is the definition of deprecated.
There is no reason why something that has such a recommendation should inherently be marked as "obsolete". Actually removing them forces them not be used, which is fundamentally different than a recommendation
-
@TheCPUWizard said in Reason #24,329 why modern software ecosystems suck:
There is no reason why something that has such a recommendation should inherently be marked as "obsolete".
It results in a build warning, communicating to the developer that it should not be used.
Actually removing them forces them not be used, which is fundamentally different than a recommendation
I agree that it shouldn't be removed from .NET Framework; but .NET Standard was a clean starting point, and would have been a good cutoff point,
-
@TheCPUWizard said in Reason #24,329 why modern software ecosystems suck:
Deprecate means "recommend not to use", nothing more, nothing less. Inherently, there is no change in support (or existence).
Well, at Square they understand it in the same way as levicki's library authors. "We're bringing in a new API and a new sandbox, the old ones are deprecated effective immediately" — which meant the old ones stopped to work. There have been no point in time at which both interfaces would exist simultaneously, making transitioning and testing so enjoyable.
Apparently that's how millenials (and what's the new generation of teenagers called) deprecate stuff and impose extra cost on everyone else.
-
@Magus What I don't understand is why they didn't develop an interface to just add new TLS DLLs or ciphers or whatever somewhere that it could pick up so I wouldn't have to download a new browser where the hipsters crippled the UI and removed features.