That's a ways out. We're not even using all bits in addresses yet. Unless they want hardware pointer tagging a la CHERI there's not going to be a need to increase address sizes, but that doesn't expose the extra bits to the user.
Data registers could be bigger. There's no reason `sizeof int` has to equal `sizeof intptr_t`, many older architectures had separate address & data register sizes. SIMD registers are already a case of that in x86_64.
> There's no reason `sizeof int` has to equal `sizeof intptr_t`
Well, there is no reason `sizeof int` should be 4 on 64-bit platforms except for the historical baggage (which was so heavy for Windows, they couldn't move even long to be 64 bits). But having an int to be a wider type than intptr_t probably wouldn't hurt things (as in, most software would work as-is after simple recompilation).
You can do a lot of pointer tagging in 64 bit pointers. Do we have CPUs with true 64 bit pointers yet? Looks like the Zen 4 is up to 57 bits. IIRC the original x86_64 CPUs were 48 bit addressing and the first Intel CPUs to dabble with larger pointers were actually only 40 bit addressing.
This promotes impractical version pinning. That leads to spoilage unless the lockfiles are updated every few hours. Freshness should be checked at build time, and the resolved version for each ingredient recorded in the SBOM but a lockfile SHOULD NOT be used for perishable ingredients. Bacteria will result in Spoilage Vulnerabilities if versions are locked inappropriately.
That circuit schematic in the header is wrong enough to look like an AI-generated hallucination of what a schematic is from the "human with extra fingers" stage of image generation. Inconsistent symbol styles, missing pin labels, a shorted capacitor in the upper-left, etc.
Ha! Good eye. That circuit was actually replicated from the Google Typograms example here: https://google.github.io/typograms/#circuits - so any schematic errors are faithfully reproduced from the original
I used it as a demo to show what MonoSketch can create, but you're right that it's not electrically sound. Maybe I should switch to a different example that won't make electrical engineers wince!
The worst part about all this isn't the fact the experts can immediately see the inadequacies of the AI tool, it's that newbies are joyously learning incorrectly. How can the Experts of the Future have a solid foundation if their foundation is built on a bunch of "your absolutely right!" LLM corrections?
I didn't even notice that the cap was "shorted", instead I noticed that it had the shorter line (traditionally negative) labeled "+" but connected directly to GND!
I feel like "SHOULD" and "SHOULD NOT" are redundant. You end up having to assume someone else treated them as a "MAY". If you control all the endpoints in a private implementation you can just deviate from the standard & not implement a MUST, it's your private implementation. There's thus no difference in public implementations between "SHOULD" and "MAY", and no difference in internal implementations between any of the words. They are therefore redundant, requirements are either mandatory or optional, there's no middle.
SSH certs aren't TLS certs. Totally different format. All SSH CAs are private, you run your own CA to issue certs to devices you want to allow to connect to your server.
The point is that a "private" cert is not a "cert" as commonly understood. The important part to a certification authority is the AUTHORITY part, not the data format. Either there is a trusted third party that will promise you are who you say you are, or there is not. With SSH, there is not, nor can there be as it is commonly deployed.
So applications that want that have used other protocols and other schemes, very productively.
I don't mean to imply it's just the format, merely that they're unrelated. Different file format, different trust model, different threat model. The point is that a device manufacturer or network administrator can trust all devices that have valid certs signed by their internal issuer, and create ways for devices to rotate host keys & request new certs.
> You'd expect that at the bottom, the smallest objects would be extremely simple and would follow some single physical law.
That presupposes that there's a bottom, and that each subsequent layer gets simpler. Neither proposition is guaranteed, indeed the latter seems incorrect since quantum chromodynamics governing the internal structure of the proton is much more complex than the interactions governing its external behavior.
Data registers could be bigger. There's no reason `sizeof int` has to equal `sizeof intptr_t`, many older architectures had separate address & data register sizes. SIMD registers are already a case of that in x86_64.
reply