That would be their locked-down sandbox. You can accomplish the same thing in vanilla Java with a security manager. (Which for all we know, they did. I haven't tried yet.) If the security manager doesn't allow it, you're not using it. Period, end of story.
You may note that everything Google has locked down is either controlled by the security manager or is simply an API to access a service that they don't provide.
which is pretty major
Generally speaking, it's a good idea to avoid multithreading/networking/filesystem access in a servlet environment anyway. That's what the container is for. It manages all those little details so you don't have to.
That's not to say that people don't come up with reasonable uses for such services (e.g. Quartz scheduler), so programmers will have to decide whether they prefer to use Google's locked-down environment with its alternative solutions (e.g. Cron) or if they would rather purchase dedicated hosting and handle all the details themselves.
For me, the answer is straightforward. I have one site that would be nice to move over, but I'm not going to. It makes use of services that Google does not provide. Those services are important enough to me to continue paying for dedicated hosting. On the other hand, I'm working on a new site that has far lower requirements. That one is getting installed on Google AppEngine.
So far I haven't found any limitations I can't live with for the new site (as I said, nothing that can't be restricted with a security manager), so I'm pretty happy. I may change my mind after using it more, but until I run into some hard and unexpected limitations, I'm not going to crucify Google for their AppEngine support.
As someone who personally loves the Java platform, I honestly think he's making a mountain out of a molehill. As far as I've been able to tell so far, the Google App Engine supports the Java platform in its entirety, with a few caveats. Those caveats deal with the services Google offers (e.g. no JDBC accessible database) and the sandbox the apps run in (e.g. no network support, no filesystem).
AFAICT, there's nothing stopping me from, say, writing a JDBC access layer for their Data Store. Which means that Google is keeping with the spirit of the platform, and that this is mostly just a misunderstanding.
If you want real problems, try running Java apps on a shared hosting provider sometime. The limitations of those sites will have you shouting praise for what Google is offering.
Price? it can be built for less than $250, including packaging.
I hope that means $250 retail and not $250 manufacturer's cost. If it sells for $250 retail, this could be an excellent satellite device for the home. Assuming it performs well enough, that is. The real failure of many "web surfing" devices has always been poor usability caused by poor performance. Many also shipped with sub-standard browsers, which presumably wouldn't be the case here.
(As an aside, does anyone else think this looks like something Rodney McKay should be toting around?:-P)
I think the problem was he wasn't offering "constructive criticism" he was just ranting about a research project that isn't even a consumer device yet
That's a fair criticism as I can see how my post would be interpreted that way. I will say that I have strong feelings against Microsoft, but I try and not let it cloud my judgment. I *am* skeptical of everything Microsoft does though, because they have burned the market repeatedly in the past.
That being said, the nanoTouch is fundamentally flawed. The design is not well built for one-handed operation, which is generally a show stopper for today's portable devices.
rather than anything constructive about applying the valuable parts of the research to a commercial endeavor.
I'd love to offer something more constructive about these devices, but I don't see any viable uses for the nanoTouch. The Codex is simply a research platform for rehashing commercially deployed technology. As it stands right now, neither of these devices are going anywhere. That's my opinion. You're free to disagree with it.:-)
humb and middle finger grasp tiny device. Index finger operates the interface.
Try holding your hand with your thumb and middle finger apart and the inside of your extended index finger facing you. Feel that pressure on your wrist? That's not going to be a very comfortable or stable grip. More likely you'd try to use your index and thumb to grasp the unit while your middle finger slides across the interface. Not as effective, but infinitely more comfortable.
Whenever you're looking at a control interface, you always need to look at the way pressures are applied. When you tap with your thumb, the force of that tap is safely absorbed by your palm. Rebound is a non-issue.
With this device, you're using force from the top and bottom to brace against a lateral shearing force applied to the back of the unit. This creates a situation where you are fighting against yourself. Your bracing fingers will eventually grow tired and one of two things will inevitably happen:
1. You will lose your grip and press the unit out of your grasp.
2. In an attempt to better brace the unit, you will slide your fingers to cover the front panel slightly. Now you are pinching the unit between your finger in the back and fingers in the front. This is a precarious hold. If the unit moves off center, you will drop it. If you press and release quickly (e.g. a tap), you might lose it when it rebounds.
Basically, the ergonomics of this are designed for two hands. Which does not gel with the requirements of most portable devices.
Such mistakes in ergonomics are common throughout history. Atari and Coleco, for example, didn't understand how a handheld joystick caused insane amounts of torque, making them difficult to use. Atari actually made the problem worse with the 7800. The joysticks had thin bodies that were not braced against torque and long necks that increased torque! Is there any wonder why the market followed Nintendo's lead and deployed the more ergonomic and stable gamepad?
Is it just me, or are vendors lately simply trying to outgeek each other rather than look for actual purpose and usage discovered through market research?
"Lately"? I don't recall it ever being any different. See: Sturgeon's Law.;-)
Actually, allowing (but not forcing) a pointer controlled with a small trackball like is used on Blackberries might solve the "hard to use one handed because thumbs are wide" issue just as well and without requiring a looser grip on the device.
Very interesting idea! I agree that could be a very useful combination.
However, it does raise one question: Is screen blocking enough of an issue to users where they feel they need an alternative method of input? My gut says 'no'. Which raises the further question of where this research is intended to take us?
It's not that Microsoft doesn't have some neat ideas here, but they really are dead-end branches of today's technology rather than looking forward to tomorrow.:-)
I'm not sure what point you were trying to making linking the the Wikipedia article on thumbs.
Circle back to the previous paragraph where I mentioned the problems of using this device with one hand. Opposable thumbs allow humans to manipulate small keyboards and touchscreens efficiently with one hand while the device sits firmly in the palm. Which is an important aspect of small device operation.
The nanoTouch requires a less secure hold. One that would make one-handed operation difficult and may lead to the device getting dropped with alarming regularity.
Regular touchscreens can still provide the needed dexterity with two hands. Humans are quite adept at using the index finger in a precise manner and without nearly as much obstruction as the use of the thumb.
If this had an apple logo on it you'd be standing in line to buy one.
An interesting troll, Mr. AC. (Who's apparently now a terrorist!:-P) Unfortunately, one that has made its way into the public consciousness.
Allow me to pose a question to you: If Apple is built entirely on hype rather than substance, then how did they manage to convert so many former Apple haters to their cause?
Maybe, just maybe Apple has earned support from the market by making superior products. Not everyone likes their products (true of any product), but a large enough segment to where their following is strong. Do you really think Apple would manage to remain the poster-child for innovation if their products started sucking? The correct answer is 'no'. They would go back to having a small niche following and a dire financial situation.
Customer loyalty only takes companies so far before customers leave for greener pastures. Just ask Palm. Or Nintendo and Sega five years ago. Or Commodore. Don't forget HP, Sun, and SGI. So on and so forth.
The nanoTouch is designed to be held by the edges in one hand while you operate the trackpad with the index finger of your other hand. The cleverest touch, so to speak, is that the device uses "pseudotransparency" to provide visual feedback--basically, the "cursor" is a life-size picture of a finger that tracks with the position of your actual finger, as if you were looking through the device with X-ray glasses.
I'm sure that will be hugely useful on a bus or train as I'm attempting to hold on to the railing with one hand, and use my device with the other. (I won't even mention usage in cars, because you're not supposed to be doing that.:-P)
Dear Microsoft, allow me to introduce you to the flaw in your scheme. Or should I say, two flaws?
Codex consists of a pair of OQO mini-tablet PCs, each with a 3-inch-by-5-inch screen, mounted in a hinged device with built-in sensors that can detect how the hinges are oriented. The sensors are important because Hinckley's whole concept is that a dual-screen device should be able to switch configurations on the fly depending on what "posture" it's in.
So it's a Nintendo DS with accelerometers? It's not that the idea is completely without merit, but I'm not sure how much it really pushes the envelope. And the example they gave of two people working across the table "battleship style" would not be something the unit could configure "reflexively" with its sensors as it cannot distinguish "tablet PC on table" from "book on table" from "battleship" modes. The user would still need to tell it what to do.
If Microsoft doesn't build such devices itself, 'somebody else will'
Well, I can guarantee that Microsoft won't build the devices. Innovation has never been their strong suit. Their usual M.O. is to wait until someone else demonstrates a good concept, then throw a ton of resources at making a better version. Once all competition is eliminated, the software or device stagnates. (No new ideas are being generated.)
Hinckley's comments strike me more as Microsoft trying to be prepared for anything new Apple might throw at them. A possibly reaction of sorts to the number of times they've been caught with their pants down. Except the problem is that these ideas seem kind of random with no clear focus on where they might be going. In result, Microsoft is going to miss the boat again when a competitor (not necessarily Apple) introduces Yet Another(TM) great advancement in interface technology.
Personally, I see a lot more promise in technologies like Siftables. Emerging new interface schemes that will be a core part of the next generation of user interfaces. The final product will probably look a lot different from the units we see today (much like touch screens evolved until we got devices like iPhones and DSes), but the core concept will be what drives the next generation.
Meanwhile, Microsoft is spending their time contemplating their collective navels. "Oh hey, look! Touchscreens and accelerometers are becoming industry standard! Those must be the next generation of technology!" No, that's what we call *THIS* generation.
If you seriously decide to wrap your chip and reader in duct tape just to avoid replacing a $10-$15 card, you're either close to living on the street or seriously need to re-evaluate your priorities.
10MB CF cards predated the common deployment of wear leveling. Those old cards could fail at the drop of a hat. Especially if anyone was foolish enough to use them in a high-volume write situation.
Because very few people reformat their Flash drives to anything other than FAT? And even if they do, the principle is still the same. The MFT, superblock/inode table, Volume Header/Allocation File (depending on your FS) are all vulnerable to similar degrees. It's the nature of file systems that they tend to have a few weak points that don't mesh well with limited-write storage. That's why wear-leveling was applied to Flash media. The individual file writes might be well distributed, but the meta data was causing a number of early drive failures.
A single power failure during a write can ruin a perfectly good SD card. It took me a single try.
You're right, I think that's the most common situation people see these days. Most of the other posters are describing sudden, total failures. Which are consistent with frying the drive rather than failures of bad blocks. Not all that different than losing a head on a hard drive.
Washing machines are pretty harsh places. You get tidal forces that will apply various physical stresses to the components. Rapid heating and cooling can cause expansion problems. Water can wear down contacts. Soaps can contaminate contacts or have negative chemical effects. So on and so forth.
If it makes it to the drier, your card could easily end up at temperatures outside the optimal storage temperature for the device. (Ever read those warnings, "Store between 70F and 100F?" Yeah, me neither.) These extreme temperatures combined with the rapidity at which they're introduced is a cornucopia of ways your device could be damaged.
In short, water isn't the real problem. It's all the stuff above and beyond that.
The one account I have found detailed using a small USB drive for/var/log storage; it failed very quickly, and then utterly (0 byte unformatted device), after five years of service in the role.
Without knowing more about this specific situation, I'd say this failure sounds like it pre-dates wear leveling. Prior to wear leveling, the most used sectors were likely to fail the fastest. And what sector gets written to more than the file allocation table?
If the file allocation table was lost, that would explain why the device became completely inaccessible. The card might not be a total loss if the card contains firmware or circuitry to remove bad blocks from usage. In that case it might be possible to reformat it. (Of course, if it lacks wear leveling I wouldn't count on it.)
Wear leveling neatly solves this issue by shifting writes to different free blocks with every write. This assures that the maximum use of the card is obtained prior to failure. Should any given block fail the card will detect the checksum error, mark the block as bad, then attempt to rewrite to a different block. This is communicated back to the reader in a transparent way. As far as the reader knows, nothing happened.
As you can imagine, wear leveling makes it incredibly rare to see Flash failures these days. It can still happen, but the results are likely to be unpredictable. The card will need to chew through all free blocks before it starts returning errors. In that case you may be able to continue reading the media. Or it may fail like the USB drive you mentioned. It all depends on the importance of the block on which the erasure was attempted. Since you only know about a failure *after* the block erasure, you're at the mercy of the quality of the card's electronics and algorithms to protect against a dangerous erasure.
So what's left of the database market if Oracle and Sun merged together?
I don't see anything changing. Right now we have a 3-way fight between three heavyweights: Oracle, IBM, and Microsoft. Everyone else is unimportant.
However, IBM and Microsoft have other competencies and sources of revenue. Oracle does not. In result, Oracle has been looking for new ways to enter the low-end market. So owning MySQL could be a boon for them, but it wouldn't significantly change the market.
I think the two companies have some excellent synergies*. My biggest concern with Oracle purchasing Sun (as opposed to the other way around) is that there would be a culture clash. Sun is a very dynamic environment that fosters great new ideas. But unless those core competencies bubble up through Oracle, the Sun portion of the company would be strangled to death.
Personally, I've always wanted to see Sun purchase Oracle. But I don't think that's happening at this point.
There are tons of examples of roll-your-own O/R mapping tools out there. JDBC is the basis for all of them. So if you support JDBC, you know that you can support everything from raw access to JDO and everything in-between.:)
Slashdot Mirror
That would be their locked-down sandbox. You can accomplish the same thing in vanilla Java with a security manager. (Which for all we know, they did. I haven't tried yet.) If the security manager doesn't allow it, you're not using it. Period, end of story.
You may note that everything Google has locked down is either controlled by the security manager or is simply an API to access a service that they don't provide.
Generally speaking, it's a good idea to avoid multithreading/networking/filesystem access in a servlet environment anyway. That's what the container is for. It manages all those little details so you don't have to.
That's not to say that people don't come up with reasonable uses for such services (e.g. Quartz scheduler), so programmers will have to decide whether they prefer to use Google's locked-down environment with its alternative solutions (e.g. Cron) or if they would rather purchase dedicated hosting and handle all the details themselves.
For me, the answer is straightforward. I have one site that would be nice to move over, but I'm not going to. It makes use of services that Google does not provide. Those services are important enough to me to continue paying for dedicated hosting. On the other hand, I'm working on a new site that has far lower requirements. That one is getting installed on Google AppEngine.
So far I haven't found any limitations I can't live with for the new site (as I said, nothing that can't be restricted with a security manager), so I'm pretty happy. I may change my mind after using it more, but until I run into some hard and unexpected limitations, I'm not going to crucify Google for their AppEngine support.
You obviously have never used COBOL.
As someone who personally loves the Java platform, I honestly think he's making a mountain out of a molehill. As far as I've been able to tell so far, the Google App Engine supports the Java platform in its entirety, with a few caveats. Those caveats deal with the services Google offers (e.g. no JDBC accessible database) and the sandbox the apps run in (e.g. no network support, no filesystem).
AFAICT, there's nothing stopping me from, say, writing a JDBC access layer for their Data Store. Which means that Google is keeping with the spirit of the platform, and that this is mostly just a misunderstanding.
If you want real problems, try running Java apps on a shared hosting provider sometime. The limitations of those sites will have you shouting praise for what Google is offering.
According to the article:
I hope that means $250 retail and not $250 manufacturer's cost. If it sells for $250 retail, this could be an excellent satellite device for the home. Assuming it performs well enough, that is. The real failure of many "web surfing" devices has always been poor usability caused by poor performance. Many also shipped with sub-standard browsers, which presumably wouldn't be the case here.
(As an aside, does anyone else think this looks like something Rodney McKay should be toting around? :-P)
The way you're using that word? I do not think it means what you think it means.
That's a fair criticism as I can see how my post would be interpreted that way. I will say that I have strong feelings against Microsoft, but I try and not let it cloud my judgment. I *am* skeptical of everything Microsoft does though, because they have burned the market repeatedly in the past.
That being said, the nanoTouch is fundamentally flawed. The design is not well built for one-handed operation, which is generally a show stopper for today's portable devices.
I'd love to offer something more constructive about these devices, but I don't see any viable uses for the nanoTouch. The Codex is simply a research platform for rehashing commercially deployed technology. As it stands right now, neither of these devices are going anywhere. That's my opinion. You're free to disagree with it. :-)
Try holding your hand with your thumb and middle finger apart and the inside of your extended index finger facing you. Feel that pressure on your wrist? That's not going to be a very comfortable or stable grip. More likely you'd try to use your index and thumb to grasp the unit while your middle finger slides across the interface. Not as effective, but infinitely more comfortable.
Whenever you're looking at a control interface, you always need to look at the way pressures are applied. When you tap with your thumb, the force of that tap is safely absorbed by your palm. Rebound is a non-issue.
With this device, you're using force from the top and bottom to brace against a lateral shearing force applied to the back of the unit. This creates a situation where you are fighting against yourself. Your bracing fingers will eventually grow tired and one of two things will inevitably happen:
1. You will lose your grip and press the unit out of your grasp.
2. In an attempt to better brace the unit, you will slide your fingers to cover the front panel slightly. Now you are pinching the unit between your finger in the back and fingers in the front. This is a precarious hold. If the unit moves off center, you will drop it. If you press and release quickly (e.g. a tap), you might lose it when it rebounds.
Basically, the ergonomics of this are designed for two hands. Which does not gel with the requirements of most portable devices.
Such mistakes in ergonomics are common throughout history. Atari and Coleco, for example, didn't understand how a handheld joystick caused insane amounts of torque, making them difficult to use. Atari actually made the problem worse with the 7800. The joysticks had thin bodies that were not braced against torque and long necks that increased torque! Is there any wonder why the market followed Nintendo's lead and deployed the more ergonomic and stable gamepad?
"Lately"? I don't recall it ever being any different. See: Sturgeon's Law. ;-)
Very interesting idea! I agree that could be a very useful combination.
However, it does raise one question: Is screen blocking enough of an issue to users where they feel they need an alternative method of input? My gut says 'no'. Which raises the further question of where this research is intended to take us?
It's not that Microsoft doesn't have some neat ideas here, but they really are dead-end branches of today's technology rather than looking forward to tomorrow. :-)
Circle back to the previous paragraph where I mentioned the problems of using this device with one hand. Opposable thumbs allow humans to manipulate small keyboards and touchscreens efficiently with one hand while the device sits firmly in the palm. Which is an important aspect of small device operation.
The nanoTouch requires a less secure hold. One that would make one-handed operation difficult and may lead to the device getting dropped with alarming regularity.
Regular touchscreens can still provide the needed dexterity with two hands. Humans are quite adept at using the index finger in a precise manner and without nearly as much obstruction as the use of the thumb.
An interesting troll, Mr. AC. (Who's apparently now a terrorist! :-P) Unfortunately, one that has made its way into the public consciousness.
Allow me to pose a question to you: If Apple is built entirely on hype rather than substance, then how did they manage to convert so many former Apple haters to their cause?
Maybe, just maybe Apple has earned support from the market by making superior products. Not everyone likes their products (true of any product), but a large enough segment to where their following is strong. Do you really think Apple would manage to remain the poster-child for innovation if their products started sucking? The correct answer is 'no'. They would go back to having a small niche following and a dire financial situation.
Customer loyalty only takes companies so far before customers leave for greener pastures. Just ask Palm. Or Nintendo and Sega five years ago. Or Commodore. Don't forget HP, Sun, and SGI. So on and so forth.
They wanted to name it the WiiPlayDualScreen, but Nintendo threatened them with trademarks.
I'm sure that will be hugely useful on a bus or train as I'm attempting to hold on to the railing with one hand, and use my device with the other. (I won't even mention usage in cars, because you're not supposed to be doing that. :-P)
Dear Microsoft, allow me to introduce you to the flaw in your scheme. Or should I say, two flaws?
http://en.wikipedia.org/wiki/Opposable_thumbs#Importance
NEXT!
So it's a Nintendo DS with accelerometers? It's not that the idea is completely without merit, but I'm not sure how much it really pushes the envelope. And the example they gave of two people working across the table "battleship style" would not be something the unit could configure "reflexively" with its sensors as it cannot distinguish "tablet PC on table" from "book on table" from "battleship" modes. The user would still need to tell it what to do.
Well, I can guarantee that Microsoft won't build the devices. Innovation has never been their strong suit. Their usual M.O. is to wait until someone else demonstrates a good concept, then throw a ton of resources at making a better version. Once all competition is eliminated, the software or device stagnates. (No new ideas are being generated.)
Hinckley's comments strike me more as Microsoft trying to be prepared for anything new Apple might throw at them. A possibly reaction of sorts to the number of times they've been caught with their pants down. Except the problem is that these ideas seem kind of random with no clear focus on where they might be going. In result, Microsoft is going to miss the boat again when a competitor (not necessarily Apple) introduces Yet Another(TM) great advancement in interface technology.
Personally, I see a lot more promise in technologies like Siftables. Emerging new interface schemes that will be a core part of the next generation of user interfaces. The final product will probably look a lot different from the units we see today (much like touch screens evolved until we got devices like iPhones and DSes), but the core concept will be what drives the next generation.
Meanwhile, Microsoft is spending their time contemplating their collective navels. "Oh hey, look! Touchscreens and accelerometers are becoming industry standard! Those must be the next generation of technology!" No, that's what we call *THIS* generation.
If you seriously decide to wrap your chip and reader in duct tape just to avoid replacing a $10-$15 card, you're either close to living on the street or seriously need to re-evaluate your priorities.
I think the shortened version is: Whoosh!
:-P
I misspoke. Thank you for the correction. :-)
10MB CF cards predated the common deployment of wear leveling. Those old cards could fail at the drop of a hat. Especially if anyone was foolish enough to use them in a high-volume write situation.
Because very few people reformat their Flash drives to anything other than FAT? And even if they do, the principle is still the same. The MFT, superblock/inode table, Volume Header/Allocation File (depending on your FS) are all vulnerable to similar degrees. It's the nature of file systems that they tend to have a few weak points that don't mesh well with limited-write storage. That's why wear-leveling was applied to Flash media. The individual file writes might be well distributed, but the meta data was causing a number of early drive failures.
You're right, I think that's the most common situation people see these days. Most of the other posters are describing sudden, total failures. Which are consistent with frying the drive rather than failures of bad blocks. Not all that different than losing a head on a hard drive.
There's a fix for that. :-P
Washing machines are pretty harsh places. You get tidal forces that will apply various physical stresses to the components. Rapid heating and cooling can cause expansion problems. Water can wear down contacts. Soaps can contaminate contacts or have negative chemical effects. So on and so forth.
If it makes it to the drier, your card could easily end up at temperatures outside the optimal storage temperature for the device. (Ever read those warnings, "Store between 70F and 100F?" Yeah, me neither.) These extreme temperatures combined with the rapidity at which they're introduced is a cornucopia of ways your device could be damaged.
In short, water isn't the real problem. It's all the stuff above and beyond that.
Without knowing more about this specific situation, I'd say this failure sounds like it pre-dates wear leveling. Prior to wear leveling, the most used sectors were likely to fail the fastest. And what sector gets written to more than the file allocation table?
If the file allocation table was lost, that would explain why the device became completely inaccessible. The card might not be a total loss if the card contains firmware or circuitry to remove bad blocks from usage. In that case it might be possible to reformat it. (Of course, if it lacks wear leveling I wouldn't count on it.)
Wear leveling neatly solves this issue by shifting writes to different free blocks with every write. This assures that the maximum use of the card is obtained prior to failure. Should any given block fail the card will detect the checksum error, mark the block as bad, then attempt to rewrite to a different block. This is communicated back to the reader in a transparent way. As far as the reader knows, nothing happened.
As you can imagine, wear leveling makes it incredibly rare to see Flash failures these days. It can still happen, but the results are likely to be unpredictable. The card will need to chew through all free blocks before it starts returning errors. In that case you may be able to continue reading the media. Or it may fail like the USB drive you mentioned. It all depends on the importance of the block on which the erasure was attempted. Since you only know about a failure *after* the block erasure, you're at the mercy of the quality of the card's electronics and algorithms to protect against a dangerous erasure.
Sun can't market their way out of a paper bag. And that's just the God's honest truth. There's nothing inherently wrong with the company besides that.
I don't see anything changing. Right now we have a 3-way fight between three heavyweights: Oracle, IBM, and Microsoft. Everyone else is unimportant.
However, IBM and Microsoft have other competencies and sources of revenue. Oracle does not. In result, Oracle has been looking for new ways to enter the low-end market. So owning MySQL could be a boon for them, but it wouldn't significantly change the market.
I think the two companies have some excellent synergies*. My biggest concern with Oracle purchasing Sun (as opposed to the other way around) is that there would be a culture clash. Sun is a very dynamic environment that fosters great new ideas. But unless those core competencies bubble up through Oracle, the Sun portion of the company would be strangled to death.
Personally, I've always wanted to see Sun purchase Oracle. But I don't think that's happening at this point.
* Warning: Corporate buzzword!
There are tons of examples of roll-your-own O/R mapping tools out there. JDBC is the basis for all of them. So if you support JDBC, you know that you can support everything from raw access to JDO and everything in-between. :)