I'm half afraid to admit this publicly, but did anyone else try clicking the "play" button on screenshot of the audio CAPTCHA player in the first article? I took me a few tries before I realized it was only an image.
This doesn't quite make sense to me. You wouldn't replace a 64 CPU supercomputer with a single 64 core CPU, but would instead use 64 multicore CPUs. As production switches to multicore, the cost of producing multiple cores will be about the same as the single core CPUs of old. So eventually you'll get 4 cores from the price of 2, then get 8 cores from the price of 4, then 16 for the price of 8, etc. So the extra cores in the CPUs of a supercomputer are like a bonus, and if software can be written to utilize those extra cores in some way that benefits performance, then that's a good thing.
As both educators and researchers, we are amazed at the hype that the MapReduce proponents have spread about how it represents a paradigm shift in the development of scalable, data-intensive applications. MapReduce may be a good idea for writing certain types of general-purpose computations, but to the database community, it is:
1. A giant step backward in the programming paradigm for large-scale data intensive applications
2. A sub-optimal implementation, in that it uses brute force instead of indexing
3. Not novel at all -- it represents a specific implementation of well known techniques developed nearly 25 years ago
4. Missing most of the features that are routinely included in current DBMS
5. Incompatible with all of the tools DBMS users have come to depend on
Like 99% of the rest of internet users, I use one browser (firefox).
I'm rather surprised this has been downloaded 10M times, unless there is some sort of patriotism based motivation going on. For the life of me I just can't picture the average internet user saying "Hey, let's see how this website looks when rendered by the Webkit engine!" while their buddy, looking on over their shoulder responds "Yeah, do it! This is going to be a blast!"
The left photo was most likely a "leak", and is simply at a low resolution. The original would have been the same resolution as the final version.
The digital, pixalated cammo is really that way. The orientation of the texels match the orientation of the fabric. If that pixelation was from the camera, the texels would all be parallel to the edges of the image. Look at the cloth in her collar. The texels are aligned with that long, narrow strip.
The simplest answer is most likely the correct answer. The unaltered photo is what was "leaked", and it is simply at a reduced resolution. AFP already had the "official" high-quality picture, which was hi-res.
The iPhone comes out, and suddenly everyone forgets that touch-screen devices of the exact same form factor have been around for over a decade. All of this has been hashed and rehashed. I ported Wolfenstein 3D, Quake 1 & 2, and a Gameboy emulator to Pocket PC, as well as doing extensive game development on new projects. For analog input, touchscreens are okay. However for binary input, aka fire / jump buttons, d-pad, etc, it sucks tremendously. I think you're confusing "tactile feedback" for "knowing where the virtual button is". It's not just about knowing where to hold your thumbs, but knowing that you've pressed the button hard enough to trigger it. The very first ARM Pocket PC, the Compaq iPaq, which had the horsepower and RAM to do some serious gaming (like run Quake), had a terrible design flaw. The D-Pad and 4 hardware buttons all resided on a daughterboard with its own microcontroller. Some bone-headed engineer had a serious lack of foresight, and the hardware was designed such that only one switch could register at a time. Thus if you were holding the D-Pad in a direction, then none of the 4 hardware buttons would register.
So the only solution to make things like Gameboy emulators playable was to throw virtual A and B buttons up on the screen. These were of course huge, so finding them wasn't a problem. However I can tell you that playing games like that, without real tactile response, sucks, sucks, sucks.
There's a reason that the Timex Sinclair's membrane keyboard didn't catch on back in the 80s, and why to this day people like the big IBM keyboards that you can hear click half way across the room when a button is pressed.
It's bad enough that the mainstream media has been acting like a bunch of prepubescent children over the urine recycling, but now Slashdot has to get into the game as well?
"that may leave you wondering if NASA is taking recycling too far"
Uh, nope, it doesn't leave me wondering that at all. In fact, when I first read about it I was rather surprised that the ISS wasn't recycling urine already. Any manned moon-base, or long-duration trip to reach Mars, would absolutely require the recycling of urine.
I have many full-length movies on my Pearl, and one of my pet-peeves was that seeking in a video was fixed at so many steps - something like 25 steps from the beginning to end. For a full-length movie the steps were then really large, like 5 minutes each.
By trial and error I finally discovered that holding down SHIFT while rotating the scroll wheel will go by very small increments - just a few seconds at a time.
So seeking in a video has the best of both worlds, if you know the keyboard modifier.
Nice. As a side note, ATI contracted me to do the Quake GS OpenGL ES conversion a few years ago (the NDA has expired). I got to fly out to one of their labs in California to do performance tuning with the guy who drafted the OpenGL ES specification. It was a nice experience.
As another side note, I had asked the marketing guy who arranged for me to do the conversion (it was done, along with MotoGP by another group to market ATI's new mobile 3D chipset) to not release the source. It was of course GPLed, and since ATI was only demoing it on their own hardware and not distributing the executable, the source did not have to be released. I wanted to contact Id about potentially marketing the game. The ATI marketing guy's contract ran out, so someone else started demoing it. That person handed the source code over to the first guy that came along. He ended up contacting me with some questions about it, which is how I found out. I told him that he would have to release the source if he distributed the game since it was GPLed. He had already flown to Id headquarters and met with Todd and had a contract in place. He then changed what he said, and told me that my work was crap, and he had another programmer totally redo the conversion (which is complete BS). I have proof that their version still incorporates that code that I modified and added under the GPL. In Quake GL the particle textures are hardcoded into the engine. They used a simple square texture which looks exactly like what was done in the software engine (a square particle was used in the software renderer purely for performance). I thought it looked particularly poor having a square particle, so I made it into a more rounded, diamond-like shape. That is what is in their version to this day.
So if the version of Quake you're talking about is from Pulse Interactive, then thanks, I'm glad you like my work, and you were seeing software running in violation of the GPL.
I'm not java expert, but I have written some things for Blackberry (a Klondike Solitaire game for one). I've done some very, very performance intensive work on Pocket PC (Quake 1 & 2, my own 3D engine with ARM ASM optimizations, etc). All in all, Java will be a substantial hindrance and cap the performance of what can be achieved on the hardware when it comes to real-time rendering.
As a small example, most mobile devices use 16 bit RGB 565 pixel format, and the CPUs are RISC 32 bit. So for maximum performance, you try to always work with two pixels at once to halve the instructions required. With java, if your pixel buffer is of a 16 bit type then you cannot simply cast a pointer to a 32-bit aligned value in the array and then do 32 bit math on it. At the very least you will have to pack and unpack the two shorts individually. I hope someone can correct me if I'm wrong on that (that you can do 32 bit math on two adjoining, aligned 16 bit values with no extra overhead), because I'll certainly make use of it.
With these types of devices, if you work within the APIs - using available drawing primitives and hardware rendering capability - you'll be in decent shape. However if you need to do direct pixel manipulation (rotozooming, custom 3D renders, voxel terrain, bumpmapping, etc) then the language will be barrier.
When performance is most important (inner loop of texture mapper rasterizers for example), nothing can beat hand-coded ASM native to the CPU. I have a friend who can code StrongARM / XScale ASM like a fiend. He can take my best, carefully optimized C loops and usually cut the execution time in half over the compiler.
So not only can't you do decent high-level performance-optimized coding in Java, but the option of hand-optimized routines native to the processor are out.
It is really good - and amazing - that they found this particle. I've lost sub-atomic particles before, and the things are just so incredibly small that it is unbelievably difficult to find them again. The resulting migraine from eye-strain can be terrible.
Yes, but what is the average company's internet downtime verses their LAN downtime for a single-campus outfit?
So instead of LAN / Exchange Server (or whatever is being used) you now have LAN / WAN / Google downtime. WAN gateway downtime is probably the weakest link in the chain, so wouldn't the total downtime be greater using something internet based?
"So, you can read books for free â" as long as you're the first person to get to your public library's computer room in the morning."
It's much worse than that. If you were to read those same books electronically from the comfort and convenience of your own home, then your eyeballs would explode and your body would spontaneously combust, possibly killing your entire family and burning down your house. At least that's the only reasonable explanation I can think of for why I would have to sit in front of a computer in the library to access an online resource instead of using my own computer.
My grandparents have a series of books entitled Foxfire, so they want to call it that as well. BTW, have you ever seen foxfire (the namesake of the book)? I have in the woods numerous times at night. It's a type of fungus that grows on dead, rotting wood that glows in the dark. It's kind of spooky when you first come across it (like blood from the alien in Predator).
I think we're already to the point where many people are aware they have a choice of web browsers. I was watching the news the other night (obviously not MSNBC), and they had a large touch-screen display running a web-browser with multiple tabs - Firefox. They were using it to display charts and other information.
Also, various family members are aware of Firefox, but they have no idea what "chrome" is. So I'm not sure how Chrome is somehow more noticeable to the mainstream, especially since it doesn't add any of the bells-and-whistles type features that typical people notice (security and performance isn't exactly exciting to the average joe).
People don't buy $250 systems just to play homebrew. Conversely, people that already have the system will dabble in homebrew to increase the value of their hardware, and allow it to do things it couldn't otherwise (like play Monkey Island, or watch DVDs).
If Nintendo is smart, they will put of a token fight - mainly to stay within contractual obligations with their game developing partners and keep them happy - while leaving plenty of loopholes for homebrew to exist. Best of both worlds for all involved.
I've developed for both Blackberry and Windows Mobile. You can develop for both platforms for free, and do not even have to sign applications. With Blackberry you do have to sign your application to use certain Java classes deemed "secure". It costs $100 for a license allowing unlimited signing. However, you can do full J2ME (plus some BB APIs) for free. Blackberry UI, processing speed and graphics capability is very, very poor. I have recently been experimenting to push Blackberry graphically, and have hit nothing but dead-ends (for example, the native display is 16 bit RGB-565, but all APIs to push raw image data are 32 bit ARGB 8888, so a very slow conversion is done by the system). However if you stick to API-supported rendering (basic font rendering, blitting with alpha channel, simple drawing primitives) then you can do quite a bit with good performance. Just don't expect to be able to do your own bitmap-level rendering in realtime (like rotozoom, bumpmapping, texture mapping, etc). All development must be done in Java.
Windows Mobile offers a ton of CPU power and RAM (I've ported both Quake I & II for example). Devices are available with 3D accelerated GPUs, touchscreens, VGA-resolution displays, CF, SD, Wifi and Bluetooth (all in a single device even). So as far as raw options in hardware capability and form-factor, Windows Mobile gives you the most choice. If your app will do some really heavy lifting graphically then Windows Mobile is the better choice. You can develop in the widest variety of languages for this platform - C, C++, C#, Java, ARM assembly, Pocket C, and Visual Basic (just to name some off the top of my head). With both iPhone and Blackberry you are restricted to a single language.
As far as iPhone goes, I've not delved there at all. Things I've heard that concern me are a non-standard programming language, restrictive distribution policy, and whether or not you can simply write and build an app and stick it on your own phone or not without having to sign it or otherwise register it with Apple.
Streaming DivX over WiFi is basically the holy grail for a media center - and I'm quite curious if the homebrew can do that. I have a Phillips DVD player from Wal-Mart that was $55 that plays pretty much anything, including DivX straight off a USB drive. However, the downside is having to copy the file off my server onto a USB drive (4-5 minutes at USB 2.0), then physically move the media from one place to another.
Not even close. The heavy lifting for 3D games is done on the GPU, and I'm not aware of any games (except perhaps games that utilize multiple monitors, like flight simulators) that can make use of more than one GPU.
So a single game could potentially drive many monitors, but not do more visually on a single display.
However, this thing could do some amazing real-time raytracing, but again, no games have been designed for such hardware yet.
Slashdot Mirror
I'm half afraid to admit this publicly, but did anyone else try clicking the "play" button on screenshot of the audio CAPTCHA player in the first article? I took me a few tries before I realized it was only an image.
This doesn't quite make sense to me. You wouldn't replace a 64 CPU supercomputer with a single 64 core CPU, but would instead use 64 multicore CPUs. As production switches to multicore, the cost of producing multiple cores will be about the same as the single core CPUs of old. So eventually you'll get 4 cores from the price of 2, then get 8 cores from the price of 4, then 16 for the price of 8, etc. So the extra cores in the CPUs of a supercomputer are like a bonus, and if software can be written to utilize those extra cores in some way that benefits performance, then that's a good thing.
Mourning seems to be a time when hallucinations are particularly common
Yes, this is very common, and is usually attributed to the caffeine withdrawal symptoms prior to morning coffee.
http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html
As both educators and researchers, we are amazed at the hype that the MapReduce proponents have spread about how it represents a paradigm shift in the development of scalable, data-intensive applications. MapReduce may be a good idea for writing certain types of general-purpose computations, but to the database community, it is:
1. A giant step backward in the programming paradigm for large-scale data intensive applications
2. A sub-optimal implementation, in that it uses brute force instead of indexing
3. Not novel at all -- it represents a specific implementation of well known techniques developed nearly 25 years ago
4. Missing most of the features that are routinely included in current DBMS
5. Incompatible with all of the tools DBMS users have come to depend on
How many web browsers do you run?
Like 99% of the rest of internet users, I use one browser (firefox).
I'm rather surprised this has been downloaded 10M times, unless there is some sort of patriotism based motivation going on. For the life of me I just can't picture the average internet user saying "Hey, let's see how this website looks when rendered by the Webkit engine!" while their buddy, looking on over their shoulder responds "Yeah, do it! This is going to be a blast!"
The left photo was most likely a "leak", and is simply at a low resolution. The original would have been the same resolution as the final version.
The digital, pixalated cammo is really that way. The orientation of the texels match the orientation of the fabric. If that pixelation was from the camera, the texels would all be parallel to the edges of the image. Look at the cloth in her collar. The texels are aligned with that long, narrow strip.
Here's a hat made of the "ARMY Digital" fabric:
http://www.camoonline.com/servlet/the-46/ARMY-Digital-ACU-Military/Detail
The simplest answer is most likely the correct answer. The unaltered photo is what was "leaked", and it is simply at a reduced resolution. AFP already had the "official" high-quality picture, which was hi-res.
The iPhone comes out, and suddenly everyone forgets that touch-screen devices of the exact same form factor have been around for over a decade. All of this has been hashed and rehashed. I ported Wolfenstein 3D, Quake 1 & 2, and a Gameboy emulator to Pocket PC, as well as doing extensive game development on new projects. For analog input, touchscreens are okay. However for binary input, aka fire / jump buttons, d-pad, etc, it sucks tremendously. I think you're confusing "tactile feedback" for "knowing where the virtual button is". It's not just about knowing where to hold your thumbs, but knowing that you've pressed the button hard enough to trigger it. The very first ARM Pocket PC, the Compaq iPaq, which had the horsepower and RAM to do some serious gaming (like run Quake), had a terrible design flaw. The D-Pad and 4 hardware buttons all resided on a daughterboard with its own microcontroller. Some bone-headed engineer had a serious lack of foresight, and the hardware was designed such that only one switch could register at a time. Thus if you were holding the D-Pad in a direction, then none of the 4 hardware buttons would register.
So the only solution to make things like Gameboy emulators playable was to throw virtual A and B buttons up on the screen. These were of course huge, so finding them wasn't a problem. However I can tell you that playing games like that, without real tactile response, sucks, sucks, sucks.
There's a reason that the Timex Sinclair's membrane keyboard didn't catch on back in the 80s, and why to this day people like the big IBM keyboards that you can hear click half way across the room when a button is pressed.
It's bad enough that the mainstream media has been acting like a bunch of prepubescent children over the urine recycling, but now Slashdot has to get into the game as well?
"that may leave you wondering if NASA is taking recycling too far"
Uh, nope, it doesn't leave me wondering that at all. In fact, when I first read about it I was rather surprised that the ISS wasn't recycling urine already. Any manned moon-base, or long-duration trip to reach Mars, would absolutely require the recycling of urine.
Here's another little tip.
I have many full-length movies on my Pearl, and one of my pet-peeves was that seeking in a video was fixed at so many steps - something like 25 steps from the beginning to end. For a full-length movie the steps were then really large, like 5 minutes each.
By trial and error I finally discovered that holding down SHIFT while rotating the scroll wheel will go by very small increments - just a few seconds at a time.
So seeking in a video has the best of both worlds, if you know the keyboard modifier.
Nice. As a side note, ATI contracted me to do the Quake GS OpenGL ES conversion a few years ago (the NDA has expired). I got to fly out to one of their labs in California to do performance tuning with the guy who drafted the OpenGL ES specification. It was a nice experience.
As another side note, I had asked the marketing guy who arranged for me to do the conversion (it was done, along with MotoGP by another group to market ATI's new mobile 3D chipset) to not release the source. It was of course GPLed, and since ATI was only demoing it on their own hardware and not distributing the executable, the source did not have to be released. I wanted to contact Id about potentially marketing the game. The ATI marketing guy's contract ran out, so someone else started demoing it. That person handed the source code over to the first guy that came along. He ended up contacting me with some questions about it, which is how I found out. I told him that he would have to release the source if he distributed the game since it was GPLed. He had already flown to Id headquarters and met with Todd and had a contract in place. He then changed what he said, and told me that my work was crap, and he had another programmer totally redo the conversion (which is complete BS). I have proof that their version still incorporates that code that I modified and added under the GPL. In Quake GL the particle textures are hardcoded into the engine. They used a simple square texture which looks exactly like what was done in the software engine (a square particle was used in the software renderer purely for performance). I thought it looked particularly poor having a square particle, so I made it into a more rounded, diamond-like shape. That is what is in their version to this day.
So if the version of Quake you're talking about is from Pulse Interactive, then thanks, I'm glad you like my work, and you were seeing software running in violation of the GPL.
I'm not java expert, but I have written some things for Blackberry (a Klondike Solitaire game for one). I've done some very, very performance intensive work on Pocket PC (Quake 1 & 2, my own 3D engine with ARM ASM optimizations, etc). All in all, Java will be a substantial hindrance and cap the performance of what can be achieved on the hardware when it comes to real-time rendering.
As a small example, most mobile devices use 16 bit RGB 565 pixel format, and the CPUs are RISC 32 bit. So for maximum performance, you try to always work with two pixels at once to halve the instructions required. With java, if your pixel buffer is of a 16 bit type then you cannot simply cast a pointer to a 32-bit aligned value in the array and then do 32 bit math on it. At the very least you will have to pack and unpack the two shorts individually. I hope someone can correct me if I'm wrong on that (that you can do 32 bit math on two adjoining, aligned 16 bit values with no extra overhead), because I'll certainly make use of it.
With these types of devices, if you work within the APIs - using available drawing primitives and hardware rendering capability - you'll be in decent shape. However if you need to do direct pixel manipulation (rotozooming, custom 3D renders, voxel terrain, bumpmapping, etc) then the language will be barrier.
When performance is most important (inner loop of texture mapper rasterizers for example), nothing can beat hand-coded ASM native to the CPU. I have a friend who can code StrongARM / XScale ASM like a fiend. He can take my best, carefully optimized C loops and usually cut the execution time in half over the compiler.
So not only can't you do decent high-level performance-optimized coding in Java, but the option of hand-optimized routines native to the processor are out.
"Particle May Have Been Found "
It is really good - and amazing - that they found this particle. I've lost sub-atomic particles before, and the things are just so incredibly small that it is unbelievably difficult to find them again. The resulting migraine from eye-strain can be terrible.
Yes, but what is the average company's internet downtime verses their LAN downtime for a single-campus outfit?
So instead of LAN / Exchange Server (or whatever is being used) you now have LAN / WAN / Google downtime. WAN gateway downtime is probably the weakest link in the chain, so wouldn't the total downtime be greater using something internet based?
"So, you can read books for free â" as long as you're the first person to get to your public library's computer room in the morning."
It's much worse than that. If you were to read those same books electronically from the comfort and convenience of your own home, then your eyeballs would explode and your body would spontaneously combust, possibly killing your entire family and burning down your house. At least that's the only reasonable explanation I can think of for why I would have to sit in front of a computer in the library to access an online resource instead of using my own computer.
My grandparents have a series of books entitled Foxfire, so they want to call it that as well. BTW, have you ever seen foxfire (the namesake of the book)? I have in the woods numerous times at night. It's a type of fungus that grows on dead, rotting wood that glows in the dark. It's kind of spooky when you first come across it (like blood from the alien in Predator).
I think we're already to the point where many people are aware they have a choice of web browsers. I was watching the news the other night (obviously not MSNBC), and they had a large touch-screen display running a web-browser with multiple tabs - Firefox. They were using it to display charts and other information.
Also, various family members are aware of Firefox, but they have no idea what "chrome" is. So I'm not sure how Chrome is somehow more noticeable to the mainstream, especially since it doesn't add any of the bells-and-whistles type features that typical people notice (security and performance isn't exactly exciting to the average joe).
You get bonus points for playing bass left-handed.
People don't buy $250 systems just to play homebrew. Conversely, people that already have the system will dabble in homebrew to increase the value of their hardware, and allow it to do things it couldn't otherwise (like play Monkey Island, or watch DVDs).
If Nintendo is smart, they will put of a token fight - mainly to stay within contractual obligations with their game developing partners and keep them happy - while leaving plenty of loopholes for homebrew to exist. Best of both worlds for all involved.
I've developed for both Blackberry and Windows Mobile. You can develop for both platforms for free, and do not even have to sign applications. With Blackberry you do have to sign your application to use certain Java classes deemed "secure". It costs $100 for a license allowing unlimited signing. However, you can do full J2ME (plus some BB APIs) for free. Blackberry UI, processing speed and graphics capability is very, very poor. I have recently been experimenting to push Blackberry graphically, and have hit nothing but dead-ends (for example, the native display is 16 bit RGB-565, but all APIs to push raw image data are 32 bit ARGB 8888, so a very slow conversion is done by the system). However if you stick to API-supported rendering (basic font rendering, blitting with alpha channel, simple drawing primitives) then you can do quite a bit with good performance. Just don't expect to be able to do your own bitmap-level rendering in realtime (like rotozoom, bumpmapping, texture mapping, etc). All development must be done in Java.
Windows Mobile offers a ton of CPU power and RAM (I've ported both Quake I & II for example). Devices are available with 3D accelerated GPUs, touchscreens, VGA-resolution displays, CF, SD, Wifi and Bluetooth (all in a single device even). So as far as raw options in hardware capability and form-factor, Windows Mobile gives you the most choice. If your app will do some really heavy lifting graphically then Windows Mobile is the better choice. You can develop in the widest variety of languages for this platform - C, C++, C#, Java, ARM assembly, Pocket C, and Visual Basic (just to name some off the top of my head). With both iPhone and Blackberry you are restricted to a single language.
As far as iPhone goes, I've not delved there at all. Things I've heard that concern me are a non-standard programming language, restrictive distribution policy, and whether or not you can simply write and build an app and stick it on your own phone or not without having to sign it or otherwise register it with Apple.
Streaming DivX over WiFi is basically the holy grail for a media center - and I'm quite curious if the homebrew can do that. I have a Phillips DVD player from Wal-Mart that was $55 that plays pretty much anything, including DivX straight off a USB drive. However, the downside is having to copy the file off my server onto a USB drive (4-5 minutes at USB 2.0), then physically move the media from one place to another.
"The service is now in production (no longer beta)"
Then they have already reached a state that Google will never achieve.
Ahh, I see her problem. If she wants to be the one person with phone number 123-456-7890 then there will certainly be consequences to deal with.
Not even close. The heavy lifting for 3D games is done on the GPU, and I'm not aware of any games (except perhaps games that utilize multiple monitors, like flight simulators) that can make use of more than one GPU.
So a single game could potentially drive many monitors, but not do more visually on a single display.
However, this thing could do some amazing real-time raytracing, but again, no games have been designed for such hardware yet.
The correct name is D+=9, or alternatively, D|=9, which is a rather nice coincidence for those of us that care about such things.