I didn't see the questions before, it was Justin who answered earlier.
I didn't see the questions before, it was Justin who answered earlier.
I'm "mth" and I'll answer as many of your questions as I can.
The devices are built in China by a factory who have done this sort of thing before. I don't know all the details, but while the yield of the first batch wasn't great, it also wasn't worse than what one would expect from a first production run. Justin has been a reseller of devices like the Dingoo A320 for several years, so he has practical experience in distribution.
Regarding the software, we build the root file system using buildroot with as few customizations as needed. Our SDL is using the Linux framebuffer for graphics and ALSA for audio, no acceleration is implemented but it's not necessary either: pushing pixels at 320x240 or synthesizing stereo audio at 44.1 or 48 kHz can easily be done by the CPU.
We do want to add acceleration for OpenGL ES. We're working to get the proprietary driver from Vivante up and running in our system (this wasn't trivial because we're using uClibc instead of glibc). We're also looking at the open source etna_viv project, but that's in an early stage of development, so it will be a while before it is usable as a full driver replacement. Note that the GPU renders from memory to memory; the framebuffer is handled by the LCD controller and that part is already fully open source, so if you want a fully open kernel you can run SDL applications just fine today.
All sources can be found on github. This includes the kernel, buildroot, the boot loader, the image generation tools and more.
Not running Android has its advantages too: porting existing C/C++ applications to Android is quite a hassle, while porting to the Zero is often a cross compile followed by customizing the key mapping. Also we have fewer layers between the application and the hardware, resulting in lower latency. Maybe it's technically possible to get low latency on Android, but in practice a lot of devices suffer from input or audio latency.
Short version: Dingux is Dingoo Linux and OpenDingux is a reimplementation of Dingux.
The project originates from the scene formed around the Dingoo A320. Ignacio García Pérez (aka booboo) ported Linux to this device and called that Dingux. Dingux worked great, but it was a one-man project and Ignacio didn't have time to keep supporting it. The code was based on the Linux kernel released by Ingenic (the manufacturer of the JZ4740 SoC), who often invent their own kernel interfaces instead of sticking with the standard ones. Also, the Dingux kernel was quite old (2.6.24) and difficult to update because also internally it took some shortcuts instead of using established interfaces.
There was a different device, the Ben NanoNote, that used a very similar SoC and had a much cleaner kernel (thanks to in particular Lars-Peter Clausen); many of their drivers are even integrated into the mainline kernel now. So we (mainly Paul Cercueil and me) started OpenDingux to merge Dingux and the NanoNote drivers into a modern kernel that uses standard interfaces.
When Justin Barwick started the GCW Zero project, he contacted Paul and me to port OpenDingux to the new device. The code is currently a mix of Ingenic's drivers and our own and while it still needs a lot of cleanup before it's ready for mainline submission, it is at least keeping up with mainline kernel releases (Linux 3.5 when we started, 3.7 now).
We just kept the name; many people who follow Linux handhelds news are already familiar with the OpenDingux name and we didn't have any great ideas for a different name either. I know I've probably answered a rhetorical question but I thought it was nice to present a little history nevertheless.
I'm one of the people working on this console. The point of it is retro gaming: emulation, classic PC games and homebrew and indie games in retro style. Touch screens and physical controls are completely types of input: you cannot play a game designed for physical input well with a touch screen or vice versa.
We've got a light embedded Linux distro on it and with C/C++ applications writing directly into the framebuffer (set up via SDL, usually) you can get very decent performance from these specs. For example, my prototype has 256 MB of memory and 240 MB of that is available for applications. Similarly, the OS footprint on the internal storage is less than 100 MB.
I assume that lab-grown meat will also mean less by-products and environmental waste than the regular method, but alas, I'm not an expert in either area.
I'm not an expert either, but I'd expect at least methane emissions to be a lot lower since lab-grown meat doesn't have a digestive system.
I think the point was that McChicken is not all that much like real chicken and still lots of people eat it. It doesn't really matter if lab-grown meat won't replace what is served at Christmas dinner; if it can replace processed meat that's already a huge success.
Even if every host you'd ever plug your device into would support ext3/4, there is still the inconvenience that the partition is exposed at the block device level, not at the file level. This means it has to be unmounted on the device before it can be mounted by the host. This is difficult to implement, since all open files on the partition must be closed before the unmount operation can succeed. Also it is inconvenient for the user: it would mean you'd have to stop a device from playing music when you want to add additional songs, for example.
Yes, since even with current technology it might be feasible to avoid the collision if we know its trajectory decades in advance. For example, if a probe flies close to the asteroid, the gravitational pull of the probe will alter the path of the asteroid a tiny bit, but a tiny bit can be enough if it happens a long time before the asteroid gets too close to earth.
It's easy to run x86 binaries on x86-64, but vice versa is not possible. I don't know of any x86-only CPUs being sold anymore, the last ones I remember were the early Atoms, so maybe in a few years we can bury the arch.
I see internal compiler errors (assertion-style) and crashes quite regularly, as in multiple times per year. Valid language constructs being rejected or invalid ones accepted happens too, although I don't know the language specs well enough to spot most of those. And occasionally a code generation bug (I can remember two from the last 10 years).
How often you find compiler bugs depends a lot on what part of the compiler you're stressing: you'll encounter more bugs on MIPS than on x86, for example, since x86 has far more users. And if you're trying new C++11 features it's far more likely you'll see a bug than when you're compiling plain C.
My e-mail address was harvested years ago: I have to rely on spam filters anyway, so I don't really worry about publishing it in bug trackers.
Registration is a pain, I agree. However, on a project that I participate in (openMSX) we did decide to stop accepting anonymous bugs reports, since the majority of bug reports lacked essential information to be able to reproduce the bug. If there is no way to contact the user who filed the bug, the only thing a developer can do is close it as non-reproducible ("worksforme" in Bugzilla - a very poor choice of words in my opinion).
How well a project responds to bugs differs a lot per project and also per individual bug. Some are fixed years later, some within a day. Some are marked invalid even though they are valid, others are indeed invalid or are duplicates. The compiler projects (GCC, LLVM, Intel C++) have been relatively good with responding to my bug reports, so I will report new bugs to them when I find any. For some other projects, I don't bother anymore unless it's a data destroyer or security issue.
Trolley buses are operational in more than a few cities without supervision or separation. I don't know if the system could scale to a much larger number of vehicles and more routes, but I don't think safety would be the blocking issue.
What about wireless charging: is it feasible to charge a car while it is moving? It might be cost effective on busy roads; cars would still need a battery but a smaller capacity would suffice if it can be recharged while driving.
He said 1% of computers that were used to play Guild Wars gave wrong answers. Gaming PCs are more likely to be overclocked too far, have under-dimensioned power supplies or overheating issues than the average PC. 1% doesn't sound unrealistically high to me.
If you suspect the compiler is generating invalid machine code, try to make a minimal test case for it. If you succeed, file a bug report and add that test case; the compiler developers will appreciate it. If you don't succeed in finding a minimal test case that triggers the same issue, it's likely not a compiler bug but an issue in your program in some place where you weren't expecting it.
Make it right before you make it faster.