The thing is, there's really is no such thing as a generic "for Linux". It's not just a matter of packaging systems, although that's a factor too. If it's anything nontrivial, it'll be linked against certain versions of certain libraries, and which libraries and which versions it depends on will prevent it from running (out of the box, at least) on distros which don't have those versions of those libraries.
I didn't look at the binary, but another commenter implied that it achieved this portability via static linking. This does get rid of a lot of the dependency issues that might cause problems, but it's not a solution either. You do not want everything to be statically linked, that would be a nightmare.
"You do not want everything to be statically linked, that would be a nightmare."
For a desktop system, you really do. The space and storage drawbacks are history with modern systems; the only remaining issue is that a user has to wait for the developer of their application to release a new version to get security updates, and that's not nearly as much an issue for a desktop system, where a user can just choose not to use software that's not updated promptly.
What makes it a technical achievement is that in order for static linking to be viable, the packager has to be very aware of dependencies and library ecosystems. The developers will also need to consciously constrain their design choices to ensure that the surface area of their package is small enough to deploy reasonably.
Comments
The thing is, there's really is no such thing as a generic "for Linux". It's not just a matter of packaging systems, although that's a factor too. If it's anything nontrivial, it'll be linked against certain versions of certain libraries, and which libraries and which versions it depends on will prevent it from running (out of the box, at least) on distros which don't have those versions of those libraries.
I didn't look at the binary, but another commenter implied that it achieved this portability via static linking. This does get rid of a lot of the dependency issues that might cause problems, but it's not a solution either. You do not want everything to be statically linked, that would be a nightmare.
"You do not want everything to be statically linked, that would be a nightmare."
For a desktop system, you really do. The space and storage drawbacks are history with modern systems; the only remaining issue is that a user has to wait for the developer of their application to release a new version to get security updates, and that's not nearly as much an issue for a desktop system, where a user can just choose not to use software that's not updated promptly.
So you don't mind downloading a gigabyte of updated packages every time libc is updated?
Correct.
What makes it a technical achievement is that in order for static linking to be viable, the packager has to be very aware of dependencies and library ecosystems. The developers will also need to consciously constrain their design choices to ensure that the surface area of their package is small enough to deploy reasonably.
[nathan@ebisu ~/opt/teeworlds] du -h . 9.7M .
That seems pretty impressive to me.