XMPP isn't even good XML. It's weirdly annoying.

XMPP absolutely requires an event-based parser, because the entire conversation from start to end is a single XML document that doesn't end until the client disconnects. So you absolutely need a parser that can deal with XML as it comes.

It's also not terribly high performance friendly. There's no clear framing, so the only way to tell where a message ends is to parse XML until you reach the end. You don't get a friendly protocol that tells you "Hey, next message is 520 bytes long", so that you can conveniently allocate a buffer upfront and read the whole thing in one go.

Besides that, it appears that XMPP's dialect deviates somewhat from proper XML, eg, by not allowing anything but UTF8 and forbidding comments. Those may be fairly minor, but they'd be problems early on, meaning you can run into trouble with the wrong XML libraries/code.

Extremely awful way to live though.

In the ideal NFT-world, everything is a NFT: your movie ticket, your school diploma, your house's deed, your membership in various organizations. The same wallet is also your way to pay for anything and log in anywhere. Your entire identity is connected to this stuff.

So under a model like that every time you interact with almost anything or anyone they find your wallet ID, and obtain the ability to scrutinize what you own, where you've been, what you pay for, how much you earn... This can be used not only to grant access but to treat you as an enemy if you happen to do something that given person/org doesn't like. And they can keep track of you after that forever.

Also this allows random people to send you anything they want, including nasty stuff. And then you can't just delete it, but have to pay to move it somewhere else. But the blockchain still records all of that, so that history is there for anyone to read. And stuff people can send you includes smart contracts which can be used to execute malicious code that steals everything you own. A bit like the good old times of VBS macros spreading by mail, only in this case they can empty your account with zero recourse or possibility of recovery.

They did find an use by the end, tickets. Owning a Bored Ape gives you the right to enter a party full of awful people. And you can't fake that because it's the blockchain they check.

Of course not even that is a good idea. Used this way you advertise your memberships to everyone you come into contact with. Imagine that every time you pay for a beer you let the bartender rifle through your wallet and see everything you're involved with.

I just took a quick look, and it's nowhere near a proper 4K movie. Everything looks visibly blurry.

Though I believe the tech still has a long way to go. If you look at experiments with using AI to generate modern, high res version of DOS game characters, it does seem like one could do a better job.

Of course that probably takes lots of work and tuning, and who wants to do that for the Holiday Special, frame by frame?

journald is not "boot logs". It's logs, period. From the kernel, from initrd, from every service that starts on boot, from every service that starts afterwards, and from any userspace application that cares to log to it, including unprivileged, user-made ones.

Also, "journalctl -o json" is a thing. But if you look at what comes out of that, it's not particularly compact. A lot of gains can be made with a better encoding.

And really, the difference between JSON and simple binary isn't that large. JSON is a complicated format that if it breaks can be troublesome.

Indexing is nice. You can ask for what happened 3 boots ago, or at 3 AM a week ago and get an answer near instantly, instead of futzing around trying to figure out which log file it is, and how to grep for a date/time range.

A tad pedantic, but yes, you can print out a QR code on a serial console.

For the best looking approach, people use UTF8, but you can draw a QR code entirely out of # characters and it'll work.

Then store it in a separate file.

Why? Why would I want to have that separate management to take care of? Or even care which file it's stored in exactly? On systemd systems I don't think of log files at all. There's a log system. It stores data however it wants to.

But why does that other file need to be binary?

Because it's in effect a simple database. And databases have advantages like being indexable, and having crystal clear field delimiters.

And because I simply don't care what format it's stored in. In traditional syslog systems, logs end up compressed, which is also a binary format that can be vulnerable to corruption.

I can always get text output and then feed that into vim, grep, or whatnot if I need to.

The scenario of "what if the machine dies and I have to look in the logs of a broken machine" is just a non-issue, because either I'll take 5 minutes to start a VM/live ISO to get tooling from a non-broken machine, or do log shipping if it's a serious concern.

