I would think they're gut core with metal winding around them - much as the bass strings on a classical guitar are nylon with a metal winding.
On a modern instrument the core would be metal as well.
1,428 karma · joined November 1, 2022
On a modern instrument the core would be metal as well.
I guess that's why Tcl is so popular in the EDA arena. I can stick some custom JTAG tooling in a Cyclone II design and talk to it by Tcl-scripting the 15-year-old software - and be confident that the same code (both in the FPGA and on the host computer) would work with the latest software and a current device.
Having said that, Tcl's not entirely free of compatibility and fragmentation frustrations: I sometimes wish that OpenOCD used full-fat Tcl rather than JimTcl, just so that I could make use of Tk. Being able to plot a histogram of data collected from the FPGA or make clickable buttons to trigger events is very useful.
I wouldn't, no - but that's exactly what's happening in the test case.
Likewise, I wouldn't expect -1 == 1 to evaluate to true, but here we are.
The strict semantics of the new bool type may very well be "correct", and the reversed-test logic used by the compiler is certainly understandable and defensible - but given the long-established practice with integer types - i.e "if(some_var) {...}" and "if(!some_var) {...}" - that non-zero is "true" and zero is "false", it's a shame that the new type is inconsistent with that.
Absolutely - there's a reason why traditional litho printing uses a clustered dot screen (dots at a constant pitch with varying size).
I've spent some time tinkering with FPGAs and been interested by the parallels between two-dimensional halftoning of graphics and the various approaches to doing audio output with a 1-bit IO pin: pulse width modulation (largely analogous to the traditional printer's dot screen) seems to cope better with imperfections in filters and asymmetries in output drivers than pulse density modulation (analogous to error diffusion dithers).
That's because Gtk4 does "client side decoration". That has the advantage (or otherwise, depending on your point of view!) that the application can now place custom widgets in the title bar, and the disadvantage that when apps do that, the part of the title bar available for dragging windows around becomes significantly smaller.
My main objection to client-side decoration is that middle-clicking a window's title bar to push it to the back no longer works. (Plus, for those of us with eyes that aren't as young as they once were, it's now much harder to choose a window border style that clearly indicates which window has focus.)
But yes, you're absolutely right - "no raindrop considers itself responsible for the flood".
Since I still have the machine in question here, and I'm now interested enough to try and get some rough measurements, I've just videoed it with my phone (30fps video) and done some frame counting, both from a cold boot with nothing cached, and also a repeated launch.
Firstly from a cold boot:
It's hard to tell exactly when the keypress registers, but I believe what I'm seeing is the key being pressed, two frames later the hourglass appears, two frames after that the calculator appears. (The TFT screen will likely be adding at least one frame lag, but let's ignore that for now.) So that's somewhere between 166 and 200ms for a cold launch.
If I close the app and repeat, there's now just one frame between keypress and hourglass, and just one more frame between hourglass and the app appearing, so now nearer 100ms.
Looking at the videos my finger is off the key the first time the app appears, but not the second time - though if I made a special effort to release the key as quickly as possible I now think I could probably just about beat it.
I do do still have both computers set up side-by-side (legacy data from an old business), and the keyboard in question was a Microsoft Comfort Curve 2000 (the calculator button wasn't a proper key, it was one of those squidgy extra keys so beloved of multimedia keyboards, so not as fast to operate as a proper key.)
Anyhow, the point (arguably hypberbolic as it may have been) wasn't about reaction time per se, it was about the older calculator app - and by extension much of the rest of the OS - being a much simpler and less bloated piece of software, and running it on faster-than-contemporaneous hardware makes for a sense of immediacy which is sorely lacking in today's world of web apps.
I'd be very interested to know to what that 300ms "threshold of perceptible delay" applies. You might not notice a window taking 300ms to open - but I'd be willing to bet that when you're highlighting text with the mouse or dragging a slider, you'd be very aware of the UI lagging by nearly 1/3 of a second.
Not to mention bloat: I have a keyboard with a dedicated calculator button. On a machine with Core i5 something or other and SSD it takes about 2 seconds for the calculator to appear the first time I push that button. On the Core 2 Duo machine that preceded it, running XP from spinning rust, the calculator would appear instantly - certainly before I can release the button.
But also WinXP was the OS a lot of people used during their formative years - don't underestimate the power of nostalgia.
Also, for some people the very fact that Microsoft don't want you to would be reason enough!
Personally if I were into preserving old Windows versions I'd be putting my effort into Win2k SP4, since it's the last version that doesn't need activating. (I did have to activate a Vista install recently - just a VM used to keep alive some legacy software whose own activation servers are but a distant memory. It's still possible, but you can't do it over the phone any more, and I couldn't find any way to do it without registering a Microsoft account.)
I've seen the same scenario - someone with limited vision, next to no feeling in his fingertips and an inability to build a mental model of the menu system on the TV (or actually the digi-box, since this was immediately after the digital TV switchover).
Losing the simplicity of channel-up / down buttons was quite simply the end of his unsupervised access to television.
A web forum I read regularly has been playing whack-a-mole with LLM scrapers for much of this year, with multiple weeks-long periods where the swarm-of-locusts would make the site inaccessible to actual users.
The admins tried all manner of blocks, including ultimately banning entire countries' IP ranges, all to no avail.
The forum's continued existence depends on being able to hold off abusive crawlers. Having to see half-a-second of the Anubis splashscreen occasionally is a small price to pay for keeping it alive.
You're saying this literally a few days after Microsoft pushed out a Win11 update that broke localhost.
Write an image to a smallish SD card using dd (to remove most of the blocks from wear-levelling circulation), mount without -noatime, and you should be able to get the lifespan down to a few hours!
In both cases the authorisation challenge/response involves part of the destination account number, so if the details are tampered with by malware the code won't work.