The Linux platform and modern GUI-based operating systems

During the last years I encountered a number of problems in the Linux platform's architecture that cause problems for GUIs on top of it. When I say 'the Linux platform', I refer to the Linux kernel, glibc and the common GNU and Linux tools, but not X11. I also ignore distribution-specific solutions for the problems. In general the lack of a tool is not a real problem for me, it just is some work that needs to be done. I am talking about the architecture, problems that can not be solved without incompatibilities or at least a lot of work. A 'modern GUI-based OS' is, for me, a OS that does not require a user to know or use a command line tool, even for rare system-administration tasks. That does not mean that it should be impossible to work with the command line and a text editor, but the command line must not be the only way to do an administration task.
So here is the (incomplete) list:

• A lot of important functionality is only available in command line tools. The code is not available in libraries or anything else that would easily make it possible write another user interface. This includes mounting and unmounting devices (mount and umount commands), copying of files without losing extended attributes (cp, mv etc), file system checking (fsck), changing passwords (passwd), loading and unloading of kernel modules (insmod, rmmode, modprobe etc), network adapter configuration (ifconfig) and modifying of routing tables (route). GUI tools usually try to work around the problem by calling command line tools and then resort to screen scraping for getting their output, or just display the output of the command line tool. The former sucks because there is no formal description of the command line tool's output and no guarantee that the output does not change in the next version. Screen scraping is ugly in the source code and results in fragile programs. The latter will almost always result in error message that can not be understand by a GUI user, like the KDE's error message when you try to mount a non-existing device.
• Almost every file in /etc has its own file format, and for the more complex ones (like Apache's) this is a real problem. The lack of formal specifications or libraries for these formats are major show-stoppers for GUI administration tools. One reason is that it's a huge effort to write parsers that do not break when the user edits the files with a text editor, and most of the configuration files were not designed to be edited with a GUI. There's also the question what happens when a new version adds features like new keywords to the format. All in all the configuration issue is a nightmare, and can only be solved when either there's a standardized syntax with schema description for the configuration files, or all servers ship either with configuration libraries or GUI tools. Until then the Linux platform won't be as easy to configure as, for example, most Windows-servers.
• The $HOME directory mixes documents (the files a 'regular' user may be interested in), configuration files and other data of non-file centric applications, like the '$HOME/Mail' directory. In general application-internal files should not be shown to the user who may not understand them, wonders where they come from and, in the worst case, may delete them. KDE currently hides most application-internal files in '$HOME/.kde' and adds a '$HOME/Documents' and a '$HOME/Desktop' directory, which would be a fine solution - if it would be used. Right now even KDE does not use them, the default directory of the file selector is $HOME. And, of course, all other applications do the same. This is not really a architectural problem, but a convention that would require a huge number of application to be changed to default to the $HOME/Documents directory.
• The /dev directory is a relict from a time when devices were dump and you identified them by the port you connected them to. With newer busses like USB and Firewire this is not possible anymore. They allow you to chain devices or to use hubs to connect several devices to a single port. Furthermore users expect devices to be found even when they connect them to a different port. Modern USB devices can identify themselves with user-readable description, and some of them have a unique serial number so you can even recognize them when you have two identical devices. This makes the /dev structure obsolete for anything but a temporary device name. You can't save a /dev path and assume that the next time the application is started it is still valid. The Linux drivers increase the device number each time a new device is added. Instead you need a combination of the device's vendor and model id, its serial number and, as a last resort, its last location in order to find a device that a user has selected. There are some proposed solutions for these kind of problems, but currently you just have a lot of trouble when using more than device of a kind (e.g. two USB printers or joysticks). There's no standard for browsing the devices and for remembering them after a restart.
• There is no support for managing centralized user accounts. You can store user accounts on a NIS, Kerberos or LDAP server and authenticate yourself on the client, using PAM and nsswitch.conf. But there is no good way to change them, beside command line tools like passwd and chfn. And they are not extendable to support new authentication mechanisms like Kerberos, each of them comes with its own administration tools. Even if a GUI application would be able to support these special administration tools, the glibc framework does not offer a way to find out where the user account comes from. Unless the user knows where the account is located (or the application has been pre-configured), a GUI application has no chance to allow administration of the user's account. It's a far way to a integrated user management system like Active Directory offers...
• When a /etc/init.d script fails on boot nothing happens but some text that is printed on the console. There's no way a GUI tool could notice it or even generate a helpful message when the user logs in or while the display manager is running. In general the control over daemons on the system is pretty poor. The only standardized interface is syslog and a couple of scripts that you can use to start and stop the daemons, provided that you screen-scrape them and don't bother to expose the user to their unfriendly error messages. There's no way to show which daemons are actually running, some standardized way to configure them, or being noticed when a daemon crashes/stops. The whole boot process and /etc/init.d is quite unusable for a GUI system.
• Somewhat similar to the /etc/init.d issue is the list of running processes. Sooner or later every user comes in contact with hanging processes, and most of them learn how to kill them. But on Linux all that you get is a list of raw process names that do not have much in common with the actual applications. It may list processes like Apache 1.x that have a dozen instances, it lists sub-processes started by the application, the processes may have names that have not much in common with the actual application name (the 'krfb' process name of KDE's Desktop Sharing is a particulary bad offender) and so on. Other systems show a relatively simple list of actual application names or window names, but Linux does not have any structures that have a higher level than the process, leaving the user exposed to the internals of all running processes.

Together these points are probably a significant part of the reasons why Linux-based systems appear less friendly to a user who is used to a system like Windows or MacOS. These systems have been designed for a GUI from the ground up. On Linux the GUI is an afterthought, and large parts have still not been adapted to be friendly for GUI users.