I mean, at least with web browsers they usually converge on a common spec eventually, and most of the time you just have a bit stupid repetition in your CSS for a bit. Wayland compositors seem to be actively against this kind of process.
Well, you are not really forced to write a compositor these days as there are libraries that do all the heavy lifting for you.
Check out Louvre for example. Or Smithay if you like Rust. And if you want a bit more depth, there is wlroots of course (or the hyprland version). It is not really any harder than writing an X11 WM.
Yeah, no I have my own wm in Ruby that is fewer lines of code than a typical Wayland Hello World, and that does what I want. I have no reason to want to throw that away for something that doesn't offer me any features I care about, and removes features I do. Such as the ability to just restart my wm if I make a change to it without affecting my current session at all.
Unless you can show me a solution that lets me replace my tiling and floating wm in ca 1500 lines of Ruby, and will let me restart without restarting my session, what you're offering me is inferior to what I have with X
wlroots and smithay (I'm not familiar with louvre) do a lot of the difficult work for you, that most compositors will do without much variation but there's still a lot that compositor writers still have to do. It's still a significantly larger task than, for example, writing an X11 WM.
(Well, writing an X11 WM that also includes a built-in compositor is a bit more than just the WM, but I'd say still less than writing a Wayland compositor using wlroots or smithay. For example, xfwm4's compositor is around 5300 lines of C, which is... not nothing, but not crazy either.)
Users? Obviously xorg devs want to work on something that isn't ancient and crufty. But users want something that actually works and it has taken almost 2 decades to get to that point.
Actually I still have more issues on Wayland than X. Although it is at least starting to swing in the other direction - e.g. KDE's screen recording feature doesn't work on X. The button's still there but if you click it nothing happens.
Most users have no idea what is behind. They don't want X or anything X related, they want things to work. Most of the things worked before 2020, including legacy things through xwayland. Now all things work, except maybe remote apps through ssh ootb, but for this you can either use RDP or Waypipe.
The only thing maybe worth discussing is video acceleration. this aside, I have been using gnome on Wayland for years and no problems what-so-ever. I really don't know what the fuss is about.
I would prefer that people start moving this legacy nonsense behind and finally start accepting new and better things and focusing on things that have future. Same thing happened with systemd, it improves massively everything Linux, yet some people just want their services started with scripts.
What problems do you have when things don't work for you on Wayland?
I don't know how you can read about the many experiences people have with Wayland not working - even now, let alone 2020 - and conclude that "all things work".
I think we are finally at the point where you can say most things work and it's silly to go back to X11, but even so Wayland has clearly been a huge failure.
It was Project Phoenix (resurrection of the Netscape browser). This resulted in the Firebird browser (Firebird and Thunderbird). But Firebird was an existing database that objected to the name. So, we got Firefox instead.
All the first 3 names were taken. They probably had to bribe even the holders of the Firefox trademark to get it (though the terms were never disclosed).
Mozilla was sued to rename Firefox (like I said) by one Phoenix Technologies. If I remember right, they picked two bad names before picking "Firefox" but I don't remember the other one.
That's irrelevant when discussing migrating large volumes of code. The hard part is migrating the project to another tech stack and setup proper test coversge. After that point, nice-to-haves such as idiomatic code is treated as mundane maintenance work.
Intrusive linked lists have performance and robustness benefits for kernel programming, chiefly that they don't require any dynamic memory allocation and can play nice with scenarios where not all memory might be "paged in", and the paging system itself needs data structures to track memory statues. Linked lists for this type of use also have consistently low latency, which can matter a lot in some scenarios such as network packet processing. I.e.: loading a struct into L1 cache also loads its member pointers to the next struct, saving an additional step looking it up in some external data structure.
“If it compiles, it is probably correct” is a major aid if you do not actually understand what the code is doing. AI and the compiler could be powerful partners.
Imagine we were talking about web browsers…
There should only be one! No security makes all my extensions work!
reply