gwillen

It's not anymore: "in April 2026 the implementation of the agreement was put on an indefinite hold due to opposition from US President Donald Trump." So whatever ICANN was going to do with .io, it's all on hold for now.

There is a list called the Public Suffix List, which is used for most purposes to make determinations about which 2lds do not own/manage the corresponding 3lds. It's maintained by Mozilla as a public service, which isn't exactly where you'd expect to find it. But it's mostly important for web security / "same origin" stuff, so it makes sense.

In addition to all the country codes TLDs that do 3rd-level registration, the PSL does also include stuff like github.io. (Maintenance of the list involves manual volunteer labor, so scaling is a real problem...)

(And of course the PSL wouldn't work well for the .name situation, where it's sometimes 2 and sometimes 3, and it can change over time. But that's no excuse for this clusterfuck of just suddenly dropping a bunch of domains that are paid up years in advance.)

It's complicated and political, like always. Officially, the ISO 3166-1 alpha-2 country code list is used to decide who gets a ccTLD. (And Taiwan is included there.) But for example ".su" still exists for historical reasons, even though the Soviet Union is long gone (and its code is listed as "exceptionally reserved", which I assume translates as "we have no fucking idea what to do here.")

The watermark is contained in the choice of output tokens. If you exert so much editorial control that Claude has no meaningful freedom in choosing tokens, then it's going to fail to watermark the text, unless the text is _very_ long (in which case even a very low-bit-rate watermark will eventually accumulate enough bits to be positive.)

In my experience with winter-storm-related power outages, the core problem is often _wind_ rather than precipitation.

Such a tool would violate the Discord Terms of Service, so the selection is limited and they don't tend to be very good unfortunately.

I'm sure it varies, but personally I have a very prosaic reason that I would still drive myself in most scenarios: If someone else is driving I tend to get motion sickness.

Confirm or deny my suspicion: your post and your comments in this thread are substantially written by ChatGPT?

I think Google basically _is_ the standards committees, at this point. Not in the sense of having majority control just by themselves, but in the sense of (1) the cartel being argued over here (browsers funded by Google) having that or close to it, and (2) Chrome being the main source of new features getting implemented, so that the job of the standards committees is mostly to play catch-up with Chrome.

> Aren’t coding copilots based on tokenizing programming language keywords and syntax?

No, they use the same tokenization as everyone else. There was one major change from early to modern LLM tokenization, made (as far as I can tell) for efficient tokenization of code: early tokenizers always made a space its own token (unless attached to an adjacent word.) Modern tokenizers can group many spaces together.

Yeah, I noticed the same thing. Quanta's version of the algorithm is not only confusing, it's also wrong.

I think the pseudocode in the paper is very hard to beat.

Merging like that doesn't work -- it will tend to overestimate the number of distinct elements.

This is fairly easy to see, if you consider a stream with some N distinct elements, with the same elements in both the first and second halves of the stream. Then, supposing that p is 0.5, the first instance will result in a set with about N/2 of the elements, and the second instance will also. But they won't be the same set; on average their overlap will be about N/4. So when you combine them, you will have about 3N/4 elements in the resulting set, but with p still 0.5, so you will estimate 3N/2 instead of N for the final answer.

I have a thought about how to fix this, but the error bounds end up very large, so I don't know that it's viable.

Robbery/burglary? SWATing? The possibilities are delightful and endless. The former is a major concern for people who are known to be rich; the latter for people who are infamous online (and has the [dis]advantage that it can be carried out by anybody, anywhere in the world, typically repeatedly, and with usually zero repercussions.)

Thanks for linking the graph, that's kind of wild. I agree with you that the lowest datapoint seems crazy. I can think of a few explanations.

- Random bad luck.

- As you say, failing to control for something -- although, if you then treat the lowest datapoint as being effectively the default risk, this would suggest support for radiation hormesis (that people who got a bit more than background radiation actually did better.)

- Some kind of data collection artifact. Perhaps the people with the absolute lowest dose, in a radiation-worker dataset, are selected for being ones who are not getting an accurate measurement (i.e. sloppy about wearing dose badges or something), and those people genuinely do have worse outcomes.

I'm not a statistician, but I think there's a bit in your excerpt that is actually a concerning display of poor statistical literacy.

If you're fitting a function which grows asymptotically (i.e. is monotonically increasing at least past a certain point), the best (polynomial) fit absolutely cannot have a negative quadratic as the leading term. If your model gives one, it is 100% guaranteed to be an artifact. Treating it as "suggesting some downward curvature" is a pretty bad misunderstanding.

If you have doubts about this, consider what would happen if we added datapoints at higher doses. Every single datapoint we add to the right side of the graph will make the fit of a negative quadratic significantly worse. Ultimately, if you continue the graph indefinitely to the right, the fit of a negative quadratic is guaranteed to be infinitely bad. Any hint to the contrary is inherently an artifact of the limited dataset.

(It may well be the case that, under certain conditions with a range-restricted dataset like this, such a finding might indeed be more likely if the true function has some downward curvature. But that's not statistics, it's voodoo. All the associated statistical parameters, p-value, likelihood ratio, etc., are absolutely meaningless nonsense.)

As I understand it, Schnorr signatures are the "natural" (and simplest) construction for a digital signature in elliptic curve cryptography. The reason ECDSA exists is simply https://patents.google.com/patent/US4995082 (now expired), which made Schnorr illegal to use, so something worse had to be invented.

Hah, yes, I had the exact same reaction. "Looks like Pittsburgh, but not quite. Also kind of looks like Virginia... let's split the difference."

According to the comments, the author has only just today learned that Substack added this new popup without asking him, after he got them to disable the previous popup. So hopefully you're right that it's possible for him to turn off.

It is a great question, the answer is nobody really knows for sure.

I got something like that not long ago, and it was diagnosed as acute macular neuroretinopathy. Luckily, in many cases it apparently resolves on its own, and mine did. Was the spot slightly off-center in your vision? That's where it tends to happen.

As I recall, it's fairly random and fairly rare, but apparently it's been seen a bit more during COVID.

Their docs say (somewhat recently updated, I think) that even 0 is not perfectly deterministic in all cases (though it's very close). Some people had previously observed this and speculated that it was some kind of floating point roundoff issue, when two outputs have almost identical scores.

Beware -- command -v does not have the same semantics as which, and is not a substitute for it in shell scripts. There is no direct substitute. See: https://github.com/koalaman/shellcheck/issues/1162

"Tinfoil wrapped around complications" is definitely going in my quotes file. Reads like James Mickens! (If that's what you were going for, well done. If not, go read his stuff immediately.)

As far as I'm aware/recall, European privacy laws consider any connection back to a telemetry server to count as "collecting" IP addresses, since the telemetry server learns it (even if they pinky swear not to write it down.)

As noted by a couple people in this thread, the anti-phishing footer is new. PayPal presumably added it in response to this scam.

I definitely wish you guys had advertised that earlier / better. I feel like I got lucky because I put off migrating until just before the sunset, at which point I discovered eco dynos. I swear they either didn't exist or were harder to find when the sunset was first announced. Thanks for making them available at all, though.

(Context: I maintain an app for an event that runs about one week a year. The ability to use free dynos the other 51 weeks means we retain the ability to do one-off analytics queries, minor development work, etc. during the off-season, without having to delete and recreate the app or something every year. Eco isn't quite as good as free, but it means we can still have separate staging and production instances during the off-season, without paying extra for staging to be idle, and without having to destroy and recreate staging every year.)

Moxie has made his decision; now let him enforce it.

x86 at one time had a single-byte instruction that would trap if the overflow bit was set, INTO. It doesn't exist in 64-bit mode, I believe, and it was never widely used as far as I know. The performance implications of adding even a single additional instruction to every integer operation were probably still prohibitive? (And there's a history in x86 of specialized clever instructions and mechanisms going unused, due to being slower than doing the same thing some other way.)

Why get rid of the next button? Stop that. Has any actual user ever asked to get rid of the next button?

Shopkeepers have the legal power to detain shoplifters in most US jurisdictions. They've just historically (in the modern era) been too afraid to use it.