Just get rid of clock changes altogether, and set the time in reference to UTC and time zone without any "daylight savings" type adjustment. Each of the 24 time zones (-12 to +12) should be one hour off from it's neighbors, and should be straight (time doesn't care about state lines).

There also should be no half hour off zones. If that matters that much, just use UTC and forget about time zones altogether.

Hashes would be perfect for this. Take the ID number, hash it, store the hash. If you need to verify, hash the ID number and compare it to the recorded one. Still no need to store _anything_ like an ID.

Also, don't hire third party companies to do it. They won't get it right. They never have. They never will. After all, it's not _them_ on the line if there is a breach. Somehow the third parties always seem to slip past the blame and liability and it all goes to the ones who hire them.

Even my Raspberry Pi has PCIE now. Why would the cripple a general purpose CPU by not giving it a bus that can keep up with it?

That was pretty much my point. Everything about it was so vague that it was, essentially, meaningless. There was no who (as you point out), no what, no where, no when, no information on which action could be taken. An example of what I, personally, would prefer is:

"You and I should connect tomorrow, I'll send an invitation based on our calendars, and work out the requirements and a plan to meet them."

So... you would like to communicate at some time using some method, but not a meeting, to work out the details of some thing which may or may not be a task and determine who will be putting what work into meeting the requirements that are still to be defined as part of this communication.

In other words, let's get together later and figure everything out.

What I don't understand is why there is no card/slot for M.2 drives. Even a full length one is not much larger than a USB drive, and the slot could be made similar to a larger USB-C style connector. Is there something technological, like trace length limitations, that makes that difficult?

Fair enough. I've definitely done an A/B setup manually for significant upgrades, and it has saved me a lot of headaches. I don't see anything that indicates whether root would be available out of the box; that is a wait and see. I would expect the display system to be Wayland, so nothing magical there.

Access to both Flatpak and Snap would leave a wide selection of OSS available. I'm not a fan of either in their current form, I've run into too many issues with both - mostly due to assumptions made by the packager about permissions or environment. I use KDE as my primary DE, but I still prefer a proper package manager over their Discover store.

What I don't like, and it is part of the reason I left Microsoft behind, is the lack of control over my system. I imagine that I am not part of the target audience for this, though, as my "daily drive" is an off-road adventure.

So KDE wants to get in on the walled garden money that Apple and Google are already dominating. I have enough problems with Flatpaks not running properly on distro where I can go in and patch the issues that this is a complete non-starter for me.

If that is the case, then it can best be summarized as "Nice code you've got there. Would be a shame if someone injected a trojan. For a suitable 'donation' we can make sure that doesn't happen. We're not responsible for anything that happens if you don't pay your dues."

It's just another walled garden that developers will have to pay to enter, and consumers will have to pay to use. (And I have full confidence that Google will find a way to make both ends pay.)

It certainly doesn't help that the first four or five pages of results are completely irrelevant "AI" generated trash anyway, so search is almost not worth the effort.

That may actually be the underlying cause. If the switches were in the "run" position but the latching had not fully engaged, the vibrations of takeoff combined with the spring may have caused them to toggle. In general, the springs are centered on switches, so that would also explain them returning to the "run" position and the tension causes oscillations.

And unfortunately, thanks to the games like this we ended up with things like the "Verifying that you are a human" interstitial pages from cloud flare, which I am guessing use something like described for Anubis. I hate it and my CPU hates it (spiking to 100% for up to a minute to perform the calculation). You know who doesn't hate it? The bots. They simply act like any browser that has no JavaScript and ignore it.

Oh, and my Noscript (different device) breaks those pages every single time, meaning that I move on to a better source.

Indeed, I would not trust a single thing he wrote to be production ready. Are all possible exceptions handled gracefully? Are edge cases incorporated? How do I back up and restore the data of the application without loss? Can I load balance it across multiple data centers internationally located? Does it properly record all authentication, authorization, and action for later audit? Is every resource access properly secured? Will it integrate into our SSO systems? Does it support closed source data stores? Using the audio example, what does it do if I feed it a "song" that is just a combination of all possible frequencies (Nyquist limited) at maximum amplitude for 24 hours? Or one that sweeps through all possible values? What about one that has invalid values? Are all inputs sanitized? I could keep going, but "vibe" coding is *not* programming. It's what I would expect from a completely new developer who just learned what code is. /rant

My castle for an edit button. *why I think* not why *why I don't think*.

Fascinatingly, this is an example of why I don't think general computing machines (especially binary based ones) won't be able to reach general intelligence. In formal logic there are only three states a proposition can have: true, false, and undecidable. The liar paradox you mentioned falls into the third category for logic. Sentient beings, however, can still resolve the question of whether 93 Escort Wagon is lying or not sufficiently to decide and act on the result. We use things like "feelings" and "experiences" (both poorly defined from a computing perspective) as input, can use approaches other than formal logic such as risk evaluation, and are able to synthesize new conclusions in the absence of complete data. Computers are excellent at deductive evaluation, where we can say A=B, B=C, therefore A=C. They are terrible at inductive logic, however, which is the foundation of this types of evaluation. For example, the extrapolation that 93 Escort Wagon is intelligent (based on their post history), has not demonstrated a tendency to lie, and is clearly being sarcastic (another inductive conclusion based on your past posts), I can easily reach the conclusion that Jim is incorrect, and further that you are lying as a form of sarcasm not meant to be interpreted literally. From that induction I can therefore deduce that you are, in fact, lying about lying. I can also induce that Jim probably is not a reliable source of information on 93 Escort Wagon. Further, since the most common color of 93 Escort Wagon was a silver/gray (in my observation) I can also guess that you are also sliver/gray, and have a laugh at the incongruence of that conclusion with the assumption that you are, in fact, a human.