Re: [dev] Wayland compositors

[Hadrien Lacour]

On Wed, Sep 08, 2021 at 08:35:33PM +0200, Laslo Hunhold wrote:
> On Tue, 31 Aug 2021 14:28:29 +0100
> Nick  wrote:
>
> Dear Nick,
>
> > Any thoughts, experiences, recommendations?
>
> the discussion has been very fruitful. Let me share my thoughts.
>
> Wayland the protocol is actually rather simple. It's a very thin
> messaging layer between a compositor and clients, nothing more.
> But this is exactly the problem: It's too thin and the
> Wayland-developers didn't dare to go beyond a minimal set of things.
>
This, it would have been a great goal to modularize X11 and keep the worthy
parts, not just reduce it to an exercise in "minimalism" (and complete lack of
portability) and expect the free FOSS market to magically solve the remainder.

> All of the things that are breaking are those based on
> (compositor-specific) Wayland-extensions which add functionality you'd
> expect (gamma control, screen sharing, etc. etc.). I will never forgive
> the Wayland-developers for their lack of courage.
>
> We're talking about the next generation of display/window managers, and
> they messed it up so badly! Just a few things that come to mind:
>
>- network transparency is a _good_ thing and was thrown away way too
>  easily. I like being able to run GUI-applications from time to
>  time via ssh. Most of the time they are just basic
>  GUI-framework-programs you could "stream" very efficiently, but if
>  you're talking about composited surfaces, I would expect Wayland
>  to do that for me too, via a compressed stream or something.
>  It's trivial to stream Ful-HD-Video P2P using modern compression
>  algorithms, why wasn't this taken into consideration?
>  People are always talking about moving away from the single
>  computer and into the "orbit" (see Urbit, etc.). Today's
>  technology makes it possible to be much more flexible in this
>  regard.
>- color management was totally ignored. This could've been a strong
>  point for Wayland, but instead they made it even worse than in X,
>  which is actually a difficult feat. We need to move away from the
>  sRGB-monoculture, especially because it's not bloaty to actually
>  support proper colour management and it has tangible benefits.
>- everything about Wayland is hacky and deeply integrated into
>  Linux, but what for? To get "perfect frames", as it is often said?
>  This could've been done so much better, for example by going
>  vector-first. Most stuff in a GUI can easily be represented by
>  vector-data, which is very sparse. You do have bitmap-surfaces
>  from time to time (video player, browser, games, etc.), but it
>  would've been a very interesting and radical approach. The
>  advantage of this is that you don't need to think about dpi and
>  other shit except in those bitmap surfaces. All the rasterization
>  would be the last step and not intrinsic to the protocol itself,
>  but just the compositor.
>
> Anyway, to sum it up: Probably nobody here is really a fan of X, but
> it's what we have. Wayland is an underwhelming mess and they really
> dropped the ball here. The mix of (often incompatible and competing)
> extensions that are made up and forced upon us (while leading to more
> and more userspace-applications relying on them and unexpectedly
> breaking in vanilla Wayland-compositors that don't want to be tainted
> with the garden-variety of extensions) is just horrible.
>
> I used to have enthusiasm about Wayland, but now this feeling has
> completely been replaced with pity. They really dropped the ball on
> this one and I will not waste any more time with it.
>
> With best regards
>
> Laslo
>
A good rant. Let me add my biggest problem: global keyboard grabbing isn't
possible unless done by the compositor, so something like bspwm+sxhkd doesn't
look possible right now.

Re: [dev] Wayland compositors

[Laslo Hunhold]

On Tue, 31 Aug 2021 14:28:29 +0100
Nick  wrote:

Dear Nick,

> Any thoughts, experiences, recommendations?

the discussion has been very fruitful. Let me share my thoughts.

Wayland the protocol is actually rather simple. It's a very thin
messaging layer between a compositor and clients, nothing more.
But this is exactly the problem: It's too thin and the
Wayland-developers didn't dare to go beyond a minimal set of things.

