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

191–200 of 518 posts

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

#191

Post by robert_foss »

chrisseaton wrote: post #175
emersion wrote: post #88

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?

NVidia has a horrible history of Linux support.

GBM works just fine, they've simply chosen not to support it.

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

#192

Post by lkirk »

mimimi31 wrote: post #13
lkirk wrote: post #3

I'm also a heavy user of an X-only window manager (xmonad). Learning about this makes me wonder if I should start learning how to work with another window manager so I'm not caught off guard when something stops working.

Do you know about Waymonad? It's supposedly Xmonad for Wayland and uses wlroots like sway.

I've heard of it, not sure how mature it is these days. Maybe I'll give it another look

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

#194

Post by 0815test »

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…

If you don't like the current maintainers' policy on "future project direction", you can always fork the project.

Yes, this involves an increased maintenance burden since you need to actively review what the upstream is doing and figure out how to cleanly pull their changes - but guess what, that's the very same burden that dealing with your proposed changes would have placed on the upstream themselves! "Authoritarianism" doesn't really come into it.

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

#195

Post by sprash »

emersion wrote: post #147
imode wrote: post #109

This is troublesome, and it feels like "progress" for the sake of "progress" rather than actual improvements. The X Window System is time-tested technology, while Wayland, from what I've seen and read, is not. This isn't a good thing to me, especially considering NVIDIA hardware doesn't seem to be well supported. Someone come along and correct me, please.

X11 is a pile of hacks. Have you ever tried to read the source code? When the X11 devs design a new system and stop maintaining X11, it's likely that X11 is not in a good shape. >This isn't a good thing to me, especially considering NVIDIA hardware doesn't seem to be well supported. Someone come along and correct me, please. It's the other way around: NVIDIA doesn't support GBM, the standard for buffer allocation.

How about cleaning up the mess.

The most "mess" is coming from old graphics hardware drivers, a task that is now managed by the kernel.

Besides, the "mess" performs better than Wayland in many use cases thanks to DRI3.

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

#196

Post by hedora »

notatoad wrote: post #63
nextos wrote: 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…

I think they are gaining control via a “dastardly power grab”, as you put it.

Software that I have relied on for decades no longer runs, and it is invariably because someone at RedHat consciously decided to break compatibility with the existing Linux ecosystem in some functionality regressing way.

This has happened with the Linux kernel, pulse audio, dbus, systemd, logins, systemd logger, wayland, gtk2->3, and countless others.

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

#197

Post by chrisseaton »

jniedrauer wrote: post #180
chrisseaton wrote: post #175

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.

But I mean what's the point of declaring something to be a standard if the important people weren't interested in implementing and supporting it?

Anyone can come up with a standard in isolation. Getting the relevant people on board and able and willing to support it is the useful bit.

Did they say they'd support it? If they never said they did it seems unfair to criticise. Are you going to support my graphics standard that I just made up?

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

#198

Post by DonHopkins »

mruts wrote: post #172
DonHopkins wrote: post #154

Earlier quoted context omitted.

Thank you, I hadn't heard of it before so I'll check it out! I'm not optimistic about Wayland, since early on they decided not to use an extension language, and that's not something you can have a change of heart about later, and then just nail onto the side. It would be interesting to see how Arcan uses L ua, which is a great language for that kind of stuff. It's a lot smaller and sleeker and better designed than Ja…

Instead of creating a half-assed extension language, a better solution is to have one language do both. Like Common Lisp for example.

Is Scheme a half-assed extension language? What about Guile?

How do you like Niels P. Mayer's XLISP-based Motif X11 toolkit widget interpreter, Winterp?

https://pdfs.semanticscholar.org/f169/54db7cb7c07ac842e31247...

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

#199

Post by acdha »

_emacsomancer_ wrote: post #189
AsyncAwait wrote: post #165

Earlier quoted context omitted.

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…

> 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 blocking dependency, waiting is the correct thing to do — this is why timeouts and health-checks are as important as making sure that your dependencies are as flat as possible.

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

#200

Post by ddevault »

csande17 wrote: post #186
emersion wrote: post #88

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.

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 pat…

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

The only successful one, to be clear. You would be unwise to base your compositor on any of the others (libweston, wlc, swc, etc). wlroots is suitable for basically any use-case.

Post reply on HN