pm215

Same principle as why many people prefer not to own shares in the company that employs them -- you're already heavily exposed to that specific risk and don't want to add more. If you live in Florida then a hurricane in Florida already might mean financial loss for you if it damages your house, so buying a CAT bond that covers a different thing is more diversified risk: you might get "house is trashed" or "bond is total loss" but at least you probably will not get both at once.

Yes, especially as CPUs have got faster and put in more clever tricks to improve performance (bear in mind that this blog post is 15 years old). Modern architectures have introduced modes to allow you to turn this off so that for your crypto code you can get back the not-data-dependent timing you wanted. For instance on Arm that's FEAT_DIT:

https://developer.arm.com/documentation/ddi0601/2025-06/AArc...

and the set of instructions you can safely use is listed.

I believe Intel has a similar thing.

PyPy intermediate representation. I assume this is what PyPy turns Python "abs(x)" into in codepaths where it knows x is a float.

By having knowledge baked into it about its properties (which it can validly do because the behaviour of the float_abs operation is specified by the language; it's not calling an arbitrary external function). The blog post sketches out one approach to this: as the optimizer is working on a tree of expressions, it has attached to the nodes extra information about the values in it (e.g. "this is a constant X" or "this value is definitely in the range A..B"); then as it simplifies the tree, it can say "abs of a value that's already definitely not negative is a no-op, don't do anything", in the same way it can say "multiplying X by 1 is a no-op".

The actual bug-fix linked to in the footnote does it in a slightly different way: it says "as I'm walking through optimizing my tree of expressions, if I see 'abs(abs(X))' then simplify the tree to just 'abs(X)'".

I think the other thing that often muddies the waters in discussions of code review is that open source projects and internal codebases are generally in rather different situations. An internal codebase is usually worked on by a fairly small group of experienced people, who are both creating and also reviewing PRs for it. So:

- the baseline "can I assume this person knows what they're doing?" level is higher

- making the "create PR" process take longer in order to make the review process faster is only a tradeoff of the time within the team

- if something is wrong with the committed code, the person who wrote it is going to be around to fix it

But in open source projects, there are much more often contributions by people outside the "core" long-term development team, where:

- you can't make the same assumptions that the contributor is familiar with the codebase, so you need to give things extra scrutiny

- there are often many fewer people doing the code review than there are submitting changes, so a process that requires more effort from the submitter in order to make the reviewer's job easier makes sense

- if there's a problem with the code, there's no guarantee that the submitter will be available or interested in fixing it once it's got upstream, so it's more important to catch subtle problems up front

and these tend to mean that the code-review process is tilted more towards "make it easy for reviewers, even if that requires more work from the submitter".

Proper focus-follows-mouse does not autoraise the window when it gives it focus. I see that that app does offer "don't raise the window" (which I think is an improvement from last time I was researching this some years back), but only under an "experimental feature" flag that relies on undocumented private macos APIs that might go away in any future macos version...

The one I have always missed is proper focus-follows-mouse support. The mac desktop always feels really clunky without that when working with multiple windows.

If you want to watch the talk that these are the slides for, it's now up on youtube along with the other KVM Forum talks: https://youtu.be/gSB5sn3ZN3w

At least in the UK I think you can at a high level map out some system level reasons why this sort of "public realm" problem doesn't get solved:

* the UK's economic growth has been poor since the 2008 financial crisis, so government resources from taxation have similarly not been growing as much as they used to

* demographics (more elderly people) mean that spending on pensions and healthcare has been steadily growing

* so the spending on every other aspect of government and other public-realm type things has been steadily squeezed: there are no resources for improvements on either the big scale or the small

* plus we have (like the US) a setup where many people and organizations have an effective veto or delaying ability on building things (houses, public infrastructure, etc), which makes fixing public infrastructure problems very expensive and time consuming.

As a water-related example of the last point: there's a proposal for a new reservoir near me which is classified as a "nationally significant infrastructure project". The timeline outlined at https://fensreservoir.co.uk/proposals/process/ started in 2022 with "pre-application consultation" in multiple phases, doesn't even submit the formal planning application until 2027, hopes to get a government decision in 2028, will not start construction until 2030 and might finally get the reservoir up and running by 2036 if nothing is delayed. And this doesn't account for the possibility of legal challenges to it which could add extra delay even if they are dismissed.

Resources-wise there's not really any "stealing" going on. The people/companies who care about KVM and the virtualization use cases work on that, and the people/companies who care about emulation work on those parts. If QEMU didn't support virtualization then it's not like the people currently working on QEMU virtualization would shift over to emulation support: they'd be working on some other project instead to achieve their VM goals.

Correctly assessing the risk doesn't mean "I don't do anything that has an unlikely possibility of a horrible outcome", it can mean "I decide that I'm OK with that possibility and do it anyway, because I think the benefits outweigh the possible drawbacks". If you then do get unlucky and catch a nasty disease, that should not change your post-recovery decisions about going on holiday a second time: your risk/reward tradeoff should still be "I'm OK with the possibility of a bad outcome".

Re "It is a human nature to overreact (post-factum) to an unlikely event" -- yes, absolutely agreed. This is what I mean by saying that humans as a species are terrible at assessing low-probability risks. That most people change their view just means that most people both underestimate the likelihood of low probability events that haven't happened to anybody they know, and overestimate the likelihood of low probability events that have happened to somebody they know.

I think that falls into the "did not correctly assess the risk beforehand" bucket (and as you say and as the post I was replying to said, this is quite common). If they had correctly assessed "this is going to be really awful if it happens such that want to rule out even an unlikely possibility of it" they ought to not want to do it the first time.

In that case they would not change their mind, though.

It might alternatively be an indication that they can't properly assess the risk and the outcome afterwards....

(More likely both: we are as a species absolutely terrible about assessing low-probability risks.)

memcpy (and the other string routines) are some of the library functions that most benefit from heavy optimisation and tuning for specific CPUs -- they get hit a lot, and careful adjustment of the code can get major performance wins by ensuring that the full memory bandwidth of the CPU is being used (which may involve using specific load instructions, deciding whether using the simd registers is better or not, and so on). So everybody who cares about performance optimises these routines pretty carefully, regardless of toolchain/OS. For instance the glibc versions are here:

https://github.com/bminor/glibc/tree/master/sysdeps/aarch64/...

and there are five versions specialised for either specific CPU models or for available architecture features.

I used a SparcStation 2 as an X terminal for several years in the late 1990s, having picked it up free as a student. Eventually PC monitors and my budget improved to the point that I retired it, but it was massively better than the cheap 14" CRT I had on my PC at the time.

I did have to contribute floating point emulation support to the Linux sparc32 kernel code, as otherwise the X server would occasionally crash when it hit a denormal number in the font rendering...

The older Sun monitors were fixed frequency (not multisync like a typical PC CRT monitor), so you only got one resolution, it couldn't sync to anything else :)

Sure, but if the fetcher is generating "39,000 requests per minute" then surely something has gone wrong somewhere ?

If you can already subvert the flow of execution enough to jump somewhere you shouldn't be, you probably have better targets elsewhere in the binary than a conditional branch.

There's a little free-entry one-or-two-room museum on the site: https://www.crystalpalacemuseum.org.uk/ (though ironically it is currently closed due to fire damage; normally open on Sunday afternoons) which has some photographs and various bits of memorabilia relating to the building. If you're planning on wandering down to the site and looking at the dinosaurs, it's worth dropping in here too.

(I work on a project that uses an email workflow. "Should we switch to something else?" is a perennial topic.)

I think the main pain points are:

* unfamiliarity -- if you're not already set up then it's extra admin work. And the "obvious" approach (paste the patch into your usual email client and hit send) generally mangles the patch.

* developers are no longer largely using local plain text based email clients -- if you are already doing email that way then sending patches like that is a natural extension. If your email client is gmail, or worse still some Microsoft mail server, now you have to figure out how to send email in a way that's not html and doesn't get mangled by your mail server.

* how to set it up is not a single well documented path. Github has an incentive to do a decent tutorial/docs, and how to create an account and send a patch is the same for everyone. Using git send-email, there's a lot more variability: how to install it depends on your OS, and how to configure it to talk to your mail server depends on your mail server. In these days of two factor authentication and app specific passwords, it's no longer as easy as "put the server name and your account name and password into the config file".

This has got better in that now you can point people at e.g. https://git-send-email.io/ which has info on e.g. setting up gmail app specific passwords and what kind of authentication to use.

If you're a regular developer on a project, this is a one-time pain and thereafter sending patches is straightforward (assuming you're not totally allergic to the command line). But for one-off or first time contributions it can be a barrier.