All of the things that are breaking are those based on
(compositor-specific) Wayland-extensions which add functionality you'd
expect (gamma control, screen sharing, etc. etc.). I will never forgive
the Wayland-developers for their lack of courage.

We're talking about the next generation of display/window managers, and
they messed it up so badly! Just a few things that come to mind:

   - network transparency is a _good_ thing and was thrown away way too
 easily. I like being able to run GUI-applications from time to
 time via ssh. Most of the time they are just basic
 GUI-framework-programs you could "stream" very efficiently, but if
 you're talking about composited surfaces, I would expect Wayland
 to do that for me too, via a compressed stream or something.
 It's trivial to stream Ful-HD-Video P2P using modern compression
 algorithms, why wasn't this taken into consideration?
 People are always talking about moving away from the single
 computer and into the "orbit" (see Urbit, etc.). Today's
 technology makes it possible to be much more flexible in this
 regard.
   - color management was totally ignored. This could've been a strong
 point for Wayland, but instead they made it even worse than in X,
 which is actually a difficult feat. We need to move away from the
 sRGB-monoculture, especially because it's not bloaty to actually
 support proper colour management and it has tangible benefits.
   - everything about Wayland is hacky and deeply integrated into
 Linux, but what for? To get "perfect frames", as it is often said?
 This could've been done so much better, for example by going
 vector-first. Most stuff in a GUI can easily be represented by
 vector-data, which is very sparse. You do have bitmap-surfaces
 from time to time (video player, browser, games, etc.), but it
 would've been a very interesting and radical approach. The
 advantage of this is that you don't need to think about dpi and
 other shit except in those bitmap surfaces. All the rasterization
 would be the last step and not intrinsic to the protocol itself,
 but just the compositor.

Anyway, to sum it up: Probably nobody here is really a fan of X, but
it's what we have. Wayland is an underwhelming mess and they really
dropped the ball here. The mix of (often incompatible and competing)
extensions that are made up and forced upon us (while leading to more
and more userspace-applications relying on them and unexpectedly
breaking in vanilla Wayland-compositors that don't want to be tainted
with the garden-variety of extensions) is just horrible.

I used to have enthusiasm about Wayland, but now this feeling has
completely been replaced with pity. They really dropped the ball on
this one and I will not waste any more time with it.

With best regards

Laslo

Re: [dev] Wayland compositors

[Tobias Bengfort]

Hi Nick,

thanks for sharing dwl. I started writing some patches and it really 
feels very close to dwm. Not fully there yet, but close.


also: don't feed the trolls

tobias

Re: [dev] Wayland compositors

[Nick]

Quoth Страхиња Радић:
> On 21/09/08 01:36, Nick wrote:
> > The fact that the Jitsi devs closed 
> > the bug as "not much we can do on our side" doesn't mean "wayland 
> > broke it and we can't fix it".
> 
> It's exactly the same thing.

In this instance it isn't, maybe I should have been more verbose.  
The issue was with web browser support for wayland screen sharing 
stuff, so Jitsi couldn't fix it theirselves, but it is now well 
integrated and supported in browsers, and therefore by extension 
Jitsi.

> The issues listed show a pattern and the impact of breaking with a
> long-standing, time-tested tradition just for the sake of doing something 
> "new"
> and "different". "New" doesn't automatically mean "good".

True, this is clearly a case where the majority of X developers 
decided it was worth the pain of starting again with a fresh design.  
There are pros and cons to that. In this case I think it sounds like 
it's worth it, as the end result should be a cleaner system with 
less code and more reliability, and I'm happy to pay the short term 
cost of changing some programs I use and learning how to do things 
differently in some cases. Obviously for some people the costs will 
be different, and the benefits don't seem worth it.

It's frustrating to feel like you have so little agency over the 
direction of such decisions - that's one of the things that attracts 
lots of us to suckless - but to some extent that's inevitable with 
large projects like this. As you say, I have little doubt that X 
will continue to receive some attention and support for a long time 
to come, even if not so much from the current core team.

