The death watch for the X Window System has probably started • Hacker News Board

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

#151

Post by microtonal » Sun, Jul 07, 2019, 7:04 PM UTC

nextos wrote: post #104

traverseda wrote: post #86

Earlier quoted context omitted.

It seems like a lot of those projects just aren't interested in accepting pull-requests from outsiders. If they were more willing to compromise and cooperate I don't think they'd catch nearly this much flac.

Exactly. And for much smaller organizations and individuals, it is much harder to organize an alternative effort to this set of projects backed up by a big corporation (Red Hat). I only expect this to happen if Systemd and related efforts become really bothersome. Right now it is a big of a mixed situation. A better init system, and some modern basic userland infrastructure was needed. Systemd has brought some good t…

Exactly. And for much smaller organizations and individuals, it is much harder to organize an alternative effort to this set of projects backed up by a big corporation (Red Hat).

There are exceptions. Drew Devault and the rest of the Sway team did write wlroots, an alternative compositor for Wayland, so Wayland is less of a monoculture.

But it is true that it requires a lot of manpower, money, and will to develop an alternative to e.g. Wayland. However, I see the current situation more as the glass being half full. Imagine that we did not have Red Hat, and others pulling the weight of Wayland (and other technologies, such as Flatpak), the Linux desktop ecosystem would in many ways be hopelessly behind macOS, iOS, and Windows.

I think this is a better outcome than being stuck with 80ies/90ies graphics technology forever, even if it is not perfect.

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

#152

Post by zlynx » Sun, Jul 07, 2019, 7:05 PM UTC

nwallin wrote: post #120

voldacar wrote: post #7

Are there any major x11 features that wayland lacks other than remote operation over a network? I think at one point it locked the refresh rate to 60hz, has that been changed?

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…

HiDPI? Um, what?

I've been running Wayland gnome-shell on Fedora since Fedora 25, on a Dell m3800 and now a Dell XPS 15, both with 4K internal displays. I often connect to external monitors or projectors, either 1080p or 4K.

Wayland has better HiDPI support than X and has for a long time.

In order to make X work in any reasonable way you need to configure X to render at 4K all the time on all outputs and downscale using xrandr on 1080p displays. X cannot handle different DPI settings.

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

#153

Post by Sir_Cmpwn » Sun, Jul 07, 2019, 7:05 PM UTC

rrss wrote: post #150

ddevault wrote: post #136

Earlier quoted context omitted.

If this check were not here, Nvidia would still not work. This serves to reduce our bug report volume. However, by deleting these few lines of code (or specifying the appropriate command line argument), Nvidia could work tomorrow if they shipped GBM support.

If that check were not there, would intel for display + nvidia for compute work? Better chance than now.

The flag is there for you to override if you think you know better. We don't answer questions or provide support for any use-case with the proprietary driver.

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

#154

Post by DonHopkins » Sun, Jul 07, 2019, 7:06 PM UTC

carapace wrote: post #110

RIP ( I don't doubt for a minute that someone will pick up the slack, but that makes me wonder, who's gonna pay for it? Would you contribute to e.g. a Kickstarter for X Windows? FWIW, I'm not sure I would, meaning no disrespect I've been hoping to ditch X for something better ever since Don Hopkins opened my eyes to NeWS, &c. ) So there's Wayland. What else? Arcan? https://arcan-fe.com/about/ On HN: https://hn.algoli…

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

The Arcan developers should check out how Factorio modding works! (But then all work on Arcan would halt when for months while they were addicted to Factorio.)

https://wiki.factorio.com/Modding

