Live data from Hacker News

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

x.org

201–210 of 318 posts

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

#201
post #61

Earlier quoted context omitted.

Right, the name or any kind of lineage does not matter, Wayland is the X11 successor because it is the current seriously developed and improved open display protocol. Nothing about Wayland stole from X11, has any less legitimacy to be the post-X11 protocol than something called X12, or prevents anybody else from improving X11 or from working on an alternative they call X12 or anything else. I don't know why people ge…

Good point. And for those who need to connect over the network there are now FOSS implementations of RDP, for example. (And VNC, but the performance there is probably not so good.) Then there’s also proprietary solutions such as BeyondTrust and NoMachine. Yeah, I know RDP was developed in Redmond but from my layman’s perspective, it’s one of the best protocols for accessing a graphical desktop environment over a netw…

You're right, RDP is pretty good. Vnc is really bad in comparison.

SPICE is actually really good in the Linux world and solves many Vnc problems but sadly it never really took off.

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

#202

Great that development of X is apparently being restarted. Wayland is ok but it has many oversights like network transparency.

> Last edited Mon 18 Sep 2017 07:52:26 AM UTC

> This is not to say that there's an X12 project. There isn't.

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

#203

Earlier quoted context omitted.

does Wayland have network transparency tho?

Network transparency doesn't offer any tangible benefits for a lot of apps and desktop environments because they are drawn with bitmaps and textures rather than vectors. This topic has been done to death for the past decade. VNC and RDP won. X11 was a razor edge case and nothing more.

X11 just had a different usecase. It was not meant for internet but for many terminals on the local network. Hence the proto design which didn't consider latency a potential problem.

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

#204

X is almost 40yo, stable, reliable, difficult to maintain. Wayland is 15yo, barely usable. Any old timers remember 1999 when X was 15? Wayland is like IPv6 of desktops

I don’t identify as an old timer but I was using NCD X-Terminals connected to Data General Aviion back in the mid 90s and they were solid as a rock. XF86 also worked quite well in the late 90s but it did require a lot of work and there were warnings that certain settings could blow the monitor. Fun times.

to be fair, we had Keith Packard working with us at NCD during the mid 90's. it helped to have someone innately connected to X11.

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

#205
post #23

X is almost 40yo, stable, reliable, difficult to maintain. Wayland is 15yo, barely usable. Any old timers remember 1999 when X was 15? Wayland is like IPv6 of desktops

Wayland is usable. It is simply not fully used. Wayland is just a protocol and there are multiple implementations in different compositors. Instead of focusing on a single great implementation, there are multiple average and weak implementations. It puts quite a bit of pressure on desktop environment developers and it seems like they don't really care about many of the defined protocols. https://wayland.app/protocols…

> It puts quite a bit of pressure on desktop environment developers and it seems like they don't really care about many of the defined protocols.

The problem is that the existing protocols are missing key functionality that desktop environment developers need (source: I am one).

Want to list all the toplevel windows that are on a particular workspace so you can write a pager or taskbar widget? Nope, can't do it. The foreign-toplevel protocol and ext-worspace protocol (the latter of which has been in standardization purgatory for 2-3 years now) don't know anything about each other, so you can't do that.

Want to write a widget that lists windows and lets you do a bunch of operations on them? Well, you can, if all you care about is minimize, maximize, fullscreen, and close. If you want to pin/unpin windows, move them between workspaces, resize them, or move them around on the current workspace... nope, can't do it.

That's just two examples off the top of my head. Looking at the list of Wayland protocols, and then digging in to figure out what they provide shows them to be immature and severely lacking.

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

#206
post #83

Earlier quoted context omitted.

No it's not, it barely does any of the things X11 is useful for.

100% of the developers who know anything about how graphics works under Linux are focusing on Wayland. Development on Xorg is moribund, with only Xwayland getting significant attention. Hint: X was optimized for 1980s graphics, which was 90% simple blits, line draws, and fills mediated by the CPU perhaps with special fixed-function accelerators for those operations. In 2023, graphics is done with the GPU -- period. Y…

Sure but GTK and the gnome world is highly politicized by RedHat. KDE and Qt are much further away from cutting X11 off. I see the case for Wayland but similar to X11 it is already showing its age in poorly conceived design decisions. Desktop sharing for example should be a first class citizen in 2023.

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

#207
post #183

Earlier quoted context omitted.

Simply the fact that systemd turned logs into a binary format that can't be read with standard tools, and this was not (easily? at all?) possible ti cgange made me really strongly dislike it. systemd has its own tool to read its binary log format, but I've already seen it corrupt its own logs and fail to read it. And did they do the binary format for efficiency? Get this: I've never seen anything be inefficient due t…

I like some parts systemd does but binary format is travesty. And I do not mean "the fact it is binary is bad" but format itself. Example: strace systemctl status haproxy 2>&1 |grep /var/log/journal |wc -l 356 356 files opened (whole logging dir is around 800MB) only to tell me CGroup: /system.slice/haproxy.service ├─2428 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.soc…

Fortunately binary logging can be switched off and redirected to syslog on hosts where have control but can't replace the init system.

https://wiki.archlinux.org/title/Systemd/Journal#Journald_in...

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

#208

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D

Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. Similarly, Wayland has a bunch of good ideas, along with a bunch of functionality that isn't there yet. Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing. I think systemd and Wayland are actually opposit…

> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing...

Screen sharing was always a weak point in X11, actually. VNC servers like x11vnc use absurd, inefficient hacks like periodically capturing fragments of the screen and checking for changes [1] -- while an extension to provide change notifications exists, it's been unreliable for ages [2] and the standard advice is to disable it.

[1]: https://github.com/LibVNC/x11vnc#algorithm

[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909

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

#209

Earlier quoted context omitted.

Simply the fact that systemd turned logs into a binary format that can't be read with standard tools, and this was not (easily? at all?) possible ti cgange made me really strongly dislike it. systemd has its own tool to read its binary log format, but I've already seen it corrupt its own logs and fail to read it. And did they do the binary format for efficiency? Get this: I've never seen anything be inefficient due t…

The binary log format has a huge advantage: it allows for arbitrary amounts of fields containing arbitrary content. Unlike syslog, journald is trivial to parse unambiguously, and you can even dump binary data like crash logs into it if you really want to. It also parses universally -- you always know what the timestamp is, you don't need to craft a per-service regex. I'm not sure what would be a better alternative. I…

A well-designed, well-implemented binary log format? Quite possibly so.

Let's create a logging daemon that creates Apache Parquet files, for instance. Or at least uses a well-established, well-tested binary row format, with existing tools capable of easily unpacking it and working with it.

Maybe journald has a good enough API to stick to it. I hope it's going to be replaced with a saner implementation of that API, like Pipewire did with Pulse Audio.

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

#210
post #194

Earlier quoted context omitted.

> Until they have to share screen in a meeting This was absolutely true, until I switched to pipewire. Once I did, this started to just work, with no issues whatsoever. (No configuration required, just followed Debian's package dependencies switching to pipewire and it started working in Firefox.)

So then, in other words, the default setup is still broken?

No, for many distros the default setup is now pipewire.
Post reply on HN