Live data from Hacker News

X12: Requirements for a successor to the X11 protocol (2013)

x.org

311–318 of 318 posts

Re: X12: Requirements for a successor to the X11 protocol (2013)

#311

Earlier quoted context omitted.

I don't do Windows development, but I remember that used to be the rebuttal from game devs that Linux missed the point about all the ease of use features that Microsoft provided. Although all the other Direct services are dead, have they not been replaced with new versions?

And it was true at the time, thought the rebuttal would be "use SDL then" -- it did provide equivalent functionality, packaged into a single library. They were replaced not by new versions, but by new or even existing libraries/subsystems, that are not marketed as Direct anything anymore. Just like alsa or pulse are not marketed as SDL or Open anything either.

TIL, thanks!

Re: X12: Requirements for a successor to the X11 protocol (2013)

#312
post #288
post #97

Earlier quoted context omitted.

Most of the criticisms in this talk are solved with DRI3. Also this guy makes money with a consultant agency that mainly works on Wayland and indirectly profits from shitting on X11. This is not a neutral source.

Right? I really feel like not enough attention is paid to the question of: Who is paid to work on "the successor to X" and what influences are at work there? Seems to me that would be an obvious place to look for "why Wayland sucks," given that unfortunately, "paid" sometimes leads one to "exclusivity."

Seriously, if you downvoted this without replying, you're a coward. At LEAST answer the question. Maybe I'm wrong?

Re: X12: Requirements for a successor to the X11 protocol (2013)

#313
post #190
post #186

Earlier quoted context omitted.

A little weird to classify the Steam Deck as a "personal computer". It's a special-purpose handheld gaming device that just happens to run Linux & Wayland under the hood. While I wouldn't call Android phones "personal computers" either, they're much closer to being the "most popular Linux PC" than a Steam Deck is.

I did say "arguably". I mean more in the sense of the hardware it uses, i.e. it's PC-compatible (x86) hardware that runs a desktop linux distribution by default.

The Steam Deck is literally a PC, no doubts about that. It's even more "P" than many other "C"s, like most Apple hardware for instance. But I think that the notion that it somehow validates Wayland as mature tech is kinda weak.

It appears that the justification for switching to Wayland in many distros (just like systemd before it) was so that the devs could actually abstract away work on these components and invest time into their flagship features (WM, filesystems, shells, look & feel, the works). For what its worth, looks like this was achieved.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#314
post #310

Earlier quoted context omitted.

Microsoft releasing worse implementation for competing system? How surprising. /s The linux team client seems to be completely unmaintained and might be thrown away soon. If you need to use teams, use it in a browser.

The Linux Teams client has been unceremoniously abandoned. The debs have been removed from the ms-teams repository. The download instructions haven't been updated, it's managed shockingly poorly.

the rpm repo is also empty, in the same unceremonial way.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#315

Earlier quoted context omitted.

What do you mean by all Wayland's calls being blocking though?

It isn't really Wayland's calls itself, I prolly stretched too much there, but the main thing is the async discussion usually comes up in the context of running applications remotely, which Wayland simply doesn't support. If you do a loop of XInternAtom (which btw you shouldn't do, even in xlib - notice that there's also XInternAtoms, plural, for that kind of thing which batches them to reduce wait time...) locally,…

> It isn't really Wayland's calls itself, I prolly stretched too much there,

Do you mean simply incorrect i.e., that Wayland calls are not all blocking? Or do you mean that in practice there are some important high-level situations that do require a round trip despite the low level purporting to be mostly asynchronous?

> Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.

Wayland can run to remote displays though, right? You could argue it's not complete or well supported or nicely integrated into the core protocol or whatever, but you can literally use it today and probably have a package to do it available in any Linux distro you're using (e.g., waypipe). So it's hard to see what you're getting at. Wayland may not have been made with transparent networking support foremost in the protocol but AFAIK the idea was always that you'd be able to do remoting by forwarding buffer contents with the protocol.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#316

Earlier quoted context omitted.

Yes I can confirm that Wayland runs fine without systemd! I am on Gentoo and using openrc and sway runs fine. The only thing that might kind of rely on systemd is sway-idle which wants logind (or to run as root iirc). I know you know this, being the sway and wlroots maintainer and all but I figured I would show a concrete example of this working fine.

FWIW, swayidle only has an optional dependency on logind. It can be built without. In fact, we're even discussing removing the logind-related features from swayidle. (swayidle never required running as root though.)

Whoops! The Gentoo use flag on swayidle says

    elogind : Enable support for rootless session via elogind
I think this is just a generic description shared between all packages with this flag though!

Maybe I can suggest that this be fixed to reduce confusion.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#317

Earlier quoted context omitted.

You absolutely can. I’m single stacking IPv6 on my fresh hetzner box. Cloudflare in front of web services and it just works(tm). For everything else - Argo can do arbitrary TCP (requires cloudflared though) and then you can start bugging your ISP about the very real need for IPv6.

> Cloudflare in front of web services and it just works(tm). Well... yeah? That's adding support for both stacks; just because you farmed it out to a middle-man doesn't mean that it's not there.

> Well... yeah? That's adding support for both stacks; just because you farmed it out to a middle-man doesn't mean that it's not there.

Not strictly true. It means that you only have to worry about IPv6 addresses in Layer 7, and you can forget about layers 2 and 3 altogether.

And Layer 7 isn’t a problem for people who should be deploying IPv6 right now because https://ipv6bingo.com/

Re: X12: Requirements for a successor to the X11 protocol (2013)

#318
post #85
post #84

Earlier quoted context omitted.

I disagree. It's a relatively standard distro up until the GUI layer, based on Gentoo. I'd agree that Android is something else, but ChromeOS is mostly the usual GNU + Linux stuff, and a weird display server which is Chrome rendering direct to the screen.

Then have fun running GNU stuff on ChromeOS, specially the devices that don't support the GNU/Linux sandox (crostini). Maybe take advantage of WASM for it. And even if Crostini is available, the usual stuff https://support.google.com/chromebook/answer/9145439 -- Cameras aren't yet supported. -- Android devices are supported over USB, but other devices aren't yet supported. -- Android Emulators aren't yet supported. -…

A bit late to this party, but you are woefully, badly misinformed as to what ChromeOS is, and what you can run on it. Well over a decade ago, I was running a full suite of gnu-linux devtools, natively, within chromeos.

You don't even need to install a chroot from another distro. Just get a gcc (chromebrew was the first to package this), and the rest is just gentoo linux (with portage ripped out - and in the early days, you could run a shell script which PUT PORTAGE BACK IN).

And if you take the time to understand the wierd partitioning layout, a couple of bind mounts in the right places is all you need to get the chromeos gui file manager (which is rather crappy, btw) to see your stuff.

Post reply on HN