[src/trunk]: src/doc/roadmaps Update roadmaps, unilaterally, because most of ...

[dholland <dholland%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/bc089813bcea
branches:  trunk
changeset: 820668:bc089813bcea
user:      dholland <dholland%NetBSD.org@localhost>
date:      Fri Jan 13 10:14:58 2017 +0000

description:
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.

diffstat:

 doc/roadmaps/desktop      |  336 ++++++++++++++++++++++++++++++++++++++++++++++
 doc/roadmaps/mess         |  219 +++++++++++++++++++++++++++++
 doc/roadmaps/mobile       |  130 +++++++++++++++++
 doc/roadmaps/networking   |   12 +-
 doc/roadmaps/ports        |  106 ++++++++++++++
 doc/roadmaps/security     |   82 +++++++++++
 doc/roadmaps/storage      |   49 +++--
 doc/roadmaps/system       |   26 ++-
 doc/roadmaps/verification |  101 +++++++++++++
 9 files changed, 1031 insertions(+), 30 deletions(-)

diffs (truncated from 1250 to 300 lines):

diff -r d41b6b3ff7a3 -r bc089813bcea doc/roadmaps/desktop
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/roadmaps/desktop      Fri Jan 13 10:14:58 2017 +0000
@@ -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