Live data from Hacker News

The death watch for the X Window System has probably started

utcc.utoronto.ca

391–400 of 518 posts

Re: The death watch for the X Window System has probably started

#391
post #338

Earlier quoted context omitted.

Haven't seen a case of dbus daemon replacement, only I think one or two client libraries, and one is niche and the other is so niche I think less than 10 people ever used it.

AKAIK kdbus re-implemented that half of it, albeit in the kernel not as a daemon. I've not been given the impression that there is anything preventing additional implementations. The strongest technical argument against dbus I've yet heard is that it's too slow for file transfers or something... well fine then, don't use it for that. But for plenty of other stuff it seems to work just fine. People complain about the…

kdbus was afaik not-exactly-compatible (at least not wire protocol compatible), and as its main reason for existence had speed.

And finally died after Linus went to town on dbus-daemon pointing out a bunch of fixes that made it much faster (though I don't know if anyone turned that example into actual patches for dbus-daemon).

As for arguments against d-bus - It's a mess. The protocol is variable-endianess for no reason, back in the very beginning the XML interface spec got significant criticism because introspection required punting and parsing XML.

Personally I'd also point to mess of multiple identifiers - last time I tried to figure out details for third-party implementation, I got 3 different addresses per object, whereas sometimes I believe just a reference would suffice.

Also, unlike its (probably closest) predecessor DCOP, it's very hard to use d-bus outside of writing a complex program.

Systemd is a factor, but it started years before. D-Bus is "desktop bus", and was rather obviously designed to be the interconnect between applications on the desktop. It seems to me to be preciously rare in its original goal of "COM-like" interop on desktop. Then it got started to be used for system daemons. HAL was somewhat reasonable if problematic. PolicyKit and ConsoleKit ... not so much. Those two laid foundations for badly described but "crucial" APIs provided by logind and systemd that were forced down everyone's throat later on. Now that I think of it, NetworkManager taking years to being configurable without gnome panel might have a hand in it too (and cast a shadow on D-Bus due to NM developer arrogance in the past).

So, generally, a bit of technology, a containership of politics.

Re: The death watch for the X Window System has probably started

#392
post #373
post #332

Earlier quoted context omitted.

For a bunch of stupid, hysterical reasons, the Open Source X11 server still has all the warts of early-1990s release. XFree86 used the MIT X.Org core dump to implement open X11 on Linux, but outside of certain new things (DRI, XRender extension) it remained stuck in "world is dumb framebuffers with optional bitter" design. Over time, a lot of useful stuff was broken and supported less and less, then reimplemented in…

I wonder why the SGI stuff for X was not open sourced?

very tightly integrated with Irix and SGI MIPS hardware, from my understanding.

A bit like IRIS GL never getting open sourced, because it wouldn't be of much use without matching hardware exposed over /dev/GL interface.

Re: The death watch for the X Window System has probably started

#393
post #10
post #4

So, RedHat decided that they do not want nvidia users anymore? I’d be more than happy to switch to Wayland, but I can’t.

GNOME, which is what powers the RedHat desktop, supports nvidia on Wayland just fine, and KDE got nvidia/EGLStreams support since KWin 5.16. So at least 2 major DEs do, though quite a few others don't, and have taken a principled stand not to (Sway for example won't). When it comes to RedHat though, they're all-in on GNOME anyway so keeping X around for nvidia users isn't really a concern for them when their desktop…

Kwin 5.16 might technically support EGLStreams, but I have an Nvidia card and tried it out - after setting env variable to even make it try to work, Plasma crashed during startup, kicking me back to login. I tried again, and it managed to start up, but then plasma-shell crashed when I tried to search something. Performance varied dramatically, the mouse cursor switched from 60fps to 1fps randomly.

Kwin EGLStreams is not ready.

Re: The death watch for the X Window System has probably started

#394

Earlier quoted context omitted.

Apple evaluated X11 when they were just starting work on Mac OS X. This comment by Mike Paquette (designer and author of Quartz!) explains why it was better to dump X11 and start over: "> they don't even use X at all! What Apple is providing is an Apple-original window system that is graphics model agnostic, as well as a vector drawing system that maps very well to PDF, which is a sort of PostScript without the non-g…

That comment is my point . Those things that the Apple guy mentions having to add to X were in fact added to X. They're called XRender. There's no reason we couldn't have added more extensions. Nobody has given me a straight answer for why Wayland-style buffer management couldn't have been an X11 extension. Nobody.

I think the more pressing question is, what's wrong with supporting all these legacy X11 apps with XWayland?

