The thing about this game that supposedly sets it apart from others is that the underlying object model doesn't change. From what I understand, the scripting language and authoring tools haven't changed in the game. And everything you come across in the game is expressed through the same old object model. Most importantly, everything you see in the game was either created by players, or could have been created by plaers. That means that without changing the underpinnings of the game itself, the stuff traded in it is entirely within players' control. By extension, the value of all that stuff is determined by the players and what (else) they create. That's totally reasonable, if you think about it. Consider having a sword worth a certain amount of money. Then one day another player creates a pistol, which is much more effective. All of a sudden your sword is obsolete and isn't worth anything. That works just as it should. I guess the interesting question is how does replication of virtual physical objects work? In other words, is creation the same as invention in Second Life -- after you create one, you can replicate as many as you want at no additional labor costs?
Apple did a _beautiful_ job at this with their Aqua/Swing wrapper for Java. (My Swing based Java applications look exactly like OS X applications, and are more portable than Cocoa based Java)
I keep seeing people mentioning ads on Yahoo!'s client. Either they are using a different version than me, or they just assume that since there's an official client, it must be pushing ads down people's throats. I, for one, only see ads in chatrooms, not in any other use of the client and I don't see what all the hoopla is about.
Also, do I understand this correctly, that third party clients are only clients with no servers? In other words, if account X is on MSN and account Y is on Yahoo!, a user with a third party client would use that client to create accounts on both MSN and Yahoo! to be able to communicate with X and Y, even if that account creation is a one-click action from the client user's perspective. If that's the case, such third party client makers are not providing anything in the way of IM protocol consolidation. Consider the possibility of everyone realizing what a great app those third party clients are and started using them. If a good percentage of people abandoned official clients, Yahoo!, MSN, AOL, and ICQ would have no reason to continue chat support -- they'd shut down the servers. The value of an IM network is comprised of the following:
network users
client availability
I think the only thing that would help consolidate different IM protocols is the emergence of standards that talk about routing messages between different chat servers. Is this what Jabber is doing?
I looked at the scriptometer page, but didn't find much about Java scripting environments (not JavaScript). I'm a long time user of Bean Shell and consider it to be damn near perfect, though I know there are other interpreters. While it does not have such scripty features as weak typing (there are other solutions that do), it does allow for very quick scripting for a Java programmer and leverages all available Java libraries! And as I said, it's not just one language, but a whole class of them to choose from. That's some powerful stuff.
1. Proper version of IE. 2. Java SDK. 3. Bean Shell (http://www.beanshell.org). 4. Active Perl (http://www.activestate.com/). 5. My own Perl and Java utilities. 6. A licensed TextPad install (http://www.textpad.com). 7. Cygwin (http://www.cygwin.com). 8. Yahoo! messenger. 9. Windows Media Player (http://www.microsoft.com). 10. Real player (http://www.real.com).
Are you nuts? If technology A runs on standard S and technologies B and C implement S, then the maker of A has two options:
* say they run on S * support one or more of S implementations and only specify which ones they explicitly support
They could have easily said, Win 3.1 is not supported on any DOS other than MS-DOS and that would have been it. They didn't have to actively go after DR DOS.
I haven't been thinking much about this issue until I read the article and the words "open source" were the first thing to pop up in my head when I read about the issues of back door code. What's there to be afraid of? We've got tons of proven software out-there. You could put some open source OS on a PC with some open source system for collecting the votes and the results could be transmitted to a central storage, a hard drive, or anything in between. You could have a multi-tiered storage system. You could use PGP so that no-one between the DRE and the auditing system could tamper with the results. What's the insurmountable problem here? There are plenty of folks much smarter and knowledgeble than me about security and if I can see this many options, surely there are many more.
Slashdot Mirror
The thing about this game that supposedly sets it apart from others is that the underlying object model doesn't change. From what I understand, the scripting language and authoring tools haven't changed in the game. And everything you come across in the game is expressed through the same old object model. Most importantly, everything you see in the game was either created by players, or could have been created by plaers. That means that without changing the underpinnings of the game itself, the stuff traded in it is entirely within players' control. By extension, the value of all that stuff is determined by the players and what (else) they create. That's totally reasonable, if you think about it. Consider having a sword worth a certain amount of money. Then one day another player creates a pistol, which is much more effective. All of a sudden your sword is obsolete and isn't worth anything. That works just as it should. I guess the interesting question is how does replication of virtual physical objects work? In other words, is creation the same as invention in Second Life -- after you create one, you can replicate as many as you want at no additional labor costs?
I use jPodder, an open source client that can be told to just drop the files on the file system.
Sorry, but that's contrary to my experience. Their L&F may look nice, but it doesn't work the same as Swing's default Metal L&F. As proof, here's a problem I encountered when working on a project of my own.
Also, do I understand this correctly, that third party clients are only clients with no servers? In other words, if account X is on MSN and account Y is on Yahoo!, a user with a third party client would use that client to create accounts on both MSN and Yahoo! to be able to communicate with X and Y, even if that account creation is a one-click action from the client user's perspective. If that's the case, such third party client makers are not providing anything in the way of IM protocol consolidation. Consider the possibility of everyone realizing what a great app those third party clients are and started using them. If a good percentage of people abandoned official clients, Yahoo!, MSN, AOL, and ICQ would have no reason to continue chat support -- they'd shut down the servers. The value of an IM network is comprised of the following:
I think the only thing that would help consolidate different IM protocols is the emergence of standards that talk about routing messages between different chat servers. Is this what Jabber is doing?
Boo hoo. Now you have to use recommended free software with no ads. What a freaking tragedy.
I looked at the scriptometer page, but didn't find much about Java scripting environments (not JavaScript). I'm a long time user of Bean Shell and consider it to be damn near perfect, though I know there are other interpreters. While it does not have such scripty features as weak typing (there are other solutions that do), it does allow for very quick scripting for a Java programmer and leverages all available Java libraries! And as I said, it's not just one language, but a whole class of them to choose from. That's some powerful stuff.
Why does art have to be objective?
Excellent point.
It's a bicycle, not a motorcycle. RTFA.
1. Proper version of IE.
2. Java SDK.
3. Bean Shell (http://www.beanshell.org).
4. Active Perl (http://www.activestate.com/).
5. My own Perl and Java utilities.
6. A licensed TextPad install (http://www.textpad.com).
7. Cygwin (http://www.cygwin.com).
8. Yahoo! messenger.
9. Windows Media Player (http://www.microsoft.com).
10. Real player (http://www.real.com).
Just give him some beer!
I knew all those years of downing black joe would have killed me by now if it was as bad as people say.
The mechanics would then contact the women directly to invite them over.
This is a little creepy, no?
It won't do anything to the plastic (it might ruin the paint). My gas can is made of plastic.
Are you nuts? If technology A runs on standard S and technologies B and C implement S, then the maker of A has two options:
* say they run on S
* support one or more of S implementations and only specify which ones they explicitly support
They could have easily said, Win 3.1 is not supported on any DOS other than MS-DOS and that would have been it. They didn't have to actively go after DR DOS.
I haven't been thinking much about this issue until I read the article and the words "open source" were the first thing to pop up in my head when I read about the issues of back door code. What's there to be afraid of? We've got tons of proven software out-there. You could put some open source OS on a PC with some open source system for collecting the votes and the results could be transmitted to a central storage, a hard drive, or anything in between. You could have a multi-tiered storage system. You could use PGP so that no-one between the DRE and the auditing system could tamper with the results. What's the insurmountable problem here? There are plenty of folks much smarter and knowledgeble than me about security and if I can see this many options, surely there are many more.