Live data from Hacker News

The X.Org Server Is Abandonware?

phoronix.com

541–550 of 714 posts

Re: The X.Org Server Is Abandonware?

#541

Earlier quoted context omitted.

Are they optional¹ and are there alternatives to them? If the answer is yes, then there is a problem. 1 - I imagine "optional" can be the wrong word, maybe the correct is "universally adopted".

Maybe a more concrete example will answer your question. The Wayland protocols are found here [1]. Your compositor will implement some of these protocols and not others. If I’m writing an application I will; possibly through some toolkit, ask the compositor what features it supports and configure how my application works accordingly. This isn’t particularly different to say, an toolkit not supporting a particular for…

So, it's quite possible that one gets a distro or a machine set up so everything works locally, but you can not tunnel a GUI application or run a remote desktop there. Or that you get a machine where you simply can not take a screenshot to report a bug?

So... I was one of those people rooting for anybody to replace X11 when wayland launched. But given the current situation, I'm just hopping that Red Hat finishes dying off before I have to work with somebody stupid enough to set some GUI system that I need to access, but only runs on a computer where I can not run a GUI.

Re: The X.Org Server Is Abandonware?

#542

Earlier quoted context omitted.

I've heard enlightenment can be a Wayland compositor now, could you try it? Also I think 3dfx Voodoo was the magic pixie dust, once you ever go OpenGL, you're not going back.

A developer sharing is experience working with EFL: https://what.thedailywtf.com/topic/15001/enlightened

It sounds like the guy is way overexaggerating and basically didn't understand the library he was working with. What he describes isn't anything special - the "Evas_Object" (aside of the weird name) sounds like a HWND in Windows or Window in X. The part about layouts sounds like similar to sizers in wxWidgets which are used so that you can avoid using heavyweight native widgets just for layout that some other toolkits do. The event callback sounds like it uses a generic messaging system - again not much different than something like WndProc in Windows.

EFL is written in C so it does have to work within the limitations of C but -non-toy- GUIs are inherently object oriented so things will be a bit more complicated than Qt that can lean on C++'s support for object oriented programming. Especially since apparently EFL also supports bindings to other languages which may also make things a bit more complicated.

Re: The X.Org Server Is Abandonware?

#543
post #528

What looks like "typical Linux geeks being geeks" with this situation: 1) the old, mostly working thing is being abandoned in favor of 2) that new thing which doesn't work in so many cases it's laughable, even after 11 years. How many years was it between the concept of X and a working release at Palo Alto? Note that the new situation is so perfect for passing the buck from the windowing system to the compositors, an…

> 1) the old, mostly working thing is being abandoned in favor of Except that X11 is NOT "mostly working" for a significant amount of modern usages. Yes, if you happen to want to run your Terminal, Emacs, etc. remotely over a network connection, X11 is your huckleberry--but only because anything more complicated than a bitmap makes that a very difficult problem. If you want HiDPI, subpixel anti-aliasing, color calibr…

None of that require throwing away the entirety of Xorg/X11, breaking every existing application while expecting everyone to rewrite their code in a completely different way, breaking a ton of existing workflows (often without alternatives) and splitting the already tiny Linux desktop in half.

Every single thing you've mentioned can be fixed with Xorg/X11.

(except subpixel antialiasing because that already existed for a long time, i'm not sure what you refer to)

Re: The X.Org Server Is Abandonware?

#544
post #430

What looks like "typical Linux geeks being geeks" with this situation: 1) the old, mostly working thing is being abandoned in favor of 2) that new thing which doesn't work in so many cases it's laughable, even after 11 years. How many years was it between the concept of X and a working release at Palo Alto? Note that the new situation is so perfect for passing the buck from the windowing system to the compositors, an…

Newer isn't better-designed. Unix was really well-designed, compared to so much of the modern stuff, and it does everything I need. Nineties Linux was a nice Unix. I wish we hadn't spent the past quarter-century turning it into nineties Windows, with layers upon layers upon layers of cruft. I don't get why Wayland is slow, when Enlightenment was fast on machines with 32MB of RAM, a 3dfx Voodoo, a spinning HDD, and a…

I don't know that Wayland is slow, but Gnome was. They fixed several big performance problems recently.

Re: The X.Org Server Is Abandonware?

#545
post #481

Earlier quoted context omitted.

The problems Wayland solve are those of yesteryear, sprinkled with the broken dreams that we'd all be running it on Linux phones by now. In that context a strict security model makes sense. Trouble is, that security model makes no sense on today's desktop. In 2020, people aren't downloading and running native applications on desktops, not even (especially?) on Linux. The desktop is now solely a manager of browser win…

One more thing: the Wayland security model doesn't make much sense anyway, considering that running untrusted code over a large attack surface and without at least virtualization is probably a bad idea anyway nowadays (and even virtual machines can be escaped from).

The Wayland security model was designed with sandboxed applications in mind. X was not.

Re: The X.Org Server Is Abandonware?

#546

