347 lines
14 KiB
Plaintext
347 lines
14 KiB
Plaintext
$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.
|
|
|