Imo they’re right, but theres some weird (pro proprietary software) claims in there.
If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system.
Those cases are rare on windows, most apps package their own versions of dependencies just like with snap/flatpak/appimage (just not so neatly organized) and it sucks.
Backwards compatibility is a major part of why Windows is still the dominant desktop OS.
But thats also a major part in why it sucks and is insecure. Microsoft knows that and has started to break stuff with higher frequency too. You should only freeze interfaces when there is a consensus that there isn’t anything to be improved anymore. You can only build this consensus when you have a clear use case.
I’d argue, that this is impossible for operating systems with desktop and all. So best you can do for backwards compatibility is to only put breaking changes in major versions and still maintain older ones. Of course that means you can’t have major versions to often and now people will complain that your software sucks because it can’t even do X.
Microsoft does this too, but they often release a whole new product instead of version bumps. And by that they accumulate even more technical debt.
Businesses actually care about this! They use ancient proprietary software that is critical to their business whose source code has long been lost to the sands of time.
This isn’t a case that should be handled by FOSS developers, but by courts fining them for putting their employees, customers and business partners at risk! Running software that isn’t maintained by you or a third party is a liability.
With Flatpak most of the runtime stuff is packaged separately, so on Flathub for example you have most of the applications using common runtime components. Sometimes you need multiple versions of one of them, but the same goes for a lot of Microsoft’s stuff.
I don’t find Windows to be any more backwards compatible than Linux is. On Linux you get the advantage of having access to the source more often, so source is going to be compatible for longer than binaries will. Source can be updated for compatibility too, giving it infinite life. (Of course, binaries could have infinite life if you take into account all the compatibility methods like virtualization.)
Yeah I’m sure business just love using ancient proprietary software and not being able to upgrade their systems. Oh wait, I thought compatibility was strong on Windows. (Not that all such software runs on Windows, but of course a major chunk of it does.) Businesses will eventually have to replace that old stuff, whether it’s sooner or later. It would have been better if they had the source code in the first place and could use that to help them upgrade or replace it.
With Flatpak most of the runtime stuff is packaged separately
They mentioned that not all flatpaks use the same separate runtime. Ideally they could just use the one my distro packages.
I don’t find Windows to be any more backwards compatible than Linux is. On Linux you get the advantage of having access to the source
You can run (a lot of) really old (late 90s) windows binaries with the modern libraries. You can also probably run really old linux binaries, but only if they use syscalls directly, not if they are (dynamically) linked against e.g. libc or x-stuff. Of course if the source is open, you can make it work.
Imo they’re right, but theres some weird (pro proprietary software) claims in there.
Those cases are rare on windows, most apps package their own versions of dependencies just like with snap/flatpak/appimage (just not so neatly organized) and it sucks.
But thats also a major part in why it sucks and is insecure. Microsoft knows that and has started to break stuff with higher frequency too. You should only freeze interfaces when there is a consensus that there isn’t anything to be improved anymore. You can only build this consensus when you have a clear use case.
I’d argue, that this is impossible for operating systems with desktop and all. So best you can do for backwards compatibility is to only put breaking changes in major versions and still maintain older ones. Of course that means you can’t have major versions to often and now people will complain that your software sucks because it can’t even do X.
Microsoft does this too, but they often release a whole new product instead of version bumps. And by that they accumulate even more technical debt.
This isn’t a case that should be handled by FOSS developers, but by courts fining them for putting their employees, customers and business partners at risk! Running software that isn’t maintained by you or a third party is a liability.
I find those points of theirs to be pretty weak.
They mentioned that not all flatpaks use the same separate runtime. Ideally they could just use the one my distro packages.
You can run (a lot of) really old (late 90s) windows binaries with the modern libraries. You can also probably run really old linux binaries, but only if they use syscalls directly, not if they are (dynamically) linked against e.g. libc or x-stuff. Of course if the source is open, you can make it work.