lilyball

At the very least the author's submission and follow-ups to Product Security looks written by AI.

This claim sounds vaguely familiar to me (though the documentation on Dictionary does not state any reason for why the iteration order is unpredictable), though the more common reason for languages to have unstable hash table iteration orders is as a consequence of protection against hash flooding, malicious input causing all keys to hash to the same bucket (because iteration order is dependent on bucket order).

If you formalize, you'll end up with one rigorous definition

Can't you just formalize both definitions and pick the one to work with based on what you want to do? Surely the only obstacle here is the time and effort it takes to write the formalization?

Or, alternatively, just because you've formalized the advanced calculus version doesn't mean you need to use the formalization when teaching basic calculus. The way we've proven something and the way we teach that something don't have to be the same.

"View types" addresses one of the top pain points of the borrow checker, which is disjoint borrows on a single value. The compiler can understand values where only some fields are borrowed, so e.g. you can mutably borrow the currently-unborrowed fields, but there's no way to write these partial borrows and so you cannot write functions that either take or return these borrows. This often means having to restructure code to split up one struct into several child structs just to be able to borrow those substructs independently.

The argument against PRNGs this paper makes isn't that the PRNG produces results that can be distinguished from TRNG, but that the 256-bit seed deterministically chooses a single shuffling. If you need 300 bits to truly shuffle the assignment but you only have 256 bits, then that's a lot of potential assignments that can never actually happen. With this argument it doesn't matter what the PRNG is, the fact that it's deterministic is all that matters. And this invalidates the p-value because the p-value assumes that all possible assignments are equiprobable, when in fact a lot of possible assignments have a probability of zero.

I imagine you could change the p-value test to randomly sample assignments generated via the exact same process that was used to generate the assignment used by the experiment, and as you run more and more iterations of this the calculated p-value should converge to the correct value, but then the question becomes is the p-value calculated this way the same as the p-value you'd get if you actually went ahead and used equiprobable assignment to begin with?

Ultimately, this all comes down to the fact that it's not hard to use true randomness for the whole thing, and true randomness produces statistically valid results, if you use true randomness for assignment then you can't screw up the p-value test, and so there's no reason at all to even consider how to safely use a PRNG here, all that does is open the door to messing up.

This sounds nice, but since you're talking about using it with agents, to what extent was AI used to actually write the app?

For new implementations, sure. But it's harder to change existing implementations (anything not already CommonMark-compatible will introduce unexpected changes to existing content if you switch to CommonMark), and especially for anything that's not being actively developed it's unlikely to ever change.

Not all markdown implementations are CommonMark

Apple Keychain syncing is end-to-end encrypted, Apple cannot see the contents of your synced keychain.

Is it? Why? If a NixOS module doesn’t support what you need, you can just write your own module, and the module system lets you disable existing modules if you need to. Doing anything custom this way still feels easier than doing it in an imperative world.

In Pattern: Defensively Handle Constructors, it recommends using a nested inner module with a private Seal type. But the Seal type is unnecessary. The nested inner module is all you need, a private field `_private: ()` is only settable from within that inner module, so you don't need the extra private type.

I haven't used Homebrew in a long time, but if I ever did it would be in the way that you describe (so far I've always found reasonable alternatives for the software I want). What I'm wondering is if this is entirely to support unsigned casks, why does Homebrew not simply resign the software itself at install time with an adhoc signature as though it had just built it?

If you don't use ANC, then why is an ANC issue that only appears on flights a reason for you to not buy a product? If someone said they have weird ears and the AirPods Pro 3 simply doesn't fit their ears, would that be a reason for you to not buy it even though it fits yours?

I'm fascinated by ASN.1, I don't know why it appeals to me so much but I find working with it oddly fun. I've always wanted to find the time to write an ASN.1 compiler for Rust, because for some reason all of the Rust implementations I've seen end up just either being derive macros on Rust structs (so going the other direction), or even just providing a bunch of ASN.1 types and functions and expecting you to manually chain them together using nom.

LaunchDaemons don't rely on GUI login state so they should come up. If you use LaunchAgents then they won't start this way, but LaunchDaemons should be enabled once the data volume is unlocked and booting finishes.

Unlock over SSH terminates the connection after unlocking the data volume, so it doesn't even attempt to start the shell until you reconnect after it's fully booted up.

FWIW you can fix the shell issue by wrapping your shell in a shim that essentially runs wait4path on the nix store before exec'ing your real shell. I set up my environment to install that shim binary directly onto the data volume at a known path so it can be used as my login shell.

