$NetBSD: desktop,v 1.4 2017/01/22 19:47:00 dholland Exp $ NetBSD Desktop Roadmap ====================== This roadmap deals with desktop support. Note that "desktop support" means several quite different things: - issues pertaining to running the Windows-like Linux desktops (e.g. GNOME, KDE, Mate, Trinity, as well as other similar things like LXDE) on NetBSD in more or less their current form; - issues pertaining to running these systems with NetBSD infrastructure, for better system integration and to avoid depending on unpopular packages like dbus and policykit; - issues specific to developer-oriented desktops; - other issues pertaining to using a NetBSD machine as one's desktop login system, regardless of the UI; - issues pertaining to running or developing a more Unix-oriented desktop environment, which is kind of blue-sky for the time being. Also, "desktop support" and "laptop support" are closely related in the sense that in the conventional wisdom laptops run more or less the same user-facing software as desktops. Additional specifically laptop- related issues, such as power management, are discussed in the "mobile" roadmap (q.v.). Furthermore, many of the above issues can be ~orthogonally divided into one of the following three broad categories: a. Providing new infrastructure for supporting facilities whose needs are reasonably well understood but are not traditionally handled by Unix and/or are not currently handled by NetBSD, or where traditional/existing support is chronically defective. Examples include font management, printing, mounting removable media, and also things like support for location services. b. Providing new infrastructure for supporting facilities whose needs are not in fact well understood. This tends to cover the domains where we don't like the GNOME/KDE/Linux tools, like dbus, as well as things that existing desktop environments fall down on entirely, like integrating with large home directory trees. c. Refactoring existing infrastructure (whether NetBSD-specific or historical Unix) to integrate new facilities and software models smoothly instead of bolting layers of crud on top of outdated structure. Examples include revisiting the assumption that logins happen on teletypes, and facing the need to restrict the access of large applications rather than giving them all the privileges of the user starting them. The following elements, projects, and goals are relatively near-term: 0. dmrkms for nvidia cards (will be in -8) 1. Don't ship twm as the default X window manager 2. Making removable media work using GNOME/KDE infrastructure 3. Making wireless config work using GNOME/KDE infrastructure 4. Sane font handling 5. Get Eclipse running properly from pkgsrc 6. Better printer management 7. Work out a long-term plan for compositing, Wayland, and graphics architecture issues The following elements, projects, and goals are longer-term: 8. Publish/subscribe sockets or IPC 9. Better native RPC library and tools 10. Native removable media handling 11. Native wireless config 12. User switching and secure attention key 13. wscons graphics The following elements, projects, and goals are rather blue-sky so far: 14. Something akin to ARexx 15. A more Unix-oriented root window/desktop basis 16. Full console virtualization Explanations ============ 0. drmkms for nvidia cards Until recently the nvidia drmkms driver (nouveau) was disabled by default. This is no longer the case in -current and it is believed to more or less work. This change will be in -8. It might also make it into a future release of -7; it is not currently clear what would be involved in that. 1. Don't ship twm as the default X window manager It's embarrassing that in 2016 we were still shipping twm as the default window system config. Heck, it was embarrassing in 2006. The work needed to move to ctwm has been largely done (by youri) and at least some of it committed, but this still (as of January 2017) isn't enabled by default. - As of January 2017 nobody is actively working on this. - It would be silly at this point to release 8.0 without it, so ideally someone will step up to get it finished and enabled. - Contact: XXX please fill in 2. Making removable media work using GNOME/KDE infrastructure Ideally when you insert a USB stick it mounts automatically, like with GNOME and KDE on Linux. I believe this is not currently working. It used to depend on hal, which was always problematic and perennially broken, but hal got deprecated and I'm not sure what is even involved. (XXX: someone please clarify.) 3. Making wireless config work using GNOME/KDE infrastructure Ideally it would be possible to configure your wireless networking using the GNOME/KDE/etc. tools. I believe this does not work either. (XXX: someone please clarify.) 4. Sane font handling See "System-level font handling in Unix" on the wiki projects page. - As of January 2017 nobody is actively working on this. - There is currently no clear timeframe or release target. - Contact: dholland 5. Get Eclipse running properly from pkgsrc As of last report Eclipse was bodgily packaged (this may not be fixable) and didn't really work (this should be). Because Eclipse is Java this depends on JDK stuff. - As of January 2017 nobody is actively working on this. - There is currently no clear timeframe or release target. - Contact: ? (XXX) 6. Better printer management See "New LPR/LPD for NetBSD" on the wiki projects page. - As of January 2017 nobody is actively working on this. - There is currently no clear timeframe or release target. - Contact: dholland 7. Work out a long-term plan for compositing, Wayland, and graphics architecture issues Nobody seems to have a good idea of what the way forward ought to be, so probably it would be advisable for someone to dig into the issues and report back. - As of January 2017 nobody is actively working on this. - There is currently no clear timeframe or release target. - Contact: ? (XXX) 8. Publish/subscribe sockets or IPC It's clear that even though traditionally Unix has next to no such facilities, a "modern" desktop system requires the ability to post notices about from one component to another. (Probably the closest thing traditional Unix ever had along these lines was comsat(8).) dholland observed some time back that there isn't really a problem if what you want to do is contact a well-known service: we have inetd for that, and while inetd could use some polishing before being deployed for such purposes that isn't a very big deal. The interesting case is multicast: when you want to send a notice to anyone who happens to be around and interested in seeing notices of some particular type, without needing to know who they are. dbus does this badly, both because the implementation is poor and because the basic concept of a "message bus" is flawed. A better model is publish-subscribe channels: a message sent ("published") on the channel is delivered to all listeners ("subscribers"), and neither the publishers nor the subscribers need to know about one another, only about the existence of the channel... which becomes effectively a well known service. The original (very tentative) plan was to wedge publish/subscribe into AF_UNIX sockets, because AF_UNIX sockets already satisfy several important criteria: (1) they have a large and flexible namespace, namely the whole file system namespace; (2) they support credential reporting; (3) the socket/bind/listen/connect API (probably) provides enough flexibility to handle the connection model; and (4) they already exist. However, nobody has yet looked into this very closely and the interface may not turn out to be very suitable after all. Note that (like anything of this sort) the naming scheme for the channels is critical, as is the development of sane protocols to run over them. Note that the publish/subscribe sockets should be transport only; protocols should be a higher-level issue. (This is one of a number of things dbus gets wrong.) One of the other things this infrastructure should provide is a decent way to post notices (e.g. for media changes, device insertions, and so on) out of the kernel, which has historically always been a problem in Unix. This item is sometimes also referred to as "dbus avoidance" - theoretically one could avoid dbus with some other architecture too, but nothing much else has been proposed. An example application we already have in base is the notices that sshd sends to blacklistd. Currently this makes a mess if sshd is running and blacklistd isn't. - As of January 2017 nobody is actively working on this. - There is currently no timeframe or release target. - Contact: dholland 9. Better native RPC library and tools Another thing dbus doesn't do very well: it's an IPC/RPC library. In the long run to support existing desktops we probably need dbus-compatible IPC tools. In the short run though we'd do well to pick or develop something of our own, and (finally) deprecate SunRPC. - As of January 2017 nobody is actively working on this. - There is currently no timeframe or release target. - Contact: dholland or ? (XXX) 10. Native removable media handling Given publish/subscribe channels, implement proper native support for mounting removable media upon insertion. This should integrate with GNOME/KDE/etc. but also work natively; e.g. provided the right services are running, it should work even when running on a text-only console. 11. Native wireless config Similarly, implement a native wireless config scheme. While we currently have wpa_cli, it lacks a certain something... 12. User switching and secure attention key See the project page on the wiki. - As of January 2017 nobody is actively working on this. - There is currently no timeframe or release target. - Contact: dholland or ? (XXX) 13. wscons graphics There's been talk on and off for some time about supporting cairo or qt-embedded or similar things directly on the console. This is probably a good infrastructure step for any UI scheme that doesn't involve an X server, such as potentially phones or tablets. (See the "mobile" roadmap for more on that.) 14. Something akin to ARexx We have a number of veteran Amiga users and whenever there's a discussion of dbus usually ARexx eventually comes up. It would be great to have something like ARexx for talking to/scripting/ controlling applications. But given that GNOME and KDE and their imitations are all based on Windows and that the state of the art seems to be dbus, if we want this we're going to have to design and build it out ourselves. It would be a good thing to do. Just remember that the good parts of ARexx didn't include the Rexx language. :-) - As of January 2017 nobody is actively working on this. - There is currently no timeframe or release target. - Contact: mlelstv? (XXX) 15. A more Unix-oriented root window/desktop basis All the existing desktops (apart from OS X, which is NextStep, but not all that much different either) are based on Windows. They share a number of properties that are not consistent with the Unix philosophy or design model. First, Unix is about files, and like it or not, files in Unix are organized in a hierarchical namespace. The Windows-like desktops, like Windows, provide a file manager as an afterthought and the desktop workspace itself has no notion of current directory, no notion of directory navigation, and only limited notions of interacting with files at all. In fact, the things that show up on the desktop typically live in a reserved directory that the desktop software insists on polluting your homedir with. A Unix desktop should have directory navigation integrated with the root window somehow -- there are many possible ways to do this, and virtually any choice would be better than what you get from GNOME and KDE. It shouldn't be necessary to open a shell (or a "file manager") to work effectively with a large source tree. Second, Unix is also about text, and existing desktop software is not. While people tend to think of GUIs and text as mutually exclusive, this is not actually the case: a GUI provides a lot of ways to place and format text that can't be done in text mode (let alone on a teletype) -- a good start, for example, might be to display the first few lines of a file when you roll the mouse over it, but one can go a lot further than that. Third, Unix is supposed to be about pluggable components. A Unix desktop should have functionality for plugging components together graphically, whether those components are traditional shell tools or "services" or "objects" or more complex things. No existing desktop has anything like this, certainly not as native functionality. Anything like this is going to have to be designed and written, since it's clearly not going to be forthcoming from the Linux desktop folks. (Note that while it would be a big effort it would also be a great publicity lever...) 16. Full console virtualization The Unix notion of a login session is stuck in the 70s, where you log in on a glass teletype and that's all you get. The consoles of modern computers have assorted other widgets as well: pointing devices, game controllers, cameras, scanners, removable storage, hotkeys, audio playback and record... not to mention graphics and video. Right now we have a bodgy scheme for chowning or chmod'ing devices on console login; in addition to potentially causing problems (what happens if one user leaves a process behind that's recording audio, then logs out and walks away?) this doesn't work well with multiple users logged in at once on the console. It also doesn't work at all with remote logins. In an ideal world, all your console hardware would be tied to your console login session, and virtualized appropriately so that multiple console logins each get suitably arbitrated access. Furthermore, it should be possible to forward your console hardware to a remote login session -- for example if you have a usb stick you should be able to log in somewhere and mount it there. Getting to this requires refactoring the way we think about logins and login devices, but it's high time.