I'd say it was the lack of a standardized install convention for "guest" (non-nix) software.
What to do about it? Couple golang's preference for large statically-linked binaries with a one-folder, one-executable install convention and Linux may become more inviting for non-nix apps.
For example, imagine "/outside/myapp/myapp" is a large, unix-unfriendly, statically-compiled binary placed in it's folder by a OS-provided install utility. "Myapp" was probably developed for Mac or Windows and by design does not give a damn about /etc, /lib, /var, etc. These app should just be allowed to crap their configuration files into the home directory into which it has been placed ("/outside/myapp"). If one no longer needs the app, the folder is deleted along with everything else the app created while it was being used. Tidy. Behind the scenes such an app would be compiled to call the standard Linux APIs, yet it would probably avoid any dynamic dependencies. Disk space is cheap. Just bundle it all together and throw it somewhere where it can run in peace.
Amiga's icon files are another approach. Rather than a large, monolithic registry tracking everything in the system, executables exist in tandem with an "icon" (.info) file. This file is generated by the OS and tracks the executable's location and other settings in the workbench (desktop). A modern reincarnation could potentially track anything. Instead of accumulating registry filth with every uninstall one can simply remove an executable and its associated .info file. Instead of adhering to the heir convention, the app plays nicely in its own folder with it's own registry. By using an ".info" file, portable non-nix installs could reside anywhere, and not in a prefabbed "/outside" folder.
The smartphone penchant for portable installation should come to nix, particularly with non-unix software. It should be encouraged, and that's coming from an OpenBSD user. Unix needs a playground for non-unix apps.
What to do about it? Couple golang's preference for large statically-linked binaries with a one-folder, one-executable install convention and Linux may become more inviting for non-nix apps.
For example, imagine "/outside/myapp/myapp" is a large, unix-unfriendly, statically-compiled binary placed in it's folder by a OS-provided install utility. "Myapp" was probably developed for Mac or Windows and by design does not give a damn about /etc, /lib, /var, etc. These app should just be allowed to crap their configuration files into the home directory into which it has been placed ("/outside/myapp"). If one no longer needs the app, the folder is deleted along with everything else the app created while it was being used. Tidy. Behind the scenes such an app would be compiled to call the standard Linux APIs, yet it would probably avoid any dynamic dependencies. Disk space is cheap. Just bundle it all together and throw it somewhere where it can run in peace.
Amiga's icon files are another approach. Rather than a large, monolithic registry tracking everything in the system, executables exist in tandem with an "icon" (.info) file. This file is generated by the OS and tracks the executable's location and other settings in the workbench (desktop). A modern reincarnation could potentially track anything. Instead of accumulating registry filth with every uninstall one can simply remove an executable and its associated .info file. Instead of adhering to the heir convention, the app plays nicely in its own folder with it's own registry. By using an ".info" file, portable non-nix installs could reside anywhere, and not in a prefabbed "/outside" folder.
The smartphone penchant for portable installation should come to nix, particularly with non-unix software. It should be encouraged, and that's coming from an OpenBSD user. Unix needs a playground for non-unix apps.