What I find suspicious is the fact that you can't take it with you.
Indeed, the Phantom or any of it's software won't even be available in stores-- some stores will allow you to purchase a Phantom, but not leave with one: the machine will be shipped to your home.
Why would they do this? The only reason I can see is that they need to hardwire your identity (obtained from the order form) into the console in order to further enhance the DRM system.
Of course this increases the production costs per unit considerably, but I cannot think of another reason they would do this. Anyone?
I live in Germany and while HDTV is theoretically available since the 80s, it's not in widespread use, not even today. IIRC some major stations only started broadcasting HDTV at the beginning of the century. I'd say today, most TV sets sold don't have HDTV support.
So much for standards.
Provide binaries for major platforms, and all compilation issues will vanish.
If this is not an option, and the install process is really that complex, and your users are really that dumb, and are unwilling to RATFM (All Those Manuals) -- why don't you provide some hand-holding services and have them pay for it?
I need two more informations:
Firstly, what data do you need to manage exactly? Probably not salaries, so do you need to assign them to projects, track their presence, care about their reports... software can do many things, and you won't need all of them. So the first step would be to define your requirements.
Secondly, volunteers for what purpose?
One problem with the way serialization is implemented in Java is that minor modifications are enough to change the "Serialization UID" of a class, which makes it impossible to deserialize objects that have been written using an earlier version of the class.
Of course, in part this is a conceptual problem not confined to Java, but in Java it's particularly nasty. Adding a column to an SQL table is a no-brainer. But add a field to a Java class and all previously serialized objects of that class will become useless.
Another problem with serialization in Java is that in practice it works only if you always use the same VM for both serializing and deserializing, which essentially means that you won't be able to upgrade easily as long as you have serialized data sitting on your hard drive. This is true for both the Sun and the IBM implementations.
I personally go a long way round Java serialization for these reasons. Java is fine, but you're better off using one of the other available persistence layers. EJB (whose initial version sucked, but 2.0 is cool) and JDO already have been mentioned, Xindice may also be worth a look at - it allows you to query data using XPath expressions. Like Prevailer this is only suited for small-scale applications that can do without ACID, though. May be interesting for reading/writing XML configuration files, storing and retrieving XSL templates for CM systems, stuff on that level.
Slashdot Mirror
What I find suspicious is the fact that you can't take it with you.
Why would they do this? The only reason I can see is that they need to hardwire your identity (obtained from the order form) into the console in order to further enhance the DRM system.
Of course this increases the production costs per unit considerably, but I cannot think of another reason they would do this. Anyone?
I live in Germany and while HDTV is theoretically available since the 80s, it's not in widespread use, not even today. IIRC some major stations only started broadcasting HDTV at the beginning of the century. I'd say today, most TV sets sold don't have HDTV support. So much for standards.
Provide binaries for major platforms, and all compilation issues will vanish.
If this is not an option, and the install process is really that complex, and your users are really that dumb, and are unwilling to RATFM (All Those Manuals) -- why don't you provide some hand-holding services and have them pay for it?
I need two more informations: Firstly, what data do you need to manage exactly? Probably not salaries, so do you need to assign them to projects, track their presence, care about their reports ... software can do many things, and you won't need all of them. So the first step would be to define your requirements.
Secondly, volunteers for what purpose?
One problem with the way serialization is implemented in Java is that minor modifications are enough to change the "Serialization UID" of a class, which makes it impossible to deserialize objects that have been written using an earlier version of the class.
Of course, in part this is a conceptual problem not confined to Java, but in Java it's particularly nasty. Adding a column to an SQL table is a no-brainer. But add a field to a Java class and all previously serialized objects of that class will become useless.
Another problem with serialization in Java is that in practice it works only if you always use the same VM for both serializing and deserializing, which essentially means that you won't be able to upgrade easily as long as you have serialized data sitting on your hard drive. This is true for both the Sun and the IBM implementations.
I personally go a long way round Java serialization for these reasons. Java is fine, but you're better off using one of the other available persistence layers. EJB (whose initial version sucked, but 2.0 is cool) and JDO already have been mentioned, Xindice may also be worth a look at - it allows you to query data using XPath expressions. Like Prevailer this is only suited for small-scale applications that can do without ACID, though. May be interesting for reading/writing XML configuration files, storing and retrieving XSL templates for CM systems, stuff on that level.
and is supposedly 100,000 times faster then today's PCs
Obviously this number depends on what task you assign it.
Microsoft Plant 2003.