Misc. BSD/UNIX X11/X.Org: The beginning of the end

[blackhole]

https://www.openbsd.org/papers/eurob...nd-openbsd.pdf

I'm not sold on it. I'm suspicious of anything so Linux centric, which is a freedesktop.org project and which is heavily backed by Red Hat and the likes of gnome project. We're all aware of the problems with X11 - but it got us here... and I'm still not sure this is the solution, just as systemd was not the solution to Linux's perceived init problem - it was just a corporate coup.

[e1-531g]

Originally Posted by blackhole

https://www.openbsd.org/papers/eurob...nd-openbsd.pdf

I'm not sold on it. I'm suspicious of anything so Linux centric, which is a freedesktop.org project and which is heavily backed by Red Hat and the likes of gnome project. We're all aware of the problems with X11 - but it got us here... and I'm still not sure this is the solution, just as systemd was not the solution to Linux's perceived init problem - it was just a corporate coup.

I'm not sold on lumping systemd and Wayland together.

Thanks for link to PDF Interesting read

[sacerdos_daemonis]

Originally Posted by e1-531g

I'm not sold on lumping systemd and Wayland together.

Perhaps not together, but systemd, wayland and pulse audio are related. They are all solutions for problems that did not exist. They are parts of a drive to "modernise" the OS according to the beliefs of a few corporate "experts". So lumping them together can be reasonable argued.

[Head_on_a_Stick]

I use Wayland (sway) in Alpine Linux and that is fundamentally incompatible with systemd because of the musl libc base.

There is absolutely no need to use systemd along with Wayland.

[e1-531g]

LXQt Desktop Now "100%" Ready For Wayland
https://www.phoronix.com/news/LXQt-Fully-Ready-Wayland

Once merged, that pull request closes this issue tracker over full Wayland support for the LXQt desktop.
2024 is certainly looking like the year of the Wayland desktop on Linux systems.

[e1-531g]

Haters gonna hate
wayland 1.22.91

This is the alpha release for Wayland 1.23.
Besides numerous bugfixes and protocol clarifications, Wayland 1.23 includes
the following new features:

- OpenBSD support

[thirdm]

This is just the scanner code that generates libraries on either side of the protocol channel. It's not a very big part of what's needed to have a wayland display server and compatible clients.

Seems like on BSDs (OpenBSD maybe less than the one I use?) there's still quite a few years before I have to worry about what compositor, if any, I'd like to run or discarding my efforts on a private twm fork.

Any sense of whether a less than stellar programmer could ever hope to learn enough to write a compositor? I'm a bit discouraged by seeing various people start and stall, e.g. ... https://github.com/malcolmstill/ulubis Granted he's put in way more features there than I would take on.

I'm sure BSDs will get it via Gnome and Plasma, or maybe I'll end up liking sway, but I'd like to do my own thing if possible, eventually, or at least trundle along in hobby style with some hope of using it along the way.

Also this openbsd page mentioning shims for udev and libinput, that's not encouraging is it? https://xenocara.org/Wayland_on_Open...ore-work-to-do Yeah, nothing to do with the init system that shall not be named but myself I don't mind that half as much as udevd. That thing has caused me no end of headaches at work.

And this idea that it's a protocol definition with many potential implementations, unlike X, well that seems off. X11 also has a protocol definition and there were/are in theory multiple implementations: "Any software or hardware that correctly interprets the X Window System protocol is a true X implementation." -- Oliver Jones, Intro to The X Window System. You might say that defacto X now is more than that, but seemingly so is defacto Wayland to some degree now if efforts to support it have these Linux shims.

This idea makes me think of the talk around Perl 6 (now Raku) vs. Perl 5. Perhaps it's good anyway but with all the talk of a spec with multiple implementations à la C for Perl 6 what ended up actually happening was that pretty much all the ones except Rakudo fell away for lack of critical mass. I'm wondering how many choices we'll end up with for compositors. X window managers have this advantage that you only have to make this client that handles certain messages, etc. You don't have to implement a whole friggin display server. Hence there are oodles of window managers. Libraries like wlroots the solution? But how big is that API and how many things must you implement compared to what sommatt like cwm does?

Not hate but trepidation for me. Although this looks kind of interesting: https://sr.ht/~shunter/wayflan/