How long is 30 days really?
I was recently informed that adobe offers CS3 as a free download, with a 30 day trial. (http://www.adobe.com/special/try_buy/trial_availability.html) Naturally, the idea here is that you download and install it; when the 30 days are up it locks you out and you have to buy. Adobe no doubt realizes that this makes it a little easier for people to steal their product, but the inconvenience (and danger) of looking for a hack or cleaning your machine enough to re-install the product or plain old ethics will keep most people honest. Good for them
However, when combined with the also free download of VPC2007, the barrier to thievery gets a whole lot lower. (http://www.microsoft.com/downloads/details.aspx?FamilyId=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en) For anyone with basic knowledge of how to use these products, it's very easy to install CS3 on a vm and keep that system at the "freshly installed" state. It's not just easy, it's convenient.
Virtual machines do some funny things with state. Encapsulating at the whole machine level puts a great deal of power (back) in the hands of users. It allows you to manipulate the state of a computer the way you would a file (or better!) and that's something applications have grown accustomed to being able to work around - but that's increasingly not the case. In the above example, virtual machines let us decouple the temporal state of the application from the users temporal state - We can use it all we want, AND control how much time seems to have passed for the app. With a more sophisticated system, I could do proper time travel and revert the machine to any historical state, then continue forward. It also lets me decouple the state of the illustrator application from the rest of my machine via sandboxing. It's interesting to think about how application programming might respond to this. I can imagine a desire to keep some state (eg temporal state, as above) persistent by moving it somewhere users can't muck with it - probably over the network. Another possible response would be to consider how different application behaviors respond to radically shifting state. For example, applications that use randomness are very much NOT idempotent under time travel, whereas some other applications will do the same thing if we roll back then continue forward. This changes the nature (and difficulty) of deterministic replay. The effect differences like this aren't widely considered when building software.
However, when combined with the also free download of VPC2007, the barrier to thievery gets a whole lot lower. (http://www.microsoft.com/downloads/details.aspx?FamilyId=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en) For anyone with basic knowledge of how to use these products, it's very easy to install CS3 on a vm and keep that system at the "freshly installed" state. It's not just easy, it's convenient.
Virtual machines do some funny things with state. Encapsulating at the whole machine level puts a great deal of power (back) in the hands of users. It allows you to manipulate the state of a computer the way you would a file (or better!) and that's something applications have grown accustomed to being able to work around - but that's increasingly not the case. In the above example, virtual machines let us decouple the temporal state of the application from the users temporal state - We can use it all we want, AND control how much time seems to have passed for the app. With a more sophisticated system, I could do proper time travel and revert the machine to any historical state, then continue forward. It also lets me decouple the state of the illustrator application from the rest of my machine via sandboxing. It's interesting to think about how application programming might respond to this. I can imagine a desire to keep some state (eg temporal state, as above) persistent by moving it somewhere users can't muck with it - probably over the network. Another possible response would be to consider how different application behaviors respond to radically shifting state. For example, applications that use randomness are very much NOT idempotent under time travel, whereas some other applications will do the same thing if we roll back then continue forward. This changes the nature (and difficulty) of deterministic replay. The effect differences like this aren't widely considered when building software.