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.

Fosstodon, just one Mastodon instance seems to have reached around 60K users.

They say their costs are $2K/month and they have two founders who I imagine are the people who manage it, plus moderators.

And I think they're at 60K only because they decided to limit signups.

While I get wanting to preserve old stuff, we all know that entropy is inexorable, and that time gradually destroys everything. No matter how much care is taken, how controlled the temperature and humidity, what gloves people wear, etc, it's absolutely a given that everything present in any museum will eventually crumble into dust, get caked in hard to remove dirt, or break from accidents, careless manipulation, or things like theft and wars. Just look at what happened at museums in Ukraine.

At this point in time, with the amount of technology we have, scanning everything should be a no brainer. This gives tons of options. We can recreate objects when they get lost. We can make reproductions to show the same thing in several places at once. We can make a reproduction and let people touch it. We can make a fixed version to show people what the actual thing in its full glory looked like. We can make replacement parts when something breaks. I'd love to have 3D models available to the people.

And honestly, 12 million sounds cheap. The British Museum is huge. It has 8 million objects. The budget for the museum was £103.4m last year. It sounds like a very manageable amount of money and one that in my opinion is well worth it.

If you want your particular concerns to be taken into account, you have to be visible in some way.

Show up to meetings/events, complain about problems, just reply "Thank you, this fixes a problem I had" to updates to make it clear you're there, pay for paid support, or for the lazy way, enable telemetry.

If nobody knows you're there, you're indistinguishable from not existing. This is especially the case in open source where you can download some software, and use it daily for years without leaving any trace of that anywhere.

My support for Ukraine has nothing to do with US politics. Not everything is about the democrat/republican kerfuffle.