You can't just have a robot start mining/processing rare earths, anywhere in the country. You need permits, and a lot of money. I guess that didn't stop AI companies ... but there isn't an "infinite" novelty/hype premium for rare-earths, like there is for LLMs.

https://jarv.is/notes/cloudflare-dns-archive-is-blocked

8MB is pretty huge though; musl libc is famous for defaulting to much smaller per-thread stack size of 128KB (to avoid over-committing lots of memory when there are many threads - the main dev is really principled/opinionated on this topic, but again there are a few ways for applications to explicitly size their stacks as large as they need). Linux kernel threads get a bit less than 16KB!

> Simply put, the things a high-end CPU needs are diametrically opposed to the things a small cost-saving microcontroller core needs.

> The conclusion he draws is that no single ISA can serve both ends, and that RISC-V fans are fooling themselves, in theory the premise is true. The conclusion does not follow, and I can show you why from three parts sitting on my desk as we speak.

> CH32V003. This is the cheap "RV32EC" with sixteen registers, no multiplier, no divider, machine mode only,

> CH32H417. A dual core MCU that is unmatched in performance to price point and is at the higher end of the MCU line

> Baochip. A VexRISC-V with an MMU built around a stack thats open from silicon to os Baochip-1x: A Mostly-Open, 22nm SoC for High Assurance Applications

Uh, which one of these is a datacenter server cpu? Or a workstation cpu? Or at least a developer laptop cpu? How about a Raspberry Pi 4 level SBC (supporting latest ubuntu and fedora releases, driving a display that runs a browser and plays video ...)

There's a lot of angry indignation but it seems obvious that Dmitry is quite right about this.

But I found this is where this blog post starts making a lot of sense:

> Has anyone tried adding an MMU to a Cortex-M? The physical tradeoffs are real, the difference is that with RISC-V, the ISA owner does not decide for you where that boundary must be drawn. If you want virtual memory on ARM you license a Cortex-A instead, which is a different core family, a different profile, a different negotiation, and a different royalty.

> Compare what happened with Baochip. The RISC-V privileged specification defines supervisor mode and Sv32 paging as optional things an implementation may provide. VexRISC-V is an open core, somebody added an MMU to it. bunnie built a chip around it and runs a microkernel with real process isolation on it

Yeah, that is a good point. We're still in the low-end specialty realm, but that is real interesting advantage for RISC-V, a good reason for it to exist.

As for shipping to Trinidad and Tobago ... this post is trying too hard to turn this into moral issue, but it seems a bit random (OrangePi cost $30 and shipped free? you can also get arm-based and stuff from the same places), and the vast majority of people don't live on semi-remote islands, it doesn't make sense to consider this kind of accessibility above all else, and it's strange to blame Dmitry for not thinking of you here.

Freakin' safety. I like doing lots of unsafe things in life: rock climbing without gear (short bouldering sections on hiking trails), bicycling and skateboarding without a helmet, etc. I developed pretty good skills in all these things, and programming C too. What kind of life would be worth living with enforced perfect safety? Without developing skill in life's many un-safe activities?

So people want to emphasize that, if they shouldn't use non-Rust languages because their safety can't be guaranteed, well your safety using Rust isn't absolute, either. So you can't tell me I must use Rust, or the Rust rewrite of my favorite tools, to "be safe".

Do you recall the early rust web framework, that used a lot of "unsafe" "inappropriately" and had some vulnerabilities ... actix web? ... reminds me of the bun-in-zig situation, kinda makes the language's PR situation more complicated and tricky.

The measure of a good high-power cable is the resistance. You can gauge it with a usb test load, typical usb power meter, and a usb-pd trigger (all can be pretty cheap, often you can find the trigger functionality combined with one of the other two). Calculate voltage drop for a given current by measuring both sides of the cable, or at least compare different cables with similar load.

But I found a "USB Cable Checker 2" by BitTradeOne which will directly measure and show the resistance in milli-ohms, very convenient! A very good cable measures 150 to 250 mOhm, the worse ones are 3 or 4 times that (at which point this device over-ranges around 1000 mOhm). You can really tell the difference with how some phones and laptops will slow their current draw after voltage droops.

I use Arch on my laptop, when I got it 2 years ago the amd gpu was a bit new so it was prudent to get the latest kernel, mesa, everything. Since I use it daily it's not bad to update weekly and keep on top of occasional config migrations.

I use Debian stable on my home server, it's been in-place upgraded 4-ish times over 10 years. I can install weekly updates without worrying about config updates and such. I set up most stuff I wanted many years ago, and haven't really wanted new features since, though I have installed tailscale and jellyfin from their separate debian package repos so they are very current. It does the same jobs I wanted it to do 8 years ago, with super low maintenance.

But if you don't want Debian stable, that's fine. Just let others enjoy it.

The patterns we had established were as simple, basic, and "safe" as practical, and we advised and code-reviewed the mechanics of services/apps for the other teams, like using database connections/pools correctly, using async correctly, validating input correctly, etc (while the other teams were more focused on features and business logic). Low-level performance was not really a concern, mostly just high-level db-queries or sub-requests that were too expensive or numerous. The point is, there really wasn't much of anything for CodeQL to find, all the basic blunders were mostly prevented. So, it was pretty much all false-positives.

Of course, the experience would be far different if we were more careless or working with more tricky components/patterns. Compare to the base-rate fallacy from medicine ... if there's a 99% accurate test across a population with nothing for it to find, the "1%" false positive case will dominate.

I also want to mention a tendency for some security teams to decide that their role is to set these things up, turn them on, cover their eyes, and point the hose at the devs. Using these tools makes sense, but these security teams think it's not practical for them to look at the output and judge the quality with their own brains, first. And it's all about the numbers: 80 criticals, 2000 highs! (except they're all the same CVE and they're all not valid for the same reason)

It's possible, they exist, many such LEDs are probably manufactured in China ... but the legit ones are probably more expensive, and you may need a more recognizable brand to do some QA, and keep pressure on the factory to not slip quality or inputs.

Consider the cheap screwdriver included with the lamp in this story: unexpectedly, many were more faulty than the cheapest $4 screwdriver you'd find in any hardware store. The more stories you read about manufacturing stuff in China, the more you'll see very strange things. It's not about nationality or anything, it's an extreme kind of optimization. If you didn't catch it already, maybe you didn't really need what you thought you asked for ... they're just checking/optimizing

(The price doesn't bother me ... it's worth the much lower chance of leaking than alkaline, if you leave it in a remote or gadget for years. But I've come to think that rechargeable NiMH like eneloops are a better idea due to the voltage.)

https://arstechnica.com/gadgets/2021/10/windows-11-the-ars-t...

> ... the best rationale for the processor requirement is that these chips (mostly) support something called “mode-based execution control,” or MBEC. MBEC provides hardware acceleration for an optional memory integrity feature in Windows (also known as hypervisor-protected code integrity, or HVCI) that can be enabled on any Windows 10 or Windows 11 PC but can come with hefty performance penalties for older processors without MBEC support.

> Another theory: older processors are more likely to be running in old systems that haven’t had their firmware updated to mitigate major hardware-level vulnerabilities that have been discovered in the last few years, like Spectre and Meltdown