> 2) "GNU/Linux" sucks at providing a rich and stable API/ABI on which proprietary software can be built and supported, and
Care to elaborate on this one? I don't see what sucks about it. You can build proprietary software and run it on Linux. See also: Steam games.
> 3) Usability of what does exist generally sucks, because unsurprisingly, not charging for your work makes it very hard to hire artists and designers.
I've personally found the latest editions of Debian-based OSes (such as Linux Mint) to be very intuitive and beautiful.
> Care to elaborate on this one? I don't see what sucks about it. You can build proprietary software and run it on Linux. See also: Steam games.
This works if you:
- Ship all your dependencies yourself (the distribution-provided dependencies can't be relied upon to stay compatible)
- Spend a lot of effort keeping your app and its dependencies working with the surrounding desktop environment (even when shipping your own libraries, IPC protocols, configuration mechanisms, and interoperability behavior are all unstable)
- Expect that your users will be technically proficient enough to deal with the inevitable breakage, and
- Can afford to spend the extra resources to use the inconsistent and often poorly documented/implemented/designed OSS application libraries that are available.
Care to elaborate on this one? I don't see what sucks about it. You can build proprietary software and run it on Linux. See also: Steam games.
I've run into this before many times. Binaries for proprietary apps, from 20 years ago, will probably still work today on Windows 10 if they didn't do anything too crazy or need low-level system functions (e.g. disk defragmenters). I don't think the same can be said of proprietary apps on Linux; there, the vast amount of diversity is also its greatest weakness and apps tend to have these massive (version-locked) dependency chains attached to them.
> Binaries for proprietary apps, from 20 years ago, will probably still work today on Windows 10
Do you really want to run 20 year-old software?
> I don't think the same can be said of proprietary apps on Linux
So, you don't know then.
-------------
In my experience, getting something to run on Linux is easier than getting it to run on Windows. The only reason that more software isn't built on Linux is the network effect.
"All of our paying customers use Windows, why would we want to build on Linux? Only free software hippies use that!" - Caricature of the average IT manager
Steam for Linux is going to gradually be a... game-changer. B)
Games? Line of business applications? Other applications that still work for me and I have no reason to upgrade?
Yes. Yes I do.
<post type="rant" intensity="105%">
Windows is literally the only OS out there right now that gives a toss about backwards compatibility.
Try compiling old code on a new linux - prepare to be stuck in dependency hell for hours as you try to find libraries that the distro maintainers ever-so-helpfully deleted outright or renamed with no pointer.
Apple shamelessly breaks things every time there's a point release to iOS or OSX. Killing this API, turning on that "security" feature which breaks your addons, etc etc.
People do want to do this. Go and look at those who are already doing it.
Your experience is quite obviously very limited if you've got problems installing software that's built for Windows, on Windows. And Steam for Linux has been out for a couple of years now yet the majority of game devs aren't building games for Linux since next to nobody is running Linux for games or buying the lackluster Steam Machine - http://www.theverge.com/2015/6/5/8733139/valve-steam-machine...
Care to elaborate on this one? I don't see what sucks about it. You can build proprietary software and run it on Linux. See also: Steam games.
> 3) Usability of what does exist generally sucks, because unsurprisingly, not charging for your work makes it very hard to hire artists and designers.
I've personally found the latest editions of Debian-based OSes (such as Linux Mint) to be very intuitive and beautiful.