ploxiln

If there's a Chinese brand that gets a good reputation, then they too will suffer from other Chinese counterfeiters. For example, the "Pinecil" soldering iron from Pine64 got popular, and then warned on their website to only purchase from their official site (or EU distributor site) because Amazon and AliExpress are rife with counterfeits of this Chinese brand soldering iron.

Apple manufactures a lot in China, you can get amazing stuff made in China and many do. The problem is trust (perhaps more specifically, provenance). Is this thing really what it says it is? It is just a strange phenomenon that China has an incredible un-matched industry in making cheap decent-looking imitations (in addition to the actual high-quality products that trusted brands sell).

Mining is not limited by human labor, we already use huge machines (and some robots) controlled by a few humans. The limitations are investment in huge machines and processing plants, and regulations on where/how you can mine/process.

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.

8MB is the default per-thread stack size from glibc, also seems to be the default "ulimit" from pam or the kernel, I'm not sure. So for the main/default thread (or if not using threads) the process can use setrlimit() and for threads it can use pthread_attr_setstacksize() to get bigger stacks if it knows it may need them.

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!

You can forward USB devices into a VM. About 15 years ago I was using a Windows VM on Linux to program PIC18F??? devices with the custom (JTAG based?) programmer provided by Microchip. The upside is that you can preserve and share this windows environment for other coworkers, and have separate VMs for different projects (perhaps one you can update, and one you can't ...)

This blog post is very defensive and argumentative, which I guess is fair considering Dmitry's post is similarly inflammatory, but most of it was really not convincing:

> 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.

I think it's a reaction to many simpler advocates of Rust saying "it's unsafe and irresponsible of you to not use Rust, you can't write software in C or C++ or Zig (or Go?) and have memory unsafety and put your users at risk, it's not safe, you have to use Rust to be safe".

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 high data rate cables all need to be stiffer. You can find good 100w or 240w charging cables with good flexibility, so that's a good reason to keep usb-2 data-speed but high-power charging cables.

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.

If they can provide only 20% of the functionality and only 1% of the bugs, that's a compelling trade-off for many use-cases! (and a bit closer to the reality IMHO)

But you probably depend on over 500 open source libraries and tools, mostly ones you're not aware of. (Do you ever use a linux VM to run or just develop your stuff? Ever use git or curl etc? Did you know that tools and components in turn use other open-source libraries that you didn't pay for?) The main reason you use such things is so that you don't have to worry about this question.

You don't have to use Debian stable, if you'd prefer Ubuntu every 6 months, or Fedora (6 months? 9 months?), or even Arch Linux updated daily ...

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.

I'm still using Xorg after all these years, on a laptop with 150% scaling, which I occasionally plug into an external monitor with 100% scaling. Somewhat surprisingly, it works great. (Cinnamon desktop, Ryzen 7840u integrated graphics. And also a desktop machine with Radeon RX 6800XT, but it's not surprising that still works great.)

it's "Enterprise" grade software! need to check the boxes for the procurement process (actually working is a separate department)

Just type <enter> without cat, your shell will show you another prompt, and the ssh escape command will also work.