Hi all. A bit of an odd problem here.
I've a perl program that opens an X window using Tk. I specify the
geometry 1400x700+0+0.
Running under Mint, it works fine, and opens exactly as expected in the
top left screen corner.
On the Pi (pi4, 11/bullseye), it opens a window with the correct size
but a very odd position:
xwininfo: Window id: 0x1a00013 "Display"
Absolute upper-left X: 1782
Absolute upper-left Y: 30
Relative upper-left X: 2
Relative upper-left Y: 30
Width: 1400
Height: 700
Depth: 24
Visual: 0x21
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (not installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +1782+30 --1262+30 --1262-350 +1782-350
-geometry 1400x700+1780+0
which is well off to the right, with the title bar concealed underneath
the top task bar.
Any thoughts please as to what might be going on?
(I know bulldog isn't the latest but I don't have any pressing need to upgrade. This machine is dedicated to running this one program.
I also see xrandr returns unexpected output about not being able to
fetch the gamma value for the screen, which it calls "default". But
maybe that's a red herring.)
(I know bulldog isn't the latest but I don't have any pressing need to upgrade. This machine is dedicated to running this one program.
On Wed, 8 Jul 2026 12:03:51 +0100, Mike Scott wrote:
(I know bulldog isn't the latest but I don't have any pressing need to
upgrade. This machine is dedicated to running this one program.
What is XDG_SESSION_TYPE? Mint is X11. I'm running the latest Trixie derivative on the Pi and it is Wayland. I'm wondering if an older XWayland isn't doing the job.
Under some circumstances, the window manager can override the
size or position parameters. Under some other circumstances, the
application can ignore those parameters.
On the Pi (pi4, 11/bullseye), it opens a window with the correct
size but a very odd position:
On Wed, 8 Jul 2026 12:03:51 +0100, Mike Scott wrote:
On the Pi (pi4, 11/bullseye), it opens a window with the correct
size but a very odd position:
On Wayland, the application is not in control of where its windows
appear.
Then, what of the time-honored -geometry or --geometry option a user can
add to a command line in a script or alias to create a window at a user-specified location? I have scripts that open multiple windows,
each at a location specified by that option.
On 2026-07-08, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On Wed, 8 Jul 2026 12:03:51 +0100, Mike Scott wrote:
On the Pi (pi4, 11/bullseye), it opens a window with the correct
size but a very odd position:
On Wayland, the application is not in control of where its windows
appear.
Then, what of the time-honored -geometry or --geometry option a
user can add to a command line in a script or alias to create a
window at a user-specified location? I have scripts that open
multiple windows, each at a location specified by that option.
Absolute positioning of
windows was something the Wayland developers objected to.
On 09/07/2026 05:34, rbowman wrote:
Absolute positioning of windows was something the Wayland developers
objected to.
That seems short-sighted.
In my former life as a Windows (cough!) developer we took some trouble
to open our main application window at the same position on the screen
as it had been when the application was last closed (and stored screen size/position values for different screen sizes/resolutions for the
benefit of those who copied the application between their laptop and
desktop PCs). It was a popular feature.
I really do *NOT* like the fact that on this (stock RaspiOS) Pi the
wm chooses to open each and every application right in the centre of
the screen and I have to move them all around to acceptable places.
The whole Wayland project seems to be the blind leading the
short-sighted.
On Thu, 9 Jul 2026 18:31:18 +0100, druck wrote:
The whole Wayland project seems to be the blind leading the
short-sighted.
Feel free to sponsor the development of alternatives that are more
simpatico with your particular weltanschauung.
Free Software is all about having a choice.
One thing is for sure: giving control to the apps themselves is never
going to be the optimal solution.
On 09/07/2026 23:58, Lawrence DrCOOliveiro wrote:
One thing is for sure: giving control to the apps themselves is never
going to be the optimal solution.
It's not clear to me that there is any one solution that is optimal in
all cases.
It's certainly nice to allow the apps to be able to request a
particular size/position, but of course the wm should be able to
ignore the request if that location makes no sense. No, the app
shouldn't have *control*, just be able to express a preference.
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. That does point to a system-level component (window manager, compositor, whatever) managing positions, following user configuration, rather than the application.
Richard Kettlewell wrote:
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. That does point to a system-level component (window manager,
compositor, whatever) managing positions, following user configuration,
rather than the application.
I rather depends on the use, i suspect. That warning window really may
need to position itself screen dead centre on top of everything else
to make the realise there's a problem with the automatic reactor
emergency shutdown :-{
It's certainly nice to allow the apps to be able to request a
particular size/position, but of course the wm should be able to
ignore the request if that location makes no sense. No, the app
shouldn't have *control*, just be able to express a preference.
On 11/07/2026 14:05, Richard Kettlewell wrote:
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. That does point to a system-level component (window manager,
compositor, whatever) managing positions, following user configuration,
rather than the application.
I rather depends on the use, i suspect. That warning window really may
need to position itself screen dead centre on top of everything else to
make the realise there's a problem with the automatic reactor emergency shutdown :-{
Daniel James <daniel@me.invalid> writes:
On 09/07/2026 23:58, Lawrence DrCOOliveiro wrote:
One thing is for sure: giving control to the apps themselves is never
going to be the optimal solution.
It's not clear to me that there is any one solution that is optimal in
all cases.
It's certainly nice to allow the apps to be able to request a
particular size/position, but of course the wm should be able to
ignore the request if that location makes no sense. No, the app
shouldn't have *control*, just be able to express a preference.
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. That does point to a system-level component (window manager, compositor, whatever) managing positions, following user configuration, rather than the application.
There is some nuance here when an application either opens more than one window, or opens a window that is in some way logically connected to
another application. Depending on whatrCOs going on it might be
preferrable for the new window to be overlapping the existing window
(e.g. menus, tooltips, confirmation dialogs, etc), or it might be
preferrable for it to not overlapping the existing window if possible
(e.g. a pop-out media player).
Wayland already covers much of this but there does seem to be a gap for
a niche set of use cases. It always seems to be the same application mentioned each time this comes up, so itrCOs unclear if the niche is
bigger than 1.
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.
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).
On 2026-07-11, Richard Kettlewell <invalid@invalid.invalid> wrote:
Daniel James <daniel@me.invalid> writes:
On 09/07/2026 23:58, Lawrence DrCOOliveiro wrote:
One thing is for sure: giving control to the apps themselves is never
going to be the optimal solution.
It's not clear to me that there is any one solution that is optimal in
all cases.
It's certainly nice to allow the apps to be able to request a
particular size/position, but of course the wm should be able to
ignore the request if that location makes no sense. No, the app
shouldn't have *control*, just be able to express a preference.
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. That does point to a system-level component (window manager,
compositor, whatever) managing positions, following user configuration,
rather than the application.
There is some nuance here when an application either opens more than one
window, or opens a window that is in some way logically connected to
another application. Depending on whatrCOs going on it might be
preferrable for the new window to be overlapping the existing window
(e.g. menus, tooltips, confirmation dialogs, etc), or it might be
preferrable for it to not overlapping the existing window if possible
(e.g. a pop-out media player).
Wayland already covers much of this but there does seem to be a gap for
a niche set of use cases. It always seems to be the same application
mentioned each time this comes up, so itrCOs unclear if the niche is
bigger than 1.
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.
Robert Riches <spamtrap42@jacob21819.net> writes:
On 2026-07-11, Richard Kettlewell <invalid@invalid.invalid> wrote:
Daniel James <daniel@me.invalid> writes:
On 09/07/2026 23:58, Lawrence DrCOOliveiro wrote:
One thing is for sure: giving control to the apps themselves is never >>>>> going to be the optimal solution.
It's not clear to me that there is any one solution that is optimal in >>>> all cases.
It's certainly nice to allow the apps to be able to request a
particular size/position, but of course the wm should be able to
ignore the request if that location makes no sense. No, the app
shouldn't have *control*, just be able to express a preference.
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. That does point to a system-level component (window manager,
compositor, whatever) managing positions, following user configuration,
rather than the application.
There is some nuance here when an application either opens more than one >>> window, or opens a window that is in some way logically connected to
another application. Depending on whatrCOs going on it might be
preferrable for the new window to be overlapping the existing window
(e.g. menus, tooltips, confirmation dialogs, etc), or it might be
preferrable for it to not overlapping the existing window if possible
(e.g. a pop-out media player).
Wayland already covers much of this but there does seem to be a gap for
a niche set of use cases. It always seems to be the same application
mentioned each time this comes up, so itrCOs unclear if the niche is
bigger than 1.
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.
i.e. you want user control of window positions, which is what IrCOm
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 yourCOre trying to make here.
On 12 Jul 2026 03:55:03 GMT, Robert Riches wrote:
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.
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, rCLwindowrCY is not synonymous with rCLcontiguous rectangular region of opaque pixelsrCY.)
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).
<https://packages.debian.org/trixie/waypipe>
Or, perhaps you're just following the far-too-frequently observed
pattern of, "The Wayland way is the _ONLY_ way!"
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.
On 12 Jul 2026 16:14:28 GMT, Robert Riches wrote:
Or, perhaps you're just following the far-too-frequently observed
pattern of, "The Wayland way is the _ONLY_ way!"
I donrCOt 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.
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.
X11 was never rCLnetwork-transparentrCY. 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.
On 2026-07-12, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On 12 Jul 2026 16:14:28 GMT, Robert Riches wrote:
Or, perhaps you're just following the far-too-frequently observed
pattern of, "The Wayland way is the _ONLY_ way!"
I donrCOt 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.
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?
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.
X11 was never rCLnetwork-transparentrCY. 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.
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.
X11 was never rCLnetwork-transparentrCY. 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.
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.
Robert Riches <spamtrap42@jacob21819.net> writes:
On 2026-07-12, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On 12 Jul 2026 16:14:28 GMT, Robert Riches wrote:
Or, perhaps you're just following the far-too-frequently observed
pattern of, "The Wayland way is the _ONLY_ way!"
I donrCOt 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.
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?
rCyWhyrCO is covered in the FAQ.
https://wayland.freedesktop.org/faq.html
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.
That has very limited usefulness today due to its unacceptably poor
security.
X11 was never rCLnetwork-transparentrCY. 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.
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.
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 thatrCOs the definition of rCynetwork transaprentrCO IrCOll not take a
view on. But itrCOs certainly inconvenient.
On 12 Jul 2026 22:16:40 GMT, Robert Riches wrote:
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.
We tended to set 'xhost +'. 'Why is it suddenly snowing on my computer?'
On 2026-07-12, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On 12 Jul 2026 16:14:28 GMT, Robert Riches wrote:
Or, perhaps you're just following the far-too-frequently observed
pattern of, "The Wayland way is the _ONLY_ way!"
I donrCOt 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.
Why is there a need to do anything? X works just fine.
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.
On 12 Jul 2026 22:16:40 GMT, Robert Riches wrote:
On 2026-07-12, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On 12 Jul 2026 16:14:28 GMT, Robert Riches wrote:
Or, perhaps you're just following the far-too-frequently observed
pattern of, "The Wayland way is the _ONLY_ way!"
I donrCOt 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.
Why is there a need to do anything? X works just fine.
Developers have largely ceased updating it, because hardly anybody
sees it as a worthwhile project any more. If you donrCOt care about
that, fine. But most of those responsible for maintaining
well-supported distros do.
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.
X11 was never rCLnetwork-transparentrCY. If the network connection went
down, all those remote X clients would die.
On 2026-07-13, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
X11 was never rCLnetwork-transparentrCY. If the network connection went
down, all those remote X clients would die.
That's not what the term means ...
Lawrence DrCOOliveiro wrote:
X11 was never rCLnetwork-transparentrCY. 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.
If the network connection goes down VNC and RDP will not be far behind.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Robert Riches <spamtrap42@jacob21819.net> writes:
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?
rCyWhyrCO is covered in the FAQ.
https://wayland.freedesktop.org/faq.html
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.
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.
That has very limited usefulness today due to its unacceptably poor
security.
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.
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).
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.
Whether thatrCOs the definition of rCynetwork transaprentrCO IrCOll not take a
view on. But itrCOs certainly inconvenient.
Not sure what you mean is inconvenient.
Robert Riches <spamtrap42@jacob21819.net> writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
Robert Riches <spamtrap42@jacob21819.net> writes:
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?
rCyWhyrCO is covered in the FAQ.
https://wayland.freedesktop.org/faq.html
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.
Wayland was largely created by X11 developers. They know a lot more
about it than you.
Wayland was largely created by X11 developers. They know a lot more
about it than you.
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.
In article <slrn115a3i3.ki8.spamtrap42@one.localnet>, Robert Riches
<spamtrap42@jacob21819.net> wrote:
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.
This is nonsense and a good hint is that you are putting words in the
mouths of others and then attacking them for those words.
I've never taken a database course but I had nearly 20 years of
database design in industry for mid-level systems. I have read some
database books written by academics along the way. The claim that they "preach normalization at (sic) an absolute goal" is plain wrong in my experience.
The academic books I've read describe multiple normal forms. I don't
recall ever seeing one singled as superior to all the others, different normal forms reflect different (generally theoretical) perspectives on
data and the relational calculus. Not surprising, I think, and I am
confident that being informed about different perspectives has helped
me design systems.
Database design requires a designer to balance various factors,
including where the data comes from, how it is to be maintained, and
how it is to be used (including performance of queries). I have no idea
which of all the tables I've designed and run in production may or may
not be normalized by any of the multiple normalizations that have been described. But I read those books in order to improve my skills and it
was time well spent.
Tom
Richard Kettlewell wrote:
Wayland was largely created by X11 developers. They know a lot more
about it than you.
Richard, that's a strange hill to die on.
An analogous thing happens in SQL database design.
On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:
An analogous thing happens in SQL database design.
It does seem like you are trying to distract attention from the X11-versus-Wayland discussion. Your argument there is collapsing, so
you try to pull the old smokescreen switcharoo: rCLNever mind that, look
over here!rCY
On 2026-07-14, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:
An analogous thing happens in SQL database design.
It does seem like you are trying to distract attention from the
X11-versus-Wayland discussion. Your argument there is collapsing, so
you try to pull the old smokescreen switcharoo: rCLNever mind that, look
over here!rCY
Collapsing? No, with the lack of mention of any sort of
replacement for the essential [-]-geometry option to launch
simple clients (xterm, mplayer, for example), it's the
pro-Wayland argument that has collapsed.
On 2026-07-14, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:
An analogous thing happens in SQL database design.
It does seem like you are trying to distract attention from the
X11-versus-Wayland discussion. Your argument there is collapsing,
so you try to pull the old smokescreen switcharoo: rCLNever mind
that, look over here!rCY
Collapsing? No, with the lack of mention of any sort of replacement
for the essential [-]-geometry option to launch simple clients
(xterm, mplayer, for example), it's the pro-Wayland argument that
has collapsed.
On 15 Jul 2026 03:10:30 GMT, Robert Riches wrote:
On 2026-07-14, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:
An analogous thing happens in SQL database design.
It does seem like you are trying to distract attention from the
X11-versus-Wayland discussion. Your argument there is collapsing,
so you try to pull the old smokescreen switcharoo: rCLNever mind
that, look over here!rCY
Collapsing? No, with the lack of mention of any sort of replacement
for the essential [-]-geometry option to launch simple clients
(xterm, mplayer, for example), it's the pro-Wayland argument that
has collapsed.
Well, then, you need to put your money where your mouth is, right? If
your argument hasnrCOt rCLcollapsedrCY, then you need to point out whatrCOs holding it up.
Start by explaining why window-arrangement options should be
reimplemented (often inconsistently) by every single X11 app, instead
of being handled once and for all in the window manager.
Well, then, you need to put your money where your mouth is, right? If
your argument hasnrCOt rCLcollapsedrCY, then you need to point out whatrCOs holding it up.
Start by explaining why window-arrangement options should be
reimplemented (often inconsistently) by every single X11 app, instead
of being handled once and for all in the window manager.
Lawrence DrCOOliveiro wrote:
Well, then, you need to put your money where your mouth is, right? If
your argument hasnrCOt rCLcollapsedrCY, then you need to point out whatrCOs >> holding it up. Start by explaining why window-arrangement options
should be reimplemented (often inconsistently) by every single X11
app, instead of being handled once and for all in the window manager.
I'm getting muddled here. I've never used Wayland, so please excuse a probably naive comment.
Suppose I start a program that pops up a window. Can I put this where
I want on the screen, presumably by a mouse drag'n'drop operation? Can
I raise and lower relative to other windows?
If either answer is 'no', I'd question the use of such a system. If
yes, then why not let this be done programmatically and save the user
a probably repetitive task?
I've seen comments about 'security'; but we live in a real world and usability and security are IME both tradeoffs. Has Wayland erred on
the too-secure side?
Suppose I start a program that pops up a window. Can I put this
where I want on the screen, presumably by a mouse drag'n'drop
operation? Can I raise and lower relative to other windows?
If yes, then why not let this be done programmatically and save the
user a probably repetitive task?
druck <news@druck.org.uk> writes:
Richard Kettlewell wrote:
Wayland was largely created by X11 developers. They know a lot more
about it than you.
Richard, that's a strange hill to die on.
The context was Robert attacking the Wayland developers, from a position
of evident ignorance, via Henry SpencerrCOs remark rCLThose who do not understand Unix are condemned to reinvent it, poorlyrCY. But the quote
does not fit, indeed it is almost the opposite of a fit: the reality is
that the Wayland developers do understand X11, more so than most, and
that is why they decided to go in a different direction.
I think they may well understand X11 very well, they just don't
understand other people value a completely different set of features
than they do, and rightly get annoyed that not only do Wayland
developers refuse to implement them, but tell them they are wrong
for even wanting them.
On 14/07/2026 08:36, Richard Kettlewell wrote:
druck <news@druck.org.uk> writes:
Richard Kettlewell wrote:
Wayland was largely created by X11 developers. They know a lot more
about it than you.
Richard, that's a strange hill to die on.
The context was Robert attacking the Wayland developers, from a position
of evident ignorance, via Henry SpencerrCOs remark rCLThose who do not
understand Unix are condemned to reinvent it, poorlyrCY. But the quote
does not fit, indeed it is almost the opposite of a fit: the reality is
that the Wayland developers do understand X11, more so than most, and
that is why they decided to go in a different direction.
I think they may well understand X11 very well, they just don't
understand other people value a completely different set of features
than they do, and rightly get annoyed that not only do Wayland
developers refuse to implement them, but tell them they are wrong for
even wanting them.
That's the hill, there are the bodies.
---druck--
On Thu, 16 Jul 2026 22:12:02 +0100, druck wrote:
I think they may well understand X11 very well, they just don't
understand other people value a completely different set of features
than they do, and rightly get annoyed that not only do Wayland
developers refuse to implement them, but tell them they are wrong
for even wanting them.
Just because you value a certain set of features, doesnrCOt mean that
anybody else is obligated to implement them for you.
If you think those features would be so useful to others, get a group together to implement them yourself.
After all, thatrCOs how projects like Wayland and systemd got started in
the first place. Oh, and Linux itself, and X11 before that, and ...
On 17/07/2026 02:16, Lawrence DrCOOliveiro wrote:
On Thu, 16 Jul 2026 22:12:02 +0100, druck wrote:
I think they may well understand X11 very well, they just don'tJust because you value a certain set of features, doesnrCOt mean that
understand other people value a completely different set of features
than they do, and rightly get annoyed that not only do Wayland
developers refuse to implement them, but tell them they are wrong
for even wanting them.
anybody else is obligated to implement them for you.
'Anybody' already had implemented them in X11, that's why we are quite
happy with that.
If you think those features would be so useful to others, get a group
together to implement them yourself.
Plenty of people already have, but the Wayland developers have refused
to accept those features, as they differ from their ideas of what it
should and shouldn't do. I would have thought you would understand
this by now.
After all, thatrCOs how projects like Wayland and systemd got started in
the first place. Oh, and Linux itself, and X11 before that, and ...
Wayland and Systemd were started by RedHat to lock people in to their
distro, its development philosophy is diametrically opposed to that of
Linux and X11.
Wayland and Systemd were started by RedHat to lock people in to their
distro, its development philosophy is diametrically opposed to that of
Linux and X11.
As far as I can tell the reality is that everyone was trying to replace
sysv init a few years back (something that was desparately overdue), and systemd is the one that got most uptake. Much the same as happened with version control systems (git largely won, against a crowded field) and
Unix platforms (Linux won against numerous free and proprietary alternatives).
possibly a reaction against
Poettering. He is young, relatively, and doesn't show proper respect for System V, POSIX, and other commandments that were chiseled in stone.
Pulse audio should have been a warning,. systemd is now here and we must
do all the work he was too lazy to do, to make it work...
On Sun, 19 Jul 2026 20:31:38 +0100, The Natural Philosopher wrote:
Pulse audio should have been a warning,. systemd is now here and we must
do all the work he was too lazy to do, to make it work...
I'm not fond of PulseAudio and friends but systemd works.
druck <news@druck.org.uk> writes:
Wayland and Systemd were started by RedHat to lock people in to their
distro, its development philosophy is diametrically opposed to that of
Linux and X11.
Sounds like a conspiracy theory to me. How does this lock-in work in practice? It doesnrCOt seem to be very effective, I have systemd-based platforms, and a three-layer rendering software chain with Wayland in
the middle, and yet no RedHat in sight.
As far as I can tell the reality is that everyone was trying to replace
sysv init a few years back (something that was desparately overdue), and systemd is the one that got most uptake. Much the same as happened with version control systems (git largely won, against a crowded field) and
Unix platforms (Linux won against numerous free and proprietary alternatives).
It didn't work very well because for inexplicable reasons other distros (including otherwise sensible ones, and I'm looking at you Debian) have adopted Red Hat's poison chalice(s).
druck wrote:
It didn't work very well because for inexplicable reasons other distros
(including otherwise sensible ones, and I'm looking at you Debian) have
adopted Red Hat's poison chalice(s).
The reasons are rather explicable. Remember Upstart? Debian had a long discussion about whether to switch to Upstart or systemd from
sysVinit. Systemd won. Ubuntu wasn't that attached to their own dog
food and switche d from Upstart to systemd. Fedora also switched from
Upstart to systemd. Upstart has been on life support for about 8
years.
Runit is another attempt to replace sysV. It's the default on antiX and
Void and can be used with a couple of others. MX didn't follow antiX and defaults to sysV with systemd as an option.
Distribution maintainers were looking for an alternative to sysV that allowed more flexibility. At least two replacements other than systemd
were available. systemd won.
rbowman <bowman@montana.com> writes:
druck wrote:
It didn't work very well because for inexplicable reasons other distros
(including otherwise sensible ones, and I'm looking at you Debian) have
adopted Red Hat's poison chalice(s).
The reasons are rather explicable. Remember Upstart? Debian had a long
discussion about whether to switch to Upstart or systemd from
sysVinit. Systemd won. Ubuntu wasn't that attached to their own dog
food and switche d from Upstart to systemd. Fedora also switched from
Upstart to systemd. Upstart has been on life support for about 8
years.
DebianrCOs decision was deeply contested within the project, but the reasoning is well documented.
I suspect Upstart is abandonware now.
Runit is another attempt to replace sysV. It's the default on antiX and
Void and can be used with a couple of others. MX didn't follow antiX and
defaults to sysV with systemd as an option.
Distribution maintainers were looking for an alternative to sysV that
allowed more flexibility. At least two replacements other than systemd
were available. systemd won.
IIRC there were upwards of a dozen attempts to replace sysvinit,
although only handful that ever reached meaningful levels of adoption (Upstart, systemd, OpenRC; plus launchd if we look beyond Linux).
My issue with systemd is its viral tendancy to want to take over
everything:
systemd-hostnamed systemd-journald systemd-logind systemd-networkd systemd-resolved systemd-timedated systemd-udevd ...
My issue with systemd is its viral tendancy to want to take over everything:
systemd-hostnamed
systemd-journald
systemd-logind
systemd-networkd
systemd-resolved
systemd-timedated
systemd-udevd
...
Sounds like a conspiracy theory to me. How does this lock-in work
in practice? It doesnrCOt seem to be very effective, I have
systemd-based platforms, and a three-layer rendering software chain
with Wayland in the middle, and yet no RedHat in sight.
It didn't work very well because for inexplicable reasons other
distros (including otherwise sensible ones, and I'm looking at you
Debian) have adopted Red Hat's poison chalice(s).
On 17/07/2026 02:16, Lawrence DrCOOliveiro wrote:
Just because you value a certain set of features, doesnrCOt mean that
anybody else is obligated to implement them for you.
'Anybody' already had implemented them in X11, that's why we are
quite happy with that.
If you think those features would be so useful to others, get a
group together to implement them yourself.
Plenty of people already have, but the Wayland developers have
refused to accept those features ...
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 51:09:43 |
| Calls: | 1,100 |
| Files: | 1,339 |
| Messages: | 276,012 |