\r\nA lot of modern OSes have features that make using the OS easier...Like automatically creating icons that launch programs...\r\n

Debian (and Debian-based distros such as Xandros, Progeny, and Lindows) handle this through the 'menu' system. New pograms added through APT are automatically added to system menus. Third-party programs which are menu-aware can similarly use this mechanism. Result: you don't en up with system menus having null entries (a menu entry with no program behind it) and largely every GUI program adds itself to the system menus. This works across all window managers. From twm to GNOME.

\r\n...add and remove program GUIs...\r\n

Debian: [link|http://www.nongnu.org/synaptic/|Synaptic].

\r\nHardware Device Manager GUIs\r\n

This one I'll grant you somewhat. Note that in the case of Linux, it's often easier to autodetect and autoconfigure hardware, as the [link|http://packages.debian.org/unstable/utils/kudzu.html|kudzu] tool from Red Hat. Hardware support in Linux is generally almost easier than with Windows: if the device is supported, it leaves a signature somewhere which can be detected, and the appropriate kernel module then autoloaded. And given that predicate, the fundamental problem of writing a GUI wrapper around the identifyication of recognized and unrecognized hardware is not all that difficult.

Printer Manager GUIs

[link|http://www.cups.org/|CUPS]. Can use some improvement, but fundamentally works.

User Manager GUIs

For better or worse (mostly worse): [link|http://www.webmin.com/|webmin]. The problem is: all of these tools are fundamentally limiting and information hiding. For many users, this is sufficient. For serious administration, it has all the same problems that the NT and kin's GUI admin has: you end up with a class of administrators which is fundamentally ignorant of what's going on behind the scenes. For this reason, while I am not opposed to such tools being available, I vastly prefer that the primary config tools be clear, well-defined, documented, sane, configuration files.

etc.

Got that: /etc ;-)

\r\nLike the missing features Linux has, like the application icon creation after installing a program. The feature is just not there, at least in Red Hat. For example Red Hat 9.0 has Mozilla 1.2.1 installed, I download 1.4 and install it, yet the X Menu icons still point to the 1.2.1 versions. Have to manually find the new location of 1.4, and change the icons/launchers to point to it. Have to reinstall or symbolic link the JRE Plug-In for 1.4 so Java can work. This sort of thing scares away potential users, and keeps the PHBs from accepting Linux.\r\n

Note that this is just one of many weaknesses of RH and RPM-based distros which become clear once you've had experience with a policy-based distribution. Given policy, you can dictate how packages interact, and you can create functionality (eg: the Debian menus system) based on those interactions, and require that it work.