Even if you could make these small, low power, and most importantly cheep enough, and even if the mosquitoes can't adapt. This has the fundamental problem that anything that casts a shadow in the beam is undetectable to humans, yet renders the device worthless.
Simplest solution is to encrypt the list with multiple keys (so they at least have to collaborate). Alternatively setup a dead man switch. Otherwise you have to source trust form somewhere.
http://finance.yahoo.com/q?s=RHT I would certainly recommend their support offerings as both best in class and exceptional value, but you don't need them in every situation. It is also interesting to turn the question around. Do you think that Redhat would prefer you to use a different distribution?
Switching to optical justifies the optical cables being active, it doesn't justify the copper ones being active. Either way it is still sending the signals over copper to the active part of the cable.
Given none of the 10gbps Ethernet PHYs need active cabling the raw speed excuse is also a little thin.
Or unless silk is written to fail-over automatically. btw. Amazon loose millions of dollars an hour if Amazon.com goes down, I would say they are valuing your browsing time fairly highly by putting it on the same system.
The is nothing out there to suggest that Windows 8 is the last OS Microsoft plan to release. If the Win8 logo mandates secure-boot, then Win 9 or 10 can require it.
FAT isn't patented vFAT is (long file names). CD-ROMs (and these phones) use ISO9660 a completely unrelated and unpattented file-system that Windows also supports (all be it read only in early versions).
A microphone would have added a couple of cents to the BoM. Are you saying that you for a few cents you will NEVER want to: Take audio notes. Use voice control (particularly voice search). Use speech-to-speech translation. Use a music identification service. Talk to someone. Record samples for a sequencer. Do something even cooler that hasn't been thought of yet?
Are you really saying that it is good that people who design cars have never tried to actually fix one? Having some experience of both system-administration and user support should be absolute compulsory requirements for any developer.
A) This is critical, but you have to allow some penny pinching if you expect them to achieve it.
B) The critical point is to release open-source drivers. If they work you will get full Cyanogenmod support within 12 hours of release whatever else you do. If you wrote them cleanly and didn't really too much on the Android patches they will also end up in the Linux Kernel and all distros in due course. XP/React is a none-starter; any tablet I buy will be ARM.
C) Hard to argue that Skype/Facetime/Google Talk don't exist, but supporting them can't hurt. Real innovative Apps shouldn't be locked to one device, let them each succeed on their own merits. The is plenty of innovation left in the hardware: - A hybrid e-ink/LCD transflective display. - Swappable batteries (in different sizes). - 3D (Please no, but it is inevitable someone tries) - Kinect - Ruggedized - Sensible number of USB and full-sized SDs
D) Yes, please yes. Just buy Wacom and use Cintiq technology at a mass-market price point. Again just release the hardware, GIMP, MyPaint and the test will get ported.
E) The are lots of eReaders, nearly all have Project Gutenberg support, what are they missing?
The Rockchip RK29xx already has full hardware decoding of VP8. It also happens to be by far the most commonly used chip in upcoming media players and TVs. Google have also provided the same VHDL or Verilog to the 20 other manufactures so it is likely all future media SoCs will support it.
This approach is already possible via: https://github.com/kripken/emscripten The overhead of implementing the bytecode and its interpreter in JS may seem ridiculous, but the actual results are amazing. Chrome's NaCl may give this a performance boost, but I expect JS will continue its reign of just-good-enough.
Past performance is no guarantee of future success.
In relative terms NASA's budget is tiny, and any effective investment in new technology will always give a many fold return. Simply sticking a NASA badge on some crazy congressional pork isn't going to provide magical benefits.
The only payload they need is to load the MBR from somewhere unexpected (i.e. probably one address change). This ensures all the current AntiVirus code will be scanning the wrong MBR and given a false negative.
ARM Holding's kept how to actually implement a JVM using Jazelle secret, so it is limited to a few commercial J2ME implementations AFAIK. However it is now generally accepted that a good JIT optimizer will outperform it anyway.
The ARM ports of HotSpot (the main desktop JVM) strip out the optimized assembly code and don't support JIT so aren't super fast. Though are probably fine for teaching.
Shark adds back a very fast JIT via LLVM, but isn't very reliable yet.
It talks 3-4 years to do a good original game. It takes far less then 6-months to copy-past a cheep knockoff with no originality or balance. The announcement makes it clear this is going to be released early next year. So I wonder which EA is planning?
This isn't a SDIO card but rather from the host device appears as a standard block storage card. Presumably finding a way of modifying the file-system without causing corruption is what qualifies this as news. The easy way way would have been to have placeholder files that were always visible to the host device. Which when read where blank, until new files where actually received. I expect they have gone an extra step and found a way of forcing the host to reload the FAT (so the files get relevant filenames), possibly simply by simulating an ejection/insertion, or perhaps just by emulating a cleverly structured read failure. This may catch a few devices out, but probably works well enough in the higher end devices they are targeting.
I doubt deliberate support is required. The game logic was almost certainly interleaved with the drawing code, such that as it scanned the display if it found a bullet it moved it up one line, or if it hit something set the reload flag. If any sort of memory corruption occurred, and two bullets were on the screen then they would both work as expected without any additional code. After the glitch can you stop firing, then fire twice (implying the reload flag isn't boolean and at least some support for multiple bullets was written in), or do you have to keep both bullets in-play to maintain the glitch?
It is likely that the file was distributed to thousands of people as a backup, and the recipients where not intended to know the password. Rather the distribution was simply to ensure that should wikileak's servers be impounded the small cabal who had memorized the password would stand a reasonable chance of being able to recover the data.
Slashdot Mirror
Even if you could make these small, low power, and most importantly cheep enough, and even if the mosquitoes can't adapt. This has the fundamental problem that anything that casts a shadow in the beam is undetectable to humans, yet renders the device worthless.
Simplest solution is to encrypt the list with multiple keys (so they at least have to collaborate).
Alternatively setup a dead man switch.
Otherwise you have to source trust form somewhere.
http://finance.yahoo.com/q?s=RHT
I would certainly recommend their support offerings as both best in class and exceptional value, but you don't need them in every situation.
It is also interesting to turn the question around. Do you think that Redhat would prefer you to use a different distribution?
They desperately need more funding to produce a ASIC version required for Linux support to mean much:
http://hardware.slashdot.org/story/11/04/30/172214/help-build-the-worlds-first-community-funded-cpu-asic
I meant what I said; It is generally accepted that climate change effects us all, so no one is independent.
Proving the world will end tomorrow would make you the most famous living scientist (for a day).
I wasn't aware of any research centers which don't have a very large vested interest in the global climate?
It is LGPL, so they can use their existing code as a library and write a closed source iOS UI.
Switching to optical justifies the optical cables being active, it doesn't justify the copper ones being active. Either way it is still sending the signals over copper to the active part of the cable.
Given none of the 10gbps Ethernet PHYs need active cabling the raw speed excuse is also a little thin.
Or unless silk is written to fail-over automatically.
btw. Amazon loose millions of dollars an hour if Amazon.com goes down, I would say they are valuing your browsing time fairly highly by putting it on the same system.
The is nothing out there to suggest that Windows 8 is the last OS Microsoft plan to release.
If the Win8 logo mandates secure-boot, then Win 9 or 10 can require it.
FAT isn't patented vFAT is (long file names).
CD-ROMs (and these phones) use ISO9660 a completely unrelated and unpattented file-system that Windows also supports (all be it read only in early versions).
A microphone would have added a couple of cents to the BoM. Are you saying that you for a few cents you will NEVER want to:
Take audio notes.
Use voice control (particularly voice search).
Use speech-to-speech translation.
Use a music identification service.
Talk to someone.
Record samples for a sequencer.
Do something even cooler that hasn't been thought of yet?
Are you really saying that it is good that people who design cars have never tried to actually fix one?
Having some experience of both system-administration and user support should be absolute compulsory requirements for any developer.
A) This is critical, but you have to allow some penny pinching if you expect them to achieve it.
B) The critical point is to release open-source drivers. If they work you will get full Cyanogenmod support within 12 hours of release whatever else you do. If you wrote them cleanly and didn't really too much on the Android patches they will also end up in the Linux Kernel and all distros in due course. XP/React is a none-starter; any tablet I buy will be ARM.
C) Hard to argue that Skype/Facetime/Google Talk don't exist, but supporting them can't hurt. Real innovative Apps shouldn't be locked to one device, let them each succeed on their own merits. The is plenty of innovation left in the hardware:
- A hybrid e-ink/LCD transflective display.
- Swappable batteries (in different sizes).
- 3D (Please no, but it is inevitable someone tries)
- Kinect
- Ruggedized
- Sensible number of USB and full-sized SDs
D) Yes, please yes. Just buy Wacom and use Cintiq technology at a mass-market price point. Again just release the hardware, GIMP, MyPaint and the test will get ported.
E) The are lots of eReaders, nearly all have Project Gutenberg support, what are they missing?
The Rockchip RK29xx already has full hardware decoding of VP8. It also happens to be by far the most commonly used chip in upcoming media players and TVs.
Google have also provided the same VHDL or Verilog to the 20 other manufactures so it is likely all future media SoCs will support it.
This approach is already possible via:
https://github.com/kripken/emscripten
The overhead of implementing the bytecode and its interpreter in JS may seem ridiculous, but the actual results are amazing.
Chrome's NaCl may give this a performance boost, but I expect JS will continue its reign of just-good-enough.
You mean an equivalent like HTML+TIME? Which Internet Explorer has supported since the last millennium and which the W3C SMIL standard was based upon.
Past performance is no guarantee of future success.
In relative terms NASA's budget is tiny, and any effective investment in new technology will always give a many fold return. Simply sticking a NASA badge on some crazy congressional pork isn't going to provide magical benefits.
The only payload they need is to load the MBR from somewhere unexpected (i.e. probably one address change). This ensures all the current AntiVirus code will be scanning the wrong MBR and given a false negative.
ARM Holding's kept how to actually implement a JVM using Jazelle secret, so it is limited to a few commercial J2ME implementations AFAIK.
However it is now generally accepted that a good JIT optimizer will outperform it anyway.
The ARM ports of HotSpot (the main desktop JVM) strip out the optimized assembly code and don't support JIT so aren't super fast. Though are probably fine for teaching.
Shark adds back a very fast JIT via LLVM, but isn't very reliable yet.
It talks 3-4 years to do a good original game. It takes far less then 6-months to copy-past a cheep knockoff with no originality or balance. The announcement makes it clear this is going to be released early next year. So I wonder which EA is planning?
This isn't a SDIO card but rather from the host device appears as a standard block storage card. Presumably finding a way of modifying the file-system without causing corruption is what qualifies this as news.
The easy way way would have been to have placeholder files that were always visible to the host device. Which when read where blank, until new files where actually received.
I expect they have gone an extra step and found a way of forcing the host to reload the FAT (so the files get relevant filenames), possibly simply by simulating an ejection/insertion, or perhaps just by emulating a cleverly structured read failure. This may catch a few devices out, but probably works well enough in the higher end devices they are targeting.
I doubt deliberate support is required. The game logic was almost certainly interleaved with the drawing code, such that as it scanned the display if it found a bullet it moved it up one line, or if it hit something set the reload flag.
If any sort of memory corruption occurred, and two bullets were on the screen then they would both work as expected without any additional code.
After the glitch can you stop firing, then fire twice (implying the reload flag isn't boolean and at least some support for multiple bullets was written in), or do you have to keep both bullets in-play to maintain the glitch?
It is likely that the file was distributed to thousands of people as a backup, and the recipients where not intended to know the password.
Rather the distribution was simply to ensure that should wikileak's servers be impounded the small cabal who had memorized the password would stand a reasonable chance of being able to recover the data.
Not only that but they STILL seem to be using 2-digit dates!