Module Name: src Committed By: dholland Date: Fri Jan 13 10:17:18 UTC 2017
Added Files: src/doc/roadmaps: desktop Log Message: Update roadmaps, unilaterally, because most of these hadn't been touched since the pre-6.0 period and nobody else has been doing the work. There's a lot of things whose current state I don't know; please fill in. Also the stuff I've added is necessarily biased towards projects I think about, so please add more. To generate a diff of this commit: cvs rdiff -u -r0 -r1.1 src/doc/roadmaps/desktop Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Added files: Index: src/doc/roadmaps/desktop diff -u /dev/null src/doc/roadmaps/desktop:1.1 --- /dev/null Fri Jan 13 10:17:18 2017 +++ src/doc/roadmaps/desktop Fri Jan 13 10:17:18 2017 @@ -0,0 +1,336 @@ +$NetBSD: desktop,v 1.1 2017/01/13 10:17:18 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: + + 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 +============ + + + 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 2007) 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 or 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. +