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."

The Severn Valley railway is about to start a trial where you can buy a standard railway network ticket to Bewdley which is then valid on the SVR on special purpose trains for the Kidderminster to Bewdley section; some of those will be steam. I think if that trial becomes a permanent operation it would count.

https://svr.co.uk/news/heritage-trains-to-carry-commuters-as...

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...

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.

Green belt areas mostly are not markers of ecologically important areas. They're a planning tool that largely exists to prevent urban sprawl. A lot of the green belt area is unremarkable commercial agricultural land.

I think here it's worth distinguishing between actually ecologically important, and the ability of campaigners to raise environmental arguments to try to prevent development when their underlying reason is something else (i.e. not wanting a nuclear plant in their back yard). There are definitely ecologically unimportant places in England, but it's almost certain that if you try to put a power station there somebody will raise an environmental concern anyway. This will probably eventually be dismissed, but you can gum up the works procedurally for a pretty long time.

Alpha punts handling of denormals, infinities and NaNs to software emulation, but that wasn't particularly unusual: some sparc CPUs and early implementations of Arm VFP floating point did the same.

Looking at the alpha architecture manual, the fp emulation traps are imprecise, which imposes constraints on codegen to make it work right: the "trap shadow" extends from the potentially trapping insn until a following trap barrier, and in the shadow you mustn't e.g. use a register more than once as a destination, have a branch, or modify registers that are inputs to any insns in the shadow. (The idea is that the hardware will have already executed some of the insns in the shadow by the time it realises it needs to trap, and the handler has to be able to emulate the trapping insn and resume execution at the insn just after that, so it will re-execute all the insns in the shadow.) That's obviously pretty inconvenient for codegen, so I wouldn't be surprised if the compiler provided some kind of fast-math mode where it didn't trap and you just had to avoid generating denormals, infinities, etc.

I think making the fp using code have to be written carefully to work with the software emulation of edge cases is unusual -- I don't think either sparc or arm imposed that requirement, and instead trap precisely, or at least before anything happens where it would matter that the fp insn is emulated late.

Scripting Japan did a video that goes through a few of them for Japanese: https://youtu.be/gjB79s4oCkc

I suspect it's a mix of historical reasons (#! support was added pretty early, in 1980 or so, when the unix development philosophy I think tended quite strongly to "do the simple thing", and there wasn't so much variation in where you might put important binaries like the shell), plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does), plus vague worries about potentially accidentally breaking existing #! lines that used to work.

Mmm. This Q&A -- https://www.chicagomanualofstyle.org/qanda/data/faq/topics/M... -- suggests it's been kicking around as printing and journalism jargon since at least the 1980s, and I would expect probably earlier.

The city government tracks data on public realm trees, and has a nice map based visualization of it: https://www.london.gov.uk/programmes-and-strategies/environm... and if you zoom in you'll see that many of these are streetside trees.

Personally I have always felt that most Japanese cities are very devoid of urban greenery compared to UK towns and cities.

Yes, QEMU's JIT is a fairly easy target to beat. Notably if you are happy to specialize the design to "only x86 to aarch64" and "only usermode" there's quite a lot of gain to be made. QEMU's usermode support is a kind of "this happens to work" appendix to its system emulation support, and the overall JIT architecture is a "guest to intermediate representation to host" one that is great for supporting a dozen guest architectures and multiple host architectures, but means you can't really take advantage of properties of a specific guest/host pair like "x86 has fewer integer registers so we can hard allocate them" or "we know the fiddly floating point semantics always match if you put the aarch64 CPU into the right mode". Plus there's just more time put into "emulate new architecture feature X" in QEMU development than into "look at optimization opportunities to make it faster", because that's what the people who pay for development work care more about.

For a long time in the dialup era my "answering machine" was a US Robotics voice-capable modem attached to my home Linux PC, with some scripts to make it pick up after N rings, play a message, record whatever the caller said, and then email me the resulting sound file. The Linux support for it included DTMF tone recognition, so I added in a quick hack so that if I sent it the right pin code during the "please leave a message" part it would wait for me to hang up and then dial my ISP, so I could ssh in to it from wherever I was...

Unfortunately the 70% price rise on the JR pass back in 2023 made it much less likely to be economic for most people compared to just buying tickets as you go, even for trips that visit more than one city. Last time I was there I did a loop up from Tokyo to Hokkaido and back by rail, and it was still cheaper to buy individual tickets. (There are obviously still some itineraries where it works out cheaper, but it's much less of an "obviously good idea for most people" than it was back before 2023.)

Also, "why these 5 in particular" is definitely not obvious -- there are a great many possible "obvious in some sense but also true in an important way" epigrams to choose from (the Perlis link from another comment has over a hundred). That Pike picked these 5 to emphasise tells you something about his view of programming, and doubly so given that they are rather overlapping in what they're talking about.

If the team is that small and working on things that are that disparate, then it is also very vulnerable to one of those people leaving, at which point there's a whole part of the project that nobody on the team has a good understanding of.

Having somebody else devote enough time to being up to speed enough to do code review on an area is also an investment in resilience so the team isn't suddenly in huge difficulty if the lone expert in that area leaves. It's still a problem, but at least you have one other person who's been looking at the code and talking about it with the now-departed expert, instead of nobody.

A fairly large category of the flaky CI jobs I see is "dodgy infrastructure". For instance one recurring type for our project is one I just saw fail this afternoon, where a gitlab CI runner tries to clone the git repo from gitlab itself and gets an HTTP 502 error. We've also had issues with "the s390 VM that does CI job running is on an overloaded host, so mostly it's fine but occasionally the VM gets starved of CPU and some of the tests time out".

We do also have some genuinely flaky tests, but it's pretty tempting to hit the big "just retry" button when there's all this flakiness we can't control mixed in there.

That's why I said "somebody else, without looking at it". Clean-room reimplementation, if you like. The functionality is not forever unimplementable, it is only not implementable by merging this AI-generated PR.

It's similar to how I can't implement a feature by copying-and-pasting the obvious code from some commercially licensed project. But somebody else could write basically the same thing independently without knowing about the proprietary-license code, and that would be fine.

If you're going to set a firm "no AI" policy, then my inclination would be to treat that kind of PR in the same way the US legal system does evidence obtained illegally: you say "sorry, no, we told you the rules and so you've wasted effort -- we will not take this even if it is good and perhaps the only sensible implementation". Perhaps somebody else will eventually re-implement it later without looking at the AI PR.

Even if there isn't any 3rd party code, the whole process of going through the codebase to confirm there really isn't any 3rd party code, and generally getting the legal department to sign off on it, is a lot of work in itself. My impression is that this kind of "historic source" release typically only happens if somebody sufficiently senior in the company cares enough to actively push it through. The default is that nobody does care that much, and it doesn't happen.

"Do nothing" has essentially zero downside for a big company that happens to have something of niche interest like this in its vaults.