1 |
Le Sun, 29 Dec 2013 23:51:03 -0600 (CST), |
2 |
Brent Busby <brent@×××××××××.org> a écrit : |
3 |
|
4 |
> After years of assuming I'd probably never set my system up with |
5 |
> multiple monitors, I've decided to go ahead and do it. I've watched |
6 |
> with some interest as various new schemes for doing it have emerged |
7 |
> over the years (Xinerama, and now lately RandR), but I've always |
8 |
> assumed that if nothing else, good old Zaphod mode would always be |
9 |
> around, since it's built right into the way X11 numbers $DISPLAY |
10 |
> (0:0, 0:1, 0:2...etc.). It's been around so long, it's older than |
11 |
> Linux itself. |
12 |
> |
13 |
> Lately, I've been reading a lot of listserv and newsgroup posts from |
14 |
> developers telling various people in forums that if they want Zaphod |
15 |
> mode, they're more or less strange odd creatures who ought to be |
16 |
> ashamed of themselves. The driver developers don't want to support |
17 |
> it anymore. It's not so much a problem in the X server as in each of |
18 |
> the individual video drivers for the various cards. I've probably |
19 |
> read seven or eight different threads like this now, so it's odd that |
20 |
> the common trend in all of them is that each of these users is told |
21 |
> no one else but them uses it. (Apparently a lot do.) |
22 |
> |
23 |
> Anyway, Zaphod is what I want. I don't care that it won't let me |
24 |
> drag windows between monitors. That's precisely the advantage of |
25 |
> it. Many applications are written with such an assumption of a |
26 |
> single display that it's best not to disappoint them. I don't want |
27 |
> to worry about what a fullscreen game will think of my multihead |
28 |
> setup. I don't want to see dialog windows (or anything else really) |
29 |
> popping up, half on one monitor and half on another. I don't want to |
30 |
> have to setup the arrangement of my desktop so that it's arranged to |
31 |
> not look rediculous at the point where the two monitors divide the |
32 |
> screen. It's all just simpler if we have two screens that are |
33 |
> completely separate, and the only magic object that's able to move |
34 |
> between them is the mouse pointer. |
35 |
> |
36 |
> X11 has been able to do this since the 80's. |
37 |
> |
38 |
> But now we're in a brave new world where "nobody wants to do that" |
39 |
> (other than seven or eight people on various forums, and those are |
40 |
> just the ones who complained). I suppose I shouldn't be surprised. |
41 |
> They say we have Wayland in our future too, which we're assured will |
42 |
> have some kind of way to run apps on a remote desktop that will |
43 |
> certainly be at least as good as running a VNC app on Windows (oh |
44 |
> joy). While we're at it, why don't we get rid of this multiple |
45 |
> desktops thing that most X11 window managers support -- nobody does |
46 |
> that on Windows either, so surely that's probably another thing that |
47 |
> nobody on Linux really uses. We should definitely find all the |
48 |
> window managers that support that and strip that feature out of them |
49 |
> for everyone's own good. |
50 |
> |
51 |
> Ok, I suppose I should quit ranting. It's just been a trend now for |
52 |
> the past five years or so that I've been seeing upstream developers |
53 |
> making "improvements" to Linux that are so basic to the |
54 |
> infrastructure that no distro can fight them (PolicyKit, Wayland, |
55 |
> goodbye Zaphod, udev, etc.). |
56 |
|
57 |
Each software you are talking about here is a particular case. |
58 |
*kit is a mandatory dependency of gnome and a few other desktops/window |
59 |
managers. I just don't install them, so I don't have *kit into my |
60 |
system. You can do that even on Debian. |
61 |
|
62 |
udev have much to do with the kernel. It is still possible to make an |
63 |
udev free system and manage a static /dev, and I know at least 1 user |
64 |
that managed to do that on a desktop PC. Also, an udev free system must |
65 |
be the way to go for many simple embedded systems, but that's another |
66 |
subject. |
67 |
|
68 |
Wayland is another issue. Due to the complexity of X and of all its |
69 |
extensions, wayland's compatibility layer will be a never finished |
70 |
job, which will break hundreds of good working software. Because of |
71 |
that, I think wayland may be a good move for the mobile or game market, |
72 |
but than for the desktop, X will remain in use for a long time, at |
73 |
least by experienced users. Or many of these experienced users will |
74 |
be looking for alternatives. Some already have done it, or are in |
75 |
the process to do it. |
76 |
|
77 |
Another concern with wayland is windows managers. Most of them will |
78 |
just stop to work with wayland, and this is not an incomplete |
79 |
compatibility layer that will make them to work. My main concern here |
80 |
is fvwm, which is not only a wm, but also a tool-kit for the Xlib which |
81 |
let its users do whatever they can think about with it. I don't see |
82 |
anything like that coming with wayland. So for me, wayland is just not a |
83 |
viable alternative, and I am not the only one in that case. |