Live data from Hacker News

The death watch for the X Window System has probably started

utcc.utoronto.ca

501–510 of 518 posts

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

#501

Earlier quoted context omitted.

Not sure what you're talking about here, Haiku's window system has network transparency, with drawcall-forwarding, even. In fact there is an HTML5-based remote client for it!

That's cool! I didn't know that. Perhaps people might be interested in porting Haiku's graphics system to Linux to replace X11?

Probably not. The entire reason that the remote-drawing works is that the draw calls are passed through all the way up from the widgets and controls layer; for apps that don't use those (e.g. Qt apps, etc.) it's just a dumber VNC (we could make it less dumb, but, a little starved for time right now.) So then you would be porting the entire Haiku toolkit to Linux ... and at that point why not just use Haiku? We have our own kernel for a reason :)

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

#502
post #350

Earlier quoted context omitted.

OP explicitly mentioned Sway (based on wlroots), not Gnome (mutter). Besides, even Gnome can't handle XWayland with Nvidia today. And if you play games, especially in Wine, that's still a requirement. While Gnome developers bent under Nvidia's pressure, other compositor developers aren't interested in accommodating exceptions for blobs and wasting their resources on that. TL;DR: just ditch Nvidia and forget about all…

> OP explicitly mentioned Sway (based on wlroots), not Gnome (mutter) My parent commenter did not refer to Sway, that's why I rejected the claim that AMD is the "only way for you to get a usable desktop with modern features". > even Gnome can't handle XWayland with Nvidia today. And if you play games, especially in Wine, that's still a requirement I'm not sure what you're referring to. I've successfully launched and…

> I'm not sure what you're referring to. I've successfully launched and played Wine games with Nvidia proprietary drivers in Gnome with Wayland.

How exactly, when it's not supported: https://wiki.gnome.org/Initiatives/Wayland/NVIDIA

    There is currently no accelerated GLX support when
    running a GNOME Wayland session no top of the NVIDIA
    drivers, meaning X11 OpenGL applications will use
    software rendering.

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

#503

Earlier quoted context omitted.

Have you considered that maybe it is the other way around: The standardised solution is inferior and NVIDIAs superior? Given the fact NVIDIA engineers probably know a lot more about modern graphics stacks than some Redhat employee this seems likely.

https://old.reddit.com/r/linux/comments/bdip8a/nvidias_patch...

So the argument it is a bad implementation because it doesn’t work with the Wayland model... maybe that model is broken then.

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

#504

Earlier quoted context omitted.

Have you considered that maybe it is the other way around: The standardised solution is inferior and NVIDIAs superior? Given the fact NVIDIA engineers probably know a lot more about modern graphics stacks than some Redhat employee this seems likely.

Some NVIDIA engineers probably know a lot about graphics stacks; charitably I'd say that those ones aren't the ones tasked with insisting on EGLStreams, which lacks a considerable number of crucial features. To be honest though, NVIDIA engineers do not spend any time engineering graphics stacks at all; they write graphics drivers for stacks that are already largely specified. They're really good at shipping hundreds…

Instead of repeating arguments made elsewhere maybe this post sheds some light on why EGLStreams are a superior solution: https://devtalk.nvidia.com/default/topic/925605/linux/nvidia...

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

#505
post #483

Earlier quoted context omitted.

Or you know, just don't use the linux desktop. Nvidia's drivers are the only ones with a good Vulkan / OpenGL implementation, the other ones are underperforming severely. Nvidia also exclusively develops CUDA, so it basically it the only serious alternative for accelerating scientific workloads. Basically no-one cares what Kernel/Window system developers think as long don't cripple the Kernel severely enough that NVI…

> Nvidia's drivers are the only ones with a good Vulkan / OpenGL implementation On the contrary, Nvidia drivers have bad reputation of violating OpenGL spec left and right. Mesa is a lot more strict about OpenGL compliance. And they don't have Vulkan advantage either. Don't use Windows if you need good quality OpenGL.

This is not about compliance but rather features and performance. When OpenGL was relevant they had by far the largest set of well thought out extensions (mutidrawindirect for example). Their Developer Tools were second to none and they had CUDA as a unique value proposition.

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