I don't want to store it separately. I want it stored with the logs, but identifiable. Eg:

journalctl --user CODE_FILE=qrc:/qml/controlsUit/+webengine/BaseWebView.qml

And this gives me every message that comes from that particular file.

Or I can ask for all the errors coming from there with:

journalctl --user CODE_FILE=qrc:/qml/controlsUit/+webengine/BaseWebView.qml PRIORITY=2

An application I develop logs extra fields to journald. Which means I can trivially search anything by any field it logs. I don't need to craft a regex for that, because it's not being dumped into a text file I have to parse. There's no problems with things like spaces, newlines, or that "5" may be a value that can appear in 5 different columns and so needs work to grep accurately for, or work to do to match columns 3 and 7. I simply have columns and values I can trivially match.

The point of this is to get work done. I don't care if it's binary or what. I care it's extremely functional, and doesn't require me to futz around with grep or perl scripts to extract useful information.

Dumping log data out to JSON with binary data in it? This isn't a log from Adobe Dreamweaver or the latest image generating AI; This is kernel boot information. WTF is JSON doing in this conversation?

This is 2023. The log is for everything, both boot logs and applications, and servers. I don't see why my log system shouldn't be able to log say, HTTP Referer as its own field, and let me search by it.

WTF are you on about? Are you implying you couldn't reformat time strings before?

No, you shouldn't need to. "journalctl -o short-precise", "journalctl -o short-unix". The log knows the actual timestamp. It can spit it out in any format you might need, without effort, and without getting tripped up by internationalization issues because deep down it's a number, not a string it has to parse.

Cursors so you can resume processing??? File and line number. Done.

Works until you have log rotation, and the access.log you started parsing is now called access.log.1 or access.log.2.gz. There's a myriad such tiny annoyances.

Binary logs are better.

Journald can log a myriad fields, all clearly delimited. With binary logs there's no need to parse your logs with a regex, since every field is unambiguously extractable. There's no problem with messages containing multiple lines. You also can display time in whatever format you find convenient, and log binary data without any issues.

You can choose output formats and fields and dump in JSON for instance.

It's also a format with cursors which means it's trivial to resume parsing.

Journald basically obsoletes the entire mess of parsing logs and reduces it to complete triviality.

They don't. You're getting an incorrect impression because you're in an echo chamber.

Slashdot on the whole is full of crusty old greybeards. People who somewhere around the 90s thought Unix was the best thing ever, and since have not found any new development in the industry worthwhile. They still think of computers as "pets", when the industry has long moved on, and think the Unix Philosophy is all there is to making good software.

People more in tune with the times are found elsewhere.

Very easy. See, it's a tower, and towers have a bottom sitting on the ground. So you put your servers down there. And if you want go higher, you put a ladder and have floors inside it.

They also get pretty darn big, so things can be pretty roomy inside.

Microcode is actually very old and existed in the 8086 already: http://www.righto.com/2022/11/...

It also wouldn't have been that big of a deal to include it in Wayland as a formally specified fallback for when shared memory won't work (remote).

It absolutely would be a big deal. Wayland is a protocol specification. This would effectively double the size of it, saying it's mandatory to communicate both with shared memory and via sockets for every program that implements it. That's not really practical because you can imagine that a lot of programs would just skip the second part anyway, since nothing would break on a local desktop.

How does waypipe do when one GUI app launches another?

Perfectly fine. You can try it youself:

waypipe ssh $server weston-terminal

The existence of Waypipe proves Wayland COULD have supported a remote protocol from the beginning.

They explicitly didn't want to. Wayland communicates using shared memory and file handles, for optimal efficiency. What Waypipe does is interposing itself and encoding that stuff into a socket, and reconstructing the shared memory/file handle setup on the other end. That has performance costs, which is why Wayland doesn't do it that way.

Waypipe is only 15K lines of C though. It's not that big of a deal to maintain it.