The Future of the KDE Free Desktop
JP: So there are major changes and improvements coming to the Free Desktop. But will the average user care about any of those?
AS: Ha. Users surely won't say, “I want to immerse myself in a socially contextual computing experience.” What people will say, however, is, “Hey, I walk into the train station and instead of going to the schedule board, I look at my phone and use the widget that is being broadcast in the building.” If people see it, they will want it and use it. They don't think, “I want the same KDE software I have on my desktop also on my phone”, but they will notice that it works and looks the same, provides the same logical work flow. Our technology simply provides advantages to users—they might have a different language from developers, but they will enjoy it. We have to focus on that. We don't have the luxury of doing pure research; it has to benefit people and be within their reach.
SK: I think if you make these features very easily accessible, users will use them. The best features are noticed only when you take them away. For example, there is window snapping in KWin, a feature we've had since forever. It makes windows a little resistant to overlapping each other, easing the placement of windows—really something users don't notice. But, turn it off, and their windows feel funny. It's hard to place them right. We have hundreds, thousands of such small things, we almost never advertise them. You can't show them in a screencast and barely can explain them in person. But they make a difference; they make your experience just feel better. This is how I would like to integrate these features—in a way nobody notices.
AS: Look at a hot topic right now, search on the desktop. The direction most implementations take is all wrong, really. Our competition thinks of Google, who is searching the Web, going through these billions of documents. You're looking for something, so you fire up the browser, go to this page with a search bar, type something and find it. The needle in a haystack. So this has been brought to the desktop. And do people use it? Not as much as you might think. They still organize files in folders, and use recent documents. You don't do a random search if you have at least a clue of where the file probably is.
SK: The technology has to be built in to applications; there shouldn't be a special “search” dialog. You want to start with what people are doing—who am I, where am I and what do I care about. We discussed this in 2004 when we wanted to get search technology moving in KDE. We wanted implied searches. Say you download photos from your camera, which has geo-tagging. When you fire up Marble (the KDE Desktop Globe), it shows the photos in the spot they were taken. That is intuitive. Compare it with what LinkedIn does—shows you other people you might know and want to connect to in the sidebar. It is unobtrusive, but you notice it when it is useful and use it. You might not have searched for those people by yourself, but LinkedIn helped you find them anyway. Users will not even know they are using it, except that they have this icky feeling their computers are psychic.
JP: But all this comes with disadvantages, right? Like bad performance, privacy and security dangers. What are you doing to combat those issues?
SK: Much of this can even improve in those areas. Caching and using desktop applications makes working with Web content faster. And, you easily can keep data off-line if you want—this is much better when it comes to privacy. Decoupling data and the user interface also makes sure that only controlled code runs locally, so there are less runtime security issues, which are so typical with on-line applications. Add-ons you can download within KDE software can be signed cryptographically to ensure integrity. Most of what Nepomuk does when relating data, it does on your own PC, which makes it much easier to keep your private data private. For many use cases, using on-line services is simply not an option—think about businesses. They can't entrust their data to Google or other on-line services, because of either internal policy or law. Our technology makes it very easy to keep the user in control without giving up on features.
AS: This is the typical innovators' dilemma. You try a new, promising thing that has never been done, and you instantly discover that despite good intentions, it doesn't work very well in practice. It is buggy, slow, hard to use. Why? Because it is new! Nepomuk, for example, is now at its third storage back end. The first one was functional, but insanely slow and resource-intensive. No kidding, it was a research project. The question the first incarnation answered was “Can we do this?”, not “Does it work well?” Currently, we use Virtuoso, which represents a huge improvement. And now Nepomuk is becoming production-ready; individual application developers are starting to create production-ready code, integrating the features. We knew years ago that contextual computing was possible, but would it work in real life? I believe in the ingenuity of people and of our community. Nothing about this is fundamentally impossible. Even now, being so new, it works surprisingly well on today's laptops and even Netbooks. We still have to migrate it down to mobile devices—of course, that's a challenge. Luckily, work is going on in that area, and as a backup, we always have the cloud. If a local computer doesn't have the power to handle it, we can move a part of the resource usage to the big iron on the Web.
- Users, Permissions and Multitenant Sites
- New Products
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- High-Availability Storage with HA-LVM
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Solving ODEs on Linux
- Non-Linux FOSS: MenuMeters
- March 2015 Issue of Linux Journal: System Administration