Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

x.org

Post reply on HN
Print view View original

261–270 of 318 posts

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

#261

Post by dale_glass »

throwawaylinux wrote: post #260
dale_glass wrote: post #178

Earlier quoted context omitted.

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…

If an application provides some standard command line tool that allows its internal data to be output as formatted text, then it in fact can be read with standard tools and manipulated with shell pipelines and scripts. Plain text files are nice where possible, but binary formats are not automatically going against the Unix Way.

And that's exactly what journalctl -o json does

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

#262

Post by dale_glass »

nine_k wrote: post #209
dale_glass wrote: post #178

Earlier quoted context omitted.

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, li…

The format is documented: https://systemd.io/JOURNAL_FILE_FORMAT/

What issues do you have with it?

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

#263

Post by yarg »

dark-star wrote: post #96

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

I downvoted for the edit.

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

#264

Post by yarg »

Aardwolf wrote: post #162
dark-star wrote: post #96

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

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…

That's fucking terrible.

A compressed log file can be implemented with append only writes.

A hash validating defragmenter can be implemented in case the compression tree becomes too lopsided.

(It's a log file, if it's not small enough that you can store two copies, you're logging too much.)

The reader itself has zero need to perform writes, letalone where it can corrupt the binary.

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

#265

Post by peoplefromibiza »

lizknope wrote: post #147
peoplefromibiza wrote: post #63

Earlier quoted context omitted.

> Anyone who believes that XFree86 was stable in 1999 was apparently running a different XFree86 to me XFree86 on Linux wasn't very stable in 1999 (although it was more than usable, more than Wayland is today). X11 on IRIX in 1999 was pretty stable. Parent said X, not specifically XFree86. also something to consider: how many people were working on Xfree86 in 1999 and how many people are working on Wayland in 2023? W…

XFree86 worked fine for me since 1994. I sometimes had problems when exiting a video game like Doom or Quake. SVGAlib would give problems but that wasn't X.

Yep, my point was my experience in 1999 with XFree86 was with Linux, which was less stable than today per se, before that I only used Xsgi on SGI Workstations, which was proprietary and was already HW accelerated.

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

#266

Post by emersion »

chlorion wrote: post #215
emersion wrote: post #175

Earlier quoted context omitted.

This used to be true, but not anymore. We have upstream support for FreeBSD in libwayland now. Other BSDs have MRs which are only waiting for CI support. Wayland itself has nothing to do with systemd, many users are running Wayland without systemd.

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

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

#267

Post by happymellon »

kelnos wrote: post #189
destructionator wrote: post #117

Earlier quoted context omitted.

This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite. A few key points: 1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns…

> Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn. This I think is a key insight. I talk about this in another post, but I've been working on "porting" parts of Xfce to Wayland, and there are so many things missing in Wayland that have nothing to do with "graphics" that means that Xfce+Wayland will be missing a lot of useful features until/unless W…

This sounds suspiciously like the conversations around "just use OpenGL/Vulkan instead of DirectX".

Because DirectX is more than just Direct3D?

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

#268

Post by lproven »

pjmlp wrote: post #85
lproven wrote: 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. -…

> Then have fun running GNU stuff on ChromeOS

I do. My only ChromeOS device at present is an old Thinkpad T420 with a Core i5 and 6GB of RAM. It runs very quickly with ChromeOS Flex. Currently I have Firefox ESR running on it, and DOSemu. Inside DOSemu I have MS Word for DOS.

It's a Linux. It runs Linux stuff thanks to a built-in feature, and since Flex came out, the Linux support has improved visibly: so for instance Firefox now works properly with either a full titlebar or none, and this depends on the settings within Firefox not on ChromeOS.

It works, it runs, it's useful, now, today.

Personally I don't give a toss about any of the other things you mention. It plays videos smoothly, it's fast and responsive, and my webcam works. I've tried Skype, Whatsapp, Facebook Messenger and Zoom in ChromeOS and all worked fine.

Sure it may be limited. I am not denying that. But it's selling well up against Windows and Mac, which is something no other Linux distro has ever managed to do. Despite all their fancy acceleration features and being free, ordinary consumers are not interested, even though they are FREE.

ChromeOS is not free: you can only get the full version by buying it on custom hardware, and you need a Google account to use it. Those are significant drawbacks compared to every free distro...

And yet 10x more Chromebooks sell per year than all the free distros put together can GIVE AWAY.

That is not just noise. That is no rounding error. That is massive.

The year of Linux on the desktop came, over half a decade ago now, and the Linux world was too busy with infighting and squabbling over Snap vs Flatpak and other pointless nonsense to even notice that the mainstream consumer world has adopted Linux bigtime.

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

#269

Post by oynqr »

kelnos wrote: post #199
armistace wrote: post #182

Earlier quoted context omitted.

I'm on Arch on my work machine and it started working with pipewire about 3 months ago... no config necessary just works as intended both screen and window. There are some others at work on Ubuntu LTS but that is because Ubuntu is using ancient packages.

Ah, but the reply was about defaults . Do any of those distros ship with Pipewire as the default? If so, I'm sure it hasn't been since 2019 as the original poster claimed.

Pretty much all distros ship pipewire. Just not as the default audio server.

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

#270

Post by vetinari »

nine_k wrote: post #218
mort96 wrote: post #118

Earlier quoted context omitted.

I mean, you can get screen sharing to work. But there are like 3 different incompatible "standards" for how to do it. There's no single simple answer to "how to record the screen in Wayland". This has been the state of screen sharing on Wayland for at least 7 years. I'm also very curious about what's envisioned for global hotkeys. Surely we don't expect people to manually go to their system settings and configure som…

I don't see why a there cannot exist a daemon that handles these IPCs in a standard way (e.g. a pipe), and which can be politely asked by apps to map particular hotkeys. An API / UI should be available for the user to review and customize the mapping, and to resolve possible conflicts. This is basically the approach that exists in macOS for many years; I haven't heard a ton of criticisms towards it.

The issue is being thought about (see https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...), and then there is a problem with changing the existing habits.

As you can see with screen capture, even if the api is available, but it will take years to adopt, with some intentionally dragging their feet -- it is different after all, and the old way worked for me, etc, etc.

MacOS ecosystem moves much faster in this regard; mac users expect rapid adoption of new apis, and do not have 20+ years old bash scripts that should continue to work untouched.

Post reply on HN