Lua's main problem is that it isn't JavaScript (i.e. in JavaScript's enviably lucky position of ubiquitous dominance).

If I had a time machine, I'd go back and try to convince Netscape to use Lua 2.1 instead of inventing JavaScript (released December 4, 1995). And hire the Self guys (Dave Ungar, Randy Smith and the crew who eventually made the Java HotSpot compiler) away from Sun, and Mike Pall (LuaJIT) from wherever he was!

https://www.lua.org/versions.html

>Lua 2.1 was released on 07 Feb 1995. Its main new features were extensible semantics via fallbacks and support for object-oriented programming. This version was described in a journal paper. Starting with Lua 2.1, Lua became freely available for all purposes, including commercial uses.

https://news.ycombinator.com/item?id=12574290

https://channel9.msdn.com/Blogs/Charles/A-Conversation-with-...

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

#155

Post by rspeele » Sun, Jul 07, 2019, 7:07 PM UTC

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 it works on everybody's environment... is not.

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

#156

Post by petschge » Sun, Jul 07, 2019, 7:08 PM UTC

maxharris wrote: post #141

petschge wrote: post #115

Earlier quoted context omitted.

Sorry if I misread your comment and thanks for editing it to make it clearer. But why are you so opposed to having this featured backed into the display system? After all you point out yourself that all display systems and up with solutions for this work flow. Why not do it right and build it into the display system instead of adding it after that fact (and usually in an inferior qay)?

I'm against baking it in precisely because it's not the right thing. Network transparency in X11 led to a design that didn't scale to meet the needs of the vast majority of users: "The X11 protocol was never meant to handle graphically (in terms of bitmaps/textures) intensive operations. Back in the day when X11 was first designed computer graphics were a lot simpler than they are today. Basically X11 doesn't send th…

Sorry, but a stack overflow answer (that doesn't even seem to be written by you) that give a bad overview over how X11 does it is not an explanation of why it can not be done. Or why it should not be done given that all platforms develop abilities to do exactly what I ask for at some point anyway.

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

#157

Post by maxharris » Sun, Jul 07, 2019, 7:09 PM UTC

petschge wrote: post #156

maxharris wrote: post #141

Earlier quoted context omitted.

I'm against baking it in precisely because it's not the right thing. Network transparency in X11 led to a design that didn't scale to meet the needs of the vast majority of users: "The X11 protocol was never meant to handle graphically (in terms of bitmaps/textures) intensive operations. Back in the day when X11 was first designed computer graphics were a lot simpler than they are today. Basically X11 doesn't send th…

Sorry, but a stack overflow answer (that doesn't even seem to be written by you) that give a bad overview over how X11 does it is not an explanation of why it can not be done. Or why it should not be done given that all platforms develop abilities to do exactly what I ask for at some point anyway.

First, I never claimed that the quote was written by me! That's what the quote marks and link are for.

Why have ALL of the other major systems - Windows/ReactOS, NeXT/Mac, BeOS/Haiku, iOS, Android, etc. - not bothered with implementing network transparency in the core of their display systems?

Mind you, I'm not asking the question of why the people that made these systems all decided against building on X11. (That was answered ages ago by an Apple employee posting on Slashdot: https://developers.slashdot.org/comments.pl?sid=75257&cid=67...)

I'm sure that you could build a new system that has this network transparency feature. But I wonder how one would avoid failing the way that previous efforts failed:

- Y window system (http://www.hungry.com/old-hungry/products/Ywindows/)

- Berlin Project (https://web.archive.org/web/20041030075704/http://www.fresco...)

These things had network transparency, and they went absolutely nowhere...

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

#158

Post by _emacsomancer_ » Sun, Jul 07, 2019, 7:10 PM UTC

AsyncAwait wrote: post #124

_emacsomancer_ wrote: post #97

Earlier quoted context omitted.

> sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1 Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. And I would use the same car metaphor for comparisons with some of the other options, esp. runit, except with systemd in the SUV slot (e.g. my runit systems all behave themselves; my systemd…

> Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. 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 anythin…

> 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 understanding is that there is a proper openrc-init being developed.

I was actually thinking more of runit and shepherd, which provide their own init and daemon-management.

> > my runit systems all behave themselves; my systemd systems frequently hang on reboot

> Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related),

This is across multiple systems, from Arch boxes, which I've hand-configured to vanilla Ubuntu boxes, and ranges in behaviour from multiple 90s timers to just hanging on completely black screen until forced to reboot. There are certainly no obvious configuration issues on any these, definitely not crypttab or the like.

> shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that)

But, even timers aside, runit is faster than systemd on both boot and shutdown, for similarly-configured systems. And provides (me at least) a best user-experience than systemd.

runit shuts things down properly; with systemd I often have to literally 'yank the cord'.

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

#159

Post by AnonymousPlanet » Sun, Jul 07, 2019, 7:11 PM UTC

izacus wrote: post #26

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.

I see this a lot and now I need to ask: do you actually use it and find it usable? Every time I've tried it, it was plagued with problems (fonts, HiDPI issues, different environments) and horrible performance. I mostly had to resort back to NX, which is okish, but not better at all than Windows' RDP or better VNC solutions. So what's the big draw here?

It's not only ssh. I start GUI applications as a different user than the current desktop user constantly. It's a way for me to separate uses from each other. It gives you a huge amount of flexibility.

I do a lot of these things with Linux, you cannot do in Windows:

   - Log in, start an arbitrary program. Then log out, without the program stopping
   - Start a GUI application as a different user than the one logged in graphically
   - Start a GUI application that resides inside a container
   - Start a GUI application in the local LAN over ssh

Take those away and you take away the biggest edge Linux has over Windows.

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

#160

Post by zlynx » Sun, Jul 07, 2019, 7:11 PM UTC

mrob wrote: post #46

voldacar wrote: post #7

Are there any major x11 features that wayland lacks other than remote operation over a network? I think at one point it locked the refresh rate to 60hz, has that been changed?

Low latency. Wayland forces you to use a compositor.

And the latency depends on the compositor. I believe Arcan achieved 0 frame compositor latency with Wayland. I think the latest gnome-shell Mutter is there as well.

If your application can draw its frame and get its notification into the compositor before the compositor begins to draw, there's no need for any additional delays.

If your app cannot complete a draw in the time left in the frame by the compositor, then it'll be one frame behind.