Maybe they mean X11-screens. That are more or less independent screens, you can't move a window from one to the other for example.Emacs supports that somewhat with the "open new frame on display server" menu option, but usually, multiple screens are not very useful.
Nowadays, multiple monitors present one big virtual framebuffer and only one logical X11 screen.
It is a niche feature, but it is still used eg when an application wants to have good control over a screen's frame buffer to display sth in an external monitor and minimise disturbances. I think it is fairly standard in psychophysics experiments, at least with some software. That's where I worked with such a ("zaphodsheads") setup.
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.
Nowadays, multiple monitors present one big virtual framebuffer and only one logical X11 screen.
reply