> You haven't mentioned the other points, just some of the major ones being the
> issue of non-GNOME desktop environments, for example KDE. I'm not using KDE, 
> but
> why just erase it in favor of GNOME monopoly? I'm using no desktop 
> environment,
> I'm using dwm, but many of its key features are not supported by Wayland. 

>From what I could see on that list, the KDE and XFCE issues 
mentioned are all things which are being worked on or have already 
been addressed by those projects. I don't really see how Wayland is 
leading to a GNOME monopoly, there are plenty of other compositors 
out there with more on the way.

I'm going to bow out of this conversation now, lest it become even 
more interminable for everyone else! But thanks for sharing your 
opinions and thoughts about it, it's (almost) always good to be 
challenged, even if it doesn't result in minds being changed :)

Nick

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/09/08 01:36, Nick wrote:
> The fact that the Jitsi devs closed 
> the bug as "not much we can do on our side" doesn't mean "wayland 
> broke it and we can't fix it".

It's exactly the same thing.

> the screen recording / sharing stuff - it works differently on 
> Wayland (for not-bad reasons),
[...]
> good reasons (thinking of the "prevents GUI applications from 
> running as root" and "breaks windows rasing/activating themselves").

The issues listed show a pattern and the impact of breaking with a
long-standing, time-tested tradition just for the sake of doing something "new"
and "different". "New" doesn't automatically mean "good".

They also show the attitude of the developers responsible for Wayland. I don't
like it when the "developers" tell the users what is good for them, especially
when they are being opinionated and stubborn for no reason at all.  Let the
users decide how they are using the software. Let us be able to make mistakes! 

It is the same line of thought as when we compare C to a language like Rust. One
of the key reasons why C is better than Rust and similar overprotecting
opinionated languages, is because it gives user the freedom to do whatever he
wants, mistakes included. In this, C is closer to machine language, and thus
more powerful, more expressive, allowing finer control.

Similar thing to Wayland happened with systemd, the developers responsible for
it were acting unreasonably and immaturely when confronted with different
opinions. Whenever one lacks civility in communication and resorts to
swearwords, that shows faulty of his cause and a weakness of his conviction.

You haven't mentioned the other points, just some of the major ones being the
issue of non-GNOME desktop environments, for example KDE. I'm not using KDE, but
why just erase it in favor of GNOME monopoly? I'm using no desktop environment,
I'm using dwm, but many of its key features are not supported by Wayland. 

Again and finally, I don't want to have to change my software-using habits just
because some "developer's" decision. I want to choose what software I use and
how. Thankfully, there are free licenses, and no free software is ever truly
"dead". If Wayland becomes enforced like systemd, in time there will be a
solution comparable to runit/OpenRC/s6.



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Nick]

Quoth Страхиња Радић:
> On 21/09/08 12:28, Nick wrote:
> > honest I found the arguments made there to be largely unconvincing, 
> 
> Any argument in particular and why?

A lot of the "Wayland breaks" examples don't seem to be fairly 
reporting on the actual issues. The jitsi screen sharing issue, for 
example, has reports that it works fine for fedora, but it's just 
the case that (at least when the bug was being discussed, over a 
year ago), the integration of xda-desktop-portal into the system of 
some users hadn't happened yet. The fact that the Jitsi devs closed 
the bug as "not much we can do on our side" doesn't mean "wayland 
broke it and we can't fix it". The same is true of at least most of 
the screen recording / sharing stuff - it works differently on 
Wayland (for not-bad reasons), so some software is redundant, and 
others needed to be updated to use new APIs, and unsurprisingly the 
proprietary crap is the last to be updated. But ultimately, the 
important tasks represented (screen sharing & screen recording) do 
work fine under wayland.

The other headings are less important, I'd say, and seem to either 
fall under same answer as above (for which the answer is often just 
to use different tools that are built for wayland), or non-terrible 
side effects things that are intentionally done differently, for 
good reasons (thinking of the "prevents GUI applications from 
running as root" and "breaks windows rasing/activating themselves").

That's my reading of that gist, anyway.

Re: [dev] Wayland compositors

[Страхиња Радић]

By the way, here's another article not on Github (but linked from that page):

https://tildearrow.org/?p=post=2=2021=antihs



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Страхиња Радић]

