Live data from Hacker News

The death watch for the X Window System has probably started

utcc.utoronto.ca

201–210 of 518 posts

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

#201

I seek to be enlightened, not to flame: what exactly is so wrong with X that it can be retrofit to work better? Wayland is taking a while, which is expected sure, but for now, X works fine although with issues.

The design assumptions that went into making X were made before the modern computer or Linux existed.

Modern X is a Frankensteinian collection fixes upon fixes and unmaintained code.

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

#202

I can't say it any better than JWZ did over 15 years ago. This is the result of the Cascade of Attention-Deficit Teenagers model and is why Linux will not approach Windows or OSX in usability. Cannot link to his site: JWZ dot org /doc/cadt.html A complete teardown and rebuild of the whole ecosystem (because X succccckkks) is fun! Making something backwards-compatible, or standardized, or polished that "last 90%" so i…

X does suck, it's incredibly insecure and the workarounds for regaining some sense of application isolation are obtuse and resource-draining. I could go into all the little technical details but the fact is, X has been around for decades and its core was made for much simpler machines.

It's time for something new. This isn't attention-deficit developers at play. People have spent a lot of time on the Wayland ecosystem. This isn't just some kids hacking away in their basements ignorant of better development practices.

You argument holds up for many Linux components, but not for X/Wayland. It's preposterous to take the stance that no component in the entire Linux ecosystem ever needs to be replaced.

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

#203

Earlier quoted context omitted.

HiDPI. It's somewhat unusual for a top end laptop to have 1920x1080 screens these days, and Wayland doesn't support 4k very well. You can upscale, but it looks like garbage, or it has a 2x mode, which draws image and such slightly too large, or you can deal with everything being tiny. For gaming, the latency is bad and always on vsync is horrible. They've fixed the 60Hz lock though, fortunately. This only applies to…

A lot of what you're saying seems due to a particular Wayland compositor, not to Wayland.

That is the problem right? Whenever there is a functionality that you could get with X11 by tweaking configurations files you have to write you own complete new Display Server in Wayland to have that functionality.

This is especially true for people that prefer low latency over tear-free rendering.

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

#204
"Why I'm not going to switch to Wayland yet"[1] argues that:

"for simple things using the compositor's screen shot tool is fine. But what if I don't like the screenshot tool for my compositor of choice? My experience with the GNOME screenshot tool (granted this was pre-wayland) was that it wasn't as good as, say, shutter, which has a lot of options, let's you easily crop and edit the screenshot from inside the screenshot tool etc. And then swaygrab doesn't even (currently) have an option to capture a rectangular region."

There are some other things this article mentions which are important to me, like Wayland's lack of color picker tools and xdotool functionality.

Wayland seems just way too immature for me to use for now. X works great, does everything I want, and I see no compelling reason to switch.

[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...

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

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

True, I don't do any laptop gaming. Intel GPU's seem to be sufficient as long as it can easily power a full HiDPI internal monitor + 4k external monitor... which Librem's Intel 620 GPU is listed as supporting but it looks like Librem's 15 v4 only has an HDMI port and not usb-c/displayport, which limits it to 4096x2160@30Hz instead of 4096x2304@60Hz. So I guess you'd have to look at Lenovo, HP etc for top tier..

Sadly my work uses all Macbrook Pros, which are amazing machines), but I'm scared to install Archlinux on them. The Archlinux Macbook wiki pages are 4yrs+ old.

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

#206

Earlier quoted context omitted.

NVIDIA doesn't support GBM, which is the standard for buffer allocation. Use nouveau. >The last issue could be solved with a reusable library that provided basic compositor functionality for window managers. This is pretty much what wlroots is.

> NVIDIA doesn't support GBM If Nvidia don't support it, how much of a useful standard can it really be?

GBM is a very useful standard if you only ever want to request buffers from drivers that use the Linux kernel's GPU buffer management code and modesetting code. (Preferably only Mesa-based drivers too.) NVidia doesn't use this and probably can't for licensing and other reasons. If you want to talk to any graphics driver that isn't correctly and intimately entwined with the right parts of the Linux kernel, GBM is basically useless. It is not in any way, shape, or form a generic standard for buffer management.

(In principle GBM isn't quite a single-implementation Mesa only standard - third party implementations are possible, though the only one that exists right now is by ARM for their newer Mali GPUs. People seem to have had mixed results with it and I'm not sure it's even intended to run desktop Wayland.)

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

#207
post #199

Earlier quoted context omitted.

> But like runit it relies on bash scripts, which are not declarative and open to a wide variety in quality, just like with sysvinit. In theory, this makes sense, with potential issues of poorly written shell scripts. In practice (I assume arising from its increasingly baroque growing complexity) systemd ends up with stability issues which aren't pleasant from an end-user perspective. Setting shutdown aside, I had a…

> On one boot I had an issue in init.el which caused emacs initialisation to hang, so the root cause wasn't systemd. But systemd didn't fail gracefully (or informatively) in this case. And it took me a while to figure out why systemd wouldn't bring up any services, since it wasn't reporting to me that the emacs service (or any service) had failed If it’s hanging it hasn’t failed. If that daemon is configured as a blo…

But as far as I can tell, the Emacs daemon shouldn't be a blocking dependency. Here's the systemd unit definition I would have been using at the time: https://wiki.archlinux.org/index.php?title=Emacs&oldid=46958... . And here's a more recent one: https://wiki.archlinux.org/index.php/Emacs#As_a_systemd_unit . Neither of these should be blocking dependencies, should they? `WantedBy=default.target` doesn't make it blocking, does it?

Is there something more that should be added to these sorts of unit definitions to improve graceful failure scenarios in systemd?

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

#208

Earlier quoted context omitted.

> NVIDIA doesn't support GBM If Nvidia don't support it, how much of a useful standard can it really be?

It's an nvidia problem, not a standard problem.

This is a standard problem. You can't be a standard if the market does't care about you. You are just a specification and guidelines.

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

#209

I'm really not very sad to see X go. It was old, creaky and insecure. As advanced and cool as it may have been at one time, and as much as I respect the people who worked on it, it's time for it to go. As for the people complaining about Wayland possibly missing some of X's features, remember that it takes time for something to mature, to accrete features and fixes, and Wayland hasn't had that time yet. If we give it…

> As for the people complaining about Wayland possibly missing some of X's features, remember that it takes time for something to mature, to accrete features and fixes, and Wayland hasn't had that time yet.

It has been a decade, precisely how long does it need to catch up? I ask because from what I can tell it is still missing features that were standard in Windows Vista in 2008, when that OS switched to DWM and WDDM.

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

#210
post #17

Earlier quoted context omitted.

Where do we even begin? Windows managers? Consistent window decorations? Thousands of applications? Consistent performance? Redshift? Global keybindings?

> Windows managers? Sway/wlroots. > Consistent window decorations? This is up to individual compositors and toolkits. > Thousands of applications Like what? Any that rely on X specific behaviour run via XWayland. > Consistent performance Wayland in theory should be faster than X, but again, this depends on compositor. > Redshift Gnome has night-light on Wayland already. KDE I think just added it. > Global keybindings…

[deleted]
Post reply on HN