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!
8MB is huge compared to the stacks we used to have when address spaces were 32-bit, but it's tiny compared to how much memory we can actually make use of now. The only real argument I can think of for having such a small stack is that large stack usage is often indicative of an infinite recursion bug and it catches them earlier.
But I don't really buy that for the same reason most programming languages don't limit loops to 8 million iterations (or whatever) by default - it would make catching infinite loop bugs easier!
I say most, because I know of at least one language that did do that - QuakeC! It made lots of sense in that context though.
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 is exactly what I do currently but it's flaky. Bekhoff installs a runtime on the development PC that works its way deep into the system that can and does crash the VM. Some USB devices work, some don't, some are buggy and may hang or fail in the middle of programming. I have to keep a dedicated Win PC just to make sure I have a working Winstall for my work. I keep VM's of 2k, XP, and 7 as I have to maintain a wide variety of hardware and software. I just want off the Windows upgrade treadmill.
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.
the author just focused on his personal experiences regarding RISC-V and what he's been able to see himself as an embedded developer. there's already RISC-V SBCs that are on par with the Raspberry Pi 5 and in terms of IPC the best RISC-V cores are only lagging 5 years or less behind the best x86 and ARM cores.
no, i'm talking about the core designs, not finished CPUs you could buy. using a leading-edge node is prohibitively expensive so nearly everything RISC-V i've seen has been using around 22nm to 12nm nodes. if you had an example of any of those cores in a finished product on a similar node they should be competitive, and in the meantime once people can get their hands on them you could test them against each other at low clock speeds to see how they compare.
Then if I understood well what you said: the main bottleneck for many of those RISC-V microarchitectures is the access to the best silicon process.
(ofc, they will have to optimize them for this node process)
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.
I don't think using an example that includes licensing, plenty of regulations governing drivers, the cars themselves and the built environment, enforcement, and plenty of research on the impact of passive infrastructure to make things safer (bollards, daylighting, raised pedestrian intersections, curbs, traffic lights, etc.) makes the case you seem to be trying to make.
Yep: there's a difference between driving a car in traffic and driving a car in a rally or in an endurance race. There will always be some rules and regulations unless you're on your own privately owned race track with no one else on there, but the regulations can differ greatly depending on the situation.
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.
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).
reply