That's another thing with Linux in particular and open source in general, the whole "well, the code is there, you can just fix it yourself!" mentality. It puts the premise that users are knowledgeable which is one of the gravest mistakes one can make; you shouldn't treat your users as idiots but you definitely need to start developing from the premise that they are, especially when it's somewhat forward facing.

It's even nicer when you are a developer and make a fix and then the maintainer doesn't accept it because of politics completely unrelated to the code. What do you do then? Do you just fork it for that one fix? Been there, said screw it, not worth my effort to further maintain that.

What if you indeed push the fix, it gets accepted and integrated but then the distro doesn't pick your version for integration? Or worse, doesn't allow you on their repos? Do you really think all users know how to add custom repositories to download packages? And if you do, do you really want your OS of choice to remain so lacking when it comes to user experience and friendliness?

My largest problem with Linux is the bureaucracy associated with absolutely everything that goes hand in hand with it.

Trace? You mean tracert or something else?
Image mounting is there on windows 8, and I think win7 can also open isos, even if you may have to tinker a bit so it sees them as an archive.
System fonts are changeable to any languages as I recall, or at least I never had trouble changing them to greek on the 17+ years I've been using them, unless you mean system language instead of system fonts. That is also available, though mostly on purchase/installation time.

You can modify bash so that it's no longer compliant to most commands, or overwrite them with aliases, which could fuck up your bash script in strange, mysterious and often hilarious ways.

Your #!/bin/bash does absolutely nothing to prevent that.

I think he means running a trace on the execution of a process to see what resources and handles and .dll's it uses. But yet again, if that's basic functionality then me and him have extremely different understandings of that term.

Not to mention that this is easily and freely handled by getting Process Explorer.
Why not? There are changes for example to shell path traversal that can make my daily job easier beyond words but might (and there are high chances that they will) break the heck out of your script.

Except my whole thread was regarding the use of bash scripts as an installer, not against "developing for Linux", remember?

Apologies for derailing the thread Morgawr, was just curious about it.

As for gog support of linux, I don't see it happening in the near future due to the openness of the *nix world.
Let me give you an example.
"Hey guys, I just got Duke3D and I can't run it on my linux machine. What can I do?"
For each question you need to ask to help me, assume 20+ more manhours needed, assuming 1 hour test per machine to make sure it works with that configuration. Even if some *nix flavours are quite similar, they still have to test it on that flavour, not to mention the hardware combinations for each flavour.
Also, even if a game runs fine under DOSBox, what version of DOSBox will you include in the installer? While you could do an apt-get DOSBox or equivalent command depending on the OS installed, that means that the installer requires an internet connection, thus isn't self-contained.

And as for just giving an archive with the required data so a *nix user can grab it and extract the data and set the game themselves, they are already doing it, though you need a special extractor to do that. The extractor is called InnoExtractor I think :P

Again, you are free to modify your system as much as you want, just don't whine when stuff doesn't work. I think it's a rather idiotic statement to say that developing for Linux is hard because people can change their own OS as they like. If you're going around changing bash then it's not bash anymore and you're clearly experienced enough to fix your own problems.
(although I see no reason why someone would modify bash, just make a fork and call it "mybash" and use your own scripts with #!/usr/bin/mybash instead so you don't break backwards compatibility of your whole system).
Most of the Linux userland uses bash scripting as far as settings and installation of application goes, if you change bash you're just asking to break things. Plan accordingly.

Contrary to what some people think, there are standards to follow when developing for Linux (you're free not to follow them, just don't expect stuff to work that easily). If people don't follow those (either the user changing things or the developer being stupid) then it's not my fault. You can get your program working universally on all distros with minimal efforts if you stick to standard guidelines and know what you're doing. If you don't then you're in for a lot of trouble (not Linux's fault though)
Yup, gogonlinux uses innoextract but that's one added dependency that makes the user's job harder to install my software. You could just give us a .rar/.zip (or even .tar.gz) and let us extract that package effortlessly.

You're yet again missing my point completely. I never said that Linux is a big black box, I just said that stating things like "you can just use a bash script to install stuff and it'll always work" is stupid.

I guess we can stop this conversation here because it's not really going anywhere... you're claiming something that simply isn't true so.. whatever :)

So instead of 1 dependancy on 1 program used for a "You are on your own" solution, you prefer having duplicate files to make your "You are on your own" solution easier?

they already have "duplicate files" on their servers for windows and mac (actually they have 3, one for their old installer format, one for win_installer and one for mac_installer), it would just mean adding support for a "universal" installer platform. Let the users do the rest of the job.

No, I'm curios what's not true? I'm claiming that using a bash script as an installer isn't a good idea because you're dependent on something that can change as opposed to having something self contained.

Using a bash script as an installer guarantees universal compatibility on pretty much all Unix machines (even OSX, *BSD and even Minix3. They all use the same version of bash). Saying that this isn't true because "some user could have modified his own bash script" is incorrect. A user could have modified any aspect of his own system (thus breaking compatibility with anything else in the world) but that shouldn't stop you from supporting said platforms. With bash you are guaranteed to work, there's no way around it really.
(as an example, most companies shipping to Linux provide bash scripts for their installation process. Think about it however you want)

Autopackage was heavily bashed for trying to implement a complicated install system with bash (later they commited that this was not a good decision... entangled bash code base was keeping growing because of the linux ecosystem "variety").

Second point, is the policy if #!/bin/bash is redirect to explicitly bash or the editor of your choice now standardized/unified among distros/unices? Was not recently (2011/10?) the behaviour changed by debian? (or was it 2009? http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14901725)

As far as I know (I might be wrong here) /bin/sh is symlinked to whatever (usually dash) but /bin/bash is the bash shell. It shouldn't be pointing to somewhere else.

And yes, bash isn't the best if you want complex and extensive install scripts. But that's not the case for gog games.