#506

Earlier quoted context omitted.

Just b/c it defaults to X does not mean it doesn't work or isn't supported on Wayland.

It defaults to X, because it works very poorly with Wayland. Until very recently, it was impossible to run Gnome with Wayland at all (even though it theoretically supported Eglstreams), as there were many kernel errors generated by gnome-shell, etc. Now it sort of works, however, lags and freezes make it completely unusable in most cases. I am testing it every Fedora release. It _is_ possible to use Gnome with Waylan…

Developers don't blame nvidia b/c they don't want to open source their driver. They blame nvidia for insisting on others shouldering the tech debt of EGLStreams (a closed, proprietary nvidia-only solution with no documentation whose implementation can't easily be tested and verified by compositor authors) instead of enabling the use of GBM with their drivers like every other Linux graphics driver. nvidia doesn't have to open up their drivers for that, AMD's closed source driver (so not the Mesa stack), supports GBM just fine.

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

#507

Earlier quoted context omitted.

> May I suggest you buy an AMD GPU next time around This doesn't help anyone. I bought an expensive Nvidia GPU 6 years ago, when AMD support on Linux was really bad. What do I do, throw out a perfectly good powerful graphics card and spend another $500 to satisfy the needs of some newfangled software which doesn't solve any of my problems? I've had 6 years to experience the horrors of Nvidia, on multiple machines. I'…

I've never experienced those supposed horrors across multiple operating systems (FreeBSD, Linux, macOS and Windows 7/8/10), the only time I owned an AMD graphics card it was a total disaster, among other things I remember are really bad Linux drivers (proprietary or otherwise). I never had any issues with my current GTX 1080, 4xGTX 2080 workstations or the 2xV100 nodes I have access to.

> I've never experienced those supposed horrors across multiple operating systems (FreeBSD, Linux, macOS and Windows 7/8/10)

You've completely missed the point. The horrors are in compatibility. NVIDIA chooses to make it difficult for their customers to use their hardware with new applications, and they hold back the whole ecosystem. In addition to the topic at hand (Wayland), their release model holds back Linux kernel releases when their driver becomes incompatible with the upstream kernel because it is not maintained there.

If you just want to run whatever boring applications NVIDIA chooses to allow you to run, congratulations! Go enjoy your "experience", and play it "the way it's meant to be played"! :- )

> among other things I remember are really bad Linux drivers (proprietary or otherwise)

You're living about seven years in the past.

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

#508

Earlier quoted context omitted.

Some NVIDIA engineers probably know a lot about graphics stacks; charitably I'd say that those ones aren't the ones tasked with insisting on EGLStreams, which lacks a considerable number of crucial features. To be honest though, NVIDIA engineers do not spend any time engineering graphics stacks at all; they write graphics drivers for stacks that are already largely specified. They're really good at shipping hundreds…

Instead of repeating arguments made elsewhere maybe this post sheds some light on why EGLStreams are a superior solution: https://devtalk.nvidia.com/default/topic/925605/linux/nvidia...

Note the first comment there shows that their EGLStreams implementation shipped with vsync broken. EGLStreams seems attractive to NVIDIA because it was easy to implement (incorrectly). The features they talk about enabling on Tegra are not impossible with GBM, it just may involve adding a feature.

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

#509
post #483

Earlier quoted context omitted.

> Nvidia's drivers are the only ones with a good Vulkan / OpenGL implementation On the contrary, Nvidia drivers have bad reputation of violating OpenGL spec left and right. Mesa is a lot more strict about OpenGL compliance. And they don't have Vulkan advantage either. Don't use Windows if you need good quality OpenGL.

This is not about compliance but rather features and performance. When OpenGL was relevant they had by far the largest set of well thought out extensions (mutidrawindirect for example). Their Developer Tools were second to none and they had CUDA as a unique value proposition.

Their blob has no features advantage, and neither performance advantage anymore vs Mesa. While it is known to cheat and violate OpenGL spec to show better results.

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

#510
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…

You have never witnessed the D-Bus Death Rattle. I have. In top, indeed. (-:

* http://jdebp.uk./FGA/dbus-death-rattle.html

Post reply on HN