Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The death watch for the X Window System has probably started

utcc.utoronto.ca

Post reply on HN
Print view View original

181–190 of 518 posts

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

#181

Post by konqi »

cwyers wrote: post #174
zrm wrote: post #135

Earlier quoted context omitted.

> The only reason they're gaining control is becuase the rest of the linux userbase has decided that although they might complain about Red Hat's work on hacker news and deride it as "not good", it's actually good enough that nobody wants to use any alternative projects to the ones red hat works on. The decisions they're making are what prevents others from doing that. When they make a bad choice you would be willing…

> Then since no one else can justify spending the resources to replace the entire Linux userland Well that's just it, though. Red Hat is spending the resources to maintain and build much of the Linux userland. And they are no longer willing to do so in a way that helps support the userlands for the BSDs or the buffet mentality of building the Linux userland. If people don't want to use the Red Hat userland, then they…

>Red Hat

>Red Hat

>Red Hat

is not the owner of Wayland, of the repositories, of the protocols, and is not the biggest contributor base

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

#182

Post by djsumdog »

dmix wrote: post #148
Boulth wrote: post #92

Earlier quoted context omitted.

Sway generally doesn't support NVIDIA, or it's rather NVIDIA that doesn't support common kernel modes that Wayland needs. Details here: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html

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

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

#183

Post by sprash »

kaendfinger wrote: post #21
beowulfey wrote: post #16

Is there any plan by Wayland to incorporate ssh forwarding? Last I heard it wasn't in the cards, and I think that feature is useful enough; it's probably the only feature I really would miss.

Waypipe does this in a really similar way to x forwarding. https://gitlab.freedesktop.org/mstoeckl/waypipe/

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 would have real network transparency even over slow low bandwidth connections.

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

#184

Post by metildaa »

dmix wrote: post #148
Boulth wrote: post #92

Earlier quoted context omitted.

Sway generally doesn't support NVIDIA, or it's rather NVIDIA that doesn't support common kernel modes that Wayland needs. Details here: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html

> 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 HP x360 with a Ryzen 2500u is rather good, and can be had for ~$400 on eBay.

It did take a full year for all the bugs to be sorted out (random kernel panics & freezing), these same bugs were problematic in Windows 10 tho. Neither OS had good platform support for quite some time...

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

#186

Post by csande17 »

emersion wrote: post #88
csande17 wrote: post #79

I would use Wayland, but the most actively-developed tiling window manager, sway, doesn't work with the NVIDIA graphics card I own. And come to think of it, isn't that a really weird problem to have? On X, the compositor (responsible for actually drawing all the windows on the screen) and the window manager (responsible for deciding how to arrange the windows and what their title bars/borders should look like) can be…

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.

The problem is that wlroots is one of several libraries with this goal.

Say I wanted to roll up my sleeves and implement NVIDIA's proprietary interface myself. (Or say in a few years we come up with some new, even better way to allocate buffers or whatever.) On X, I can write a compositor that uses that interface, and it'll work with basically every window manager written since the early 90's.

On Wayland, I could patch wlroots, but then I'll only be able to use window managers based on wlroots. If I want to use a different window manager, I'll need to patch a different library. And depending on how stable wlroots's interface is, I might need to maintain patches for old versions of it depending on how maintained my preferred window managers are.

The Wayland situation is probably fine if you only ever want to use the latest version of the most popular two or three desktop environments. But speaking personally, if I wanted to do that, I'd just run macOS.

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

#187

Post by sprash »

kabwj wrote: post #37

Can Wayland currently handle several monitors with different DPI? And by “handle” I mean, being able to resize (blurry, I know) windows that are not DPI-aware transparently when I move them between monitors. What Windows has been able to do for years now.

It would have been possible if Wayland decided to include drawing primitives. They religiously decided against it.

Now every toolkit has to somehow manage dpi scaling by itself. Actually it is a huge mess.

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

#188

Post by pantalaimon »

voldacar wrote: post #133
nwallin wrote: post #120

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…

>For gaming, the latency is bad and always on vsync is horrible. They've fixed the 60Hz lock though, fortunately. This only applies to gaming though. So there is no way for a game to bypass wayland and write directly to the fullscreen framebuffer? You're just stuck with an extra frame or two of latency?

The idea of using DRM Leasing to allow the full-screen app to exclusively grab the framebuffer for itself has been floated around.

I'm not sure how graceful the alt+tab behavior of this approach would be though.

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

#189

Post by _emacsomancer_ »

AsyncAwait wrote: post #165
_emacsomancer_ wrote: post #158

Earlier quoted context omitted.

> Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. I'm not that familiar with openRC or s6 (I've played with them, but don't use them on any 'real work' systems), though my…

I guess I did not explain myself properly, s6 is not actually a wrapper over sysvinit in practice, it's its own thing, like runit. But like runit it relies on bash scripts, which are not declarative and open to a wide variety in quality, just like with sysvinit. Also, runit does i.e rely on logind, which everybody forgets systemd took upon themselves as consolekit was unmaintained. Why does runit rely on systemd's wo…

> 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 horribly difficult-to-debug boot issue with systemd: a daemon failing in an unexpected way caused a failure to bring up any services, but without systemd failure messages. The problem was a systemd emacs service. 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.

I've since reverted to launching emacs daemons via .xinitrc or the like on my systemd boxes, so that any emacs init issues don't pull the rest of systemd down.

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

#190

Post by acdha »

traverseda wrote: post #118
izacus wrote: post #111

Earlier quoted context omitted.

> It seems like a lot of those projects just aren't interested in accepting pull-requests from outsiders. What kind of pull requests though? Minor fixes or big architectural decisions like ssh forwarding and security features? Because there's a difference between just accepting PRs and public ownership of future project direction. The second usually doesn't result in a successful project.

>PRs and public ownership of future project direction. https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar That's kind of the point of open-source, public ownership. Sure, you need someone to be in charge and reject outright bad ideas, but when you're refusing to add options that support other people's personal preferences that's when it's starting to become a problem. It's all these authoritarians that think…

Do you have examples of working pull-requests which were rejected for what you consider bad reasons? I’m sympathetic to maintainers choosing not to take on additional technical debt so I’d especially be looking for things like willingness to shoulder long-term support costs and other constraints imposed by accepting a PR.
Post reply on HN