desktop revision 1.2
1$NetBSD: desktop,v 1.2 2017/01/13 10:41:16 leot Exp $ 2 3NetBSD Desktop Roadmap 4====================== 5 6This roadmap deals with desktop support. Note that "desktop support" 7means several quite different things: 8 - issues pertaining to running the Windows-like Linux desktops 9 (e.g. GNOME, KDE, Mate, Trinity, as well as other similar things 10 like LXDE) on NetBSD in more or less their current form; 11 - issues pertaining to running these systems with NetBSD 12 infrastructure, for better system integration and to avoid 13 depending on unpopular packages like dbus and policykit; 14 - issues specific to developer-oriented desktops; 15 - other issues pertaining to using a NetBSD machine as one's desktop 16 login system, regardless of the UI; 17 - issues pertaining to running or developing a more Unix-oriented 18 desktop environment, which is kind of blue-sky for the time being. 19 20Also, "desktop support" and "laptop support" are closely related in 21the sense that in the conventional wisdom laptops run more or less the 22same user-facing software as desktops. Additional specifically laptop- 23related issues, such as power management, are discussed in the 24"mobile" roadmap (q.v.). 25 26Furthermore, many of the above issues can be ~orthogonally divided 27into one of the following three broad categories: 28 29 a. Providing new infrastructure for supporting facilities whose 30 needs are reasonably well understood but are not traditionally 31 handled by Unix and/or are not currently handled by NetBSD, or 32 where traditional/existing support is chronically defective. 33 Examples include font management, printing, mounting removable 34 media, and also things like support for location services. 35 36 b. Providing new infrastructure for supporting facilities whose 37 needs are not in fact well understood. This tends to cover the 38 domains where we don't like the GNOME/KDE/Linux tools, like 39 dbus, as well as things that existing desktop environments fall 40 down on entirely, like integrating with large home directory 41 trees. 42 43 c. Refactoring existing infrastructure (whether NetBSD-specific or 44 historical Unix) to integrate new facilities and software models 45 smoothly instead of bolting layers of crud on top of outdated 46 structure. Examples include revisiting the assumption that 47 logins happen on teletypes, and facing the need to restrict the 48 access of large applications rather than giving them all the 49 privileges of the user starting them. 50 51 52The following elements, projects, and goals are relatively near-term: 53 54 1. Don't ship twm as the default X window manager 55 2. Making removable media work using GNOME/KDE infrastructure 56 3. Making wireless config work using GNOME/KDE infrastructure 57 4. Sane font handling 58 5. Get Eclipse running properly from pkgsrc 59 6. Better printer management 60 7. Work out a long-term plan for compositing, Wayland, and graphics 61 architecture issues 62 63The following elements, projects, and goals are longer-term: 64 65 8. Publish/subscribe sockets or IPC 66 9. Better native RPC library and tools 67 10. Native removable media handling 68 11. Native wireless config 69 12. User switching and secure attention key 70 13. wscons graphics 71 72The following elements, projects, and goals are rather blue-sky so far: 73 74 14. Something akin to ARexx 75 15. A more Unix-oriented root window/desktop basis 76 16. Full console virtualization 77 78 79Explanations 80============ 81 82 83 1. Don't ship twm as the default X window manager 84 85It's embarrassing that in 2016 we were still shipping twm as the 86default window system config. Heck, it was embarrassing in 2006. The 87work needed to move to ctwm has been largely done (by youri) and at 88least some of it committed, but this still (as of January 2017) isn't 89enabled by default. 90 91 - As of January 2017 nobody is actively working on this. 92 - It would be silly at this point to release 8.0 without it, so 93 ideally someone will step up to get it finished and enabled. 94 - Contact: XXX please fill in 95 96 97 2. Making removable media work using GNOME/KDE infrastructure 98 99Ideally when you insert a USB stick it mounts automatically, like with 100GNOME and KDE on Linux. I believe this is not currently working. It 101used to depend on hal, which was always problematic and perennially 102broken, but hal got deprecated and I'm not sure what is even involved. 103(XXX: someone please clarify.) 104 105 106 3. Making wireless config work using GNOME/KDE infrastructure 107 108Ideally it would be possible to configure your wireless networking 109using the GNOME/KDE/etc. tools. I believe this does not work either. 110(XXX: someone please clarify.) 111 112 113 4. Sane font handling 114 115See "System-level font handling in Unix" on the wiki projects page. 116 117 - As of January 2017 nobody is actively working on this. 118 - There is currently no clear timeframe or release target. 119 - Contact: dholland 120 121 122 5. Get Eclipse running properly from pkgsrc 123 124As of last report Eclipse was bodgily packaged (this may not be 125fixable) and didn't really work (this should be). Because Eclipse is 126Java this depends on JDK stuff. 127 128 - As of January 2017 nobody is actively working on this. 129 - There is currently no clear timeframe or release target. 130 - Contact: ? (XXX) 131 132 133 6. Better printer management 134 135See "New LPR/LPD for NetBSD" on the wiki projects page. 136 137 - As of January 2017 nobody is actively working on this. 138 - There is currently no clear timeframe or release target. 139 - Contact: dholland 140 141 142 7. Work out a long-term plan for compositing, Wayland, and graphics 143 architecture issues 144 145Nobody seems to have a good idea of what the way forward ought to be, 146so probably it would be advisable for someone to dig into the issues 147and report back. 148 149 - As of January 2017 nobody is actively working on this. 150 - There is currently no clear timeframe or release target. 151 - Contact: ? (XXX) 152 153 154 8. Publish/subscribe sockets or IPC 155 156It's clear that even though traditionally Unix has next to no such 157facilities, a "modern" desktop system requires the ability to post 158notices about from one component to another. (Probably the closest 159thing traditional Unix ever had along these lines was comsat(8).) 160 161dholland observed some time back that there isn't really a problem if 162what you want to do is contact a well-known service: we have inetd for 163that, and while inetd could use some polishing before being deployed 164for such purposes that isn't a very big deal. The interesting case is 165multicast: when you want to send a notice to anyone who happens to be 166around and interested in seeing notices of some particular type, 167without needing to know who they are. 168 169dbus does this badly, both because the implementation is poor and 170because the basic concept of a "message bus" is flawed. A better model 171is publish-subscribe channels: a message sent ("published") on the 172channel is delivered to all listeners ("subscribers"), and neither the 173publishers nor the subscribers need to know about one another, only 174about the existence of the channel... which becomes effectively a well 175known service. 176 177The original (very tentative) plan was to wedge publish/subscribe into 178AF_UNIX sockets, because AF_UNIX sockets already satisfy several 179important criteria: (1) they have a large and flexible namespace, 180namely the whole file system namespace; (2) they support credential 181reporting; (3) the socket/bind/listen/connect API (probably) provides 182enough flexibility to handle the connection model; and (4) they 183already exist. However, nobody has yet looked into this very closely 184and the interface may not turn out to be very suitable after all. 185 186Note that (like anything of this sort) the naming scheme for the 187channels is critical, as is the development of sane protocols to run 188over them. Note that the publish/subscribe sockets should be transport 189only; protocols should be a higher-level issue. (This is one of a 190number of things dbus gets wrong.) 191 192One of the other things this infrastructure should provide is a decent 193way to post notices (e.g. for media changes, device insertions, and so 194on) out of the kernel, which has historically always been a problem in 195Unix. 196 197This item is sometimes also referred to as "dbus avoidance" - 198theoretically one could avoid dbus with some other architecture too, 199but nothing much else has been proposed. 200 201An example application we already have in base is the notices that 202sshd sends to blacklistd. Currently this makes a mess if sshd is 203running and blacklistd isn't. 204 205 - As of January 2017 nobody is actively working on this. 206 - There is currently no timeframe or release target. 207 - Contact: dholland 208 209 210 9. Better native RPC library and tools 211 212Another thing dbus doesn't do very well: it's an IPC/RPC library. In 213the long run to support existing desktops we probably need 214dbus-compatible IPC tools. In the short run though we'd do well to 215pick or develop something of our own, and (finally) deprecate SunRPC. 216 217 - As of January 2017 nobody is actively working on this. 218 - There is currently no timeframe or release target. 219 - Contact: dholland or ? (XXX) 220 221 222 10. Native removable media handling 223 224Given publish/subscribe channels, implement proper native support for 225mounting removable media upon insertion. This should integrate with 226GNOME/KDE/etc. but also work natively; e.g. provided the right 227services are running, it should work even when running on a text-only 228console. 229 230 231 11. Native wireless config 232 233Similarly, implement a native wireless config scheme. While we 234currently have wpa_cli, it lacks a certain something... 235 236 237 12. User switching and secure attention key 238 239See the project page on the wiki. 240 241 - As of January 2017 nobody is actively working on this. 242 - There is currently no timeframe or release target. 243 - Contact: dholland or ? (XXX) 244 245 246 13. wscons graphics 247 248There's been talk on and off for some time about supporting cairo or 249qt-embedded or similar things directly on the console. This is 250probably a good infrastructure step for any UI scheme that doesn't 251involve an X server, such as potentially phones or tablets. (See the 252"mobile" roadmap for more on that.) 253 254 255 14. Something akin to ARexx 256 257We have a number of veteran Amiga users and whenever there's a 258discussion of dbus usually ARexx eventually comes up. It would be 259great to have something like ARexx for talking to/scripting/ 260controlling applications. But given that GNOME and KDE and their 261imitations are all based on Windows and that the state of the art 262seems to be dbus, if we want this we're going to have to design and 263build it out ourselves. It would be a good thing to do. 264 265Just remember that the good parts of ARexx didn't include the Rexx 266language. :-) 267 268 - As of January 2017 nobody is actively working on this. 269 - There is currently no timeframe or release target. 270 - Contact: mlelstv? (XXX) 271 272 273 15. A more Unix-oriented root window/desktop basis 274 275All the existing desktops (apart from OS X, which is NextStep, but not 276all that much different either) are based on Windows. They share a 277number of properties that are not consistent with the Unix philosophy 278or design model. 279 280First, Unix is about files, and like or or not, files in Unix are 281organized in a hierarchical namespace. The Windows-like desktops, like 282Windows, provide a file manager as an afterthought and the desktop 283workspace itself has no notion of current directory, no notion of 284directory navigation, and only limited notions of interacting with 285files at all. In fact, the things that show up on the desktop 286typically live in a reserved directory that the desktop software 287insists on polluting your homedir with. A Unix desktop should have 288directory navigation integrated with the root window somehow -- there 289are many possible ways to do this, and virtually any choice would be 290better than what you get from GNOME and KDE. It shouldn't be necessary 291to open a shell (or a "file manager") to work effectively with a large 292source tree. 293 294Second, Unix is also about text, and existing desktop software is not. 295While people tend to think of GUIs and text as mutually exclusive, 296this is not actually the case: a GUI provides a lot of ways to place 297and format text that can't be done in text mode (let alone on a 298teletype) -- a good start, for example, might be to display the first 299few lines of a file when you roll the mouse over it, but one can go a 300lot further than that. 301 302Third, Unix is supposed to be about pluggable components. A Unix 303desktop should have functionality for plugging components together 304graphically, whether those components are traditional shell tools or 305"services" or "objects" or more complex things. No existing desktop 306has anything like this, certainly not as native functionality. 307 308Anything like this is going to have to be designed and written, since 309it's clearly not going to be forthcoming from the Linux desktop folks. 310(Note that while it would be a big effort it would also be a great 311publicity lever...) 312 313 314 16. Full console virtualization 315 316The Unix notion of a login session is stuck in the 70s, where you log 317in on a glass teletype and that's all you get. The consoles of modern 318computers have assorted other widgets as well: pointing devices, game 319controllers, cameras, scanners, removable storage, hotkeys, audio 320playback and record... not to mention graphics and video. Right now we 321have a bodgy scheme for chowning or chmod'ing devices on console 322login; in addition to potentially causing problems (what happens if 323one user leaves a process behind that's recording audio, then logs out 324and walks away?) this doesn't work well with multiple users logged in 325at once on the console. It also doesn't work at all with remote logins. 326 327In an ideal world, all your console hardware would be tied to your 328console login session, and virtualized appropriately so that multiple 329console logins each get suitably arbitrated access. Furthermore, it 330should be possible to forward your console hardware to a remote login 331session -- for example if you have a usb stick you should be able to 332log in somewhere and mount it there. 333 334Getting to this requires refactoring the way we think about logins and 335login devices, but it's high time. 336 337