speedstyle

'Coming soon'. 2027 perhaps?

Of course it is, if you rely on that boundary. The 'consumer' use of tailscale is just as a reverse proxy, and that's how I figured GGP sees it. I don't have anyone on my tailnet, and when I did they didn't have ssh keys, and if they did I imagine there'd be many paths to privilege escalation, certainly it's a bigger surface than sshd. So I was clarifying it seems like an escalation from authorized execution to privileged execution, and not e.g. from unauthorized users to RCE

I gather the bug allows people you've explicitly authorized to ssh into some account on your machine, to access more than that account can. So if you only use ssh yourself, or only give ssh keys for users with sudo, or only to people you trust not to exploit this, or if other vulnerabilities allow local shell users to escalate, or if you only use tailscale for port forwarding, then you're unaffected. Arguably even less exposed than a public openssh instance, though I can't say I have any issue doing that

I got a replacement widget recently, the website pushes the app but when I asked in branch they gave me one without even asking my name. I had to wait on the phone to register the new serial number, maybe I could've done that in person too, but it lasted years (and multiple phones) so I don't mind too much

They shouldn't be locked the day you buy them.

2% tolerance is not the same as 2% failure rate

Yeah, I don't think the problem needed billions of tokens

Well, that part is easy.

Not everything is trying to be a walled garden. Only 2 apps on my machine are nonfree, and not productivity ones I would care to integrate like this. But yes it's fundamentally hard (and I don't think their suggestions are great)

(More precisely, doesn't have the reasoning from when the code was written)

It's not that apps should be websites, but that you should be able to load apps as freely as websites.

uBlock Origin has a built-in option for AI overviews (among other things). Settings > Filter lists > Annoyances > AI widgets

I'm British and I think it's quite different.

Leaflet is (generally) for streaming image tiles, OsmAnd renders a set of geographical features itself. But yes, it could do so more efficiently

Yes, we need abstraction. X being written in Y doesn't mean you can build the same systems, with the same adaptability, reliability, and performance, within the same time and cost.

Obviously there are also unnecessary differences between tools, and hiring shouldn't focus on easily transferred skills

Races can be memory safe (they are in Java and Ocaml), but in Go they can indeed cause UB.

https://go.dev/ref/mem#restrictions:~:text=such%20races,corr...

https://www.ralfj.de/blog/2025/07/24/memory-safety.html (I don't agree with everything here, but it's a very thorough explanation)

Efficiency, output per input, is only relevant for similar inputs. An ICE being more efficient means proportionally lower costs and emissions, but like you said, an electric drivetrain being 90% efficient is less informative than a well-to-wheel comparison.

Similarly, I think it's unhelpful to just expand it to primary energy. What's the efficiency of a wind turbine? In 50 countries already, a 100% efficient ICE would emit more than an EV! The reason for efficiency here was costs and emissions, so compare those.

I for one would prefer to pay for services, than be psychologically manipulated into paying (more, on average) to other companies who are paying to make those services worse.

Much less than 100% of electricity is... still more efficient than ICE? I don't see how that changes things.

US electricity averages 384g CO2/kWh, so EVs emit 100-130g/mile, equivalent to 90-110mpg. And that improves year on year, while an ICE is at best as efficient as when it was produced

You can drive hundreds of miles, but you'd only be able to charge 40-50. If your typical daily use is within that, you can go further at the weekend, or make an unexpected trip, and catch up over a few days (or at a fast charger)

> The net change in accuracy does not show whether the same individual calls succeed with and without the watermark.

Why would that matter in the slightest? LLMs aren't deterministic, the same happens with a different seed, or whitespace in the prompt.

An AI-assisted rewrite can make sense, if you take the time to uphold semantics and code quality, as they suggested. In practice, the first file I looked in had unsound unsafe – in the Rust sense, that a safe caller could cause UB, not that any callers do so – in fact there are no callers, the functionality was removed from the C++ bindings in a 1400-file changeset but left in the associated Rust module.

Humans have the ability to consider things beyond their immediate incentives. Most find it difficult not to.

We don't know what benefits they received from defecting anyhow

'Best' is putting it strongly for an autonomous claudish summary of an autonomous claudish rebuttal to a claudish write-up of the finding

In Rust these specifically take `FnMut`, a function which can update internal/borrowed state, rather than `Fn` which can't easily. In `map` or `filter` you shouldn't rely on the iteration order so that's not often useful – maybe something 'logically' stateless but which needs a mutable connection/threadpool/cache, or eg a counter which is really an ancillary reduction. There's even `inspect` which is explicitly for such side effects. In `fold`, the order is guaranteed and you could use it for a state machine, a fiddly `zip` with other mutable iterators, etc – something you need to perform the reduction, but which isn't really an output, I think you could reasonably write either

    .fold(init, move |acc, x| {…})  // or
    .fold((state, init), |(state, acc), x| {…}).1

I think the authors above put their opinion well: "Developers of self-driving vehicles work with a particular idea of a possible and desirable future. Members of the public may not share the assumptions on which this is based … Many respondents present alternative representations of relationships between the technology, other road users and the future. Rather than accepting a dominant approach to public engagement, which seeks to educate members of the public away from these views, we instead propose that these views should be seen as a source of social intelligence, with potential constructive contributions to building better transport systems. Anticipatory governance, if it is to be inclusive, should seek to understand and integrate public views rather than reject them as irrational or mutable."

I don't have an issue with autonomous vehicles (though I think we should also reduce the overall proportion of trips by car) but yes, obviously you need societal buy-in. "People want this" into 'some don't but they'll die' is hardly a serious approach to policies that impact everyone.

Anyway, I don't think your interpretation is supported by that data. Every age group responded net negatively, and age wasn't the strongest factor – for instance, women were less than half as likely as men to be comfortable sharing roads with self-driving vehicles

Obviously that's not true, but moreover it's meaningless – what counts as an option?

US cities are spread out due to policies enacted only 50–60 years ago to improve connectivity by car. New policies can (and will) reshape them again in the next couple of decades. For example, building transit creates environments where people's trips are well served by transit.

> people want this.

Could you justify this? e.g. https://doi.org/10.1080/17450101.2024.2325386 (N=1890):

"What first comes to mind when you hear the term self-driving vehicles?" (coded free-text) 17% positive, 34% neutral, 49% negative

"How would you feel about riding in a self-driving vehicle instead of the existing ways you travel?" 28% comfortable, 15% neutral, 53% uncomfortable

"How would you feel about using the roads alongside self-driving vehicles?" 29% comfortable, 20% neutral, 49% uncomfortable

A 64-bit sum type can't magically combine an i64, f64, and several raw pointers, each of which carry a full 64 bits themselves. You have to change the semantics of the code. Some semantics could be expressed more easily with compiler improvements, allowing eg `Aligned<T>` like `NonNull<T>`, or `FiniteF64` like `NonZeroU64`, or even `#[range(0..1<<60)] u64`, but you still couldn't overlap two `Aligned`s in one enum, because only one can be stored unchanged, the others need masking off before usage. Even if the enum semantics allowed this, I'm not sure the compiler should do this kind of compute/memory tradeoff automagically. Which doesn't mean you can't write nice abstractions over it, there's a few tagged ptr crates which aim to do it for you