pm215

The linked article claims "in dry conditions, summer tires have the best grip down to 0C", though, which doesn't seem to match where you suggest the crossover point is.

I agree that testing colder conditions would be useful, but I guess you get into problems with it being ice and snow that you're testing, not the "summer tyres get too hard in the cold" hypothesis.

It's winter if it's noticeably cooler than summer. For instance London's climate has a January average minimum temperature of just under 3C, which is very clearly winter compared to the July minimum of 14C. (figures from Met office site on their Heathrow station.) While the temperature does drop below 0C sometimes, it is not consistently below zero.

In southern England pretty much nobody changes tyres for winter -- you just use the same set all year. Optimising for "2C in the wet" seems about right...

ARMv8 also gives you a a UDF imm, for a guaranteed undefined insn with an immediate payload.

The reason to want a true UDF imm with an immediate comes down to it being pretty solidly guaranteed that it's going to turn into your language/OS equivalent of a SIGILL insn. In theory an OS could by convention allocate some subset of BRK space for arbitrary userspace purposes, but in practice none did, so trying to use BRK gets you dumped into a debugger, or doesn't have consistent behaviour. It's nice for userspace to have something that doesn't need active OS support.

This is just unfortunate ambiguous phrasing -- Tim Ferris (and anybody else happy on part time hours rather than taking a part time job because they can't find a full time job) doesn't get counted because they don't match the "and wants one" qualifier.

The white paper states the definition more precisely:

"LISEP’s definition of “True” employment or unemployment accepts the U-3 rate for comparison purposes, but modifies it by adopting two important stipulations. The first stipulation deals with the workweek. To be employed for the purposes of LISEP’s true employment concept, an individual must either have a full-time job (35+ hours per week) or have a part-time job but no desire to be full-time (e.g., students). The second stipulation is that an individual must earn at least $20,000 annually."

FWIW, I have always and still do enjoy reading fiction, and I never visualize what's happening in the book. I just read the words and enjoy the story...

Though even in the UK I think it has a slightly old fashioned feel -- I feel like parents are more likely to have a pushchair than a pram.

I think it's reasonable to complain that the system doesn't have an "important but not urgent" message category (which might e.g. have the same "window pops up that you have to dismiss" UI but trigger whatever your usual text-message notification sound/vibration is rather than the VERY LOUD siren).

And given that the system does not have that "important but not urgent" category it's also reasonable to complain when the government uses the "urgent" notification system for something that is not urgent.

It caused me to turn off "severe" alerts (leaving "emergency" enabled).

You wouldn't want to hard-wire the deidentification company's name into the contract between Google and Spirit. Otherwise, if the deident-company happens to go bankrupt or otherwise be unable to do the work then you'd need to re-do the Google-Spirit contract, which would be a massive pain. And you don't want to make "we can sign this with Spirit now" be dependent on "we have first signed the deal with the deident-company". So I think it's reasonable that the contract says "one or more third parties acceptable to or designated by Buyer" rather than being specific here.

I see from the court PDF that the process here involves Spirit giving the data to a "Deidentification Agent" (a third party firm that Google selects and pays for) who is responsible for stripping out things that would link data to any particular person before passing the data on to Google. Is that a standard thing, such that everybody in this transaction would have said "yes, put in the usual clauses about deidentifying the data" and multiple firms offer this service, or is it something that they custom-specified for this "we want the data for AI" transaction?

(The PDF mentions "the standard for deidentification set forth under the California Consumer Privacy Act", which suggests this is all pretty well legislatively understood.)

Well, it was originally created for language learning. With vocabulary there really is so much of it that you're better off learning the stuff that sticks and moving on from the handful of items that just don't. In some other fields you really do need to memorise the whole set of items, but that's just never going to happen for second language vocab.

The other thing about leeches is that they're a sign that you probably want to try to change something about the way you're trying to learn them, because what you're doing now is obviously not working for those things.

A lot of work and code is Debian specific, and so there's a choice to be made about LLM use for that code, as there is for any project. And there are questions about LLM use in mailing list discussions, bug reports, and other non code interactions. Most of the options take a position on that (i.e. impose some rules for those contributions) one way or another.

What other projects choose on the question is interesting and might inform the choice, but what e.g. the kernel opts for doesn't control what Debian decides for itself, any more than the kernel's choice imposes any requirements on Rust or glibc or gcc.

This is the way general resolutions in Debian generally work. There's a lot of pre-vote discussion where different people and groups propose and draft their preferred options, to produce what they feel is the best expression of their position. If you can get enough seconders for your proposal it goes on the ballot, with the text you chose and your seconders agreed with. There isn't any requirement for the options to use consistent terminology or avoid overlap, and no overarching editorial process to impose consistency (which would be tricky anyway in cases like this where terminology choices and overall framing can be part of the disagreement between people.)

Neither choice 7 nor 8 attempt to forbid packaging of any upstream project with LLM contributions like the kernel.

Choice 7 says "The proposal does not cover indirect contributions, i.e. those originating from upstream works.". It's only making requirements on Debian work specifically.

Choice 8 says "We also acknowledge that LLM usage can be hard if not impossible to detect and that Debian as a distribution cannot really impose LLM policies on other projects we package and distribute. Therefore this text is just a position statement." It doesn't impose any requirements at all on anybody, even for debian specific work: it just says "we'd prefer it if you don't use this technology".

You started here with "associated with the environmental movement". That's not the same as everyone campaigning on a local issue who puts "environmental issues" into their big list of why some local development shouldn't happen: most of those people aren't associated with the environmental movement at all.

I guess my point is that I think the problem is nimbies, not environmentalists, and since I think we need a faster and cheaper planning system in the UK I think it's important to identify the actual problem. Getting the Campaign to Protect Rural England or whoever to produce a ranking of places by importance does nothing if we still have a system where local residents can raise objections about building on locations at the bottom of the ranking and it takes forever to push something through.