jiveturkey

Even ECH isn't that helpful. ISP still sees the IP addresses you connect to. Even when non-dedicated IPs are used, I'd be surprised if a quite basic traffic analysis (say, bytes transferred on first visit) wouldn't identify the domain.

VPN providers at the tier of Mullvad should be precise about this stuff -- I think it's more than just a nitpick, considering the audience. oh god did I just use an emdash.

Note that you need some flavor of secure DNS to enforce ECH. The protocol is designed to be downgradable.

and there's a goddam ad at the start of every apple TV show, and macOS forces ads on you via the SETTINGS app! (both such ads are for other apple products ... still, it's an ad)

What's to prevent Apple from making iOS and macOS free to "copy, redistribute, and modify"? The OS is free already, and the platform does cryptographic signature verification before allowing its installation. macOS already automatically finds local caching servers, which amounts to redistribution capability baked in.

They can just claim that the user is free to turn off SIP and "modify" the binary bits, or that kernel extensions amount to modification.

I think you're misreading it. It doesn't ban Linux from providing age collection and verification. It makes it a choice, rather than mandatory.

I would expect that Linux users want access to age-verified apps just as much as other users, so such a signal will be available.

Also, you're being overly pedantic on the language used. It transfers liability away from the service, more easily allowing operation in about half of the states. "age verification" is a fine lay description.

But all 3 of those use cases, plus privacy, can be addressed with word.salad@bigdomain.com. So you may as well get the privacy bit in there.

> all APs identify as the same BSSID, and decide between them who answers a client

That is decidedly not a solution. Neighboring APs necessarily need to be on different channels, to avoid Co-Channel Interference (CCI). An AP doesn't answer just on BSSID but also on a specific channel.

> weren’t authorized

this is easily solved with current technology, if they had an incentive to do so.

besides firing folks that get caught, flock themselves should be brought to court.

I've recently bought many domains (1000+ over the last year). A few of them (the more valuable ones) all had TXT records for `@` (the root) that had for-sale info. This new record is just a TXT record anyway, proving the point that the interested buyer can quite easily learn of a domain for sale with existing mechanisms.

Also, for domains that are just "parked", not in current use, obviously the parking page can just have a for-sale banner. This is exceedingly common.

> Enquiries that would have been welcome never arrive, and the ones that do arrive are indistinguishable from spam.

Laughable misrepresentation.

claim is that very many things are not needed, but they are. they are just provided by the layer beneath (S3). so isn't correctness highly dependent on s3 correctness? was s3 built for that, vs just plain durability? for example, would it be just as reliable with minio?

i would prefer a thing that was more self-contained, not dependent on a black box service layer underneath.

much apologies if i just have a poor understanding.

It's too bad they would follow the letter of the law, and not state the salary anyway. I see that as a negative indicator, regardless of offer size.

Well that isn't that much. $1M / month feels more like it.

I think the idea is that, in fact, you do.

Not one-time cost, but rather TCO.

indeed. the post may as well be, javascript must be disabled.

How is Snap-On approved and Proto is on the watchlist?

Proto >> Snap-On IMHO. Both in raw quality and in value.

And while Craftsman may have changed significantly even before Sears' demise, there are still some excellent tool lines within the brand.

That is the video title, but I think it should be paraphrased here to be more correct given our highly technical audience. The politician is actually reading an unedited AI response, which includes "editors notes" or maybe you could call it meta-content.

the truncation is a poor example.

- it creates the file if it does not exist, not merely truncate. as a tutorial kind of blog post this incomplete description matters IMO.

- it would work the same without the colon (similar for default variable assignment examples). we generally strive not to have "extra" things, like useless use of cat.

- educationally it's useful to demonstrate that redirection, like parameter expansion, works before the command executes (the null command in this case), but the article doesn't explain that at all!

otherwise i <3 this article. some uses of colon i had never thought of or seen before. like file truncation, not sure i'd use them but it was cool to see them.

looks like a response to https://news.ycombinator.com/item?id=48445834

> DACs are copper, and they're happy.

Well come on. GP really means category cable (twisted pair copper) is not happy at 10Gb distribution lengths (so-called horizontal cabling, although in a home it may span multiple floors without IDFs). That's kind of obvious context.

DACs are not category cable; they are twinax, short, and bulky.

JWTs can do that (delegate) and such capability is already well defined.

entropy check, for one

> TL;DR: Don't overthink it, just send a verification email.

pretty bad advice, if taken only as written, without adding more flavor on top.

the major email providers will penalize you if you generate too many undeliverable emails. thus, if you just send a verification email without any pre-validation, it's pretty easy to get into a DoS situation where current/valid users don't get important email sent to them, or that email is significantly delayed, plus incur huge operating cost to resolve the problem.

some form of rate limiting is needed, plus IMHO it's better to use a verifier service or your own heuristic or ML model to test for email validity including valid but fake/spammy/disposable addresses.

sorry, but we are way past the point of being able to have nice things, esp. when we're talking about email.

the "lies" part of the content is great. people do assume all those wrong things. however the TLDR is just wrong, and potentially harmful.

oooh. i have an original. it doesn't have the 'Collector's Edition' etching. Does that make it a fake?

But the chatbots/aggregators do, and they accept the reports as fact.

As is noted in the conclusion.

> Instead of releasing our results all at once, we're going to focus on one report at a time. This approach both prevents individual examples being overlooked and allows us to illustrate the negative impacts of vibe citing on research quality and public trust.

Not to take away from the actually great reporting here, but what they mean is, This approach allows them to milk it for as many clicks as possible.

why is that? you'd run yt-dlp from the same device you generated the cookies on (with a real browser). yt-dlp will have the bare cookie and also be able to refresh the cookie just like the browser.

There was a secondary sale in April.

There's a newish term for this: RLO, Recurring Liquidity Opportunity. These are tender offers at some recurring interval. Even some companies that have a shorter lifespan (say 7 years) offer this.

We are still in the short-half-life phase of GPUs. If a 2x faster GPU is on the horizon, why wouldn't OpenAI already be in line to buy? They aren't buying just 1, they are buying multiple datacenters' worth. So they wouldn't be a low priority, back of the line customer.

A short half-life means you are going to quickly dispose of what you have now, anyway. In fact most current datacenters can't even handle Vera Rubin, so I don't think there's short term risk here.

  BOOBS

age verified