No, the problem I describe is "I am thinking of a Japanese sentence (which I know the meaning of), and I could write it in hiragana but not in kanji".

This is analogous to "I want to write an English sentence, but I can't remember how to spell one of the words", except it's worse because at least English words are spelled vaguely in line with their pronunciation.

I think where I may have stated the problem confusingly was my reference to not having a link between the Japanese word and the English RTK keywords. RTK assigns one unique keyword to each kanji, which (a) doesn't always line up with the meaning of a word in which it's the only kanji and (b) doesn't inherently help with multi kanji words. In this case benkyou is 勉強 which is two kanji with the RTK keywords EXERTION and STRONG. Unless you actively learn and memorise a link between the Japanese word and this pair of keywords, RTK is not going to help you with writing the word.

I think the thing that makes it a problem for most people is that they can't memorise them as "once and done" the way Heisig says he did. So as well as the initial time spent looking at the kanji and coming up with a good memorable story/image/mnemonic/etc, most people I think also spend time in an SRS (e.g. anki, or kanjikoohii) reviewing the characters they learnt previously. It's the review time that really stacks up, especially where you have particular characters that you have trouble with ("leeches").

I knew the word (including how it is spoken and what it means), so I would have no difficulty of understanding if it was said to me in conversation, I could read the word whether in kanji or hiragana, I could compose sentences in my head which used it and use it when speaking, I just didn't always remember how to write it in kanji...

