They claim not only fast charging, long life and low cost, but also very high energy density, no degradation in low temperature, no thermal runaway, non-hazardous materials and no "geopolitical" needed.
This one runs Linux on the ARM cores rather than the RISC-V cores in the same package, so it's apples and oranges, but still pretty neat for something that comes essentially with a companion MCU and is in the same form factor:
In embedded systems it's very common to have a bigger SoC and a satellite MCU to handle e.g. network comm and power lifecycle. I've still not really tried out my Milk-V Duo, but it's interesting to get a combo like this in a hobbyist board form factor.
They also claim desktop-class performance for this RISC-V-based miniITX board, it's a bit weird though since it doesn't claim RVA23 compliance:
I'm building Fostrom (https://fostrom.io), an IoT Cloud Platform. We have Device SDKs to simplify integrating devices, powered by a small Device Agent written in Rust.
I wanted to support RISC-V boards too, so I went with the Milk-V Duo S as the test device. I have managed to get Tailscale working, and our Device SDK works too, with the bundled Python.
The experience of using the Milk-V Duo is definitely not as straightforward as the Pi Zero, but it does work, and is easily available in most places, unlike some of their other products. The Linux distro they provide is quite barebones, and I wasn't able to get Debian working. The docs for the device are pretty decent. I hope we get better support for Debian/Alpine/Arch for these kinds of boards soon.
Interesting. I sometimes get similar behaviour on KDE / wayland, usually it is "2" or "3", and it seems to only affect electron apps. Always thought it has something to do with a dodgy ps/2 to usb converter I use to attach my old mechanical keyboards. I think it does not happen if electron apps are started with "--ozone-platform=wayland" but not completely sure, and I have no reliable way to reproduce or somehow trigger that behaviour.
Aren't they talking about the c++ dialect the compiler expects without any further -std=... arguments? How does that affect the bootstrapping process? This https://gcc.gnu.org/codingconventions.html should define what C/C++ standard is acceptable in the GCC.
The way I read withzombies's comment (and it could be wrong) was they were talking about the language version of the compilers source. I assumed that from the "dogfooding" portion of the comment.
Correct, this is a discussion of which language version the compiler should follow if the programmer doesn’t specify one. It’s not about which features are acceptable when implementing the compiler.
Nobody is constantly charging their completely empty EV.
A typical commute of 50km/day at 20kWh/100km means you have to put 10kWh into you car (per day). A 230V outlet can deliver 3,7kW at 16A, so your car would be topped up again after about 3h.
Tesla Supercharger prizes at 20kWh/100km are in the same ball park as Diesel at 5l/100km. Charging at home should approach half that, and charging with PV will amount to <2€/100km.
We don't want the CO2 that is created (and other consequences of oil production/consumption), the money can be spent on something better, and we don't want to depend on oil-exporting countries more than necessary.
reply