Not quite as dramatic but if an officer triggered an emergency alert a modal dialog was popped up on all dispatch stations. At least one dispatcher had to acknowledge the dialog before the stations were released.
Not quite as dramatic but if an officer triggered an emergency alert a modal dialog was popped up on all dispatch stations. At least one dispatcher had to acknowledge the dialog before the stations were released.
Okay, here's one niche use case:
- I want to run a shell script that opens four xterms (or similar), and on the command line that starts each instance the script specifies colors and screen size/position.
- On another day of the week, I have a different shell script that opens nine xterms (or similar). Again, each command line in the script specifies colors and screen size/positions.
Here's another:
- I want to monitor a group of maybe a dozen machines involved in a performance benchmark, so I have a script that opens a small monitoring application (maybe xload or "vmstat 3" or similar) on various machines. I would use the equivalent of "ssh -X ..." to launch them, since IIUC Wayland doesn't do network transparency (defined as a client application throwing its display to display server).
Oh, another:
- I want to open several web browser windows in specific screen sizes and positions to run a web app.
If you want total control over how things are laid out, put them all in the same window. In this case, open the terminal sessions as panels in a single window.
(Note that, in both X11 and Wayland, “window” is not synonymous with “contiguous rectangular region of opaque pixels”.)
i.e. you want user control of window positions, which is what I’m arguing for:
| I would argue that for the most part, the window position preferences | (or outright control) should come from the user, not the application | at all.
This is not inconsistent with the user control being expressed via a window manager rather than through the application, so I have no idea what point you’re trying to make here.
Happy that there's some agreement.
For the record, I did not write the "I would argue ..." piece. IIUC, it appears you did.
While it may be possible for user preference to be expressed via the window manager, in the cases I'm thinking of, it's much easier for the user to simply add the [-]-geometry option to the command line (perhaps in a shell script) when launching the application(s).
Perhaps you did not understand. The xterms or whatever are the applications. I'm just want to use something like [-]-geometry when launching instances of the applications so that they are arranged how I (as the user) want them.
Or, perhaps you're just following the far-too-frequently observed pattern of, "The Wayland way is the _ONLY_ way!"
Yes, there are a few things that create windows that are not rectangular.
Nice that somebody finally came around to seeing that some form of network transparency is needed. However, the real beauty of X's network transparency is not in 'ssh -X', it is in putting a hostname or IP address in the value of $DISPLAY so that X clients can access X display servers wherever they may be.
I don’t see anybody offering a serious alternative. All I see is people like you, complaining about things changing but not serious about wanting to do something about it.
X11 was never “network-transparent”. If the network connection went down, all the remote X clients would die.
To achieve network-transparency, you had to resort to something like VNC or RDP. And those sorts of protocols can work equally well with Wayland.
Why is there a need to do anything? X works just fine. What happened to the motto of not fixing something if it's not broken? Why is there such a mad rush to re-invent things but do so more poorly than the original, working solution?
Wrong! Without resorting to VNC, RDP, or anything similar, I have personally launched X clients that displayed on a display server on a different host. All you have to do is use the proper syntax to specify the remote display server in $DISPLAY or when calling the library function to open the display, set XHost appropriately, and supply the XAUTH key/cookie/whatever.
‘Why’ is covered in the FAQ.
That has very limited usefulness today due to its unacceptably poor security.
Lawrence is right that your clients die if the network goes down (e.g. if the client endpoint sleeps, which is the usual reason my remote X clients fail).
Whether that’s the definition of ‘network transaprent’ I’ll not take a view on. But it’s certainly inconvenient.
If the network connection goes down VNC and RDP will not be far behind.
We tended to set 'xhost +'. 'Why is it suddenly snowing on my computer?'
Yes, and those who have chosen to pathetically re-implement ntpd for systemd (throwing out everything that makes ntpd a superior solution) have similar justifications for their needless efforts.
There's a quote, something to the effect that those who do not understand Unix will be condemned to re-implement it--poorly. The same seems appropriate when describing systemd's poor imitation of ntpd and Wayland.
Yes, but in those cases where it is useful (far inside more than a few levels of security fencing and such), it's still useful and consumes a lot less resources than ssh -X.
The first part about clients dying if the network connection goes down is so obviously trivial that it doesn't deserve comment. I think that gimmick might be called a red herring.
Where Lawrence is wrong is that X does not require ssh -X, VNC, RDP, or anything similar to do X displaying across a network. That is what is normally meant by X's network transparency.
Not sure what you mean is inconvenient.
That's where the "appropriately" part comes in. If there aren't enough layers of security fencing between what you're doing and either pranksters or bad guys, you want to be more selective.
I would agree that in _MOST_ cases, ssh -X is probably preferable in today's environment.
Developers have largely ceased updating it, because hardly anybody sees it as a worthwhile project any more. If you don’t care about that, fine. But most of those responsible for maintaining well-supported distros do.
X11 was never “network-transparent”. If the network connection went down, all those remote X clients would die.
That's not what the term means, and as someone else already pointed out, VNC and RDP and anything else would soon follow. To help you correct your misunderstanding of the terminology:
Doesn’t matter what you think it means. That’s what happens, regardless.
But your clients will still be there when you reconnect. With remote X, or X forwarding, they won’t be.
Wayland was largely created by X11 developers. They know a lot more about it than you.
SSH is the ‘security fencing’, and consumes almost no resources on modern hardware (meaning last 20 years or so).
It was literally in the previous paragraph:
| Lawrence is right that your clients die if the network goes down ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | (e.g. if the client endpoint sleeps, which is the usual reason my remote | X clients fail). | | Whether that’s the definition of ‘network transaprent’ I’ll not take a | view on. But it’s certainly inconvenient.
Ahhh, yes... The "My dad is smarter than your dad" card was very popular on the grade-school playground.
Without an equivalent or replacement for the [-]-geometry option when starting a simple (rectangular) client, a graphical windowing system is nearly as useless as Mickey$oft WinDoze. Being able to do the equivalent of "xterm -geometry
48x16+100+200" or "mplayer -geometry 720x480+200+300" is essential functionality.Parsimony is generally a good thing, but it be overdone to the point of impracticality. Software engineering academics will preach parsimony as an absolute goal. However, the benefits of parsimony need to be balanced against practical considerations in order to achieve useful results.
An analogous thing happens in SQL database design. Academics preach normalization at an absolute goal. However, with a sufficiently complex system, full normalization can require each query to use an excessive number of joins, and that can adversely affect performance. Those with practical experience in DB design will concede that sometimes you need to denormalize slightly in order to get reasonable performance.
Richard, that's a strange hill to die on.
---druck
Have something to add? Share your thoughts — no account required.
Ask the community — no account required