Free of systemd ...
On Sat, 26 Jul 2025 18:40:19 -0400, Popping Mad wrote:
Free of systemd ...
Seems they have to implement a whole systemd-compatibility layer, just
to allow them to pull in packages from Arch upstream without breaking <https://forum.artixlinux.org/index.php/topic,5353.0.html>.
How do they handle sysvinit scripts? Does their compatibility layer
include a reinvention of systemd-sysvcompat? Or do they run sysvinit directly? The first would seem to make things even more complex than
systemd, while the latter would seem to be a step backwards ...
Free of systemd and wayland
and it just works
https://forum.artixlinux.org/index.php/topic,8409.0.html
They do not use systemd.
On Sat, 26 Jul 2025 18:47:23 -0700, Bobbie Sellers wrote:
They do not use systemd.
Seems they have to implement a whole systemd-compatibility layer, just
to allow them to pull in packages from Arch upstream without breaking <https://forum.artixlinux.org/index.php/topic,5353.0.html>.
How do they handle sysvinit scripts? Does their compatibility layer
include a reinvention of systemd-sysvcompat? Or do they run sysvinit directly? The first would seem to make things even more complex than
systemd, while the latter would seem to be a step backwards ...
KiCad Advises Linux Users to Stick with X11 for Professional PCB Design
By Bobby Borisov June 27, 2025
The KiCad team outlines serious Wayland limitations, including window control and
crashes, urging users to stick with X11 desktops for reliability. Full article at the
next URL: <https://linuxiac.com/kicad-advises-linux-users-to-stick-with-x11-for-professional-pcb-
design/>
On 7/26/25 18:57, Lawrence D'Oliveiro wrote:
Or do they run sysvinit directly? ... would seem to be a step
backwards ...
A step baclward is a matter of opinion not of utility.
On Sat, 26 Jul 2025 20:28:48 -0700, Bobbie Sellers wrote:
On 7/26/25 18:57, Lawrence D'Oliveiro wrote:
Or do they run sysvinit directly? ... would seem to be a step
backwards ...
A step backward is a matter of opinion not of utility.
Just about every person knowledgeable on the issue considers sysvinit to
be antiquated and no longer fit for purpose.
On Sat, 26 Jul 2025 20:28:48 -0700, Bobbie Sellers wrote:
On 7/26/25 18:57, Lawrence D'Oliveiro wrote:
Or do they run sysvinit directly? ... would seem to be a step
backwards ...
A step baclward is a matter of opinion not of utility.
Just about every person knowledgeable on the issue considers sysvinit to
be antiquated and no longer fit for purpose.
Just about every person knowledgeable on the issue considers sysvinit to
be antiquated and no longer fit for purpose.
On 7/26/25 21:38, Lawrence D'Oliveiro wrote:
On Sat, 26 Jul 2025 20:28:48 -0700, Bobbie Sellers wrote:
On 7/26/25 18:57, Lawrence D'Oliveiro wrote:
Or do they run sysvinit directly? ... would seem to be a step
backwards ...
A step baclward is a matter of opinion not of utility.
Just about every person knowledgeable on the issue considers sysvinit
to be antiquated and no longer fit for purpose.
Then how am I typing this if SysV is not fit for the limited
purpose of starting up a computer.
On 7/26/25 17:30, Lawrence D'Oliveiro wrote:
On Sat, 26 Jul 2025 18:40:19 -0400, Popping Mad wrote:Systemd was un-necessary but some people will do anything to
Free of systemd ...
Seems they have to implement a whole systemd-compatibility layer, just
to allow them to pull in packages from Arch upstream without breaking
<https://forum.artixlinux.org/index.php/topic,5353.0.html>.
controlt the choices of other people. Which may work in Enterprise situations. I dunno about that since I have never dealt with that.
On 7/26/25 21:38, Lawrence D'Oliveiro wrote:
On Sat, 26 Jul 2025 20:28:48 -0700, Bobbie Sellers wrote:
On 7/26/25 18:57, Lawrence D'Oliveiro wrote:
Or do they run sysvinit directly? ... would seem to be a step
backwards ...
A step baclward is a matter of opinion not of utility.
Just about every person knowledgeable on the issue considers sysvinit to
be antiquated and no longer fit for purpose.
Then how am I typing this if SysV is not fit for the limited
purpose of starting up a computer.
Why has Slackel 8.0 "Openbox" decided to use SysV?
How did my computers even start today if SysV is unfit to
start a system?
Free of systemd and wayland
and it just works
https://forum.artixlinux.org/index.php/topic,8409.0.html
Popping Mad <[email protected]> wrote:
Free of systemd and wayland
and it just works
https://forum.artixlinux.org/index.php/topic,8409.0.html
Slackware is systemd free as well, and has no wayland (as of the
moment).
Bobbie Sellers <[email protected]> wrote:
On 7/26/25 17:30, Lawrence D'Oliveiro wrote:
On Sat, 26 Jul 2025 18:40:19 -0400, Popping Mad wrote:Systemd was un-necessary but some people will do anything to
Free of systemd ...
Seems they have to implement a whole systemd-compatibility layer, just
to allow them to pull in packages from Arch upstream without breaking
<https://forum.artixlinux.org/index.php/topic,5353.0.html>.
controlt the choices of other people. Which may work in Enterprise
situations. I dunno about that since I have never dealt with that.
Lawrence is our local systemd evangelizer.
On 7/27/25 8:19 PM, Rich wrote:
Bobbie Sellers <[email protected]> wrote:
On 7/26/25 17:30, Lawrence D'Oliveiro wrote:
On Sat, 26 Jul 2025 18:40:19 -0400, Popping Mad wrote:Systemd was un-necessary but some people will do anything to
Free of systemd ...
Seems they have to implement a whole systemd-compatibility layer,
just to allow them to pull in packages from Arch upstream without
breaking <https://forum.artixlinux.org/index.php/topic,5353.0.html>.
controlt the choices of other people. Which may work in Enterprise
situations. I dunno about that since I have never dealt with that.
Lawrence is our local systemd evangelizer.
Systemd doesn't need evangelizing ... it either serves your needs or
it doesn't. It's not evil nor Devil's Spawn nor a Second Coming. If
SysV will do it for you then stick to SysV. That works, it's very
well documented and it's fairly simple.
You are arguing with one who has drunk the systemd kool-aid. There's
no point, as nothing will disuade him from his kool-aid induced love of systemd.
Systemd is ... massively over complicated shit that has been
massaged at enormous man hours to approximately work well enough to
be useful.
Given not only the apparent shortcomings of Wayland, but also the
attitude of some of its supporters-bullies ...
On 2025-07-28, Rich wrote:
Bobbie Sellers <[email protected]> wrote:
On 7/26/25 21:38, Lawrence D'Oliveiro wrote:
Just about every person knowledgeable on the issue considers
sysvinit to be antiquated and no longer fit for purpose.
Then how am I typing this if SysV is not fit for the limited purpose
of starting up a computer.
One thing I find curious here is the generalization of just referring to "sysvinit". Certainly systems in that style aren't all similar, although
they may operate within certain expectations or constraints of the
system design they adhere to?
Weren't there e.g. upstart and openrc?
Nuno Silva <[email protected]d> writes:
On 2025-07-28, Rich wrote:
Bobbie Sellers <[email protected]> wrote:
On 7/26/25 21:38, Lawrence D'Oliveiro wrote:
Just about every person knowledgeable on the issue considers
sysvinit to be antiquated and no longer fit for purpose.
Then how am I typing this if SysV is not fit for the limited purpose
of starting up a computer.
The firmware and boot chain start the computer. The init system
(sysvinit, systemd, etc) are responsible for managing services once it
has started. Sysvinit’s deficiencies in that respect have been rehearsed
a great many times, and I expect that’s what the previous poster is referring to.
[..]
One thing I find curious here is the generalization of just referring to
"sysvinit". Certainly systems in that style aren't all similar, although
they may operate within certain expectations or constraints of the
system design they adhere to?
Weren't there e.g. upstart and openrc?
Yes, and others besides. Upstart was used in Ubuntu for a handful of releases.
We wanted and needed
- a simple protocol to draw pictures on a screen
- a simple protocol to *exactly* specify a page layout
On Tue, 29 Jul 2025 11:13:02 +0100, The Natural Philosopher wrote:
We wanted and needed
- a simple protocol to draw pictures on a screen
- a simple protocol to *exactly* specify a page layout
Both the PostScript graphics model and language have been obsoleted by
better choices for those purposes.
On 2025-07-27, Lawrence D'Oliveiro wrote:
Having had first-hand experience of writing both sysvinit scripts
and systemd service definitions (as part of the work I do for a
living), I know which one I prefer. And it’s not the clunky,
fragile, boilerplate- ridden cobbled-together-shell-script fudge
that is a leftover from the 1980s.
This is starting to sound like shell wars or programming language
wars or editor wars.
Nuno Silva <[email protected]d> writes:
Weren't there e.g. upstart and openrc?
Yes, and others besides. Upstart was used in Ubuntu for a handful of releases.
On 2025-07-29, Lawrence D'Oliveiro wrote:
On Tue, 29 Jul 2025 11:13:02 +0100, The Natural Philosopher wrote:
We wanted and needed
- a simple protocol to draw pictures on a screen
- a simple protocol to *exactly* specify a page layout
Both the PostScript graphics model and language have been obsoleted by
better choices for those purposes.
So what are the better choices for a Turing-complete language producing graphic output suited for printing in a similar fashion to PostScript?
On Tue, 29 Jul 2025 09:02:22 +0100, Nuno Silva wrote:
Given not only the apparent shortcomings of Wayland, but also the
attitude of some of its supporters-bullies ...
Nobody is forcing you to use it. Free software is all about choice.
On 7/29/25 15:44, Lawrence D'Oliveiro wrote:
On Tue, 29 Jul 2025 09:02:22 +0100, Nuno Silva wrote:
Given not only the apparent shortcomings of Wayland, but also the
attitude of some of its supporters-bullies ...
Nobody is forcing you to use it. Free software is all about choice.
Certain choices depend on the distribution.
On Tue, 29 Jul 2025 23:23:32 +0100, Richard Kettlewell wrote:
Nuno Silva <[email protected]d> writes:
Weren't there e.g. upstart and openrc?
Yes, and others besides. Upstart was used in Ubuntu for a handful of
releases.
How well did they cope with existing sysvinit scripts?
I get the feeling that one significant factor (of the many) in favour of systemd was it made the transition away from sysvinit much less painful.
On Tue, 29 Jul 2025 22:14:51 +0100, Nuno Silva wrote:
On 2025-07-27, Lawrence D'Oliveiro wrote:
Having had first-hand experience of writing both sysvinit scripts
and systemd service definitions (as part of the work I do for a
living), I know which one I prefer. And it’s not the clunky,
fragile, boilerplate- ridden cobbled-together-shell-script fudge
that is a leftover from the 1980s.
This is starting to sound like shell wars or programming language
wars or editor wars.
This is a case of real-world experience. E.g. <https://web.archive.org/web/20240711140744/https://list.waikato.ac.nz/archives/list/[email protected]/thread/BIAW7GY4KGPUGWIIRWNMBE5JSUVT2VWX/>
On 2025-07-27, Lawrence D'Oliveiro wrote:
On Sun, 27 Jul 2025 00:58:29 -0700, Bobbie Sellers wrote:
On 7/26/25 21:38, Lawrence D'Oliveiro wrote:
On Sat, 26 Jul 2025 20:28:48 -0700, Bobbie Sellers wrote:
On 7/26/25 18:57, Lawrence D'Oliveiro wrote:
Or do they run sysvinit directly? ... would seem to be a step
backwards ...
A step baclward is a matter of opinion not of utility.
Just about every person knowledgeable on the issue considers sysvinit
to be antiquated and no longer fit for purpose.
Then how am I typing this if SysV is not fit for the limited
purpose of starting up a computer.
Having had first-hand experience of writing both sysvinit scripts and
systemd service definitions (as part of the work I do for a living), I
know which one I prefer. And it’s not the clunky, fragile, boilerplate-
ridden cobbled-together-shell-script fudge that is a leftover from the
1980s.
This is starting to sound like shell wars or programming language wars
or editor wars. There's objective debate of features implemented, extensibility, paradigms made easier, easeness of debugging, &c., and
then there is stuff like "but I like my editor/language/shell/init
system better!".
You can comment on your feelings about init scripts for some init system
you file under "sysvinit", you can comment on complexity of its language
or verbosity or inability to cover some approach you want to use.
But calling such systems "unfit" for an init system definitely is
neither.
On 2025-07-29, Lawrence D'Oliveiro wrote:
On Tue, 29 Jul 2025 11:13:02 +0100, The Natural Philosopher wrote:
We wanted and needed
- a simple protocol to draw pictures on a screen
- a simple protocol to *exactly* specify a page layout
Both the PostScript graphics model and language have been obsoleted by
better choices for those purposes.
So what are the better choices for a Turing-complete language producing graphic output suited for printing in a similar fashion to PostScript?
Richard Kettlewell wrote:
Nuno Silva <[email protected]d> writes:
Weren't there e.g. upstart and openrc?
Yes, and others besides. Upstart was used in Ubuntu for a handful of
releases.
How well did they cope with existing sysvinit scripts?
I get the feeling that one significant factor (of the many) in favour
of systemd was it made the transition away from sysvinit much less
painful.
Why does it have to be Turing complete?
It doesn't show added complexity or difficulty with non-systemd.
My beef was that thos shell scripts were stable and debugged and
*worked* whereas systemd stuff often did not.
One gets the impression [Poettering] is a frustrated CompSci looking
[f]or elegance and not a software engineer looking for stability,
simplicity and resilience
Systemd was released before it was fully debugged ...
Well, no, longer doesn't mean more complex, but, anyway, that wasn't the point, as noted with the paragraph you did not quote.
On Wed, 30 Jul 2025 11:42:05 +0100, The Natural Philosopher wrote:
Just like Pulse Audio.
That's the one I had problems with. After an Ubuntu update it wouldn't recognize the wired speakers. I screwed around with it for a while with no joy. It did recognize the Bluetooth buds so I bought Bluetooth speakers
and moved on.
Fedora uses Pulseaudio too but didn't have the same problem.
On Wed, 30 Jul 2025 23:40:21 +0100, Nuno Silva wrote:
Well, no, longer doesn't mean more complex, but, anyway, that wasn't the
point, as noted with the paragraph you did not quote.
From my original email:
That’s 20 lines (17 excluding blank ones), nearly all of which is
repetitive boilerplate. You’ll note the one I posted was just 12,
including blank lines, of which only one was actual executable
code (all the rest were directives).
On 7/27/25 8:18 PM, Rich wrote:
Popping Mad <[email protected]> wrote:
Free of systemd and wayland
and it just works
https://forum.artixlinux.org/index.php/topic,8409.0.html
Slackware is systemd free as well, and has no wayland (as of the
moment).
Slack has always been good - but it CAN be kind of
a LOT of work.
On 2025-07-31, Lawrence D'Oliveiro wrote:
On Wed, 30 Jul 2025 23:40:21 +0100, Nuno Silva wrote:
Well, no, longer doesn't mean more complex, but, anyway, that
wasn't the point, as noted with the paragraph you did not quote.
From my original email:
That’s 20 lines (17 excluding blank ones), nearly all of which
is repetitive boilerplate. You’ll note the one I posted was
just 12, including blank lines, of which only one was actual
executable code (all the rest were directives).
You're still missing the point: what your mail/post shows, is that
you're choosing to see this as a reason why systemd is superior to
the other kind of init system that was brought up. This is your
subjective opinion, but you're handing it out here like you're
envagelizing people based on some religious book.
Just like Pulse Audio.
On 2025-07-31, Lawrence D'Oliveiro wrote:
On Wed, 30 Jul 2025 23:40:21 +0100, Nuno Silva wrote:
Well, no, longer doesn't mean more complex, but, anyway, that wasn't
the point, as noted with the paragraph you did not quote.
From my original email:
That’s 20 lines (17 excluding blank ones), nearly all of which is
repetitive boilerplate. You’ll note the one I posted was just 12,
including blank lines, of which only one was actual executable code
(all the rest were directives).
You're still missing the point: what your mail/post shows, is that
you're choosing to see this as a reason why systemd is superior to the
other kind of init system that was brought up.
This is your subjective opinion ...
You keep insisting that everyone must buy into your opinion of systemd
being superior because you counted lines or because you personally find systemd easier to write for or to maintain.
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the
moment).
Slackware has both X11 and Wayland. You are free to choose the window
system.
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the
moment).
Slackware has both X11 and Wayland. You are free to choose the window
system.
On Thu, 31 Jul 2025 16:22:10 +0200, Marco Moock wrote:
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the
moment).
Slackware has both X11 and Wayland. You are free to choose the window
system.
It also has embraced Poettering’s other brainchild, PulseAudio.
On Thu, 31 Jul 2025 22:58:08 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Thu, 31 Jul 2025 16:22:10 +0200, Marco Moock wrote:
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the
moment).
Slackware has both X11 and Wayland. You are free to choose the window
system.
It also has embraced Poettering’s other brainchild, PulseAudio.
It worked.
I think I misspoke in an earlier post. It was the update to
PipeWire that rained on my parade when Ubuntu adopted it. Some people were able to revert to PulseAudio but that wasn't easy and tended to be
fragile.
On Thu, 31 Jul 2025 22:58:08 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Thu, 31 Jul 2025 16:22:10 +0200, Marco Moock wrote:
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the
moment).
Slackware has both X11 and Wayland. You are free to choose the window
system.
It also has embraced Poettering’s other brainchild, PulseAudio.
It worked. I think I misspoke in an earlier post. It was the update to PipeWire that rained on my parade when Ubuntu adopted it. Some people were able to revert to PulseAudio but that wasn't easy and tended to be
fragile.
On 2025-08-01, rbowman wrote:
On Thu, 31 Jul 2025 22:58:08 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Thu, 31 Jul 2025 16:22:10 +0200, Marco Moock wrote:
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the
moment).
Slackware has both X11 and Wayland. You are free to choose the window
system.
It also has embraced Poettering’s other brainchild, PulseAudio.
It worked. I think I misspoke in an earlier post. It was the update to
PipeWire that rained on my parade when Ubuntu adopted it. Some people were >> able to revert to PulseAudio but that wasn't easy and tended to be
fragile.
Unrelated to their stability, but:
PulseAudio is also an example of where some misinformation did get
spread saying Alsa "could not" handle output from multiple applications
and that PulseAudio was required for such a thing.
On 01/08/2025 09:47, Nuno Silva wrote:
PulseAudio is also an example of where some misinformation did get
spread saying Alsa "could not" handle output from multiple applications
and that PulseAudio was required for such a thing.
I found that to be the case actually. Maybe it wasn't a theoretical limitation, but in practice it appeared.
On 2025-08-01, The Natural Philosopher wrote:
On 01/08/2025 09:47, Nuno Silva wrote:
PulseAudio is also an example of where some misinformation did get
spread saying Alsa "could not" handle output from multiple applications
and that PulseAudio was required for such a thing.
I found that to be the case actually. Maybe it wasn't a theoretical
limitation, but in practice it appeared.
Did you try to configure Alsa to enable software mixing?
This appeared to be disabled by default with some configurations, but
could be enabled (I remember reading or being told it was about the
default configs when using some cards with more channels than stereo,
but maybe that was inaccurate).
On 01/08/2025 09:47, Nuno Silva wrote:
On 2025-08-01, rbowman wrote:I found that to be the case actually. Maybe it wasn't a theoretical limitation, but in practice it appeared.
On Thu, 31 Jul 2025 22:58:08 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Thu, 31 Jul 2025 16:22:10 +0200, Marco Moock wrote:
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the
moment).
Slackware has both X11 and Wayland. You are free to choose the window >>>>> system.
It also has embraced Poettering’s other brainchild, PulseAudio.
It worked. I think I misspoke in an earlier post. It was the update to
PipeWire that rained on my parade when Ubuntu adopted it. Some people were >>> able to revert to PulseAudio but that wasn't easy and tended to be
fragile.
Unrelated to their stability, but:
PulseAudio is also an example of where some misinformation did get
spread saying Alsa "could not" handle output from multiple applications
and that PulseAudio was required for such a thing.
The Natural Philosopher <[email protected]d> wrote:
On 01/08/2025 09:47, Nuno Silva wrote:
On 2025-08-01, rbowman wrote:I found that to be the case actually. Maybe it wasn't a theoretical
On Thu, 31 Jul 2025 22:58:08 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Thu, 31 Jul 2025 16:22:10 +0200, Marco Moock wrote:
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the >>>>>>> moment).
Slackware has both X11 and Wayland. You are free to choose the window >>>>>> system.
It also has embraced Poettering’s other brainchild, PulseAudio.
It worked. I think I misspoke in an earlier post. It was the update to >>>> PipeWire that rained on my parade when Ubuntu adopted it. Some people were >>>> able to revert to PulseAudio but that wasn't easy and tended to be
fragile.
Unrelated to their stability, but:
PulseAudio is also an example of where some misinformation did get
spread saying Alsa "could not" handle output from multiple applications
and that PulseAudio was required for such a thing.
limitation, but in practice it appeared.
It appeared if your distro did not enable Alsa software mixing, which
was always a thing, but often not enabled in the default config the
distros deployed.
On 01/08/2025 18:15, Rich wrote:
The Natural Philosopher <[email protected]d> wrote:
On 01/08/2025 09:47, Nuno Silva wrote:
On 2025-08-01, rbowman wrote:I found that to be the case actually. Maybe it wasn't a theoretical
On Thu, 31 Jul 2025 22:58:08 -0000 (UTC), Lawrence D'Oliveiro wrote: >>>>>
On Thu, 31 Jul 2025 16:22:10 +0200, Marco Moock wrote:
On 28.07.2025 00:18 Rich Rich wrote:
Slackware is systemd free as well, and has no wayland (as of the >>>>>>>> moment).
Slackware has both X11 and Wayland. You are free to choose the window >>>>>>> system.
It also has embraced Poettering’s other brainchild, PulseAudio.
It worked. I think I misspoke in an earlier post. It was the update to >>>>> PipeWire that rained on my parade when Ubuntu adopted it. Some people were
able to revert to PulseAudio but that wasn't easy and tended to be
fragile.
Unrelated to their stability, but:
PulseAudio is also an example of where some misinformation did get
spread saying Alsa "could not" handle output from multiple applications >>>> and that PulseAudio was required for such a thing.
limitation, but in practice it appeared.
It appeared if your distro did not enable Alsa software mixing, which
was always a thing, but often not enabled in the default config the
distros deployed.
Could well be.
I might have to revisit that mess later this year...
Previously I've also described my contrary experience with writing
a Systemd service which cemented my opinion to stick with SysV Init.
On Thu, 31 Jul 2025 10:30:38 +0100, Nuno Silva wrote:
You keep insisting that everyone must buy into your opinion of systemd
being superior because you counted lines or because you personally find
systemd easier to write for or to maintain.
I can only describe my first-hand personal experience, after all.
On 2 Aug 2025 09:30:43 +1000, Computer Nerd Kev wrote:
Previously I've also described my contrary experience with writing
a Systemd service which cemented my opinion to stick with SysV Init.
Only one? I have done a few. All were less than a couple dozen lines.
How complicated was yours?
On 2025-07-29, Lawrence D'Oliveiro wrote:
This is a case of real-world experience. E.g.
<https://web.archive.org/web/20240711140744/https://list.waikato.ac.nz/archives/list/[email protected]/thread/BIAW7GY4KGPUGWIIRWNMBE5JSUVT2VWX/>
That just shows the same thing that we're seeing it here.
It doesn't show added complexity or difficulty with non-systemd.
It shows you claiming that the alternative posted there is worse than systemd, and trying to come up with excuses to claim so, in that case counting lines.
When you’re thinking about the manageability and security of
a whole system these are substantial advantages. If you’re one person adding one daemon the different might be small, if you’re doing it regularly (e.g. because you’re maintaining an OS) it’s quite a different matter.
I've found some good uses for systemd however
The firmware and boot chain start the computer. The init system
(sysvinit, systemd, etc) are responsible for managing services once it
has started.
But in terms of a relatively 'naive' user who just wants 'a desktop that works out of the box' by and large in many cases systemd has resulted in stuff that does *not* work straight out of the box.
There’s a couple of bugs in the sysvinit script at that link.
The systemd version doesn’t need anything like the helpers that the sysvinit version does. All that functionality is either built in
(e.g. logging) or irrelevant (no need to rely on pidfiles).
When you’re thinking about the manageability and security of a whole
system these are substantial advantages. If you’re one person adding
one daemon the different might be small, if you’re doing it
regularly (e.g. because you’re maintaining an OS) it’s quite a
different matter.
And that really is the issue. If you are setting up a machine - a big
machine - with multiple *custom* services to initiate, then the
effort to learn systemd is probably saved in terms of writing the
service definitions.
But in terms of a relatively 'naive' user who just wants 'a desktop
that works out of the box' by and large in many cases systemd has
resulted in stuff that does *not* work straight out of the box. And,
worse, trying to extract error logs from systemd is far more involved
to determine *why*.
In essence there are (at least) two different target audiences. But a Poeterring imposed 'one size that suits enterprise Linux is what you
should *all* be using' on the workstation, both for sophisticated and
naive users, is less than ideal.
I always mention postScript, X windows and systemd as examples of
stuff that really didn't work that great when first introduced, and
took a long time to get going bug free and was always - in the case of PostScript and X windows a huge amount of code that by and large *no
one ever used*.
The Natural Philosopher <[email protected]d> writes:
And that really is the issue. If you are setting up a machine - a big
machine - with multiple *custom* services to initiate, then the
effort to learn systemd is probably saved in terms of writing the
service definitions.
But in terms of a relatively 'naive' user who just wants 'a desktop
that works out of the box' by and large in many cases systemd has
resulted in stuff that does *not* work straight out of the box. And,
worse, trying to extract error logs from systemd is far more involved
to determine *why*.
In essence there are (at least) two different target audiences. But a
Poeterring imposed 'one size that suits enterprise Linux is what you
should *all* be using' on the workstation, both for sophisticated and
naive users, is less than ideal.
LP could only influence Red Hat’s Linux platforms (and I doubt he was
the only decision maker there, although I’ve no idea how RH operate internally). So I don’t really buy the ‘imposed’ narrative. Other platforms chose to adopt systemd, or in some cases not, according to
their own priorities.
Sometimes an OS can offer a choice between components. For example,
Debian includes at least a dozen desktop environments. Service
management is a bit more fundamental; it’s not necessarily impossible to support a choice, but it is more challenging, and for much less reward. It’s not surprising that most distributions have decided to pick one.
End users get to follow what their OS of choice does. If enough people
share the same priorities (and if at least some of them have appropriate skills and resources) then you end up with platforms following those priorities, and that does seem to have happened with systemd: https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd
I always mention postScript, X windows and systemd as examples of
stuff that really didn't work that great when first introduced, and
took a long time to get going bug free and was always - in the case of
PostScript and X windows a huge amount of code that by and large *no
one ever used*.
In the case of X11, my understanding is that the outcome of getting rid
of all that cruft is Wayland.
The Natural Philosopher <[email protected]d> writes:
On 03/08/2025 12:13, Richard Kettlewell wrote:
The Natural Philosopher <[email protected]d> writes:Indeed. It should be. It doesn't seem to be quite *there* yet though.
I always mention postScript, X windows and systemd as examples of
stuff that really didn't work that great when first introduced, and
took a long time to get going bug free and was always - in the case of >>>> PostScript and X windows a huge amount of code that by and large *no
one ever used*.
In the case of X11, my understanding is that the outcome of getting
rid of all that cruft is Wayland.
That was my impression too, although as it turns out I’m using Wayland daily and didn’t even know it, which is a promising sign.
Apropos of pure curiosity, how much less RAM does Wayland use?
On pure-Linux systems I still only have Xorg. The X11 display server
plus the window manager look like this:
PID RSS CMD
1113 400304 /usr/lib/xorg/Xorg :0 -seat seat0 [...]
1538 58992 marco
So ~459Mbyte RAM used.
I don’t have a pure Linux that uses Wayland, but WSL2 uses Wayland to display Linux graphical applications on the Windows desktop[1], and the
part that isn’t WSL2-specific looks like this:
PID RSS CMD
12 91972 /usr/bin/weston --backend=rdp-backend.so [...]
In Wayland terms this is a compositor, analogous to the combination of display server and window manager.
IN order to display X11 applications there is a also an X server in
WSL2, which renders to the Wayland display rather than directly to a
video card:
PID RSS CMD
25 66448 /usr/bin/Xwayland :0 -rootless -core [...]
So that’s ~158Mbyte, including support for X11 applications.
This may not be a very accurate comparison. The Xorg example is serving
a MATE desktop environment, the Wayland example is supporting a single
(X11) application just now; presumably it’ll use more RAM if it has more work to do.
Conversely Wayland here is using 60Mbyte just to support X11
applications, something that is presumably unnecessary in fully migrated environments.
[1] architectural overview at:
https://github.com/microsoft/wslg#wslg-architecture-overview
On 03/08/2025 12:13, Richard Kettlewell wrote:
The Natural Philosopher <[email protected]d> writes:Indeed. It should be. It doesn't seem to be quite *there* yet though.
I always mention postScript, X windows and systemd as examples of
stuff that really didn't work that great when first introduced, and
took a long time to get going bug free and was always - in the case of
PostScript and X windows a huge amount of code that by and large *no
one ever used*.
In the case of X11, my understanding is that the outcome of getting
rid of all that cruft is Wayland.
Apropos of pure curiosity, how much less RAM does Wayland use?
On 2025-08-05, Rich wrote:
Richard Kettlewell <[email protected]d> wrote:
Lawrence D'Oliveiro <[email protected]d> writes:
Richard Kettlewell wrote:
Bobbie Sellers <[email protected]> writes:
So you see that some functionality is missing from Wayland.
Some of that does look look missing functionality ...
There is a deliberate policy in the design of Wayland that applications >>>> shall neither know nor care about the positions of their windows on the >>>> screen, and possibly even their Z-order layering.
From [1] it looks like they’ve realized the trouble this superficially >>> rather bizarre policy causes and are walking it back.
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
Reading some of the history reveals an amazing arrogance and (to put
this into Eric Raymond terms) a very "Cathedral style" of development
mindset. We, the great and holy monks residing in the rareified air of
the holy Cathedral have decided that you, the lowly bazzar members, do
not need X, Y or Z, and so thou shall not be allowed to have X, Y or Z
in the new bazzar we are building for you to use on the other side of
the river.
Especially amazing is the back and forth of:
"please explain why you need this"
"explanation ..."
"that is not a valid explanation according to my personal secret
opinion of what makes an explanation valid"
"another explanation ..."
"that is not a valid explanation according to my personal secret
opinion of what makes an explanation valid"
"yet a third, very valid, explanation ..."
"that is not a valid explanation according to my personal secret
opinion of what makes an explanation valid"
and so on.
You can almost spot that pattern in this thread here too... sigh.
There *are* bullies in the Wayland crowd, what I don't know yet, because
I didn't check, is whether these are just outsiders, or if the problem behaviours arise from within the project too.
On Wed, 06 Aug 2025 09:03:36 +0100
Nuno Silva <[email protected]d> wrote:
Some X functionality was removed from Wayland by design to improve
security. There is no 'fix'.
That's a frequent argument, but is that indeed true?
All the missing features, even ones that have to be implemented by
other projects, are missing from the graphical system *because of
security*?
They seem to operate on some demented notion of "security" where GUI
windows exist in total isolation from everything else, even in the same
user session - where even something as basic as the size/layout of the screen(s) is Classified Information and windows will confine themselves
to their Designated Space and Refrain From Fraternizing even within the
same *application.*
It's utterly bizarre - I'd call it the mindset of a person who has
never used or wanted to use anything but tiling WMs, but that linked discussion thread even has developers of some tiling WMs chiming in
to complain that it's arbitrarily restrictive and weird.
Hilarious to watch them be all obstinate about how This Is By Design
and That Can't Be Done Because Security only to blink and back down sputtering once it became clear that their goal of getting everyone to
join them in "the Wayland world" wasn't gonna happen otherwise. Great
show, guys, you sure asserted your Fundamental Rightness real good!
Actually, quite a few people have complained about their use of a
graphical system not being compatible with Wayland. It's just that some bullies try hard to silence that and pretend such use cases don't exist.
They partially have a point. The X11 protocol is from the era of most isolated systems on local in building networks without general internet connectivity. Under X, any program can "screen shot" any other window, and/or listen in to the keystrokes being fed to the window with
keyboard focus.
Looked at in total isolation, this is a big security issue. Some
nefarious program could be spying on you right now, and you'd never
even know.
But what they fail to then consider is the simple fact that if you have
a nefarious program running on your personal computer that is being used
by you alone, well, then, just like locking the barn door *after* the
horse has escaped, the game is effectively lost at that point.
Rich <[email protected]d> writes:[...]
They partially have a point. The X11 protocol is from the era of most
isolated systems on local in building networks without general internet
connectivity. Under X, any program can "screen shot" any other window,
and/or listen in to the keystrokes being fed to the window with
keyboard focus.
Looked at in total isolation, this is a big security issue. Some
nefarious program could be spying on you right now, and you'd never
even know.
I know nothing about Wayland’s client isolation, but there is a general point to be made about this claim:
But what they fail to then consider is the simple fact that if you have
a nefarious program running on your personal computer that is being used
by you alone, well, then, just like locking the barn door *after* the
horse has escaped, the game is effectively lost at that point.
By that standard the game was lost decades ago and there’s no evidence available yet that it can be won. As a civilization, we’ve not yet
figured out how to ensure that the real computers that are actually
deployed run only non-malicious applications that contain no
vulnerabilities. Specific environments can go a long way towards that
goal but in general-purpose computing, the empirical outcome is that
it’s just not that simple.
On Wed, 6 Aug 2025 04:23:43 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:
It's truly bizarre - this kind of behavior makes perverse sense in
the world of proprietary software, where companies like MS or Apple
have a clear financial stake in locking users into their ecosystem,
but in the FOSS world it's just baffling.
It doesn’t happen in the FOSS world.
We've just been discussing it in the context of Wayland devs and their imperious You Don't Need That attitude towards things that have been
standard window-manager functionality in *every other extant GUI
environment* since approximately the Mesozoic era, which people have
been pointing out for an age and a half and which they're only just
backing down on after like a year of back-and-forth in which they've variously attempted to convince themselves that:
"It's Not Necessary!"
"Well, even if it *is* necessary, it's Not Possible!"
"Well, even if it *is* possible, it's Not Viable!"
"Well, even if it *is* viable, it [etc. etc.]"
Another fine example of this nonsense in the FOSS world would be GNOME
Team (You Don't Need...pretty much *any* of the stuff GNOME 2 gave you,
and you *do* want your desktop GUI to look and act halfway like a
tablet GUI,) among others.
On Wed, 6 Aug 2025 04:23:43 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:
It's truly bizarre - this kind of behavior makes perverse sense in
the world of proprietary software, where companies like MS or
Apple have a clear financial stake in locking users into their
ecosystem, but in the FOSS world it's just baffling.
It doesn’t happen in the FOSS world.
We've just been discussing it in the context of Wayland devs and their imperious You Don't Need That attitude towards things that have been
standard window-manager functionality in *every other extant GUI
environment* since approximately the Mesozoic era ...
They seem to operate on some demented notion of "security" where GUI
windows exist in total isolation from everything else, even in the same
user session ...
On 2025-08-06, Richard Kettlewell wrote:
By that standard the game was lost decades ago and there’s no
evidence available yet that it can be won. As a civilization, we’ve
not yet figured out how to ensure that the real computers that are
actually deployed run only non-malicious applications that contain no
vulnerabilities. Specific environments can go a long way towards that
goal but in general-purpose computing, the empirical outcome is that
it’s just not that simple.
I think we've figured (around 1936?) that there is *no* way to ensure
that in general-purpose computing? Or at least I suppose anything that
allows unlimited programs and relies on analysing them would be
reducible to the Entscheidungsproblem?
Yes and no, but none of what you cite has anything to do with the point
at issue, which is that every current GUI framework* _except_ Wayland provides the means for applications to do very basic things like size
and position their windows according to saved user preferences or find
out basic properties of the screen(s) for responsive layout purposes; meanwhile, Wayland (until just recently) has refused to implement such functionality, claiming that this is By Design and that Can't Be Done
without compromising security...
*However,* that does not make Wayland's rationale for hampering window- management functionality not patent nonsense. Providing applications
with basic information about screen layout and allowing them to size
and position windows automatically does *not* implicitly require
allowing them to scrape the contents of *other* applications' windows,
snoop global keyboard input, or anything of that nature.
John Ames <[email protected]> writes:
*However,* that does not make Wayland's rationale for hampering window-
management functionality not patent nonsense. Providing applications
with basic information about screen layout and allowing them to size
and position windows automatically does *not* implicitly require
allowing them to scrape the contents of *other* applications' windows,
snoop global keyboard input, or anything of that nature.
I think there is a legitimate risk here. If a bit of malware that looks
like your bank's website (as it would appear in a browser) manages to position itself directly over the window that really has your bank's
website at the point you're expecting to enter your credentials, you're
going to take a loss.
That doesn't require intercepting global input (just input focus), or scraping another window (what your bank's website looks like is public knowledge).
It does require some knowledge about window positions; control of its
own window position; and knowing what bank you're accessing and when
you're doing it (not trivial but I can think of a couple of approaches
that might be fruitful).
But it's one thing to provide a default behavior for don't-care cases
and quite another to completely disallow applications from specifying or
even hinting to the WM about relative positioning ...
As has already been pointed out, though, trying to solve "malware is
being tricksy and evil" by clapping *all* programs in irons is a real "barricading the barn door and hiding punji traps in the barnyard after
the cows have already gone" mindset.
If evil software is running on the local machine under a valid
user's session, the safeguards've *already failed* ...
On Thu, 7 Aug 2025 15:56:22 -0700, John Ames wrote:
If evil software is running on the local machine under a valid
user's session, the safeguards've *already failed* ...
Not necessarily that it’s actually running *on* there, but that it is accessing that display server.
Richard Kettlewell <[email protected]d> wrote:[...]
That doesn’t require intercepting global input (just input focus), or
scraping another window (what your bank’s website looks like is public
knowledge).
As has already been pointed out, though, trying to solve "malware is
being tricksy and evil" by clapping *all* programs in irons is a real "barricading the barn door and hiding punji traps in the barnyard
after the cows have already gone" mindset. If evil software is
running on the local machine under a valid user's session, the
safeguards've *already failed* - anything with that level of access
can snarf the entire $HOME and beam it right up to the mothership for analysis.
On Thu, 07 Aug 2025 23:14:04 +0100
Richard Kettlewell <[email protected]d> wrote:
As I’ve said before I’m not fully convinced by the Wayland design, but >> when it comes to _saved_ positions in particular, I think that very
much belongs in the window manager rather than the application, for
several related reasons.
Firstly, it’s functionality that basically every application needs;
making every application handle it explicitly is pointless duplication
of effort.
In the general case, I'd agree - window managers already handle this on
the regular for the majority of applications, usually present the user
with options for configuring the default placement/sizing strategy, and that's all well and good.
On Fri, 8 Aug 2025 04:18:26 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:
If you allow don’t-care cases to apps the user trusts, then all it
needs to bypass the do-care cases is to pretend to be an app that the
user trusts.
If that's a possibility, you've got a serious security failure on your
hands.
But if you *do,* the right thing is to fix the *actual* problem,
not to construct some Byzantine set of hypothetical safeguards ...
What we *have* been arguing over (since you've evidently lost track) is Wayland ...
And that rationale never made sense to begin with. If it were*ever*
the case that malicious actors could remotely induce a Wayland server
to display information and accept input on a user session, security would*already* be compromised, whether they could control window size/ position or not. The thing to do is design a system where that *can't
happen* - hobbling legit programs on the off chance that you might
slightly hamper some future burglar is just inane.
On 2025-08-03, rbowman wrote:
Some X functionality was removed from Wayland by design to improve
security. There is no 'fix'.
That's a frequent argument, but is that indeed true?
All the missing features, even ones that have to be implemented by other projects, are missing from the graphical system *because of security*?
On Wed, 06 Aug 2025 09:03:36 +0100
Nuno Silva <[email protected]d> wrote:
Some X functionality was removed from Wayland by design to improve
security. There is no 'fix'.
That's a frequent argument, but is that indeed true?
All the missing features, even ones that have to be implemented by
other projects, are missing from the graphical system *because of
security*?
They seem to operate on some demented notion of "security" where GUI
windows exist in total isolation from everything else, even in the same
user session
John Ames <[email protected]> wrote:
On Wed, 06 Aug 2025 09:03:36 +0100
Nuno Silva <[email protected]d> wrote:
Some X functionality was removed from Wayland by design to improve
security. There is no 'fix'.
That's a frequent argument, but is that indeed true?
All the missing features, even ones that have to be implemented by
other projects, are missing from the graphical system *because of
security*?
They seem to operate on some demented notion of "security" where GUI
windows exist in total isolation from everything else, even in the same
user session - where even something as basic as the size/layout of the
screen(s) is Classified Information and windows will confine themselves
to their Designated Space and Refrain From Fraternizing even within the
same *application.*
They partially have a point. The X11 protocol is from the era of most isolated systems on local in building networks without general internet connectivity. Under X, any program can "screen shot" any other window, and/or listen in to the keystrokes being fed to the window with
keyboard focus.
But what they fail to then consider is the simple fact that if you have
a nefarious program running on your personal compter that is being used
by you alone, well, then, just like locking the barn door *after* the
horse has escaped, the game is effectively lost at that point.
Yes and no, but none of what you cite has anything to do with the point
at issue, which is that every current GUI framework* _except_ Wayland provides the means for applications to do very basic things like size
and position their windows
according to saved user preferences
or find out basic properties of the screen(s) for responsive layout
purposes;
meanwhile, Wayland (until just recently) has refused to implement such functionality, claiming that this is By Design and that Can't Be Done
without compromising security...
On 08/08/2025 23:38, John Ames wrote:
And that rationale never made sense to begin with. If it were*ever*
the case that malicious actors could remotely induce a Wayland server
to display information and accept input on a user session, security
would*already* be compromised, whether they could control window size/
position or not. The thing to do is design a system where that *can't
happen* - hobbling legit programs on the off chance that you might
slightly hamper some future burglar is just inane.
Its the same logic that says you need to have locks on all your
cupboards in case someone breaks into the house...There is a slender
thread of logic, but not much,
Since the cupboards would all have the keys in them anyway if they were
in regular use...
On 08/08/2025 23:38, John Ames wrote:
And that rationale never made sense to begin with. If it were*ever* the
case that malicious actors could remotely induce a Wayland server to
display information and accept input on a user session, security
would*already* be compromised, whether they could control window size/
position or not. The thing to do is design a system where that *can't
happen* - hobbling legit programs on the off chance that you might
slightly hamper some future burglar is just inane.
Its the same logic that says you need to have locks on all your
cupboards in case someone breaks into the house...There is a slender
thread of logic, but not much,
Since the cupboards would all have the keys in them anyway if they were
in regular use...
Real-world example: A PPOE decided to improve after-hours security by requiring all entry and exit to be through only one of the several doors
in the building. Previously I could park by the door nearest to my
office for easy entry and exit. After the change, I had to walk the
length of the building on the outside to get to the designated door,
enter, then walk the length of the building inside to get to my office.
But here's the kicker: there were no locked doors internally - once you
were in (by any door) you had the run of the building.
Its the same logic that says you need to have locks on all your
cupboards in case someone breaks into the house...
In the US there are politicians that would prefer your firearms in locked cupboards if not removed from your hands completely.
On 09/08/2025 23:26, rbowman wrote:
In the US there are politicians that would prefer your firearms in locked
cupboards if not removed from your hands completely.
As is the case here.
Strangely people with guns do not regularly storm innocent households
Knives have been found just as good at killing people
--
Give me a fish and I will eat today.
Teach me to fish and I will eat forever.
The Natural Philosopher wrote this post while blinking in Morse code:
On 09/08/2025 23:26, rbowman wrote:
In the US there are politicians that would prefer your firearms in locked >>> cupboards if not removed from your hands completely.
As is the case here.
Strangely people with guns do not regularly storm innocent households
Knives have been found just as good at killing people
:-D
On 09/08/2025 23:26, rbowman wrote:
In the US there are politicians that would prefer your firearms in
locked cupboards if not removed from your hands completely.
As is the case here.
Strangely people with guns do not regularly storm innocent households
Knives have been found just as good at killing people
Strangely people with guns do not regularly storm innocent households
Knives have been found just as good at killing people
On Sun, 10 Aug 2025 10:15:52 +0100, The Natural Philosopher wrote:
On 09/08/2025 23:26, rbowman wrote:
In the US there are politicians that would prefer your firearms in
locked cupboards if not removed from your hands completely.
As is the case here.
Strangely people with guns do not regularly storm innocent households
Knives have been found just as good at killing people
I'm fond of knives and have enough lying around to open a cutlery store.
As I understand it my ECD would be frowned upon in the UK.
https://www.bladehq.com/item--Kershaw-Cryo-II-1556Ti--12693
Carrying a bit of history like my Fairbairn–Sykes would probably result in spending the rest of my life in gaol. Gods forbid I stick it into a
Muslim in the process of raping a young girl and though I suppose the European Convention on Human Rights precludes hanging even for a heinous
hate crime.
* (Can we just note for a minute how *weird* these people are about a
furshlugginer display server? Imagine how many freenix zealots would
shit themselves if they heard MS employees talking about getting
programs/people into "the WPF world" like they're lining up to drink
the Sacred Poison Wine and beam up to the Mothership.)
On 10/08/2025 21:06, rbowman wrote:
On Sun, 10 Aug 2025 10:15:52 +0100, The Natural Philosopher wrote:You might get by with that in the company of fishing rods or nets, but
On 09/08/2025 23:26, rbowman wrote:
In the US there are politicians that would prefer your firearms in
locked cupboards if not removed from your hands completely.
As is the case here.
Strangely people with guns do not regularly storm innocent households
Knives have been found just as good at killing people
I'm fond of knives and have enough lying around to open a cutlery
store.
As I understand it my ECD would be frowned upon in the UK.
https://www.bladehq.com/item--Kershaw-Cryo-II-1556Ti--12693
you would have a hard time explaining it in your pocket on a high
street.,
Carrying a bit of history like my Fairbairn–Sykes would probably result
in spending the rest of my life in gaol. Gods forbid I stick it into a
Muslim in the process of raping a young girl and though I suppose the
European Convention on Human Rights precludes hanging even for a
heinous hate crime.
If the gut is rapung a quick kick between teh legs is all you need.
But there are people out there who *do* want that, and who are you
(or the Wayland devs) to say they're wrong?
Which is exactly where the Wayland devs have found themselves -
their goal is to get everyone to join them in "the Wayland world,"*
But I thought *Metro* was supposed to be the Universal Good-For-What-
Ails-Ya Future Of Everything Forever...!
And if the user prefers a workflow based around saved window
configurations, as f'rexample the KiCad community does, I don't
think it's the place of display-server developers to decide for them
that You Don't Need That.
On 11 Aug 2025 21:06:16 GMT rbowman <[email protected]> wrote:
They tried. I heard they hired a coven of Wiccan witches to drive a
stake into the heart of WinForms and they failed. Then there was UWP.
"maybe if we rename it to MAUI they'll bite this time.' The Maui Wowie
doesn't seem to be rolling off the shelves either.
But I thought *Metro* was supposed to be the Universal Good-For-What-
Ails-Ya Future Of Everything Forever...! Man, all that effort put into Windows Phone support, wasted - well, at least I can support Windows 10 Mob...oh, wait...or, um, all those HoloLens devices everybody has...
On Mon, 11 Aug 2025 15:19:05 -0700, John Ames wrote:
But I thought *Metro* was supposed to be the Universal Good-For-What-
Ails-Ya Future Of Everything Forever...!
There you go. You were complaining about open-source folks supposedly
trying to impose some kind of UI uniformity on their users when they
were doing no such thing. And you completely missed the proprietary
companies who *were* indeed trying to do that.
On Mon, 11 Aug 2025 23:27:47 -0000 (UTC)linux_windowing_environment.html
Lawrence D'Oliveiro <[email protected]d> wrote:
I mentioned before how Blender has been offering that feature going
back years, decades. And the transition it made from X11 to Wayland has
been essentially seamless.
You've mentioned that repeatedly, yes - the only problem is that,
AFAICT, you're wrong. Per Blender's own documentation,* restoring saved window positions does not work under Wayland, on account of Wayland's developers deliberately choosing not to provide a mechanism for this.
*
https://docs.blender.org/manual/en/latest/getting_started/installing/
https://projects.blender.org/blender/blender/issues/98928
https://projects.blender.org/blender/blender/issues/113558
(I will concede that it's possible their documentation is wrong and
you're right, but as it's a known fact that Wayland has historically
declined to provide a mechanism for this and its developers have only recently backed down on that, it would not be my first guess.)
Maybe the KiCad folks could learn from that?
If Blender's own documentation is anything to go by, probably not!
On Mon, 11 Aug 2025 23:27:47 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:
I mentioned before how Blender has been offering that feature going
back years, decades. And the transition it made from X11 to Wayland has
been essentially seamless.
You've mentioned that repeatedly, yes - the only problem is that,
AFAICT, you're wrong. Per Blender's own documentation,* restoring saved window positions does not work under Wayland, on account of Wayland's developers deliberately choosing not to provide a mechanism for this.
Lawrence D'Oliveiro <[email protected]d> wrote:
Obviously Blender on Wayland has no control over the position of its
GUI relative to other applications’ windows, but I never cared about
that.
That's fine for you, but yet again you do not seem to understand that something not being important to *you, personally* does not mean that
*other people* don't care about it.
Which is sort of the crux of the whole thing, as the Wayland developers
also embody this sort of "I don't need XYZ, therefore nobody else does" thinking, and are learning the hard way that that kind of attitude is
mostly only gonna win converts from the set of people who *already*
think like them.
In Wayland, the answer is: the application communicates intent to the
display service and the display service decides on how to meet that
intent.
The application’s requirements are, normally, not that windows must be >positioned at specific locations, but rather than windows must be
positioned in a specific layout with respect to one another and
(perhaps) with respect to elements of the physical display.
Simple examples of this would be context menus and dialog boxes. The >application doesn’t care where they go as long as it’s somewhere >sensible. If the user wants to include their positioning beyond “they go >somewhere sensible”, they will want to make one global change, not >reconfigure every application.
Are we there yet? When my desktop switched from X11 to Wayland, I
hardly noticed.
I think the situation with Wayland is similar. They’re trying something novel, and are identifying requirements incrementally and interactively.
When it comes to the case of applications that want to arrange multiple windows in a coherent layout, they are somewhere in the middle of that process.
Sources:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 https://www.mail-archive.com/[email protected]/msg41606.html
https://canonical-mir.readthedocs-hosted.com/latest/explanation/window-positions-under-wayland/
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
It didn’t always look the same: anything that used SysV STREAMS had
to change to use sockets or /dev/ptmx or whatever, for example.
Are we there yet? When my desktop switched from X11 to Wayland, I hardly noticed.
Are we there yet? When my desktop switched from X11 to Wayland, I hardly noticed.
On 2025-08-13, Richard Kettlewell wrote:
I think the situation with Wayland is similar. They’re trying something
novel, and are identifying requirements incrementally and interactively.
When it comes to the case of applications that want to arrange multiple
windows in a coherent layout, they are somewhere in the middle of that
process.
From what has been said in this thread, the case might be that, sadly,
what they're doing is closer to bullying and ignoring requirements than
to identifying requirements.
Sources:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
https://www.mail-archive.com/[email protected]/msg41606.html
https://canonical-mir.readthedocs-hosted.com/latest/explanation/window-positions-under-wayland/
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
Nuno Silva <[email protected]d> writes:
On 2025-08-13, Richard Kettlewell wrote:
I think the situation with Wayland is similar. They’re trying something >>> novel, and are identifying requirements incrementally and interactively. >>> When it comes to the case of applications that want to arrange multiple
windows in a coherent layout, they are somewhere in the middle of that
process.
From what has been said in this thread, the case might be that, sadly,
what they're doing is closer to bullying and ignoring requirements than
to identifying requirements.
That’s not the impression I get from primary sources, but by all means
rely on the peanut gallery instead.
Sources:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
https://www.mail-archive.com/[email protected]/msg41606.html
https://canonical-mir.readthedocs-hosted.com/latest/explanation/window-positions-under-wayland/
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
Marc Haber <[email protected]> writes:
Are we there yet? When my desktop switched from X11 to Wayland, I
hardly noticed.
For you, apparently yes; for some others, apparently not. Debian trixie
is still giving me Xorg at present.
On Wed, 13 Aug 2025 21:32:47 +0200, Marc Haber wrote:
Are we there yet? When my desktop switched from X11 to Wayland, I hardly
noticed.
I switched my laptop first, before following suit with my other machines. >Then, after a Debian Unstable upgrade a few months ago, Wayland logins on
my laptop stopped working, and I had to go back to X11 for a while.
I eventually figured out the problem was connected in some way to the
display manager I was using: when I took out lightdm and switched to sddm, >Wayland logins worked again.
On 2025-08-14, Richard Kettlewell wrote:
Nuno Silva <[email protected]d> writes:
On 2025-08-13, Richard Kettlewell wrote:
I think the situation with Wayland is similar. They’re trying
something novel, and are identifying requirements incrementally and
interactively. When it comes to the case of applications that want
to arrange multiple windows in a coherent layout, they are
somewhere in the middle of that process.
From what has been said in this thread, the case might be that,
sadly, what they're doing is closer to bullying and ignoring
requirements than to identifying requirements.
That’s not the impression I get from primary sources, but by all
means rely on the peanut gallery instead.
Yeah, to be clear: I'm not claiming I saw that *myself* from Wayland developers. The only thing I've witnessed was bullying from people in
the fediverse, who may have nothing to do with the actual project.
I was just bringing that up, given that your post did not mention it at
all, if I've read it correctly (I read it last night, and I tend to
avoid caffeine before sleep, so it *is* possible I've overlooked
something).
Sources:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
https://www.mail-archive.com/[email protected]/msg41606.html
https://canonical-mir.readthedocs-hosted.com/latest/explanation/window-positions-under-wayland/
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
(I didn't read these sources (yet?), but I've kept these in my reply
because it seemed to me that these should be present.)
Richard Kettlewell <[email protected]d> wrote:
Marc Haber <[email protected]> writes:
Are we there yet? When my desktop switched from X11 to Wayland, I
hardly noticed.
For you, apparently yes; for some others, apparently not. Debian trixie
is still giving me Xorg at present.
Does it still give Xorg on a new install? I think you may have to
switch manually if you upgrade.
On 2025-08-13, Richard Kettlewell wrote:
[...]
I think the situation with Wayland is similar. They’re trying something
novel, and are identifying requirements incrementally and interactively.
When it comes to the case of applications that want to arrange multiple
windows in a coherent layout, they are somewhere in the middle of that
process.
From what has been said in this thread, the case might be that, sadly,
what they're doing is closer to bullying and ignoring requirements than
to identifying requirements.
If that is accurate, then it surely won't a good environment to
update/enrich requirements and use cases.
Sources:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
https://www.mail-archive.com/[email protected]/msg41606.html
https://canonical-mir.readthedocs-hosted.com/latest/explanation/window-positions-under-wayland/
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
Richard Kettlewell <[email protected]d> wrote:
In Wayland, the answer is: the application communicates intent to the
display service and the display service decides on how to meet that
intent.
The application’s requirements are, normally, not that windows must be
positioned at specific locations, but rather than windows must be
positioned in a specific layout with respect to one another and
(perhaps) with respect to elements of the physical display.
Simple examples of this would be context menus and dialog boxes. The
application doesn’t care where they go as long as it’s somewhere
sensible. If the user wants to include their positioning beyond “they go >> somewhere sensible”, they will want to make one global change, not
reconfigure every application.
Are we there yet? When my desktop switched from X11 to Wayland, I
hardly noticed.
Greetings
Marc
John Ames <[email protected]> writes:
Lawrence D'Oliveiro <[email protected]d> wrote:
Obviously Blender on Wayland has no control over the position of its
GUI relative to other applications’ windows, but I never cared about
that.
That's fine for you, but yet again you do not seem to understand that
something not being important to *you, personally* does not mean that
*other people* don't care about it.
Which is sort of the crux of the whole thing, as the Wayland developers
also embody this sort of "I don't need XYZ, therefore nobody else does"
thinking, and are learning the hard way that that kind of attitude is
mostly only gonna win converts from the set of people who *already*
think like them.
Having read around the subject a bit, it’s a lot more complicated than that.
If you’re attached to a narrow set of requirements, and either think
that only your favorite requirements need to be satisfied, or
alternatively just want to crow about someone being forced to take your favorite requirements seriously, don’t bother reading on, just keep
arguing with each other.
Otherwise...
The question is where decisions are made about window placement, and how
that is negotiated between an application and a display service. (The application and the display service are most likely both component-based systems; they might each be more than one process; the various bits
might not all be on the same physical machine, etc.)
In Wayland, the answer is: the application communicates intent to the
display service and the display service decides on how to meet that
intent.
The application’s requirements are, normally, not that windows must be positioned at specific locations, but rather than windows must be
positioned in a specific layout with respect to one another and
(perhaps) with respect to elements of the physical display.
Simple examples of this would be context menus and dialog boxes. The application doesn’t care where they go as long as it’s somewhere sensible. If the user wants to include their positioning beyond “they go somewhere sensible”, they will want to make one global change, not reconfigure every application.
Another example is for windows to be in the same place they were last
time the application ran, support for which was added a few years ago.
The Wayland design seems to be that the application tells the display
server what it’s trying to achieve, and the display server figures out where to put windows in order both to satisfy this and to satisfy any user-level preferences.
The other issue is that left to themselves, applications get it
wrong. Examples cited include application positioning their windows off-screen, or wrongly estimating the size of frames so that
window-level controls are obscured, or mishandling changes to monitor
layout and resolution, or ignoring desktop-wide conventions (e.g. a
tiling window manager).
The conclusion Wayland seems to have reached from these two things that
is that since applications shouldn’t need to control absolute positions, and since when they do try to control absolute positions they get it
wrong, the ability to set absolute positions is not available.
What this means is that the protocol needs to include support for each realistic set of application goals. Almost everything has context menus, dialog boxes, etc so they were in from relatively early. Persistence of positions across session restarts came later. Applications trying to do something more complex aren’t there yet.
A comparison could be drawn with the early days of Linux. In my first
job a lot of our code started life on SunOS, UnixWare and possibly even
older things. As time progressed more of it migrated to Linux, and
sometimes I ran into things that just weren’t there in Linux and had to work around them.
This was mildly annoying, certainly, but nobody concluded from this
either that the things missing from Linux weren’t needed, nor that Linux was deliberately ignoring particular requirements, and when Linux moved forward nobody thought it had conceded after some kind of fight.
Rather, everybody knew it was a work in progress and that missing functionality would turn up sooner or later, in some form. It didn’t
always look the same: anything that used SysV STREAMS had to change to
use sockets or /dev/ptmx or whatever, for example.
In a very distributed fashion, the Linux world was empirically searching
out the requirements imposed on Linux by the applications people wanted
to run on it, and sometimes taking the opportunity to improve on the
state of the art as they did so. I’m quite glad not to have had to deal with STREAMS for a few decades...
I think the situation with Wayland is similar. They’re trying something novel, and are identifying requirements incrementally and interactively.
When it comes to the case of applications that want to arrange multiple windows in a coherent layout, they are somewhere in the middle of that process.
Sources:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 https://www.mail-archive.com/[email protected]/msg41606.html
https://canonical-mir.readthedocs-hosted.com/latest/explanation/window-positions-under-wayland/
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
On Tue, 12 Aug 2025 23:29:04 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:
Obviously Blender on Wayland has no control over the position of its
GUI relative to other applications’ windows, but I never cared about
that.
That's fine for you, but yet again you do not seem to understand that something not being important to *you, personally* does not mean that
*other people* don't care about it.
KiCad could do something similar to this.
They could, yes. They could pour developer hours into re-engineering
their entire layout/workflow and force their userbase on *every other platform* (including Linux under X11) to adapt to the new way of doing things, all for the sake of aligning with the design philosophy of a
minority of a minority of their userbase.
Sure! Makes sense to *me!*
My guess is that it will depend largely on what you are running on it.
I believe I am still running X.
I believe I am still running X.
On 13/08/2025 20:32, Marc Haber wrote:
Richard Kettlewell <[email protected]d> wrote:My guess is that it will depend largely on what you are running on it.
In Wayland, the answer is: the application communicates intent to the
display service and the display service decides on how to meet that
intent.
The application’s requirements are, normally, not that windows must be >>> positioned at specific locations, but rather than windows must be
positioned in a specific layout with respect to one another and
(perhaps) with respect to elements of the physical display.
Simple examples of this would be context menus and dialog boxes. The
application doesn’t care where they go as long as it’s somewhere
sensible. If the user wants to include their positioning beyond “they
go somewhere sensible”, they will want to make one global change, not
reconfigure every application.
Are we there yet? When my desktop switched from X11 to Wayland, I
hardly noticed.
I believe I am still running X.
On 14/08/2025 00:16, Nuno Silva wrote:
On 2025-08-13, Richard Kettlewell wrote:
I think the situation with Wayland is similar. They’re trying
something novel, and are identifying requirements incrementally and
interactively. When it comes to the case of applications that want
to arrange multiple windows in a coherent layout, they are somewhere
in the middle of that process.
From what has been said in this thread, the case might be that,
sadly, what they're doing is closer to bullying and ignoring
requirements than to identifying requirements.
No one likes being told what to do by a user when you are programming,
or a programmer when you are a user.
A little give and take helps. As does some management.
On Thu, 14 Aug 2025 13:04:28 +0100, The Natural Philosopher <[email protected]d> wrote in <107kjcc$d4vh$[email protected]>:
On 13/08/2025 20:32, Marc Haber wrote:
Richard Kettlewell <[email protected]d> wrote:My guess is that it will depend largely on what you are running on it.
In Wayland, the answer is: the application communicates intent to the
display service and the display service decides on how to meet that
intent.
The application’s requirements are, normally, not that windows must be >>>> positioned at specific locations, but rather than windows must be
positioned in a specific layout with respect to one another and
(perhaps) with respect to elements of the physical display.
Simple examples of this would be context menus and dialog boxes. The
application doesn’t care where they go as long as it’s somewhere
sensible. If the user wants to include their positioning beyond “they >>>> go somewhere sensible”, they will want to make one global change, not >>>> reconfigure every application.
Are we there yet? When my desktop switched from X11 to Wayland, I
hardly noticed.
I believe I am still running X.
$ echo $XDG_SESSION_TYPE
x11
Running XFCE here -- it's just now starting to have Wayland support,
thanks to another library that should allow quite a few traditional
window managers to gain Wayland chops.
I'm in no hurry, I already get 4K @ 120fps in Elite Dangerous...wondering
how obs-studio will act in Wayland, glad that X11 is still an option.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 07:14:17 |
| Calls: | 12,100 |
| Calls today: | 8 |
| Files: | 15,003 |
| Messages: | 6,517,930 |
| Posted today: | 1 |