xref: /netbsd-current/doc/roadmaps/desktop

$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.