Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring the Fragmentation of Wayland, an xdotool adventure

semicomplete.com

Post reply on HN
Print view View original

41–50 of 97 posts

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#41

Post by saurik »

kjellsbells wrote: post #17

Second system effect is the curse of FOSS projects. It's been that way for decades. I don't see a reliable solution for the structural problem that doesn't somehow end up like a Benevolent Dictatorship. At the end of the day, designing complex systems by committee is hard to do. Maybe there is a maximum size of a group beyond which the communication matrix between the members starts to fracture?

I would claim the dictators -- even the "benevolent" ones--tend to do this more often than committees, as they have more inherent power to do so: the committees tend to get stuck in backwards compatible land forever (for better or for worse). I mean, look at Larry Wall or Guido Van Rossom with their respective debacles. Bjarne Stroustrop couldn't mess up in that way even if he seems to want to. As another example, HTTP only started having this problem with Google being able to railroad everyone. The only major second system effect caused by what I believe is a committee that I can easily come up with is IPv6?

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#42

Post by tsimionescu »

jauntywundrkind wrote: post #27
dvntsemicolon wrote: post #2

You'll never find me saying that Wayland development is good in its present state. I think it's a mess and it has a lot of issues. But let's be honest about Xorg. The overwhelming majority of people who worked on Xorg are now developing Wayland. Why? Because developing Xorg is a massive pain in the butt. It is a 400K LOC behemoth of a project and it has a ridiculous amount of technical debt. I would have to imagine t…

There's so much hot debate about how bad Wayland is, how incorrect it is. But theres something I respect enormously about Wayland which is that: it is so so so much less than Xorg. It uses the kernel's graphics buffers. It uses the kernel's mode setting. These alone are humongous differeniatiors. There's so many other amazing glorious ways that Wayland is less. The protocol-centricity is vastly under rated, a massive…

This is exactly backwards. Whenever some team that is maintaining a monolith will look at the possibility of splitting it up and going with this protocol idea, they will look at Wayland as a cautionary tail of just how badly that works out in practice.

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#43

Post by lmm »

RVuRnvbM2e wrote: post #30

This is analogous to calling unix account separation "fragmentation". Why can't I just run all my services as root? It has worked for years!? The answer is that it is a fragile, unmaintainable security nightmare. Wayland has separation of concerns to fix that problem, with the tradeoffs described in the blog post.

And yet unix account separation really did turn out to be overcomplicated and useless. Hosting providers were never able to separate untrusted users by user account, they either use VMs or containers or give up on offering shell access at all, and on home machines the whole effort falls prey to https://xkcd.com/1200/ .

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#44

Post by codedokode »

ziotom78 wrote: post #39

