-
Notifications
You must be signed in to change notification settings - Fork 279
/
desktop
321 lines (238 loc) · 13.2 KB
/
desktop
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
$NetBSD: desktop,v 1.6 2022/01/15 19:38:05 gutteridge 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, Xfce, LXQt, LXDE, DeforaOS, as well as
others not presently successfully packaged, like Cinnamon, Lumina,
and Trinity) 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. Making removable media work using GNOME/KDE infrastructure
2. Making wireless config work using GNOME/KDE infrastructure
3. Sane font handling
4. Get Eclipse running properly from pkgsrc
5. Better printer management
6. Work out a long-term plan for compositing, Wayland, and graphics
architecture issues
The following elements, projects, and goals are longer-term:
7. Publish/subscribe sockets or IPC
8. Better native RPC library and tools
9. Native removable media handling
10. Native wireless config
11. User switching and secure attention key
12. wscons graphics
The following elements, projects, and goals are rather blue-sky so far:
13. Something akin to ARexx
14. A more Unix-oriented root window/desktop basis
15. Full console virtualization
Explanations
============
1. 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.)
2. 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.)
3. 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
4. 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)
5. 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
6. 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)
7. 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
8. 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)
9. 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.
10. Native wireless config
Similarly, implement a native wireless config scheme. While we
currently have wpa_cli, it lacks a certain something...
11. 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)
12. 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.)
13. 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)
14. 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...)
15. 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.