Aaron J. Seigo: I've used Windows XP for a scant total of 2 days, so I'm anything but an authority on Windows XP. Due to the closed nature of Windows XP and the fact that it doesn't provide me with the features I need nor run the applications I use I don't have any need for it.
I will say that during my brief time with the system, I found the file manager pleasant to look at but horrible to use: it imposes too much of itself on the user without offering enough in return. Most laughably, I could not move a music file from the desktop while it was being viewed in the file manager. I would suggest to Microsoft that they fix those sorts of problems first before spending any more time on their embedded photo album view. The new start menu is also an abomination. In fact, those two days with Windows XP reminded me why most people hate computers. I'd hate them too if that was all that was out there.
Like any potentially successful methodology, task based mechanisms have their place and can be very effective when applied to an appropriately task based problem. Task based interfaces can be quite good but they can also be quite out of place and/or implemented poorly. I really don't know how XP stacks up in that regard.
Havoc Pennington: XP seems to have lots of nice small details, but is overall a bit too complex. The task-based interface looks interesting, but I've never tried it out or seen a detailed analysis of how it works.
Waldo Bastian: I am not familar with Windows XP.
6. Recently, we have seen a few attempts to help users better store and organize their files, and there have been two extremely different approaches. The approach taken by the BeOS, among others, was to provide a general framework from which the user could organize files in rather powerful ways (by using file system attributes). The other approach, taken most strikingly by Apple, is to provide filetype-specific applications to manage the files (such as iTunes managing a database of all your music, and iPhoto your photos, etc.). Which do you think is the better approach, and to what extent, if any, do you see [your project] adopting those practices?
Aaron J. Seigo: You're asking whether metadata management belongs at the OS level or on the application level. The benefit of it happening at the filesystem level is that it can be fast and universally available to all applications, but at the expense of portability and flexibility. Leaving it to the applications allows more flexibility, portability and choice but makes sharing the results between applications harder. I think both of these approaches leave much to be desired.
Another approach is a hybrid class of program that sits below the user application level but above the filesystem. This allows choice, availability and portability. Such a program would offer collections of data from and about the filesystem and other programs would provide an interface from which to view and interact with these collections. The inklings of this can be seen in the KDE KParts and KIOSlave technologies. There is more to be done, of course, but it is the most promising approach I've yet to see in actual use.
Havoc Pennington: I think GNOME is following the Apple approach at the moment, though we also do have "emblems" and other file system attributes, they are underused.
My intuition would be that most users are a bit lost by the filesystem concept, and making it even more complicated than files/folders doesn't necessarily help. While a dedicated application can do a lot of nice things automatically and is based on the task the user is trying to do - play music, organize/retouch their photos.
7. The biggest problem I personally see today with all the X11 DEs when compared to OSX, BeOS, OS/2 and Windows, is the pretty much non-existant integration to the underlying system. No X11 DE "truly knows" about the system, its drivers and configuration, or how to deal with them, as every distribution/Unix has its own way of making the OS work. Is there a way to bring these DEs in a status where they "understand" the system and provide preferences/settings or application behavior/features that normally the distribution would have to provide? For example, there is a "mouse" panel under Gnome's preferences configuring the options for the mouse driver used, but there is also "mouse" panel under the "system settings" Red Hat menu, this time about the driver itself. This is a necessary additional step from the distro maker to add more similar panels, as Gnome and KDE don't know how to deal with the system itself. But in order to create a low-bloat, consistent and integrated interface that makes the usage of the OS easy, the DEs will have to learn about the system and use it accordingly. What is your opinion on this, and how could this be achieved when we have so many different and sometimes incompatible distributions (despite LSB), while not even counting the BSDs, Solaris, IRIX and AIX ports.
Aaron J. Seigo: Underlying this is the same issue underlying question #9, which I've answered below.
Havoc Pennington: I believe this can be done, but it is highly nontrivial and no one has really attacked it with the level of seriousness required.
The first task is to figure out how to present the root/user split, and the idea that some settings will affect all users and some will affect only yourself. The coward's way out, in my view, is to just have people log in as root. The reason I think this is bad is that it throws out a big reason Linux is *better* than Windows, our competitive advantages: manageability and security. If people are logged in as root they can break the system much more seriously (reducing stability), as well. So I think it's OK to ask users to understand the multiuser nature of the OS on some level; but I'm not sure what the best way to present it is.
After figuring out the UI we want, it's more or less a simple matter of coding. I'm hoping that some new technology such as D-BUS will be helpful here. It will give us a way to pop up a dialog triggered by kernel events, for example - something we haven't really had in the past.
The result is that system integration comes mostly down on the distributor.
There have been several attempts to create "standard" configuration tools by different groups but none of those have been widely adopted across distributions. I'm pessimistic about this area since I don't think the current mainstream distro's are willing to change this given the investments they have done in their own set of tools.