v1ne

Why eInk? The display updates often, that's a perfect choice for Sharp MIP displays. Also: Please use a fixed-width font for numbers. Seeing the values wobble around looks like a generic website, not like a serious product.

No, it can do whatever it wants. Just don't leak resources!

Don't worry. Once IT Security discovers that they miss their trusty endpoint security products on your Mac, they'll add it and you'll be in the same ballpark as the Windows machine. Been there, received that, and learnt that Microsoft Defender exists for macOS, too.

"USB data blocker" on AliExpress yields you very small adapters that enable you to run USB-PD, but block the data lines.

I tried to read this, and what the tool works, but this is so much text with little context. Looks like AI fluff. It sounds pretty straight-forward, so this should be a single page with a few paragraphs only.

Interfaces are persistent in Windows, that's why they get assigned such silly names as "LAN interface (42)".

If the mapping between the logical and physical interfaces changes, that probably means that your NICs lack proper IDs to differentiate them or the bus topology is somehow not stably sorted. I wouldn't blame the OS for this.

The trick about documentation is depth, not prose. You need context and understanding to write documentation "like in the old days". No amount of LLM trickery will free you from that. Once you have that source material, it's easy to re-shape it into an 80's/90's/00's doc format.

Negative example: I was looking into the German manual of my Canon EOS R5 II, and it is just fluff. Hundreds of pages, full of white space, telling me about features without actually explaining what they mean. Awful automatic translations. Their manuals used to be good (looking at my EOS 6D). But these days: oh boy.

It's sad to see Xtensa go. Their architecture was a clean design, a treat to read the assembly code. I get it, RISC-V comes without licensing costs, but that's one of the few positive things about it. For a fresh start, it is just already in this "we pile stuff on stuff on stuff" state that you expect of an architecture after 10-20 years of productive use.

Well, salt may be less volume than brine. But the demand for table salt is pretty limited. Thus: Why pay for its disposal when you can discharge brine for free?

Great! Brings a bit more dynamic into the market. So far, I'm happy with DxO, but I also don't need to manage a library.

I don't know, does Resolve have lens corrections for 100+ lenses built-in? That's the thing that DxO does really well: Lens corrections, matching your camera's color rendering, denoising. Unfortunately, they still struggle with HDR output.

I imagine the tools in Resolve save you much time, due to automation. Probably handy if you shoot a lot. Yet, the biggest difference is that in photography, you're not necessarily limited by throughput. You can and do actually put a lot of effort into single images.

I think it's more people being fascinated by this curious architectural detail. I imagine it's fascinating to people who are not exposed to the intricate details of computer architecture, which I assume is the vast majority here. It's a glimpse into a very odd world (which is your day-to-day work in the HFT field, but they rarely talk about this, and much less in such big words).

TBH, I didn't watch the video because the title is too click-baity for me and it's too long. Instead, I looked at the benchmark results on the Github page and sure, it's fascinating how you can significantly(!) thin the latency distribution, just by using 10× more CPU cores/RAM/etc. Classic case of a bad trade-off.

And nobody talked about what we use RAM for, usually: Not to only store static data, but also to update it when the need arises. This scheme is completely impractical for those cases. Additionally, if you really need low latency, as others pointed out, you can go for other means of computation, such as FPGAs.

So I love this idea, I'm sure it's a fun topic to talk about at a hacker conference! But I'm really put off by the click-baity title of the video and the hype around it.

Does anybody else's fingers also tingle like this is written by an AI?

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.

All of this works much worse on macOS: Scaling sucks, as it's integer-upscaled rendering + fractional downscaling in a shader. Windows can't span screens either.

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.

If people make extraordinary claims, I expect extraordinary proofs…

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

Completely agreed. I sit in dismay, remembering the Microsoft I frowned upon back in the days as a Linux/FreeBSD user. But at least their software was accessible via keyboard and their translations were really good.

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.

> Also, ML is now really good to translate between European languages

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.

Something to hack, but I don't see how to easily type braces and parentheses. Looks like a non-starter to me because for me, I hack by writing in languages that require parentheses.

The problem is not only the DAW support, but the support of low-latency audio interfaces in Linux. Audio interface makers rarely create a Linux driver, and a low-latency setup on Linux is its own hell, with real-time kernel patches. On MacOS and Windows, it works out of the box.

Thing is: That's your preference and nobody should force you to use these indicators. Even on Windows, the tray icons are usually mostly hidden away.

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

Well, it's a bold hypothesis that a household washing machine should sterilise clothes. It's a machine to reduce the load of microorganisms to a manageable level and to remove dirt, fat, and odours. I don't get how the authors arrive at their hypothesis. Before washing machines, people washed clothes with their hands. Cooking them in a pot was only viable with very robust fabrics made from cotton/hemp/flax. I seriously doubt that the microbial load would have been lower before the invention of washing machines. And with older washing machines, using those nasty aggressive washing agents: Maybe, but your clothes would not last that long (there's this difference between old US-style washing machines that just stir and don't heat and EU washing machines that have a drum that turns and always heat the water).

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.

I think the article misses the point: It's not about how complex the data structures are, it's about the result, in all its details.

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.

If it's not a user-space, but a driver issue, I found powercfg /sleepstudy pretty helpful to determine why a W11 machine didn't enter or exited sleep too often, after the fact.

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.

The question is: Who is the beneficiary of the app sandbox? Is it you, the user, because no malicious processes can taper with your apps? Or is it the corporations, because they prevent you from modifying their apps – which makes you a pure consumer?

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.

Yup, which is why a project that is serious about compilation time splits off type-independent parts into .cpp files that can be compiled separately, improving the speed of compilation for users of that template.

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

NTFS is slow, especially when you operate on a lot of tiny files (nobody in the Windows world would do that, you'd always put your tiny data blobs into a bigger container file, e.g. asset files in games), but from my corporate experience, it's mostly the _multiple_ "endpoint security" solutions that bog file system performance down.

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

Well, I consider software liability a good thing. Question is how to achieve this goal. Of course it's sad when a bureaucracy answers this with the only means a bureaucracy has: A box-ticking exercise.

Yep, and AVR-8 has excellent documentation, is easy to learn and I find really fun to work with.

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.

FreeBSD and Suspend/Resume… About 10 years ago, I switched from FreeBSD to Linux because I couldn't get suspend/resume to work reliably (i.e. suspend/resume cycle succeeds and it doesn't drain my laptop battery in between) on FreeBSD on my Thinkpad. And this was only Suspend to RAM. Suspend to Disk is really nice to have, especially if coupled with hybrid standby, as on macOS and Windows by default.

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

In theory, it's easy. But as you see, in practice, it's very difficult because the attacker doesn't have to play by your rules.

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.

The title is wrong. The author glitched the IP block with the one time programmable fuses in conjunction with logic that uses those fuse bits, not the RISC-V cores themselves.