Live data from Hacker News

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

x.org

221–230 of 318 posts

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

#221
post #179

Earlier quoted context omitted.

It is dbus api, and is able to work cross-namespaces (i.e. flatpak containers too). There no harm in using it in non-flatpak apps, at least you will be ready if your app ends up in flatpak. Wrt global shortcuts, I see that there is some work done. The intentional part isn't malice, as in not willing to implement it at all. It is about not implementing temporary solution, that will be quick and dirty, and then being s…

So kind of like Go and generics in that regard

It took Golang 12 years to attain generics. Wayland is already 14 years old.

To tell the truth, X11 took roughly 10 years (1986 to 1996) to get to a pretty usable, while pretty imperfect, state, and largely dominate Unix desktops.

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

#223

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 the default on RHEL since 2019. Wayland is the default on Centos since 2019. Wayland is the default on Ubuntu and Debian since 2022. In Arch, Wayland is the default for GNOME installs. Wayland is far from "barely usable" And yes, I remember 1999. X was a pain to get working properly with many graphics cards. Some things never change...

> Wayland is the default on Ubuntu and Debian since 2022.

In Debian, only GNOME has Wayland by default. KDE wouldn't be there for next release, and there's a long list of (unsupported) [0]

[0] https://wiki.debian.org/Wayland#Desktops

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

#224
post #120
post #21

Earlier quoted context omitted.

That's quite a stretch, Wayland and X (any X, 11 or hypothetical 12) are so vastly different that calling Wayland "the new X" is like calling Quartz "X for macOS".

It's not as far fetched as you'd think. My understanding is that Wayland is a result of X11 developers going together to design a new protocol based on the thoughts and ideas they've had for an "X12" throughout the decades.

[dead]

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

#225
post #166

Earlier quoted context omitted.

I don't really see the parallels. For the past few months I've been investigating and working on porting parts of Xfce to be usable under Wayland. It's astonishing the number of features that are just not implementable at all on Wayland, at least not without inventing new non-standard Wayland protocols. (Another option is refactoring the desktop environment so all the individual components run in the same process as…

> Even if fixing inherent problems in X11 (security, graphics rendering, etc.) would require compatibility breaks, personally I would find that preferable to throwing the entire thing out and having to build (and build on) an entirely new system. Why? X11 in the current state would need to be radically redesigned anyway. There's a bunch of stuff that long stopped making sense, like XDrawLine and similar. The networki…

The point may be to create a smaller, simpler, more secure protocol which is easier to develop against.

Unlikely it could be made more flexible than X11 though. But at least it could be made flexible enough.

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

#226

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

Easy. At the very least, IPv6 works well, and does not introduce new significant limitations.

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

#227
post #186
post #139

Earlier quoted context omitted.

> Wayland is 15yo, barely usable It's the default on several distros. I regularly play AAA games on my gentoo gaming PC, using proprietary NVIDIA drivers, on KDE Plasma, with little or no performance differences compared to X11. Even the Steam Deck, arguably the most popular linux PC, runs its default UI on Wayland.

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.

At least it's closest to a "Linux distro" software-wise.

(Otherwise Android phones would be the most widespread Linux devices with a powerful GUI.)

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

#229
post #207
post #183

Earlier quoted context omitted.

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

> Fortunately binary logging can be switched off

This is not switching them off. It is having the binary logs mirrored to text logs:

> […] by letting systemd forward all messages via the socket /run/systemd/journal/syslog.

So now you have two copies of the same information.

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

#230
post #196

Earlier quoted context omitted.

The problem is that systemd vs sysv-init is a false dichotomy. Systemd took over a ton of important non-init functionality, like DNS, logging, and interactive sessions. That could be fine if systemd did so in a nice and rock-solid way, but it was unpleasantly bug-ridden for years after being thrust on mainstream distros via a hard Gnome dependency. SysV-init sucks in many ways, it's well known, and I can personally a…

upstart: a broken design and abandoned by its author and canonical https://lwn.net/Articles/581548/ openrc: I don't believe openrc had a process supervision story 8-9 years ago. from what I recall at the time openrc was just a slightly better sysvinit. runit: I have a lot of experience with runit, and while it works, it has many footguns and is hard to use correctly. s6: a better runit with better footguns A great th…

Is systemd footgun-free? I doubt it.

(Runit worked reasonably fine for me for last few years, and it's way simpler and saner than SysV-init, at least.)

Post reply on HN