LOL! I was asking Gemini Wix questions. The answers were wrong! When I pointed that out I got apologies and more code that didn't work. As with most newbies, I finally trial and error'ed my way out. I want to know how the "experts" have figured out how to use Wix. What is it that I should know but don't about learning Wix?
Have you toured the Battleship NJ? The firing computer is a mechanical analog computer. It's wild to see what can be done with some precision ground gears.
I remember starting to use software to stop a machine when the door was opened. A more experienced engineer stopped that and we added relay hard logic. That was 40 years ago, it's clear as day. Exactly the same issue with the Therac-25.
No, but anyone who has used the tube or busses more than a couple of times will know exactly what they're talking about when they see the pictures of the seats associated with the word.
Here is one from 1958 in Japan that has been preserved. The whole video is worth watching, but here is a demo of a running calculation: https://youtu.be/_j544ELauus?t=1027.
Yes, it made a racket! There is a description of the Harvard Mark I crashing in Beyer's "Grace Hopper and the Invention of the Information Age":
> Hopper, Campbell, and Bloch invested substantial energy in developing practices and procedures for debugging. Like physicians, they identified symptoms, made diagnoses, and prescribed treatments. Sometimes symptoms were obvious, as when Mark I would come to a crashing halt: “The crash of that thing sounded as if a plane had run into the building,” Hopper recalled. ”You never heard such a crash in your life.”
Is that where the term of a computer "crashing" comes from?
Similar to how the term debugging may or may not have been "reinforced" by the finding of an actual moth on the Mark II (it wasn't its origin, according to Wikipedia: https://en.wikipedia.org/wiki/Debugging#Etymology ).
"Watcher is extremely efficient. In most cases, even when scanning millions of paths, this library uses a near-zero amount of resources." Yea, maybe or maybe not and my first guess is maybe not.
This needs at least some bullet points on HOW it does this so efficiently so that I'll keep looking. A blanket statement like this means "they hope it is efficient" or "They want it to be efficient" or "It's good in some scenarios but not others".
With those additional bits, I have a reason to dig around the source.
If so, there are equivalent options, including systemd path units, incron, and the inotifywait utility, in addition to the C API.
The "man systemd.path" page does list explicit limitations of this kernel system call:
"Internally, path units use the inotify(7) API to monitor file systems. Due to that, it suffers by the same limitations as inotify, and for example cannot be used to monitor files or directories changed by other machines on remote NFS file systems." (Files modified by mmap() also don't trigger events.)
It's just an input right? Forget your expectation that an input causes a 'page' to move vertically; the screen is just a canvas that can change over time or in response to inputs.
(But, because it breaks your expectation is why people don't like it, call it 'scrolljacking' i.e. hijacking scroll behaviour, etc. It's worst IMO when it's done to make the page 'sticky' at certain banner points, so it takes unintuitively more or less scroll movement at certain points as you move down the page.)
