The formatting is strangely inconsistent, highlighting only some numbers and some variables in fixed-width font. Also there's odd statements like that the reference resistor keeps its value "at all temperatures", which is just not true. Other phrases like "poly-silicon resistor" are highlighted, and then not explained. All in all, I find this article to be quite a mess and not a clear explanation.

On Windows, the window will adapt as you move its center of gravity across the edge of the screens. Sure, could be better than at the moment where the window is the wrong size, but it would always be blurry.

Also, there is nothing complex in a C compiler. As students we built these things as toy projects at uni, without any knowledge of software development practices.

Yet, to bring an example for something that's more than a toy project: 1 person coded this video editor with AI help: https://github.com/Sportinger/MasterSelects

Fast forward to now, after being a dev on Windows for years and loving it, and now their UX is a joke. For example, to jump back and forth between chats, neither the back/forth mouse buttons nor any other key combo works on macOS. You have to click the navigation buttons in the symbol bar instead. Translations are AI-powered, and that shows. Also, Teams is dog slow, which I also count as a UX issue.

As somebody who has to regularly bear "German" machine-translated UIs and manuals that originate in English, I can only say: No, it's not. It's atrocious.

I find them highly useful on macOS, but there I lack the configurability I have on Windows.

And then, "potential pathogens" in the biofilm in the machine. Ah, well. My skin and mouth are also full of potential pathogens. I don't know what this study is trying to show. Washing machines are not sterile, I guess.

Comparing different RAW converters (Lightroom, DXO), their image rendering is slightly different. If you compare the colors with the JPEG image, even more so. If the goal is to faithfully reproduce the colors as they were shown in the camera, you depend on the manufacturer's knowledge. To me, it makes not sense to have some "open" DNG format in the middle, when it's flanked by proprietary processing.

It's not about the format, it's about knowing the details, including parameters, of the image processing pipeline to get a certain look.

On my laptop, this led me to discover that my Qualcomm X55 WAN is a real standby drain and that my Lenovo Thunderbolt dock really likes to disable its sleep mode after some big Windows updates, leading to a standby drain after the first time I plugged it in. I'm still surprised how many pitfalls there are with standby, even on Windows.

I think, for the tech-savvy, the latter is more accurate and I think it is very important to be able to crack open these sandboxes and tinker with processes. Be it to inject ad blockers, automate them, modify their appearance, etc. It should be a right of a user to be able to do these things.

I consider being a header-only "library" a code smell. It's purely for convenience, at the cost of compilation speed.

It's the reason I so far use a Mac at work, which has its own issues, and a lot of them.

Honestly, AVR-8 is the reason I'm really into low-level hardware. If I would have started with amd64, I guess I would have given up long before.

I really appreciate that people still maintain FreeBSD on the desktop, though.

The attacker can play arbitrary shenanigans, like in this example, glitching only one power rail of many to attack a crucial part, or shine light on parts of your die. And suddenly, there is only little of this "usual" behaviour that remains.

You can look at the hardening mechanisms of Hardware Security Modules or security processors, e.g. in Smart Cards, for all the effort they take in order to detect an attacker.

To come back to your original question: Burning a "wire" is not what's usually done. I consider this to be impractical, since such a "wire" fuse would be electrically weak, impeding performance of any signal travelling through that wire. The same goes for an antifuse (I interpret the "AF" in the RP2350 datasheet as "antifuse" array), which when closed also only creates a weak electrical connection. That's why you usually use fuse bits as input to CMOS switches that will then be opened or closed.

Yet, if you would distribute these fuse bits and switches and put them directly next to their usage site, I think that could achieve your goal. Yet, still, this would mean you'd now have to route the control signals to these fuses instead, which would mean you have to route high-current or high-ish-voltage signals across your chip. So, in the end, I don't see an easy solution to this fuse dilemma.

I usually get barely a working day out of my corporate MacBook Pro M1 with Corpo Security Special Sauce, CLion and Teams. But I have to kill CLion when it gets too crazy (i.e. often). Do you have any insights from Activity Monitor on who is draining the battery?

My biggest offenders: - Symantec Data Loss Prevention Agent (x86 Emulation) - $Corporation App Store (I never use it, don't know why it burns CPU time)

This corporate "security" software is the essence of everything that's wrong with a corporation.