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