It's not just 5 moves. It's 5 crossing changes (which don't change the number of crossings, they just change the order of the strings in a crossing). Unknotting also involves moving the strings around to add or remove crossings, without performing crossing changes (if you take a loop and twist it into a figure eight, you've moved the strings and created a crossing but you haven't cut the strings and performed a crossing change).

If you look at the preprint paper, the knot it starts with has 14 crossings, but they actually move the strings around to end up with 20 crossings prior to performing the first 2 crossing changes in the unknotting sequence. So the potential space for moves here is actually rather large.

If you need to hold a lock across an await point, you can switch to an async-aware mutex. Both the futures crate and the tokio crate have implementations of async-aware mutexes. You usually only want this if you're holding it across an await point because they're more expensive than blocking mutexes (the other reason to use this is if you expect the mutex to be held for a significant amount of time, so an async-aware lock will allow other tasks to progress while waiting to take the lock).

Your argument here is basically just "I already know Markdown". Sure, the Markdown image syntax is similar to its hyperlink syntax, so if you know the hyperlink syntax then the image syntax is easy, but the same argument works for reST but even better, the image syntax is the same as any other directive, so if you know how to write a directive then you know how to write an image.

It's extremely distracting. I'm not normally one to have issues that require reduced motion, but the asteroids are almost distracting enough on their own, and the fact that it causes my cursor to vanish is a real accessibility issue. I didn't actually realize just how much I use my mouse cursor when reading stuff until now, partly as a fidget, partly as a controllable visual anchor as my eyes scan the page.

Yes, if you look at the Linux-specific breakdown it shows "SteamOS Holo" is 28.31% of the Linux userbase, by far the largest single entry there.

It's worth noting that the percentage of Steam users that are Mac users is not going to be equal to the percentage of gamers who play games on Macs, because not only is Steam not the only distribution channel for games on Mac, it's always been a fairly poor UX there, so bad I don't usually even bother installing it on my Macs anymore. Steam sees me as a Linux user as I have a Steam Deck, but I spend more time playing non-Steam games on my Mac than I do using that.

Actually, I think the last time I installed Steam on a Mac I did so in a CrossOver Games bottle, so even there Steam would have seen that install as a non-Mac user.

EDIT: Also just because I think it's interesting to note this, Steam Deck accounts for most of Linux's headroom there, if you subtract the SteamOS numbers from the rest of Linux it's at 2.07% instead, which is much closer to Mac.

But with a full searchable transcript

Full screen stuff isn't supposed to go behind the notch, unless they opt in to supporting it. By default, fullscreen stuff just gets the notchless 16:10 area under the menubar, and the menubar area goes black, so the notch becomes invisible and nothing is "glaring", it just looks like the top bezel of the screen is larger.

Those presets aren't display ratios, those presets have to do with color profiles, HDR support, etc.

Good! Wipr was very cheap, so was Wipr 2, if paying a tiny fee every few years for a well-made app that does its job well keeps the developer in business and able to keep maintaining it, then I'm happy to do it.

That said, I'm not actually convinced there will be a Wipr 3, at least not without some significant change to the ecosystem first. Wipr 2 was a complete rewrite of Wipr, there's no reason to expect it will need yet another complete rewrite.

You're describing a different format entirely then if you're doing generic whitespace trimming without any consideration for the definition of "whitespace". The Git config format explicitly defines ignorable whitespace as spaces and horizontal tabs, and says that these whitespace characters are trimmed from values, which means nothing else gets trimmed from values. If you try to write a parser for this using a regular expression and `\s*` then you'd better look up what `\s` means to your regex engine because it almost certainly includes more than just SP and HT.

I can't think of any features in Rust that will lead someone away from this pattern of error, where this pattern of error is not realizing that round-tripping the serialized output back through the deserializer can change the boundaries of line endings. It's really easy to think "if I have a bunch of single-line strings and I join them with newlines I now have multiline text, and I can split that back up into individual lines and get back what I started with". This is doubly true if you start with a parser that splits on newline characters and then change it after the fact to use BufRead::lines() in response to someone telling you it doesn't work on Windows.

The "destinations much closer than 500 miles" was explicitly handled in the story, I don't know why that was even in the FAQ except that the asker failed reading comprehension.

"There are a number of destinations within that radius that we can't reach, either, or reach sporadically, but we can never email farther than this radius."

Most of these are good, but "can't log in while standing up" is just too implausible. I can't possibly be led to believe that every single one of a whole group of technically-literate touch typers failed to notice that keys were swapped.

That first link doesn't work in Safari, and I'm really wondering what's missing. Clicking the button works, but clicking the warheads does nothing. I also don't get the crosshairs cursors that I see when I try this in Firefox.