dom0

> Humans are not always great at self-moderation

Humans are never great at self-moderation.

So you are saying that what makes the tactility (the slider moving on the spring) and that what makes the contact (the slider moving the spring until it touches some other metal) are the same, which is exactly what I said ("mechanically connected").

How the making or breaking of the contact is related in terms of travel to the key press force doesn't have much to do with that.

The point I made was simply that on other kinds of keyboards the two are not related. On a rubber mat keyboard you can keep the dome depressed yet not actuate, for example. The collapse of the dome is also harder to control than the resistance against the spring. That makes preloading harder.

A bunch of news sites use similar URL parsing; they tend to not care about the "slug" either. I think this is, in the general case, the best way.

It is positively the correct time to shovel some money into the trash fire ^W ^W ^W ^W ^W ^W ^W invest wisely, in BTC.

> or why video codec accelerators are also faster and more efficient than GPUs for video decoding

encoders: also much higher quality

> We used simple machines, long before we understood them.

There are infinitely many examples of this, from metallurgy to rolling bearings to gears (gear reduction has nothing to do with teeths), medicine, astronomy (humans have predicted the motion of the stars for thousands of years), ...

> Nope! This is rarely (if ever?) the case.

Cherry MX.

Seasoned gamers preload keys they are anticipating to use. On my keyboard I have less than a millimeter of travel from the preloaded point I use (which is right in front of the tactile bump and is quickly trained) to actuation.

In tacticale switches the bump and the making of the contact are mechanically connected.

Using the moment of finger/key contact quite obviously selects for travel, among other things.

> which activate on first key press

No, mechanical keys have some travel before actuation as well.

memcpy is done by the CPU core, at least for x86. The IMCs don't process data.

The CPU core has more bandwidth than the IMC anyway, so there would be no speed-up from adding this complexity to the IMC (it would not only need to perform the operation, but it would also need a way to maintain cache coherence and communicate with the issuing CPU, none of which is a problem if you just do it in the core). It might not even save power.

They agreed, but now they regret the decision and wouldn't make it again. To prevent themselves from doing so, they will not speak with OpenBSD until later in the process.

Contra: A 14.5 year old open issue that is genuinely untouched for 14.5 years is most likely irrelevant, either because it was swept up, has become obsolete or is some kind of request that no one cares about (otherwise it would not sit around untouched for 14.5 years).