Not an expert here, so I’m genuinely curious how could a video stream (edit: with muted audio stream) possibly cause another laptop in close proximity to crash?
What is claimed in TFA is that the hard drive resonate frequency reacts to the Janet Jackson video in bad ways because that music video puts out music that interferes with what the hard drive expects.
TFA was lacking details so this is merely a retelling.
Obviously not the video but the accompanying audio track. Could also just be a made up apocryphal engineering story that never actually happened exactly as described. Engineering as a profession is chock full of them but they do tend to be memorable parables of things to keep in mind when working on a relevant piece of tech.
What is definitely well documented is Brendan Gregg’s related discovery of performance degradation in servers from vibration of sibling servers / clapping nearby that caused spinning disks to pause their heads.
I doubt it could, but when you run into a problem that defies your understanding of reality, you might try out responses that also defy your understanding of reality, in the hopes you might gain the missing insight somewhere along the way, yeah?
Also not an expert, it would have to be EMI or maybe the bright light was causing LEDs on the nearby laptop to generate voltage. LEDs can poorly work in reverse.
If this is just a fiction novel world‑building question: The video pixels create a bitstream to bitbang the gpu bus into emitting a 2.4‑gigahertz EMF signal to exploit a flaw in the Wi‑Fi driver.
I’m curious how type checking is possible in a JDoc project. As far as I’m aware there’s no way to get type checking to work without tsc or a TypeScript LSP plugin.
That is exactly how it works. Any IDE providing you intellisense is using the TypeScript language service. That's why this article is called "JSDoc is TypeScript". If you see a red squiggly because of your JSDoc comment, you are almost certainly already using TypeScript (without any .ts files)
Ha! I see I elicited the copy/paste response I’ve seen elsewhere. The gp comment I was replying to implied a JSDoc only solution (“all in JSDoc”), but given the response, clearly they’re still relying on the TypeScript language service (aka lsp plugin) to achieve type checking inside their IDE.
Wishful thinking on my part that an alternative solution for JSDoc based type checking exists :)
Generally, no. Only in the case you had a requirement to exclusively use JavaScript as the programming language you might be in for an awkward time justifying that you added type checking to the project via the type checker component of TypeScript with JSDoc :)
Depends on your definition of "using" JavaScript. The main difference between common TypeScript and TS-based JSDoc is the need for an additional build step. Being able to ftp-upload your `.js` files and then be done with it is a remarkable advantage over Vite/Webpack/whatever in small to medium-sized projects. If editor based type support is sufficient to you (i.e. no headless checks), you won't need to install any TS packages at all, either. tsserver is still used in the background, but so are thousands of other binaries that keep your editor, OS and computer running, so I don't see that as an argument.
It would, but it would be platform-specific and an external dependency. It was my first thought too until I started planning out it working cross-platform.
That personal risk includes having yourself or loved ones thrown in prison without any contact to the outside world for however long the dictatorship sees fit.
It’s a very sad history of oppression and corruption that has forced many Venezuelans to pull up their roots and risk their lives leaving their own country. It would be a dream come true to see this dictatorship overthrown and replaced by a democratic system of government that serves the people.
I really think that Rust has one of the best designed/inspired type systems.
If I had to rewrite a Python project, I would consider Rust or another statically typed language before choosing to continue in a dynamic language with types bolted on. I hope the situation improves for dynamic languages with optional types, but it still feels weird and bolted onto the language because it is.
I'm a professional .Net Core developer, but I'd throw my hat in the ring for Swift on this one. While obviously not exactly a 1:1 with Rust, there is definitely some common benefits between the two. Though, from what I understand of Rust (very little), its typing system is slightly more strict than Swift's which is slightly more strict than C#'s.
Ahh this might explain the behavior I observed when running npm install from a freshly checked out project where it basically ignored the lock file. If I recall in that situation the solution was to run an npm clean install or npm ci and then it would use the lock file.