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.
> 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), ...
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.
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).
> Shirley rejects Leibniz as the first creator of the binary system.
I think the idea of single-source attribution of relatively simple concepts is plain stupid. Any number of people could have made this up in a wide array of circumstances and for a similarly wide array of circumstances we may never know about it. For somewhat similar reasons a lower bar for patents has been established.
"The march toward specialized systems" is an interesting slogan (if you will), since that's exactly where we came from; we (as in: the industry) made a huge point out of doing as much as possible using general-purpose components (remember GPGPU?) and more or less open standards. It is of course obvious that the general purpose approach has inherent inefficiencies, but we gladly paid the price. I see some similarities here with the recent rise in popularity of lower level programming languages (better C++, Rust, even Go), after the move to VM-based highest-level languages (Python, Ruby, JavaScript, countless others, perhaps even Java).
We see the gains in productivity and the reduction in cost – at least according to some measures –, but it has inherent inefficiencies. Inefficiencies like simple applications using far more CPU and memory than they're due to.
This perhaps makes people think again what would be possible if all the abstraction (analogous to general-purposeness of hardware) were wiped away and what has been possible in the past using far fewer resources.
> It's one of the most important projects for the open source desktop, for example GTK (formerly GIMP Toolkit) is one very important outcome.
Is it? GTK/Gnome was created over a historical footnote and to this day is more of a hindrance than helpful overall. It effectively bisected the entire Linux desktop community and caused so much time lost with downstream application developers.
GIMP is obtuse to use and provides an UX that has been out of touch for many years. It doesn't support features that are just bog-standard in other products, for years. (Like >8 bit colour). It is exactly the kind of amateurish project that gave FOSS GUIs their bad reputation.
On a marginal connection source/sink of a DP link will re-train which interrupts main link operation, causing brief lags in display. If the connection is even worse you'll get the usual black-picture-for-a-few-seconds dance.
Humans are never great at self-moderation.