SAI_Peregrinus

I've got a 61mp camera, and an RX 7900XT. It takes about 15s/picture for DXO to denoise, which is a lot longer than people are willing to wait on a phone to take a photo. Topaz is even slower. A cloud service could be used to do it in post, but someone has to pay for that.

I've been learning FreeCAD, while it's still more frustrating than Fusion or SolidWorks it's much better than it used to be pre-1.1, and it's FOSS. Also constraint-based, I've been using the new spreadsheet view as the source of all constraint dimensions, with parts derived by binding to top, front, or right-side orthographic "master" sketches. Much like hand-drawn design, where you draw the orthographic views and use those directly to create an isometric view.

I'm sure the doohickeycorporation folks on Reddit can come up with some.

The big hardware issue is that QKD requires point-to-point links between the endpoints that authenticate to one another. That doesn't scale well to more than a handful of endpoints. Even if the endpoint hardware is free.

The big logical issue is that QKD requires a classically-authenticated channel, so you either need a post-quantum signature scheme (at which point why bother with QKD since you can usually use the same computational hardness assumptions to construct a post-quantum key exchange scheme & use AES-GCM or ChaCha20-Poly1305), or you need pre-shared symmetric key material & a Wegman-Carter MAC a la Poly1305 (at which point why bother since you can just use AES-GCM or ChaCha20-Poly1305).

Of course that also means you need a mesh network topology (every node needs a direct link to the node it wants to share qubits with), so a quantum internet (interconnected network of networks) is impossible.

Parmigianino-Reggiano is aged milk, so I'm not sure what people have against aged milk. Aged milk can be great

HTTPS encrypts the password in transit, but the remote server (verifier) still gets the plaintext of the password. You need a PAKE to use a password without transmitting it to the verifier.

Of course there's a solar factor. The question is the size of the effect. The effect of increasing CO2 is much, much larger than the effect of variations in the sun's energy output.

Even 1 year is still a lot longer than "immediately getting burned". Fuel gets consumed immediately when it's used, it doesn't keep being re-used for a year or more.

Open-source software provides the four freedoms, but doesn't necessarily require preserving them transitively.

GPL software requires preserving them transitively and requires derivative works using the licensed software as a component to provide them.

MPL requires preserving them transitively.

BSD/Apache/MIT don't require preserving them, but still require the resulting software to include the original license & attribution. In the case of a closed-source program distributing (say) MIT-licensed software with proprietary modifications, the resulting binary is still released partly under the MIT license & includes the MIT license text, but doesn't include the source code.

For an offline install on Windows, stick the Python .exe in `uv`'s executable directory[1].

[1] https://docs.astral.sh/uv/reference/storage/#executable-dire...

Haven't you? There's quite a bit of closed-source software based on permissively-licensed code. You can get the upstream source for the permissively-licensed code, but not the modifications made to it. Windows (used to) use some BSD-licensed code for a few network utilities like nslookup.

EEVBlog #646[1] demonstrates the gravitational bias.

[1] https://www.youtube.com/watch?v=zILwgQhjC_Q

They're spec complaint with genuine USB-PD charging capability. Some devices are counterfeit with fake USB logos & USB-C connectors but not compliant with the specs. I blame the counterfeit sellers & manufacturers.

They typically don't require any custom one-off parts to be made, just mass-produced off-the-shelf stuff, so they're common enough.

Most of the issues with YAML are really issues with people who think that since "configuration as code" is good, that "code as configuration" must also be good.

Try http://127.0.0.1:hkp instead of http://127.0.0.1:11371 for an OpenPGP HTTP keyserver. HTTP will work, but using the service name won't. Does that make what they're trying to say clearer?

It's a problem anywhere, just that the dry bulb temperature needed to reach a given wet bulb temperature goes up as humidity goes down.

Also how much short-term inaccuracy there is depends on the type of oscillator used. An OCXO will (usually) have less short-term jitter and better stability with ambient temperature changes than a chip-scale atomic clock module, but will drift more than the atomic clock long-term. The really expensive setups combine various clocks to maximize stability over all the durations of interest & minimize influence from various external factors (temperature, humidity, barometric pressure, external magnetic fields, other EMI, gravitational bias, etc.).

Gravitational bias is a really fun one since you can easily demonstrate it & its' not immediately obvious. Take a quartz oscillator, and a reference oscillator. Measure the frequency of both. Turn the quartz oscillator on its side. The phase (and usually also frequency) will change: the physical quartz has inertia & gravitational mass, so changing its orientation changes how it oscillates. In one orientation the movement of the quartz atoms is perpendicular to the force of gravity, so both directions of oscillation are biased the same amount. In another orientation one the movement of the quartz atoms is parallel to the force of gravity, so the part of the crystal moving down accelerates a bit more than the part of the crystal moving up.

And this is why I prefer a "hybrid" version scheme between CalVer & SemVer: A series number to allow LTS releases, a period, a hyphenated datestamp, optional "flag" letters "B" for breaking changes, "S" for security fixes, "F" for new features (more than one can be present, always in that order), and if more than one release is made on the same day the second & subsequent releases get a period followed by a release number starting from 1.

E.g. 3.2026-05-01FS for a first release of the day with a new feature & security fix to release series 3, 2.2026-05-01S backporting the security fix to release series 2 (LTS, say), 3.2026-05-02 for a "bug fixes & performance improvements" release, 3.2026-05-02S.1 for a security fix to the "bug fixes & performance improvements" release.

Like SemVer, this lets users know when there are breaking changes to an API or such, which releases contain security fixes, which releases have new features, and allows multiple simultaneous release versions for LTS support. Like CalVer it lets users know how recent a release is, and makes it pretty easy to figure out what the release schedule was historically (and likely still is) by comparing versions.

On Linux, with a compose key, it's <compose><-><-><.> (at least with the settings I have, I don't think I overrode that one). "⸻" is even more fun. You can even make your own sequences, e.g. I've got <compose><O><h><m> for "Ω", and <compose><m><u> for "μ", very handy for electrical stuff like "160μA at 1.8V needs a resistance of 1.25kΩ, dissipating 288μW".

Stick all the stuff you manually care about into `~/home/` (or some other directory of your choice, e.g. `~/a/` for easy typing). Leave `~/` for the various programs to dump config files in.

I think one thing we'll see is that "sophisticated" multi-step exploit chains will become the domain of script kiddies. They often already were, malware vendors often pre-packaged software that exploited several vulnerabilities in a row, but I expect that LLMs will make the "Attack Complexity" metric in CVSS even more useless than it already is.

Plain MSG absolutely does not taste bitter. I just tried some (again) to confirm, it's not salty & not bitter. Just a strong flavor of its own.

You could also use the mol to count requests. It's somewhat inconveniently large, so 1 request/s turns into about 1.661ymol/s of requests.

And 12 months of credit monitoring to go with the 2346823 months of credit monitoring they already have.

Good old "one dollar, one vote" democracy!

AFAIK they're talking about anhydrous HF gas, not solutions of it. That sounds substantially less fun to work with. It's used to clean CVD chambers.

As usual for particularly nasty crap, Derek Lowe has written amusingly about why he won't work with it[1].

[1] https://www.science.org/content/blog-post/things-i-won-t-tou...

For the most sensitive fields (names, addresses, phone numbers) it's quite simple. For names, you get a list of the (say) 1,000 most common names, and pick randomly from the list. For phone numbers, you generate random numbers with valid formatting (not all area codes are valid, etc.). For addresses, you pick randomly from a database of real addresses. Etc. No LLM-style generation needed.