If Wayland is the future, then the future was 12 years ago. Since it hasn't really caught on or solved the same problems that X.Org accomplished a long time ago, it seems kind of pointless to continue pursuing it at this point. In my opinion, the best thing about X.Org is that it's no longer changing. I remember installing updates for X.Org all the time and booting to a black screen on multiple occasions.

The issue is not Wayland or "something else". The issue is trying to implement a radical change in the userspace Linux ecosystem. It's not possible without a ton of effort, so it takes an incredible amount of time, sweat and tears. That's the reason it takes 12 years and counting. The utopian philosophy of "Linux is about choice" has doomed any idea of a Linux desktop.

> The utopian philosophy of "Linux is about choice" has doomed any idea of a Linux desktop.

If it isn't about "choice" - ie. user control and freedom - then what is the point of using Linux in the first place and not stick with Windows where things are already chosen for you and way more often than not work out of the box because it is by far the most tested against desktop environment?

Re: The X.Org Server Is Abandonware?

#547
post #506

Earlier quoted context omitted.

I’m not entirely sure that I understand your point. Here are the facts which I think we can agree on. * X11 is a protocol * Wayland is a protocol * X11 and Wayland are not compatible protocols * Wayland protocols are all public * XOrg is an implementation of the compositor of the X11 protocol * wl_roots is a toolkit used for creating compositors From this, it follows that: * Anyone can theoretically write another X11…

The wayland protocol (with the very few standard common extensions) does far less than the X11 protocol. There are extensions to Wayland that add missing functionality, but those are compositor-specific. Meaning effectively that each compositor has its own incompatible variant of the Wayland protocol. In that sense, it is not one Wayland protocol but a whole cesspool of them... It will also get worse, because the arc…

> There are extensions to Wayland that add missing functionality, but those are compositor-specific. Meaning effectively that each compositor has its own incompatible variant of the Wayland protocol.

Well no — this is where I disagree. The extensions are standard and hosted within the repository [1]. A repository may support their own proprietary protocol, after all it’s an XML file, but practically speaking without distributing it through the repository means that you won’t get any clients to actually use it. It is wrong to suggest that there is a huge proliferation of interfaces.

It is true that the core Wayland protocols support less functionality than X11. It’s also true that developers implementing windowing managers need to do more work — however, again I point you towards wl_roots, libinput etc. as examples to show that you don’t need to implement anything from scratch unless you want to.

I don’t believe this particular design doesn’t have trade-offs, but to pretend that it has no benefits is also incorrect. The fact that there are less core protocols means that you can implement a simpler compositor if you should so wish. There are comments in this thread pointing to the usage of Wayland in different devices as an application of this.

[1] https://github.com/wayland-project/wayland-protocols

Re: The X.Org Server Is Abandonware?

#548

Earlier quoted context omitted.

Maybe a more concrete example will answer your question. The Wayland protocols are found here [1]. Your compositor will implement some of these protocols and not others. If I’m writing an application I will; possibly through some toolkit, ask the compositor what features it supports and configure how my application works accordingly. This isn’t particularly different to say, an toolkit not supporting a particular for…

So, it's quite possible that one gets a distro or a machine set up so everything works locally, but you can not tunnel a GUI application or run a remote desktop there. Or that you get a machine where you simply can not take a screenshot to report a bug? So... I was one of those people rooting for anybody to replace X11 when wayland launched. But given the current situation, I'm just hopping that Red Hat finishes dyin…

Well yes — in the same way that you could have had a half-baked implementation of X on a remote desktop; but it’s unlikely because most GUI-based interfaces will bundle with some level of support. For example, I don’t expect Canonical’s Wayland compositor to not support screenshots; so while I don’t think your worry is unfounded, I do think it’s disproportionate.

Re: The X.Org Server Is Abandonware?

#549
post #474

Earlier quoted context omitted.

One of these days you should read the X section of the Unix Haters Handbook. Wayland is being built for the world as it is, X was built for a world that never was. In this case, it’s quite hard to not be better designed.

" One of these days you should read the X section of the Unix Haters Handbook. " I have. It was written by someone who doesn't know the difference between a "client" and a "server".

No, really. The author, whose name I can't remember at the moment, complains that X has the server/client roles reversed; that xcalc is a server and the display is a client. The usual defense is that it's "tongue in cheek", but from a networking standpoint it is simply wrong.

Re: The X.Org Server Is Abandonware?

#550

Earlier quoted context omitted.

So, it's quite possible that one gets a distro or a machine set up so everything works locally, but you can not tunnel a GUI application or run a remote desktop there. Or that you get a machine where you simply can not take a screenshot to report a bug? So... I was one of those people rooting for anybody to replace X11 when wayland launched. But given the current situation, I'm just hopping that Red Hat finishes dyin…

Well yes — in the same way that you could have had a half-baked implementation of X on a remote desktop; but it’s unlikely because most GUI-based interfaces will bundle with some level of support. For example, I don’t expect Canonical’s Wayland compositor to not support screenshots; so while I don’t think your worry is unfounded, I do think it’s disproportionate.

Oh, ok. I imagine you had a stricter interpretation of "universally adopted" then.

If every practical system support them, they are universal enough.

Post reply on HN