Hacker News Reader

Comment by jemmyw | Hacker News Reader

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 might be a far slower and worse approach. It's not clear that's the case long term though, making things easier to try out different ideas and then finding a winning compositor project could be better than being stuck with one.

View on HN

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 don't find too many of -- though there were multiple implementations over the years! -- but that's not really much different than Wayland where everyone is using the same library to implement the behaviors as part of their coupled-together balls of mud.)

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.

I dunno: I have never ever wanted to make a compositor -- which, to me, feels like a really boring piece of graphics infrastructure -- and yet I have used multiple window managers over the years and have absolutely wanted to make my own window manager? In X, making your own window manager was so popular of an activity that it honestly felt kind of unreasonable just how many window managers existed, and yet everyone used one of a handful of compositors and I'm honestly not sure why anyone in their right mind would bother making their own display server?

for instance as a X11 user I don't want a compositor at all

(Same... I know people use them to get some pretty effects; but, they add a frame of latency I do not want and require lots of memory and assume acceleration I don't need.)

There is no way to avoid a frame of latency without "racing the beam", which AFAIK quite complicated and not compatible with most GUI frameworks. That is, if you don't want tearing.

But I may be wrong here

One frame of latency and adding a frame of latency are different things. The first is required (without tearing) the second should be avoided at all cost (athough high display refresh rates reduce the problem of "long" swapchains quite a bit).

>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.

Tell that to the Wayland people? ;P

Dwm is both the compositor and window manager in Windows. It’s the same with WindowServer in macOS.

If you are talking about the shell or task switcher, then yeah your point stand with Gnome but KDE has kwin and plasmashell processes.

> Short term this might be a far slower and worse approach.

We are way past the short term with Wayland!

Wayland is 17 year old.

Existing != used

It does not matter if the devs alone worked on it in isolation but at what point there was public use and how it has evolved. The earliest you could argue it was being used by user on a distro would be 2016 in fedora. Actual mainstream use in ubuntu around 2021 but optional and default literally only just this year.

Perhaps proprietary closed source development is better for making operating systems. Is it a coincidence that Google was able to scale Linux to billions of devices while open source development ones weren't? Open source development should take some lessons if they want to be successful and not aggrevate developers writing apps for your platform like what happened in the article, forcing them to do extra work.

If development for X is ceasing now, there isn't time to experiment on finding the true successor.

Access to virtually infinite cash had more to do with Android's success than the source being proprietary.

I think the hard part about the Linux desktop ecosystem and its development pattern is the cobbled-up-parts nature of the system, where different teams and individuals work on different subsystems with no higher leadership directing how all of these parts should be assembled to create a cohesive whole. We have a situation where GUI applications depended on X.org, yet the X.org developers didn't want to work on X.org any more. If the desktop Linux ecosystem were more like FreeBSD in the sense that FreeBSD has control over both the kernel and its bundled userland, there'd be a clearer transition away from X.org since X.org would have been owned by the overall Linux project. However, that's not how development in the Linux ecosystem works, and what we ended up with is a very messy, dragged-out transition from X to Wayland, complete with competing compositors.

Bazaar-style development seems to work for command-line tools, but I don't think it works well for a coherent desktop experience. We've had so much fragmentation, from KDE/Qt vs GNOME/GTK, to now X11 vs Wayland. Even X11 itself didn't come from the bazaar, but rather from MIT, DEC, and IBM (https://en.wikipedia.org/wiki/X_Window_System).

> Perhaps proprietary closed source development is better

Perhaps...

> Open source development should take some lessons if they want to be successful

A lot of people who write the gui stuff for Linux do it because they want to. Success is not necessarily the same metric as a company making a product.

There are companies working within the space and I doubt the licensing really makes much difference to the outcome (i.e. your Google example)

> If development for X is ceasing now, there isn't time to experiment on finding the true successor.

Why? Again, the people working on it because they want to don't need to do anything, they can experiment. Someone can still fix up issues in X. Some companies will fund the development of things that are important to them. You make it sound like the oss community should be acting like one entity to achieve something, but there is no overarching goal nor a reason for there to be one. People will continue pulling in different directions.

> A lot of people who write the gui stuff for Linux do it because they want to.

Think about how many people might want to write for it if it had a compelling ui stack, tho

You think Linux isn't widely used at scale?

Phones are a different market from computers, even though they're technically the same thing. A large segment of people own "phones" but not a computer. Linux runs a large chunk of the internet. I think it's used quite well at scale.

Even in the server market the success of having a stable app platform can be attributed to Linux, the kernel, solely for having a policy to never break userspace. The base of the app platform was already figured out a long time ago, and if you look at the bulk of Linux contributions you will see that they are coming from companies using Linux commercially.

> You think Linux isn't widely used at scale?

Certainly not in a high-productivity environment. Google has to swap out most of the runtime components with distributed alternatives to make it compelling in a corporate (distributed) environment.

Linux (the kernel) is also open source and doesn't suffer from the fragmentation problem. It's pretty much unique to the Linux desktop because there are too many cooks involved.

But even if there's only one cook, it could be worse (if that cook is the gnome team). At least with multiple cooks we can pick kde instead of gnome.

> it wouldn't be unreasonable to have a goal of "make it so that other devs can make their own compositors easily"

I can't say i've ever wanted a second compositor to choose from. Ideally it would just be part of the window server.

Reply on news.ycombinator.com