Support for "real" desktops on NetBSD is somewhat limited and also
scattershot.
Part of the reason for this is that most of the desktops are not
especially well engineered, and they contain poorly designed
infrastructure components that interact incestuously with system
components that are specific to and/or make sense only on Linux.
Providing the interfaces these infrastructure components wish to talk
to is a large job, and Linux churn being what it is, such interfaces
are usually moving targets anyway.
Reimplementing them for NetBSD is also a large job and often
presupposes things that aren't true or would require that NetBSD adopt
system-level design decisions that we don't want.

Rather than chase after Linux compatibility, we are better off
designing the system layer and infrastructure components ourselves.
It is easier to place poorly conceived interfaces on top of a solid
design than to reimplement a poorly conceived design. Furthermore, if
we can manage to do a few things right we should be able to get at
least some uptake for them.

The purpose of this project, per se, is not to implement any
particular piece of infrastructure.
It is to identify pieces of infrastructure that the desktop software
stacks need from the operating system, or provide themselves but ought
to get from the operating system, figure out solid designs that are
compatible with Unix and traditional Unix values, and generate project
descriptions for them in order to get them written and deployed.

For example, GNOME and KDE rely heavily on dbus for sending
notifications around.
While dbus itself is a more or less terrible piece of software that
completely fails to match the traditional Unix model (rather than
doing one thing well, it does several things at once, pretty much all
badly) it is used by GNOME and KDE because there are things a desktop
needs to do that require sending messages around.
We need a transport for such messages; not a reimplementation of dbus,
but a solid and well-conceived way of sending notices around among
running processes.

Note that one of the other things dbus does is start services up; we
already have inetd for that, but it's possible that inetd could use
some strengthening in order to be suitable for the purpose.
It will probably also need to be taught about whatever message scheme
we come up with.
And we might want to e.g. set up a method for starting per-user inetd
at login time.

(A third thing dbus does is serve as an RPC library. For this we
already have XDR, but XDR sucks; it may be that in order to support
existing applications we want a new RPC library that's more or less
compatible with the RPC library parts of dbus. Or that may not be
feasible.)

This is, however, just one of the more obvious items that arises.

Your goal working on this project is to find more.
Please edit this page and make a list, and add some
discussion/exposition of each issue and possible solutions.
Ones that become fleshed out enough can be moved to their own project
pages.