You're viewing a single thread.
I think there are two major hurdles keeping Linux adoption back (besides the obvious installation bit). The first is that our backwards compatibility is terrible. It is easier to get old versions of Windows software to run in Wine than it is to get some old Linux software to run natively.
If something like Photoshop did finally release a Linux version, even if they only did one release to make 2% of people happy, it likely wouldn't be able to run natively after 5 years.
The second is a good graphical toolkit. Yes, GTK and Qt exist, but neither are as simple as WinForms or SwiftUI/Aqua.
I've got plenty of old software here under Linux that still runs fine to this day across a number of PC's and even a Raspberry Pi that I use as a backup desktop. I honestly can't see backwards compatibility being any more of an issue than it is under Windows - There's a number of accounting packages released under Windows 7 that won't run under Windows 10, the latest version of most popular browsers won't run under Windows 7. Likewise, the latest version of MS Office 365 won't run under Windows 8.
Manual installation is one thing, but by far the biggest reason is OEM preinstalls. 98% of the people never install any operating system themselves, the devices just come with one and that's the one that'll be used.
To allow modern windows to run legacy applications a lot of caution is given to updating libraries or fully new ones are given while keeping the older ones. Also static builds are more common on Windows, or come bundled with a copy of the required libraries as .dll files.
- Let's say an application requires
libexample1. It works, the library is available too. - Eventually the application gets abandoned, but still works.
- But eventually a
libexample2gets released that drastically changes how the library works. The program doesn't work on this version. The older release of the library then get's abandoned. - Distributions now start removing the package from the repositories as the older library is slowly requiring no longer supported releases of its own dependency.
- Now application is borked
Aplication could have still worked if it came bundled with its own copy of libexample1 and of its dependencies, or was statically linked.
An example of this is Nero, a software kit for managing CD/DVD disc media. They made a build of some of their tools for Linux, meant to run on Debian 7. This builds were an experiment and got abandoned because of the very few users it had. Yet, these tools still work perfectly fine on Debian 12 despite being based on ancient libraries because it bundles all its requirements as a copy in its own proprietary blob.
I talked about caution on updating libraries on Windows. You can find many deprecated methods in any native Windows library that will likely never be removed from the library binaries, as many applications require it. The new, better and more feature rich method is given a different name instead, and is pointed out in the documentation for the older method.
Projects like FUSE are very nice for this, where an AppImave bundle of prebuilt binaries is given and can potencially not only be ran everywhere that can run FUSE but also in the future too.
Isn’t this what Flatpaks are doing?
Flatpak is definitely a possible solution. We will see how it will be managed in the future
- Let's say an application requires
All you mf saying Photoshop and Adobe PROBABLY dont even use it. Its like a mantra I keep hearing. Really? all you whiners use Photoshop and Adobe as professionals?
I personally don't use Photoshop but was using it as an example. You could fill in the blank with other tools like AutoCAD, MS Office, QuickBooks/Quicken, etc.
Yes.
Yup