1. You are going to be working on kernel and system-level projects to improve the Linux desktop experience. What does that exactly mean? What these projects are and how will they help the desktop users?
Robert Love: There is no specific definition of what I want to accomplish, because it is my mandate to do whatever is necessary at the kernel and system-level to improve the quality of desktop Linux and thereby take Linux on the desktop to new levels.
Some of my first projects are going to include:
* Hardware integration. The kernel does hardware pretty well right now, but the integration with user-space needs work. For example, applications and the desktop have no knowledge of hardware events, sans polling. A cohesive solution is needed for device management, naming, hotplugging, and integration with the desktop. The solution will involve a lot of different players: at least hotplug, udev, HAL, and D-BUS. Some sort of desktop component, providing a policy manager, events layer, and notification system, will be needed on top. Applications will then interface with this component and libhal, HAL's library. The user will interface with the desktop component, which will provide policy. One example policy might be, what to do when the user plugs in a camera or inserts a new CD. We should be doing cool stuff, like asking the user if they want to copy their photos to a new album.
* Kernel events layer. We need a simple, low overhead, fast communication channel from the kernel out to user-space, to communicate everything from device status ("your processor is overeating") to system events ("a new volume has been mounted"). I do not want to reinvent the wheel here, however. I think netlink (an existing socket-based high-speed communication layer in the kernel) forms the perfect kernel-side to the solution. We just need an abstraction and interface on top of it. For the user side of things, D-BUS is the obvious candidate. We definitely want to format the messages to be D-BUS capable, but I think we want to remain agnostic toward which user-space messaging system we actually require.
* Desktop tuning. This includes things such as tuning the kernel to provide a highly responsive and very low latency desktop environment, using things such as the CFQ I/O scheduler, and making sure that desktop and "normal sane machine" performance remains a priority and is not allowed to regress.
Other things are important, too:
* Better X and 3D support.
* A strict insistence on keeping interfaces stable.
* A Linux answer to WinFS.
* Better hardware support of consumer-level devices, especially laptop-related hardware.
* Improved power management.
Despite this long lists, we are really close. The newly-released 2.6 kernel is an excellent desktop kernel, and the current desktop offerings are excellent. I am very stoked -- world domination has never been so attainable.
2. In my experience, the most UI-responsive OS I ever used, was BeOS. When I asked my ex-Be engineer husband "how did Be achieve this?", his response was "easy, the kernel guy's cube was next to the app_server's guy". Do you also believe that in order to achieve high responsiveness on the desktop the kernel and X/Qt/Gtk guys should have 'meetings' and architect their projects in a way that integrate together best instead of trying to patch later?
Robert Love: I think that, in general, it never hurts to have all of the pieces to the puzzle come together and have solutions architected as a whole instead of piecemeal. Conversely, however, it is also important to keep layers conceptually separate. Microsoft is just now seeing this: note their recent decision to move the "core OS" to its own team (by core OS, they mean to separate the kernel and system-level guys out from the rest of the Windows umbrella). It is important to juggle the cooperation and the separation wisely.
That said, I think the reason BeOS is so often touted as being very responsive is that it was highly threaded and traded throughput for latency at many levels.
I believe both Linux and Mac OS X are very response systems too, however. It is all very subjective.
3. Depending on the kernel patches used, mouse movements can be vary from normal to very jerky on the current distros. For example, Fedora has the best mouse movements today in my experience, while other distros or stock kernels (like on Slackware) suffer from bad mouse movements. Is kernel 2.6 any better in this respect by default or extra patches will still be needed?
Robert Love: I do not think the 2.6 kernel should need patches to improve mouse tracking.
4. What goodies the 2.6 kernels is going to bring to users who are mostly interested in the desktop Linux experience?
Robert Love: On the usability front, we have the device model, which brings us better device management, sysfs, and a complete hotplug solution. This means things like udev and HAL are a reality in 2.6.
On the performance front, we have an improved process scheduler, the CFQ I/O scheduler (not yet merged), a preemptive kernel, improved VM, and lower-latency/more-fair algorithms throughout the kernel. All add up to a radically improved desktop experience.
5. At your work at Ximian, are you interested in helping out the goals of freedesktop.org's projects, e.g. HAL?
Robert Love: I am a big fan of all of their projects.
Both HAL and D-BUS are immediate interests of mine. I see both of them holding an important role in my "make hardware work" project outlined above.
6. Is there any support for node monitoring and "live queries" on 2.6's XFS or ReiserFS? If yes, any plans at Ximian to help out projects like GNOME Storage or implement something like having your saved queries get messages from the kernel that new results were added to the query and ultimately inform the user?
Robert Love: I am totally unfamiliar with this!
7. Where would you like to see kernel 2.8 or 3.0 to go towards? Are there plans to implement a "visual" method and help users install easily third party drivers, like nvidia's or winmodem drivers instead of using the command line to achieve this?
Robert Love: There is definitely no plans to make binary drivers happier. Linus has made it clear: he and many other kernel hackers just do not care about them. I don't mind that, either!
I would like to see the 2.7 development kernel carry on 2.5's quest to lower latency and improve fairness in kernel algorithms. Both because there are surely some missed corner cases, and also because it will require eternal vigilance to keep everything smooth in that regard.
I would also like to see the merging of the kernel events layer.
Finally, the obligatory "rewrite the tty layer"!