How do you plan to enforce that? Remember we're talking about state level actors.

1. Buy a bunch of phones in the US
2. Ship to Russia
3. Take apart, hook up probes instead of the camera.
4. Fake the entire environment -- spoof GPS signal, spoof cell tower.
5. Produce whatever signed picture you need, that seems to have been taken elsewhere.

Sure, this takes work, but all the tooling for it is available and it's peanuts to a government, there's even small companies that own such hardware for testing purposes.

How is that supposed to work?

Russia, as much as the current government sucks, still has plenty smart people in it. If you create a signing mechanism and Russia or China want to create chaos by AI fakes, then it won't be that much effort for them to obtain phones, hack them, and sign whatever they please.

Worst case, they take the device apart, and hook up something instead of the sensor to feed the right image to the signing chip.

More likely, they'll find some hole to exploit, or even print whatever they want in high quality, and take a photo of it really carefully.

This kind of thing can't possibly dissuade a serious attacker like a government.

Bitcoin was supposed to usher in an era of uncontrolled finances where no government could impose rules on your payments and no central bank could control your currency. We can see how well this worked in almost every bloc as bitcoin regulation fills greedy government agendas.

Bitcoin failed even before regulation caught up. This whole dream was held only by a very small amount of people, who got completely overwhelmed by the "get rich quick" crowd as soon as BTC turned from a theoretical thing for nerds to play with to something that could make you tons of $$$.

And that imposed rules even worse than any government. Who elected BTC Core, or the miners? There's like a dozen guys on top of BTC, unelected and unaccountable to anyone, and yet they still get to make decisions about how the network operates.

The design for BTC was fatally flawed from the start, in that for instance it failed to realize that mining would quickly require pools, and pools concentrate power in the hands of the very few.

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.