It's all rumors at this point, so we could be wrong. But the rumors are about an always-online requirement. The features you mention don't require the console to be permanently connected to the internet; they just reduce waiting time if the console can download stuff in advance overnight.
It's far more than just the "technical requirement" of having a working internet connection. What they require is that the console phones home to a Microsoft server to check if you're allowed to play the game. It means that if the server side is unavailable due to an outage, a DDoS attack or is simply turned off, you can no longer play your games. It makes the system fragile (more points of failure) and it gives Microsoft the ability to decide when the console you bought will be effectively bricked (no longer usable as a game console).
Some people may not care that they buy a console and games that will only work for 5-10 years. But personally I like the ability to replay games that I played long ago. Even though I only do that occasionally, knowing that I can is a good feeling in itself.
so it can check in too see if any updates are available without drawing much power
Depends on what you call "much power": it uses about 10W in "online" standby mode. That might not seem like a lot, but it draws that 24 hours a day, so it adds up over the years.
In addition, I prefer to do firmware updates only when I buy a new game that needs one, rather than every time a firmware is released. There have been firmware releases with serious bugs in them; why run the risk?
The numbers I found in a quick search suggest that EU-wide there is still a small population growth, but pretty close to zero. The import/export balance (PDF, see graphs on page 2) for raw and processed products combined seems to be roughly zero as well, but in terms of raw materials the EU is still net importing agricultural products. To say Europe is going to "become almost entirely dependent on the outside world" doesn't match these figures though.
You're forgetting what might be the most important step:
Set strict rules for campaign contributions, to make sure that corporate "donations" are not a deciding factor in who gets elected. Like other humans, politicians often carry out the orders from the one who pays them.
What this means is that if there is ever an earthquake in California that exceeds more than $5 Billion in insurance payments, Berkshire Hathaway is on the hook for any payments exceeding that amount. AFAIK he has no upper ceiling on his liability. If the big one hit southern California it's conceivable that his entire company would go bankrupt backstopping the insurance market.
That sounds like a large earthquake would be a humanitarian disaster followed by a financial disaster. Someone will have to absorb the amount not paid out in case of a bankruptcy. Whether it's the insurance companies, the citizens of California or the government, it's going to be painful, since they will all be short in cash after a large earthquake.
The argument only works if there are enough alternatives available. For web mail, that is the case. For printers it's quite possible that all of them had closed source drivers at that time, so switching suppliers would not have helped.
From the start, GMail offered a lot of storage space in exchange for the ad bots looking at your mail to provide context sensitive ads. If people are not OK with their mail being scanned by the ad bots, why did they create a GMail account in the first place? I can imagine an outrage if the terms and conditions were changed after people signed up, but that is not the case here.
I haven't seen any part of this puzzle other than the grid itself, but if you interpret every clue as a match for the full line like you said, there is exactly one solution.
Given that both using and not using the chemicals has drawbacks and that it is difficult to make good decisions at a time of crisis, isn't it a good thing this study is done now? That way, when another spill happens, there is more knowledge to base decisions on.
Indeed: the feed-in tariff means that home owners get paid a decent price for delivering electricity to the grid. It doesn't specify where the home owners should buy their panels.
People still need time to read a book (or listen to music), which limits the number of people that will read the book even if the ownership can be transferred indefinitely. However, we have effectively perpetual copyright at the moment and it just wouldn't be fair to the starving writers' grand-grand-grandchildren if the market for the book would eventually dry up because there are a sufficient number of copies sold such that every person who wants to read it can get a second hand copy.
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.
Slashdot Mirror
It's all rumors at this point, so we could be wrong. But the rumors are about an always-online requirement. The features you mention don't require the console to be permanently connected to the internet; they just reduce waiting time if the console can download stuff in advance overnight.
It's far more than just the "technical requirement" of having a working internet connection. What they require is that the console phones home to a Microsoft server to check if you're allowed to play the game. It means that if the server side is unavailable due to an outage, a DDoS attack or is simply turned off, you can no longer play your games. It makes the system fragile (more points of failure) and it gives Microsoft the ability to decide when the console you bought will be effectively bricked (no longer usable as a game console).
Some people may not care that they buy a console and games that will only work for 5-10 years. But personally I like the ability to replay games that I played long ago. Even though I only do that occasionally, knowing that I can is a good feeling in itself.
so it can check in too see if any updates are available without drawing much power
Depends on what you call "much power": it uses about 10W in "online" standby mode. That might not seem like a lot, but it draws that 24 hours a day, so it adds up over the years.
In addition, I prefer to do firmware updates only when I buy a new game that needs one, rather than every time a firmware is released. There have been firmware releases with serious bugs in them; why run the risk?
The numbers I found in a quick search suggest that EU-wide there is still a small population growth, but pretty close to zero. The import/export balance (PDF, see graphs on page 2) for raw and processed products combined seems to be roughly zero as well, but in terms of raw materials the EU is still net importing agricultural products. To say Europe is going to "become almost entirely dependent on the outside world" doesn't match these figures though.
You're forgetting what might be the most important step:
Set strict rules for campaign contributions, to make sure that corporate "donations" are not a deciding factor in who gets elected. Like other humans, politicians often carry out the orders from the one who pays them.
What this means is that if there is ever an earthquake in California that exceeds more than $5 Billion in insurance payments, Berkshire Hathaway is on the hook for any payments exceeding that amount. AFAIK he has no upper ceiling on his liability. If the big one hit southern California it's conceivable that his entire company would go bankrupt backstopping the insurance market.
That sounds like a large earthquake would be a humanitarian disaster followed by a financial disaster. Someone will have to absorb the amount not paid out in case of a bankruptcy. Whether it's the insurance companies, the citizens of California or the government, it's going to be painful, since they will all be short in cash after a large earthquake.
The argument only works if there are enough alternatives available. For web mail, that is the case. For printers it's quite possible that all of them had closed source drivers at that time, so switching suppliers would not have helped.
From the start, GMail offered a lot of storage space in exchange for the ad bots looking at your mail to provide context sensitive ads. If people are not OK with their mail being scanned by the ad bots, why did they create a GMail account in the first place? I can imagine an outrage if the terms and conditions were changed after people signed up, but that is not the case here.
T-Mobile is part of Deutsche Telekom: Germany is where they started from.
What rights would that be? The patents themselves are the rights...
I haven't seen any part of this puzzle other than the grid itself, but if you interpret every clue as a match for the full line like you said, there is exactly one solution.
Solved it a few days ago. It was fun. It's not as hard as it looks.
and yes there is a solution
In fact, there is exactly one solution.
Given that both using and not using the chemicals has drawbacks and that it is difficult to make good decisions at a time of crisis, isn't it a good thing this study is done now? That way, when another spill happens, there is more knowledge to base decisions on.
Indeed: the feed-in tariff means that home owners get paid a decent price for delivering electricity to the grid. It doesn't specify where the home owners should buy their panels.
People still need time to read a book (or listen to music), which limits the number of people that will read the book even if the ownership can be transferred indefinitely. However, we have effectively perpetual copyright at the moment and it just wouldn't be fair to the starving writers' grand-grand-grandchildren if the market for the book would eventually dry up because there are a sufficient number of copies sold such that every person who wants to read it can get a second hand copy.
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.