I will reply, just because you said please 
What are you referring to as a projected misinformation? None of the things I said is false, it is damn hard and I compare that to all the years from using different OS’s since 87. That doesnt mean that I stay away from using Linux but I always end up using Bash and manually configuring files, always! And it doesnt matter what distro it is. It is not spreading misinformation. I Dont recommend Linux anymore for non-techies for the reason being that I will be the one helping out and trying to explain how it works. You namedropped Nuke which is an exception rather than a rule. Installing applications on Linux is damn hard and a simplyfied installer that works the way AppImage works is very welcome.
Nuke and Modo are the only two applications I have used for Linux that works that well. I remember spending about 3 months trying to Maya on Linux Mint because alien could only automate so much and I ended up having to manually find and link ~70 or so libraries for the software to even start. Then there was the numerous bugs introduced because of the libraries I linked to and so on…
The problem is that Nuke and Modo are the exception rather than the rule and my time with Linux was far from painless. A problem that AppImage seemingly would solve quite nicely.
Package managers and repo’s are a special thing on Linux/*BSD that Windows/Mac don’t really acknowledge, and works fabulously if you understand the concept.
Whether package managers work well is highly circumstantial. There’s tons of different systems, repositories and maintainers for all those Linux distributions. Often enough, the application you want isn’t being maintained at all, or it is poorly maintained. Blender is really the best example here: On literally every distribution I have tried, the Blender package was severely outdated and/or broken in some way (Cycles being missing, broken Python).
One thing is for certain however: Supporting all of this as a developer is a giant pain in the ass. If you don’t get lucky and have repo maintainers do it for you, you have to build and test packages for all the distributions you want to support. You may even end up building packages for different versions of the same distribution, because some dependency might be too old (or too new) to be contained in the official repositories. It’s insanity.
Just look at the Linux download options for Mitsuba: There’s a package for five different versions of Ubuntu/Debian, two for Fedora and one for Arch. Unfortunately, not a single package for any current version of those distributions or for the supposedly most popular Linux distribution: Linux Mint (at least according to distrowatch).
If you don’t, it’s not a Linux problem, so don’t project misinformation unto Linux, please.
If Linus Torvalds says it’s a problem for Linux it probably is a Linux problem.
The point of mentioning Nuke (and other self contained installers) is that it is possible. Having difficulty to install Maya on a distribution that Autodesk doesn’t want to support, is not a Linux problem, IMHO. Autodesk could do what The Foundry or SideFX are doing to make it easier, but Autodesk choose not to.
Package managers and repositories are community managed, yes, and priorities vary there. Ease of installation is up for discussion here, and here I still maintain that using your distro (GUI on top of) package manager is easy. Proprietary / 3rd party applications could do what Nuke/Houdini/etc are doing, and if they do provide RPMs/DEBs it just a bonus for those of us who maintain a private/company repo.
Just look at the Linux download options for Mitsuba: There’s a package for five different versions of Ubuntu/Debian, two for Fedora and one for Arch. Unfortunately, not a single package for any current version of those distributions or for the supposedly most popular Linux distribution: Linux Mint (at least according to distrowatch).
Linux Mint is Debian, and it is stated on the Linux Mint website. You can install and use packages for older distributions, unless something major has changed in the newest distro release, like using the latest, compatibility breaking glibc or omitting Python2 or something like that. I can download a RPM for RHEL6 and install and use it on CentOS7 for example. In the case of tracking software Mocha, the company only provides a RPM for RHEL5(!) and that doesn’t work on RHEL7. Again, I don’t see that as a Linux problem, but as a problem with the company not keeping up with 1 enterprise distro, and it is its responsibility since the source is closed.
Listen, I’m not against stuff like AppImage or Docker, but I feel a big deal is being made about how Linux distros deal with software installation/update, when there are strengths in that, but different from how Win/OSX does it. Sure computing power, memory and space is cheap now, but I agree with Torvalds when he says:
So the problem is Valve will build everything statically linked and create huge binaries, and that’s kind of sad, but it’s what you have to do right now.
When I tried Appimage years ago, I failed in every attempt to create portable applications. Judging by the small number (and old) of apps here:
http://portablelinuxapps.org/
I think Appimage is too complicated for normal users like me, and maybe not the best to be used by developers when creating applications with static libraries.
At that time, I had found most interesting the CDE project (at least for normal users without much programming knowledge):
http://www.pgbovine.net/cde.html
At least I had managed to create some portable applications with it, anyway also remember having some problems. And unfortunately the CDE project seems abandoned now.
Warning: I seem to remember that when you create portable apps with CDE, by default the local app data of the llinux user were included in the portable app (or something like that, I do not remember well). I think this was possible to correct later, and then you can clear user data. Just keep in mind this if you are thinking in try CDE and share the portable apps. So, you could create a new user just to create your portable apps there.
Not super experienced about various GNU/Linux distros, but this subject, is the very reason I chose OpenSUSE. It has this…
You can (somehow) use that, to convert software designed for other distros to OpenSUSE. So far, when I’ve looked up an application, someone has already done the work, and you can just download their version instead of even having to use the online toolset.
One problem is, I am not quite sure if this would work on closed-source/proprietary software (maybe someone else here will know).
A week ago I used it for the first time in OpenSUSE, and the very latest version (think it was released that day even) of Blender was available (-though the official repo was a version behind) still, the newest one was already there ready to install, was basically one click no hassle.
The fact that it is (in the words of Torvalds) a “major fucking pain in the ass” is a Linux problem. It’s not even a technical problem, it’s a cultural problem.
Since Linux is such a small platform (on the desktop), it should really be the opposite way: Building and redistributing applications should be as simple and un-bureaucratic as possible.
Ease of installation is up for discussion here, and here I still maintain that using your distro (GUI on top of) package manager is easy.
Sure, it’s easy to install an outdated/broken version of Blender from a repository. It’s also not that hard to run Blender from the official tar.gz distribution. Both are shitty user experiences, however.
Linux Mint is Debian, and it is stated on the Linux Mint website. You can install and use packages for older distributions, unless something major has changed in the newest distro release, like using the latest, compatibility breaking glibc or omitting Python2 or something like that.
Ubuntu uses Debian packages as well, yet Mitsuba has different packages for every single release (plus another one for Debian itself). The reason is that each distribution provides different ABI-incompatible binaries of its dependencies. Those aren’t “major” changes, at all. This doesn’t affect each application equally, so you may just not have run into that problem.
I can download a RPM for RHEL6 and install and use it on CentOS7 for example. In the case of tracking software Mocha, the company only provides a RPM for RHEL5(!) and that doesn’t work on RHEL7. Again, I don’t see that as a Linux problem, but as a problem with the company not keeping up with 1 enterprise distro, and it is its responsibility since the source is closed.
This is a symptom of the problem. Clearly, Linux is so insignificant to their business that this company can’t even be bothered to keep the RPM for the one supported Linux distribution up-to-date.
Listen, I’m not against stuff like AppImage or Docker, but I feel a big deal is being made about how Linux distros deal with software installation/update, when there are strengths in that, but different from how Win/OSX does it.
The problem isn’t having package managers, the problem is not having an established way to properly redistribute software without them.
I am compiling master under last ubuntu LTS.
After several weeks of refusal to recognize my Titan Card with an up-to-date driver as an OpenSubdiv capable device, ideasman killed my motivation to follow master dev.
Python: remove support for Python 3.4
I feel your pain, following master is sometimes crazy.
I think it would make more sense if install_deps.sh script just created a static compiler environment instead of trying to use packages from different distributions and versions. I mean, it has to compile python 3.5 anyway on almost all non-bleeding edge distributions why not just compile everything that should be static and create a shareable static blender by default?
I also think the jump to python 3.5 just when it’s out is too soon… but I already updated my build environments for that and the drop of scons.
Linux way of compiling everything and the kitchen sink is just crazy.