(Here べんきょう is just an example: the same issue applies to essentially every word.)

Yes, I agree that trying to learn kanji upfront is a silly idea.

Heisig says in the introduction to RTK I that he learned 1900 characters "before the month was out". If like him you can do the whole set in a month and then have no further need of formal review or study beyond using them as they turn up, then I can see it not being a terrible idea. But as far as I can tell, almost nobody has a mind that works like Heisig's does: people seem to need longer and to rely more on review via an SRS like Anki.

Personally I found my problem with RTK was that I successfully memorised "English keyword to write the character" for 2000 kanji, but this was not at all linked to my actual use of the language, so I still had the problem I started with of "I want to write the word べんきょう but can't bring to mind the kanji for it", because I had no association between Japanese words and the English keywords for their component kanji...

I think the thing about academic open source is that the government is not "funding open source" -- they're funding research, and all the incentives and measurements and funding criteria are set up (give-or-take) to drive towards "better research". Any open source software produced is a by-product. A hypothetical "government funded open source" would hopefully have criteria and incentives that drive towards better software...

Presumably the LLM reads your accidental double negative ("when no high quality sources are not available") and interprets it as what you obviously meant to say...

There's an example of this in railway electrification: if you scroll down to the graph in https://publications.parliament.uk/pa/cm5801/cmselect/cmtran... it shows that the UK tends to do electrification as occasional big projects, whereas Germany has consistently done about the same mileage every year for decades, presumably with the same institutions maintaining their expertise and just moving on to the next bit of track. Their costs are a quarter of the UK's...

In particular listed buildings are subject to special planning rules and need permission for any extension, alteration or deletion; the planning authorities can mandate that you do any alterations in particular ways (e.g. use of traditional materials) to avoid damaging the character of the building. This means that everything is more expensive and takes longer. Luckily in this case the current owner seems to have done all that hard work already...

The listing says it has "a 250,000 litre rain harvest system and storage with a reverse osmosis system providing potable water".