Who cares about xeyes, xterm and twm? I sure don't, at least not when it comes at the expense of maintainers that have better things to do.

Re: The death watch for the X Window System has probably started

#395
post #372
post #73

Earlier quoted context omitted.

Again -- XWayland is Xorg. The xorg-server codebase contains a number of components, one of which is a front end called DIX (Device Independent X) that handles protocol-level stuff, another of which are several backends collectively called DDX (Device Dependent X) that handle drawing to the actual video hardware or other graphics layer. One of these DDX backends is 'xwayland'. So the XWayland server incorporates the…

Problem with your suggestion is that Wayland won't be around in 15 years while Xorg will still be km kicking.

What makes you think that? The maintainers of both Wayland and Xorg have chosen to take Xorg behind the barn and shoot it.

Re: The death watch for the X Window System has probably started

#396
post #50

Earlier quoted context omitted.

My concern at the moment with Wayland (and Systemd, Pulseaudio, DBus and a few others) is that Linux is loosing modularity. All these dependencies seem to be getting more or less mandatory. Running a distribution without them is getting harder. Given that they are all getting pushed by the same group of people at Red Hat, it is concerning as they are effectively gaining control of the Linux userland. And given that t…

>they are effectively gaining control of the Linux userland. but they aren't gaining control by some dastardly power grab, they're gaining control because they're the only ones actually putting in the work. They're simply doing what they think is best for their product, while at the same time contributing their work back to the open source world. That is good, that's how it's supposed to work. The only reason they're…

scorched earth

Re: The death watch for the X Window System has probably started

#397
post #183

Earlier quoted context omitted.

No not really similar. It is basically a raw video that transfers the full window content over the wire. X11 is capable of drawing primitives. Even though the most popular toolkits (Gtk, QT) sadly did not use them, those who did (e.g. Athena, Tcl/Tk) worked perfectly over the network, even modem lines. If Wayland would contain modern drawing primitives like those that Cairo offers which could easily be serialized, we…

