Hacker News new | past | comments | ask | show | jobs | submit login

Well, normally that would be true.

But Wayland decided to "boil the ocean" and entirely replace a stack of stuff that was working perfectly well for most people.

So perhaps the onus should be on the people who decided to do that, to make sure that things keep working instead of just dumping it?

An alternative design would have been to have built Wayland inside X.org and tunnel the new protocol over the existing protocol, and then migrate chunks of functionality one at a time.

Which is exactly how X11 replaced X10, and X10 replaced X9, etc.

But that would have been careful engineering practice, and not nearly as much fun, so I understand why it did not happen.




“So perhaps the onus should be on the people who decided to do that”

They’re doing, you’re complaining. All the X.org software is there for all the detractors to pick up and maintain. That is what happened when the XFree maintainers didn’t want to accept patches from a larger group: it was forked into X.org.

Now the people doing the work want to do Wayland. If it doesn’t please you, then by all means carry on with the old stuff and show them how it should’ve been done.


> An alternative design would have been to have built Wayland inside X.org and tunnel the new protocol over the existing protocol, and then migrate chunks of functionality one at a time

You are looking at it from the wrong direction, though. But otherwise, that’s pretty much what wayland does for backwards compatibility with xwayland — it wraps an x session into a window you can normally use from wayland.


Yes, that is also a valid backwards compatibility choice, although it is an all-or-nothing choice, clients cannot mix and match wayland and X11 functionality.

But if they had allowed more of the X11 APIs to be supported via that Xwayland, the transition would be a lot easier.

Unfortunately that was shot down, in favour of forcing every new wayland compositor to implement things like remote desktop and screen capture differently.


> An alternative design would have been to have built Wayland inside X.org and tunnel the new protocol over the existing protocol, and then migrate chunks of functionality one at a time.

This is the kind of ignorance Drew was complaining about. Wayland is a fundamentally different design that cannot simply be embedded in the X protocol; and besides which, again, nobody wants to touch the Xorg code base.

Again. Every single person who knows or cares about the modern Linux graphics stack is pretty much in agreement that abandoning the X approach and starting from scratch was the correct choice. This has been explained time and time again by Drew, Daniel Stone, and others much more knowledgeable about this issue than I. Explaining it over and over again to the stubborn and ignorant is getting tiring. You want to stay on legacy, unsupported X11? Fine. Enjoy having no modern software available for your system, as toolkit and app developers remove their X code paths entirely. Red Hat is abandoning X11 already, and Red Hat IS userspace Linux.


For starters, it is rather rude to assume how little I know about this.

Leaving that aside, Drew is mis-characterising things a little.

Wayland is fundamentally a different __compositor__ architecture. But the X11 system is about more than that, in fact compositors are a rather late addition to the X11 system.

And the protocol architectures are actually quite similar in shape. Which is not surprising, since good ideas last, and X11 has been around for a long time and has accumulated lots of good things (along with lots of cruft too).

So it would have been quite possible, but a good deal less fun, to do it differently.


> And the protocol architectures are actually quite similar in shape. Which is not surprising, since good ideas last, and X11 has been around for a long time and has accumulated lots of good things (along with lots of cruft too).

With the XPresent extension, you effectively get "Wayland inside X11". It's a wonderful thing, as X engineering goes anyway, that precisely no one asked for.

The whole point of the Wayland project is to get rid of all the cruft that X has accumulated over the decades. Embedding Wayland inside Xorg would defeat the whole purpose of the project. The very essence of Wayland is to start over with something new, unhindered by legacy cruft, allowing innovation in the Linux graphics space to take place.

So it was decided, unanimously, by the X devs: the X team would become the Wayland team, Wayland would be the future and X would be abandonware. Anyone who wants to step up and take over maintainership of X can, but I don't see a lot of activity happening.


>Fine. Enjoy having no modern software available for your system, as toolkit and app developers remove their X code paths entirely. Red Hat is abandoning X11 already, and Red Hat IS userspace Linux.

This seems to me no different than big monopoly corp obseleting old devices with software updates. However, that gets a reaction of opposite polarity usually (including from me).


Big mono Corp can obsolete things and forbid anyone from picking it up to maintain. Nobody is preventing a group from picking up the old stuff and maintaining it - it’s just a bunch of people shouting at those doing the work (or paying for it) that they should be doing it differently.


Over a long enough period of time, technically correct choices are always orthogonal to choices that are useful to users.

I am sure windows, like X, also made assumptions that were violated with the advent of things like HiDPI, multiple monitors, video streaming, etc,.

Once assumptions are broken, you pretty much have to pile on hack after hack to get around them. This is what windows does (10+ different APIs to do the exact same action A, for many values of A), and that is why it supports 30 years of software. This is technically horrible, but it is what is ultimately useful to users.

However, it is absolutely not fun work for developers, which is why unpaid ones won't do it, and prefer the easier start-from-scratch approach.


The core developers of Wayland (and formerly X.org) are not unpaid though.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: