OSX's installer isn't fast, it's true. But good God; three days?! What machine was he trying to use?

RAM is not in the habit of reporting its manufacturer to the OS, last I checked, so the only way to detect this RAM would be to run actual tests on it. Thorough testing can take hours to run on systems with large amounts of RAM. The most thorough method known to date -the Major March- can take upwards of a week. This man is complaining about the install taking too long, and he wants to add in RAM testing?

Tough cookies. Anyone here remember OSX 10.0, then this installation phase was not performed? Although this is a minor annoyance, it results in performance gains which were more than worth it.

Only if you don't back up your Home folder. Everybody sing, to the tune of "If You're Happy And You Know It":

Alternatively, you can use the installer's "Archive And Install" option, which preserves user data.

Why is he actually trying to manage these things, as though they were INITs under OS9? Would he prefer that they be rolled into the kernel, creating stability and security issues?

This is a problem with that program, not with OSX. Apple is known to work with big developers to help fix bugs; they should be taking advantage of this.

This was true up until OS8, as well as OSX. No one complained then.

Actually, filenames can contain question marks, even on standard Unix, though they require a bit of hoop-jumping if you intend to use them in the Terminal.

There are only two characters which cannot appear in OSX filenames: slash (/) and colon (. Of these, the colon wasn't allowed in OS9 either, because it was used to separate folder names when dealing with file paths. The same is true of the slash in OSX. All other characters are allowed.

Fixing permissions does surprisingly little; although it can help on rare occasions, it is mostly voodoo. What Apple really needs to do is fix its Installer to keep permissions from being messed up in the first place.