Very little modern software uses the X drawing functions. GTK uses Cairo, but so does X (that's where it came from, the library behind the X drawing API). But apps will use the GTK implementation of Cairo (client side) because it works on other platforms as well (windows and OSX). In most cases it doesn't actually make sense to put your drawing functions in the display server any more.

Cairo wasn't the library behind the X11 drawing API, it was originally the Xr rendering extension, that was an alternative to the original X11 drawing API.

https://en.wikipedia.org/wiki/Cairo_(graphics)

>The name Cairo derives from the original name Xr, interpreted as the Greek letters chi and rho.

You're right, it doesn't actually make sense to put your drawing functions in the display server any more (at least in the case of X11, which doesn't have an extension language to drive the drawing functions -- but it did make sense for NeWS which also used PostScript as an extension language as well as a drawing API).

So Cairo rose above X11 and became its own independent library, so it could be useful to clients and toolkits on any window system or hardware.

https://www.osnews.com/story/3602/xr-x11-cross-device-render...

https://web.archive.org/web/20030805030147/http://xr.xwin.or...

https://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004...

Here's some email discussion with Jim Gettys about where Cairo came from:

From: Jim Gettys Date: Jan 9, 2007, 11:04 PM

The day I thought X was dead was the day I installed CDE on my Alpha.

It was years later I realized the young turks were ignoring the disaster perpetrated by the UNIX vendors in the name of "standardization"; since then, Keith Packard and I have tried to pay for our design mistakes in X by things like the new font model, X Render extension, Composite, and Cairo, while putting stakes in the heart of disasters like XIE, LBX, PEX, the old X core font model, and similar design by committee mistakes (though the broken core 2D graphics and font stuff must be considered "original sin" committed by people who didn't know any better at the time).

So we've mostly succeeded at dragging the old whale off the beach and getting it to live again.

From: Don Hopkins Date: Wed, Jan 17, 2007, 10:50 PM

Cairo looks wonderful! I'm looking forward to using it from Python, which should be lots of fun.

A lot of that old X11 stuff was thrown in by big companies to shill existing products (like using PEX to sell 3d graphics hardware, by drawing rotating 3-d cubes in an attempt to hypnotize people).

Remember UIL? I heard that was written by the VMS trolls at DEC, who naturally designed it with an 132 column line length limitation and no pre-processor of course. The word on the street was that DEC threw down the gauntlet and insisted on UIL being included in the standard, even though the rest of the committee hated it for sucking so bad. But DEC threatened to hold their breath until they got their way.

And there were a lot of weird dynamics around commercial extensions like Display PostScript, which (as I remember it) was used as an excuse for not fixing the font problems a lot earlier: "If you want to do readable text, then you should be using Display PostScript."

The problem was that Linux doesn't have a vendor to pay the Display PostScript licensing fee to Adobe, so Linux drove a lot of "urban renewal" of problems that had been sidelined by the big blundering companies originally involved with X.

>So we've mostly succeeded at dragging the old whale off the beach and getting it to live again.

Hey, that's a lot better than dynamiting the whale, which seemed like a such good idea at the time! (Oh the humanity!)

https://www.youtube.com/watch?v=AtVSzU20ZGk

From: Jim Gettys Date: Jan 17, 2007, 11:41 PM

> Cairo looks wonderful! I'm looking forward to using it from Python, which should be lots of fun.

Yup. Cairo is really good stuff. This time we had the benefit of Lyle Ramshaw to get us unstuck. Would that I'd known Lyle in 1986; but it was too late 3 years later when I got to know him.

https://cairographics.org/bibliography/

Re: The death watch for the X Window System has probably started

#398

Earlier quoted context omitted.

Meanwhile X is still on death watch and Nvidia will be brought into the fold or be forced to stop pretending they support the linux desktop.

Wherein "death watch" is expected to work without difficulty for the next decade or longer. They aren't pretending they support Linux, BSD, Solaris, Mac, Windows for a decade after each card is released. While this was true ATI/amd were shipping garbage that barely worked for a few years. This has only changed in recent years. We are a few years having one dedicated gpu maker in the fold and are already talking about…

It really doesn't matter to me if Nvidia drops out of the linux desktop market or not. I've never owned their hardware and never will, so it makes not an iota of difference to me.

I'm just observing that Redhat is the trendsetter and if they say X is legacy, that makes it so. Unless Nvidia or Nvidia customers decide to pick up where Redhat is leaving off and pay for developers to work on X, but I sincerely doubt that's going to happen.

Unless Nvidia decides to support the new system, they can't plausibly claim to support the linux desktop. I just hope whatever happens will result in less online whining from linux-using Nvidia customers.

Re: The death watch for the X Window System has probably started

#399
One thing that a great majority of commenters here seem to be missing is that Wayland's issues that make it unsuitable to replace X Windows will not just be ironed out in a couple of years (at least not in a way that would be an improvement over X), because it is flawed by design.

The thing is, Wayland developers do not want you to take screenshots or automate input events (injection and interception). Those are both "power-user" and "accessibility" features. So respectively those who like to use the Unix (or other OS) programming environment to its full potential (hackers?), and the blind/visually impaired will have a hard time if Wayland gets forced on them.

It is possible to solve those problems with effort on a per-compositor basis (meaning less choice for users and more redundant programming effort - programs that interact with GUIs will need to have separate code for each compositor!), or with protocol extensions - that, of course, would not be universally accepted. For example, I think no compositor currently give a Wayland user the option to mess with input events (key presses, etc.). This means no hot-keys!

Quoting Red Hat: "Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so."

An interesting Reddit discussion: "It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it." [7]

See [1] [2]. And my previous comments on the same topic: [3] [4].

Another thing wrong with Wayland is that forced compositing means noticeably (in interactive applications) more latency.

Small nitpick regarding the blog post: Chromium depends on GTK3.

[1] https://wiki.gnome.org/Accessibility/Wayland

[2] https://www.freedesktop.org/wiki/Accessibility/Wayland/

[3] https://news.ycombinator.com/item?id=20310200

[4] https://news.ycombinator.com/item?id=20308011

[7] https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...

Re: The death watch for the X Window System has probably started

#400
post #148

Earlier quoted context omitted.

> Every GPU vendor but Nvidia supports these APIs. > About a year ago Nvidia announced “Wayland support” for their proprietary driver. This included KMS and DRM support (years late, I might add), but not GBM support. They shipped something called EGLStreams instead, a concept that had been discussed and shot down by the Linux graphics development community before. That’s pretty damning for Nvidia. I can see why the d…

The ideal Linux laptop is one with just Intel integrated, and no discrete GPU. Honestly, Intel GPUs are decent enough, even if you want to do some mild gaming. Handing two GPUs on a laptop in Linux doesn't have the best support. A lot of the Optimus/Bumblebee stuff is not very well maintained.

> even if you want to do some mild gaming

Just to back this up, I've recently bought a non-touchbar 13" MBP from 2016, and been amazed at the amount of games I've been able to play no issues on the Intel graphics in it.

Post reply on HN