Xdotool and Xmodmap are the two main reasons why, after a few months running Wayland+keyd+dotool I went back to X11. I found really hard to have the following things working at once: - Italian layout for my keyboard with heavily-customized AltGr keys for mathematical notation (in X11 it's just a matter of having a Xmodmap file) - Using Espanso for many common shortcuts like :date: (current YYYY-MM-DD date) and :pidig…

> A reasonable way to run Windows in a VM

What's wrong with this case? Virtual machine reports invalid key codes to the guest? You need to have the proper layout in Windows, as (virtual) hardware only reports key codes.

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#45

Post by jauntywundrkind »

tsimionescu wrote: post #42
jauntywundrkind wrote: post #27

Earlier quoted context omitted.

There's so much hot debate about how bad Wayland is, how incorrect it is. But theres something I respect enormously about Wayland which is that: it is so so so much less than Xorg. It uses the kernel's graphics buffers. It uses the kernel's mode setting. These alone are humongous differeniatiors. There's so many other amazing glorious ways that Wayland is less. The protocol-centricity is vastly under rated, a massive…

This is exactly backwards. Whenever some team that is maintaining a monolith will look at the possibility of splitting it up and going with this protocol idea, they will look at Wayland as a cautionary tail of just how badly that works out in practice.

What an utterly vacuous statement saying nothing. Making no refutable claims. Typical hot air, full of nothing. Boring as fuck, nothing here.

Further, your point is spoken from the perspective of a company, a single entity. Companies are utterly unable to bank on Bazaar practices, to embrace the multitudes way of finding answers. They lack the hackerly blood to try many approaches. They are not creative enough to do anything but build their one Cathedral.

As a company, no, you should not try to build interoperable protocols to foster internal completion on. Duh, no shit. But strong command and control-while it may be good for a company-is not going to be how a much broader ecosystem finds the best paths to take.

It's incredibly impressive how much Wayland compositors compete/cooperate for better. Sway/wlroots for one example has a new Vulkan backend. They could just go try and do new things. There's protocols to implement and they made new implementations, and now there's a half dozen Wayland compositors that have new cutting edge tech they are trying out. Innovation at the edge, but working together, is the shit. Yeah it's not a model that helps the corpo's but that's because open source is searching a much wider field of options, looking much better for wins, and the cathedral model isn't going to get you any of that.

I'm still impressed what vacuous say nothing piece of shit useless Fear Uncertainty and Doubt folks can spread. This era has such a virulent pox of hatred, built around such empty words. None of these bitter words actually say anything, this whole discussion is filled with rabid useless disdain. Piss on ye, say something contestable you villainous cowards. What does you are, saying nothing, but trying to dynamite it all. A pox.

The calculus of what some team does is totally different than what open source does.

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#46

Post by [deleted] »

jauntywundrkind wrote: post #27
dvntsemicolon wrote: post #2

You'll never find me saying that Wayland development is good in its present state. I think it's a mess and it has a lot of issues. But let's be honest about Xorg. The overwhelming majority of people who worked on Xorg are now developing Wayland. Why? Because developing Xorg is a massive pain in the butt. It is a 400K LOC behemoth of a project and it has a ridiculous amount of technical debt. I would have to imagine t…

There's so much hot debate about how bad Wayland is, how incorrect it is. But theres something I respect enormously about Wayland which is that: it is so so so much less than Xorg. It uses the kernel's graphics buffers. It uses the kernel's mode setting. These alone are humongous differeniatiors. There's so many other amazing glorious ways that Wayland is less. The protocol-centricity is vastly under rated, a massive…

[deleted]

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#47

Post by gf000 »

charcircuit wrote: post #4
dvntsemicolon wrote: post #2

You'll never find me saying that Wayland development is good in its present state. I think it's a mess and it has a lot of issues. But let's be honest about Xorg. The overwhelming majority of people who worked on Xorg are now developing Wayland. Why? Because developing Xorg is a massive pain in the butt. It is a 400K LOC behemoth of a project and it has a ridiculous amount of technical debt. I would have to imagine t…

There wasn't a need to have 10s of different wayland compositors. There is not a need to endlessly bikeshed over extentions instead of delivering user value. These are failures of leadership in driving the replacement of X. Just compare this to Windows and how they made this rearchitecture of making their compositor more modern without splitting into 10s of compositors and breaking a ton of apps.

How can you compare the Cathedral with a bazaar? This is not a technical difference at all.

Apple/Microsoft can do whatever they want, just break compatibility at any point and everyone else wanting to have their programs supported on their platform will adapt.

Meanwhile for Linux network effect has a much bigger role to play, you can't tell anyone else what to do, but protocols can only emerge from working together.

Also, I wouldn't bring up Microsoft's display stack as a positive example at all.

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#48

Post by XorNot »

saurik wrote: post #41
kjellsbells wrote: post #17

Second system effect is the curse of FOSS projects. It's been that way for decades. I don't see a reliable solution for the structural problem that doesn't somehow end up like a Benevolent Dictatorship. At the end of the day, designing complex systems by committee is hard to do. Maybe there is a maximum size of a group beyond which the communication matrix between the members starts to fracture?

I would claim the dictators -- even the "benevolent" ones--tend to do this more often than committees, as they have more inherent power to do so: the committees tend to get stuck in backwards compatible land forever (for better or for worse). I mean, look at Larry Wall or Guido Van Rossom with their respective debacles. Bjarne Stroustrop couldn't mess up in that way even if he seems to want to. As another example, HT…

IPv6 is a victim of the nature of the problem and a lot of under informed observers. I see too many comments asking why it's just backwards compatible or suggesting less bits would make it easier.

There are real problems but really the issue is that it was a hardware and software problem wrapped into one as well as being a collective action problem.

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#49

Post by gf000 »

saurik wrote: post #36
jemmyw wrote: post #6

Earlier quoted context omitted.

Here you're just comparing proprietary closed source development to open source development. In the proprietary version the goal is to improve a product. The OSS goals are much harder to pin down and can be different person to person, but it wouldn't be unreasonable to have a goal of "make it so that other devs can make their own compositors easily" and therefore you're describing an obvious success. Short term this…

It isn't particularly easier to make your own compositor either, as you now also have to bring your own window manager. What made the X architecture much more interesting is that it avoided coupling the window manger to the compositor. Hell: there even are multiple popular compositors for X, as they also managed to avoid coupling the compositor to the display server (which would be the one part of the system that you…

But why would I ever want to have a separate compositor and window manager? Like the display stack benefits from "vertical integration", being modular is a tradeoff, often of performance and significant complexity.

Why not just make a display server (which handles everything rendering related, compositing included), and then add a window manager as a plugin/extension on top? Window managers are not that complicated.

Re: Exploring the Fragmentation of Wayland, an xdotool adventure

#50

Post by charcircuit »

saurik wrote: post #36
jemmyw wrote: post #6

Earlier quoted context omitted.

Here you're just comparing proprietary closed source development to open source development. In the proprietary version the goal is to improve a product. The OSS goals are much harder to pin down and can be different person to person, but it wouldn't be unreasonable to have a goal of "make it so that other devs can make their own compositors easily" and therefore you're describing an obvious success. Short term this…

It isn't particularly easier to make your own compositor either, as you now also have to bring your own window manager. What made the X architecture much more interesting is that it avoided coupling the window manger to the compositor. Hell: there even are multiple popular compositors for X, as they also managed to avoid coupling the compositor to the display server (which would be the one part of the system that you…

>What made the X architecture much more interesting is that it avoided coupling the window manger to the compositor

This is the industry standard, putting the compositor and window manager in separate processes.

Android separates SurfaceFlinger and WindowManagerService.

iOS separates quartz compositor and springboard.

Windows separates dwm and explore.

MacOS separates WindowServer and Dock.

Post reply on HN