I have written desktop applications for Windows, OS X, and Linux, and before WebGL was a thing, I took the Win32 source code for Google Earth, made it portable, made a Mac version and then others built on top of that to make a Linux version.
I will second everything that this slashdot comment says.
The WIN32 version, all that we've ever released, still work. Some of the older ones may not find old servers, but the code itself is functional.
None of the older linux versions work on a modern linux distribution. In fact, we gave up maintaining the Linux version because it was too much work to keep up with the drift in LSB, OpenGL, libc, and when you put in man-months to get the latest version working on the main distributions, you had the Gentoo users screaming bloody murder that we can't support every combination of compile flags they used. LSB was supposed to fix this, but it was a dumpster fire.
Mac is somewhere in between. Apps run for a while, but the deprecation of 32-bit apps broke older Google Earth binaries. On OS X, you need to recompile and re-distribute your software every 2-3 years, would be my rough guess.
Windows has backward compatibility solved better than anyone. I can still run 1990's code on Windows 10.
> The WIN32 version, all that we've ever released, still work. Some of the older ones may not find old servers, but the code itself is functional.
I feel you. I made pretty much this argument to a fellow GNU/Linux user (arch Linux user, if that adds anything). He started saying that syscalls are stable and that it's a gtk/GUI library problem and that if you were to, say, if you somehow loaded all the old libraries, it would work.
Which might be true and everything, but come on. That's the equivalent of pushing your hands on your ears and shouting.
Quite frankly, the thing that saves GNU Linux a bit is that windows is basically getting shittier and shittier at user experience.
I recently compiled linux code from late 90s on Ubuntu. Apart from having to apt-get make utils and deprecated libs, it still worked, though with wrong server hosts. You may run into glibc, 64 bit vs 32 bit issues and the like, but lots of it is pretty compatible. Windows has its own legacy compatibility layers, though it is questionable if that's really a great idea.
Yes, indeed, I do believe it's both feasible and true, but let's keep the discourse in the context of desktop usage and desktop users: could you really advice a regular user to go through all those steps?
That's the point. In windows 99 times out of 100 you can just run the binary.
> He started saying that syscalls are stable and that it's a gtk/GUI library problem and that if you were to, say, if you somehow loaded all the old libraries, it would work.
That's because no single organization can be blamed for the mess that is "GNU/Linux" ;-) Binary compatibility is very important for the kernel folks, but apparently much less so for maintainers of glibc and other libraries.
As a workaround, binaries can be statically compiled, or bundled with all their dependencies. Flatpak and Snappy are two projects addressing this issue by packaging applications as containers.
When it comes to backward compatibility nobody cares what projects are starting today (and would care even less considering how many projects die). It matters what you've been doing in the last 10-15 years.
It's not about whose fault is or is not. It's about the state of things.
It's not that Windows has backward compatibility solved better than anyone. It's that they don't remove the old stuff. They only removed Win16 in the 64-bit versions of Windows so it was around for 20 years. Perhaps they will leave Win32 in until they come out with Win128.
Backward compatibility isn't a technical issue, it's a political one.
If only GNU/Linux systems have had half of Windows' marketshare, obviously some choices about breaking app-level compatibility would have been very different.
But just remember folks, Windows 10 telemetry is basically Microsoft-sanctioned adware/spyware right on your computer. I've done a "base setup" of W10 sniffing traffic from a clean/fully patched install and it talks to everyone. The only way I've been able to mitigate this is running LTSB/LTSC versions along side of reputable "disable telemetry" software pulled from GH. It's gross.
Although I admit to fighting with my Debian installations from time to time, at least they respect my privacy.
I feel you. Very much in the same boat. I do miss a lot of the fun things I did on/with Windows, but with all the malware that's baked into Windows 10 (and prior versions too - they just weren't as heavily scrutinized it seemed) it's just a non-starter for me. Creeps me out too much.
A Microsoft Linux would also be DOA for me, given that I wouldn't trust it to not be the same as their current offering - jam-packed full of privacy-violating spyware, riddled with secret security holes, and getting worse as the days go by. At least with Debian and Fedora, I know what to expect, and I could have an influence on what happens there.
Cynicism aside, I do believe that Microsoft's Linux would be a great choice for consumers. Background upgrades with fast reboots is my number one selling point of Ubuntu to regular users.
What do you mean by "sniffing traffic"? Is this something you observed yourself or just repeating sensationalist claims by others? Are you claiming they installed a compromised certificate and are MITM-ing all your traffic !?
FWIW, in my case I use the built-in controls for turning telemetry down, and supplementing with a pi-hole on the network that blocks a lot of telemetry endpoints. I'm confident that whatever (if anything) slips through is just generic anonymized usage stats; they wouldn't risk compromising privacy this way especially with GDPR (and other similar things) in play.
I’m quite sure he meant that he was sniffing traffic through wireshark or such. And using that he found it was making lots of connections to different endpoints.
I'm still running kde neon with a ubuntu 16.04 base. I've been getting update popups for a while, but previous experiences updating Ubuntu versions has left me with problems and I haven't really felt like going through the efforts of a fresh install yet, but i've been noticing it's harder and harder to find working packages for updated software or even for me to be able to build the newest versions of some apps due to being stuck on older versions of libraries.
The thing is, older software not updated since before 2016 tends to also be problematic due to older versions of libraries being unavailable.
It feels like being stuck in a snapshot in time roughly 4 years or so from the release date of my distro.
It's getting to the point where the hassle of updating is looking to be more appealing than trying to keep dealing with the hassle of library problems with everything I find not made specifically for libraries available from 2016 to nowish.
Don't get me wrong, there's plenty of software that does work hassle free, but I find the more time goes on, the harder it is to keep things up to date or get newly released software without problems.
Did fresh install of Mint xfce 20, haven't looked back and even reformatted the ssd. I was on 14 lts. Upgrades work fine so far and should be possible to revert to snapshot.
I'm good with kde neon, I I like having rolling kde releases with a long term stable core, hence my resistance to upgrading.
In general though, the linux library snapshot issue will exist mostly whatever distro you use. Either.you're keeping up with the latest and greatest and losing compatibility with older software, or stuck somewhere in the past.
Library management between distros and versions of distros is probably my only complaint about linux and honestly, I think a lot of people's complaints boil down to that in the end, because a lot of software problems on linux for users and developers tends to end up being something along the lines of
'This app doesn't work properly or can't be installed or built because these libraries aren't available or aren't found where expected. The developer also can't or won't help(not unexpectedly) because they use q totally different distro and set of libraries and the only way around it is by replicating the dev's setup.
At this point, i've lost count of the amount of different versions of different things I have scattered around various places just as workarounds.
If i migrate to a newer system, I have no idea how many of those will work or need to be fixed or will be available through a package manager.
19 comments
[ 4.0 ms ] story [ 57.4 ms ] threadI will second everything that this slashdot comment says.
The WIN32 version, all that we've ever released, still work. Some of the older ones may not find old servers, but the code itself is functional.
None of the older linux versions work on a modern linux distribution. In fact, we gave up maintaining the Linux version because it was too much work to keep up with the drift in LSB, OpenGL, libc, and when you put in man-months to get the latest version working on the main distributions, you had the Gentoo users screaming bloody murder that we can't support every combination of compile flags they used. LSB was supposed to fix this, but it was a dumpster fire.
Mac is somewhere in between. Apps run for a while, but the deprecation of 32-bit apps broke older Google Earth binaries. On OS X, you need to recompile and re-distribute your software every 2-3 years, would be my rough guess.
Windows has backward compatibility solved better than anyone. I can still run 1990's code on Windows 10.
I feel you. I made pretty much this argument to a fellow GNU/Linux user (arch Linux user, if that adds anything). He started saying that syscalls are stable and that it's a gtk/GUI library problem and that if you were to, say, if you somehow loaded all the old libraries, it would work.
Which might be true and everything, but come on. That's the equivalent of pushing your hands on your ears and shouting.
Quite frankly, the thing that saves GNU Linux a bit is that windows is basically getting shittier and shittier at user experience.
That's the point. In windows 99 times out of 100 you can just run the binary.
That's because no single organization can be blamed for the mess that is "GNU/Linux" ;-) Binary compatibility is very important for the kernel folks, but apparently much less so for maintainers of glibc and other libraries.
As a workaround, binaries can be statically compiled, or bundled with all their dependencies. Flatpak and Snappy are two projects addressing this issue by packaging applications as containers.
When it comes to backward compatibility nobody cares what projects are starting today (and would care even less considering how many projects die). It matters what you've been doing in the last 10-15 years.
It's not about whose fault is or is not. It's about the state of things.
What do you think backwards compatibility is?
Naa, especially old games work often better with wine then with Win10. I even can run DOS code from 1990 without any problems (trough dosbox)
If only GNU/Linux systems have had half of Windows' marketshare, obviously some choices about breaking app-level compatibility would have been very different.
But just remember folks, Windows 10 telemetry is basically Microsoft-sanctioned adware/spyware right on your computer. I've done a "base setup" of W10 sniffing traffic from a clean/fully patched install and it talks to everyone. The only way I've been able to mitigate this is running LTSB/LTSC versions along side of reputable "disable telemetry" software pulled from GH. It's gross.
Although I admit to fighting with my Debian installations from time to time, at least they respect my privacy.
A Microsoft Linux would also be DOA for me, given that I wouldn't trust it to not be the same as their current offering - jam-packed full of privacy-violating spyware, riddled with secret security holes, and getting worse as the days go by. At least with Debian and Fedora, I know what to expect, and I could have an influence on what happens there.
Cynicism aside, I do believe that Microsoft's Linux would be a great choice for consumers. Background upgrades with fast reboots is my number one selling point of Ubuntu to regular users.
FWIW, in my case I use the built-in controls for turning telemetry down, and supplementing with a pi-hole on the network that blocks a lot of telemetry endpoints. I'm confident that whatever (if anything) slips through is just generic anonymized usage stats; they wouldn't risk compromising privacy this way especially with GDPR (and other similar things) in play.
The thing is, older software not updated since before 2016 tends to also be problematic due to older versions of libraries being unavailable.
It feels like being stuck in a snapshot in time roughly 4 years or so from the release date of my distro.
It's getting to the point where the hassle of updating is looking to be more appealing than trying to keep dealing with the hassle of library problems with everything I find not made specifically for libraries available from 2016 to nowish.
Don't get me wrong, there's plenty of software that does work hassle free, but I find the more time goes on, the harder it is to keep things up to date or get newly released software without problems.
In general though, the linux library snapshot issue will exist mostly whatever distro you use. Either.you're keeping up with the latest and greatest and losing compatibility with older software, or stuck somewhere in the past.
Library management between distros and versions of distros is probably my only complaint about linux and honestly, I think a lot of people's complaints boil down to that in the end, because a lot of software problems on linux for users and developers tends to end up being something along the lines of
'This app doesn't work properly or can't be installed or built because these libraries aren't available or aren't found where expected. The developer also can't or won't help(not unexpectedly) because they use q totally different distro and set of libraries and the only way around it is by replicating the dev's setup.
At this point, i've lost count of the amount of different versions of different things I have scattered around various places just as workarounds.
If i migrate to a newer system, I have no idea how many of those will work or need to be fixed or will be available through a package manager.