Your suspicion could have easily been cleared by reading the paper.
If you're short on time: the paper reads a bit dry, but falls in the norm for academic writing. The github repo shows work over months on 2024 (leading up to the release of 3.13) and some rush on Dec 2025 to Jan 2026, probably to wrap things up on the release of this paper. All commits on the repo are from the author, but I didn't look through the code to inspect if there was some Copilot intervention.
If we go by Microsofts 2020 account of 1 billion devices running Windows 10 [0], and assume all those are running some kind of electron app (or multiple?) you easily get your gigawatt by just saving 1 watt across each device (on average). I suspect you'd probably go higher than 1 gigawatt, but I'm not sure as far as making another order of magnitude. I also think the noisy fan on my notebook begs to differ and maybe the 10 GW mark could be doable...
Not sure about that, SSDs historically have followed base-2 sizes (think of it as a legacy from their memory-based origins). What does happen in SSDs is that you have overprovisioned models that hide a few % of their total size, so instead of a 128GB SSD you get a 120GB one, with 8GB "hidden" from you that the SSD uses to handle wear leveling and garbage collection algorithms to keep it performing nicely for a longer period of time.
Yes, the thought crossed my mind too... But then I tried a private window and it opened, so maybe the other suggestion that the cookies are very long lived is right.
A little bit off topic: but I couldn't even start to read the article because "I reached my article limit" out of I site I never visited before... What are they using to determine how many articles I've read?
Opening in a private window solved the issue, however I'm pretty sure I don't regularly read anything on this site (maybe never was an overstatement?).
In the ~30 years I've used computers, they've become ~1,000,000 times faster. My daily experience with computers doesn't show it. There's someone out there who took the time to measure UI latency and has shown that, no only isn't it faster, it's actually slowed down. And yet, our hardware is 1,000,000 times faster...
The abstract of OPs link mentions "Processing-Using-DRAM (PUD)" as exactly that, using off the shelf components. I do wonder how they achieve that, I guess fiddling with the controller in ways that are not standard but get the job (processing data in memory) done.
Edit: Oh and cpldcpu linked the ComputeDRAM paper that explains how to do it with off the shelf parts.
No, I just went to search if the topic is mentioned in guidelines (which it is, multiple times). I'd then expect a (good) expert to pick on those breadcrumbs and search on how to do that (if they don't have the skills already). If I were working on a computer, I'd try to find IOCs that point to an infection (or lack of evidence for it).
If there's a memory dump to work on, a more in-depth analysis can be done with Volatility on running processes, but it usually falls back on the expert having good skills on that kind of search (malfind tends to drop a lot of false positives).
But at least the guides gave a baseline/starting point that seems to be better than what was described. It's very difficult to prove a negative, so I'd also be careful with the wording, eg: "evidence of a malware infection was not found with these methods" instead of "there's no malware here".
The lack of standards falls on the acting part. I ran a quick search and found that SWGDE best practices guides and documents do consider the case for the presence of malware on the digital evidence sources on many different scenarios [1]. Having an "expert" who is unaware of these guides is another story.
That's interesting. A project at work is affected by Windows slow open() calls (wrt to Linux/Mac) but we haven't found a strong solution rather than "avoid open() as much as you can".
When I moved some projects from OpenCV 3 to 4 I got a nice speed up pretty much everywhere, some things no speed up at all and some others pretty big. I can't really remember the numbers, but at the moment it was a global 10 to 20% perf improvement just on updating a library.
Might want to check that. Also 4.something got SIFT as part of OpenCV (instead of living in the contrib module) because the patent expired and you can now use it for free.
As for blowing up with NN packages and such... I don't really use those parts, but if the NN module had easier support to run networks trained on popular frameworks I might've used it. Disclaimer: it's been quite a while since I last tried to use those parts, so maybe now the latest version has fantastic support and I'm talking nonsense.
I ran a few tests in Windows Terminal. The bomb emoji got width 2, while the motorboat got width 1 and correct aspect ratio, though I didn't quite get to see it properly until I zoomed in like 5x. The family was rendered all as one emoji, cells wide, but left 4 blank cells before it.
So it was a bit better than the authors tests, but there's still room for improvement.
> It means LK99 is about as good as the other materials, at minimum. However, its chemical composition is different than any of the other materials on the chart (i.e. it is lead based)
While what you say is correct, let's not forget that lead _is_ an elemental superconductor. With a Tc of 7K, it's only bested by niobium (9K) and diamond (11K) as an elemental superconductor.
Yes, cuprates and ceramics were ruling high-temperature SC so far, but it's not like lead was entirely unexpected in the superconducting world.
If you're short on time: the paper reads a bit dry, but falls in the norm for academic writing. The github repo shows work over months on 2024 (leading up to the release of 3.13) and some rush on Dec 2025 to Jan 2026, probably to wrap things up on the release of this paper. All commits on the repo are from the author, but I didn't look through the code to inspect if there was some Copilot intervention.
[0] https://github.com/Joseda8/profiler