On 21/09/08 12:28, Nick wrote:
> honest I found the arguments made there to be largely unconvincing, 

Any argument in particular and why?

> * I'm thinking in particular of the repeated "emojis broke my st" 
>   mails, caused by a bug in Xft that noone upstream seems to care much
>   about fixing, and the fact that surf is a really just a nice
>   interface atop the hulking edifice of webkit2/gtk+

This is the fault of X developers, who decided to dedicate their time entirely
to Wayland. In their eyes, Wayland is the continuation of X.Org.

It is clear by now that Wayland is influenced by big corporations, RedHat in
particular, which is also forcing things like GNOME, systemd and Rust in the
Linux kernel upon the users.

Wayland sucks. X.Org sucks too, but it is still much better than Wayland.



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

[Nick]

Hi Maarten et al,

Many thanks for your replies, this was very handy to read.  
Interesting to hear that sxmo is moving in the wayland direction, 
too. I haven't managed to get around to actually trying wayland yet, 
as as ever my attention has been pulled in too many different 
directions. But I'll get there.

Thanks to Страхиња Радић, too, for the link to the "wayland is bad" 
github gist. The idea that a github gist is the place for such 
discussion is funny to me, given that github's model and interface 
is hardly suckless, but hey ho, such is modern internet life. To be 
honest I found the arguments made there to be largely unconvincing, 
and while the idea that compositing is not separated from window 
management certainly seems dodgy on first reading, the wayland way 
seems much nicer than X to my eyes. I'm reading the Wayland book at 
the moment , so soon my opinion will be 
better informed - don't take my words too seriously on the matter 
for now.

The issue with suckless software depending on sucky libraries 
outside of their direct control is an enduring one* with no easy 
fixes, but it looks to me like the move away from X should go some 
way to (hopefully) more solid foundations to build on in the future.  
I'm an optimist, in this way.

Anyway, thanks again for all your thoughts.

Nick

* I'm thinking in particular of the repeated "emojis broke my st" 
  mails, caused by a bug in Xft that noone upstream seems to care much
  about fixing, and the fact that surf is a really just a nice
  interface atop the hulking edifice of webkit2/gtk+

Re: [dev] Automatic C header dependency tracking for the redo build-system

[Sergey Matveev]

*** Thomas Oltmann [2021-09-07 23:15]:
>Nevertheless, these are some of the reasons I care about redo, in no
>particular order: [...]

Good points I support too! Also:

* The whole redo build system description/rules fits on single screen,
  like here: http://www.goredo.cypherpunks.ru/Usage-rules.html
  Compare it to NetBSD bmake (used in FreeBSD) or GNU Make, having an
  unbelievable size. redo does not even force you to use shell in
  anyway -- you can use whatever language you wish for
* mtime, used in Make, won't work in practice for many possible reasons:
  https://apenwarr.ca/log/20181113. Make does not give any atomicity in
  builds. It hard to parallelize and all of us know how often many
  software can be built only sequentially (however it is related
  directly to "recursive make considered harfmful"
  http://www.stargrave.org/recursive_make.pdf).
  Basically, Make just does not work (reliably)

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: [dev] Automatic C header dependency tracking for the redo build-system

[Sergey Matveev]

*** Thomas Oltmann [2021-09-07 22:57]:
>For example, it is also able to properly recognize: [...]

I see, thanks!

However personally in C-projects I use https://include-what-you-use.org/
and h-extract.pl script to make depends only on local headers:

whatever.do:
[...]
redo-ifchange `./h-extract.pl $src`

h-extract.pl:
#!/usr/bin/env perl
# Extract all locally included header files (not <>-ones, but "")

# hack, to badly exit if there is unexistent file
$SIG{__WARN__} = sub { die @_ };

map { $inc{$_} = 1 } @ARGV;
while (<>) {
/^#include "([^\/]+)"$/ and ($1 !~ /\.in$/) and $inc{$1} = 1;
};
print join " ", sort keys %inc;

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF