Slashdot Mirror
Handspring Hides Flash ROM in Handspring Treo
miradu writes: "TreoCentral has just posted an intriguing article about how the Handspring Treo has Flash ROM - something that Handspring claims it doesn't. They've worked with Brayder Technology to create applications to utilize this newly discovered feature. It brings up the question, Why do developers lie about features in a device - especially if they are features that are wanted? Does anyone know any other examples?" Strange -- hardware manufacturers don't often underestimate their products' capabilities, do they?
It allows them to remove the Flash at some point in the future and replace it with a cheaper ROM. If they don't tell you that they have a Flash, then you won't complain when it is removed. I would expect the next version to be missing the Flash.
The dogcow says "Moof!"
Users of the Samsung i300 for the longest time were told that there was no flash rom, and that the operating sytem was not upgradable.
Then FlashPro came out and proved that there was flash in the i300.
Upgrading the OS is still not an option, considering that there are lots of propreitary extensions to the OS.
However, the flash capabilities of the devices were hidden for quite a while.
Jake
The developers of the hardware usually aren't the ones who are lying.
Agreed! I've seen that happen more than a few times. Thought it might be useful to add another possible reason why some features are hidden.
My expertise is with software (20+ years in QA), not hardware, but I've seen the hiding of features happen several times. In my experience, the develpment cycle starts off with marketing making its pitch for what needs to be in the product release, and development pushes back with what is feasible in the time frame, as well as what they would like to do. There's some negotiation, and then development goes off to "do their thing". And all is happy and good.
Then QA appears and does its thing. Sometimes QA is called in right from the start; other times the product is almost ready for release and someone thinks it might be good to have QA look at it before it is shipped tomorrow. I actually have seen a few projects released on time, under budget, and with the promised capabilities. But, that is sadly the exception rather than the rule. Even with an early participation by QA, there are often far more developers at work than QA people. The number of possibilities goes up exponentially, and there's just not enough time to test everything as it is developed. Design errors and implementation errors are found. Rework is required. Deadlines loom. All is not as happy and good as it once seemed. And then it happens.
Maybe it's a nasty memory leak that builds up over time. Maybe there's a variable that gets corrupted, eventually. And there's not enough time to isolate it and fix it. So, instead of yanking out all the questionable code (which would introduce its own bevy of problems), the common approach is to just remove access to it (e.g. removing a choice from a pull-down menu) and, of course, removing all reference to it in the documentation.
So, there's quite possibly some hidden functionality in a program (or a piece of hardware), but it was hidden for a reason. If you're a bleeding-edge kind of person, go have fun. In light of your particular circumstances, it might well seem to work okay. But, if you need to be able to rely on the application or system, it might be a Really Good Idea(TM) to use only the documented features. You might miss out on some helpful features, but you might also save your butt.
Mainframes would ship with various disabled features. Remember these were room-size devices (well, multiple large cabinets which would fill up a big room). When the customer wanted an upgrade, an IBM technician would be sent out, he would rearrange some jumpers, enabling a feature, and the customer would receive a bill for e.g. $100,000 for a memory upgrade.
IBM made no apology for this: you were charged for the functionality you received, and the fact that the "upgrades" already existed inside the boxes in your computer room was irrelevant.
So perhaps one can blame IBM for having started the ball rolling on the idea of strong control of "intellectual property" by the vendor... I wonder if anyone back then "hacked" their own mainframes?