I've been using Linux for 9 years.
Newbie
(I kid I kid :P)
I'm using a minimalistic ditro (the live CD is just a very basic command line, and doesn't even have an installer; aside from copying the OS from the server to HDD, everything is done manually from command line).
My first "real" Linux distribution was Red Hat 6.0, released in 1999 (and I held off on buying 5.2 for the release of 6.0). I've been (mainly) using Gentoo since 2002 (though running and dealing with various other flavors over the years).
I don't have Windows installed. I am quite familiar with Linux. Also, I know what "sh" is. I've written shell scripts before. I also know that they are often used for distro-agnostic installers, and its not just IBM that uses them.
Probably not, but I do remember them from IBM, their main use was forcing users to agree to an EULA, other than that they served no real purpose as they generally (in like 80% of the cases) just extract everything to whatever directory you point them to (or just to the pwd).
I think you are are using the term "install" a bit narrowly. Simply copying programs into place is an installation process. Package files are installers. They contain the files to run the program, and instructions for the package manager to follow in order to make sure everything ends up in the right place, and all configuration are set. If that isn't what an installer does, then please, tell me what an installer really is.
No, an installer is a standalone program, a package requires a package manager to be of use. There's a very clear distinction, the former is almost never useful on Linux, the latter is used everywhere.
I know you can go from deb --> tarbar, and I've read guides to do so thinking I would need to (luckily I did not need to), though I would like to avoid that if possible. I'm much fonder of the idea of running sh DOS.sh as opposed to tearing apart a deb.
Also, I have only twice encountered a tarball that didn't follow the extract --> config --> make --> make install paradigm. The two were Rochard from a Humble Bundle and par2-tbb (the later of which was surprising as I would have expected that to be compiled for each machine).
You are failing to make the distinction between a source tarball and a regular tarball, a tarball is just a fancy name for a tar-file. When dealing with open source software you'll indeed generally get a source tarball nowadays, but back in the day *cough* most projects provided binary tarballs as well, keep in mind that back then there was basically just RPM (which sucked back then) and apt, both only used in their own distros, nowadays most distros provide their own builds for open source projects. But a lot of commercial software or "big" open source projects are still available as binary tarballs, Java is an example I already gave and the same goes for IntelliJ and Eclipse as well as, for example, Emacs.
The problem here is that for something like a game extracting the game is about as much installing as you have to do. There shouldn't be any shared libraries or anything that need to be accessible from the rest of the system (in fact, there better not be). The only "complex" things a game installer might want to do are:
1) extracting compressed resources
2) compiling a wrapper executable that adapts to the installed system.
3) possibly create shortcuts in various desktop environments
But the main reason to avoid making packages is that they're distro dependant and on top of that they're usually dependent on the version of the distro as well. If you provide a tarball then the community will generally take care of creating the packages for various flavors of Linux and keep them up-to-date in the future, if you provide some installer then you sometimes have to be lucky that it doesn't just break a few years down the line (happend to me to some commercial IDEs installer, it was a real pain to work around) and if you only provide distro specific packages you'll annoy users of other distros that now have write scripts to pick apart the package for some other distro to be able to generate one for theirs.
My main point is that a tarball is a neutral starting ground from which you can generate all other things: packages and installers. So providing your software as a simple tar file is convenient for everyone down the line.
