Actually, I've been at "Excellent" Karma for ages. I find that the trick is not playing the system: I post long, I post late, I post reasonably rarely, and I post my own opinion, not some random "must please the/. masses" crud. Sometimes I present my opinion in a heated manner and get modded down for it, but the times when I think before I post, or close the comment tab before posting because I think it'd be inane do most of the upmodding for me. That you even stop to think "how do I game the system?" is already doing it wrong on several levels.
The whole "oh noes, public domain" argument applies to copyright, or to patents -- not to trademarks. I think that nobody in their right mind will disagree that your company has a right to its own image, and that trying to piggyback on it is wrong. This is obviously a scare tactic, because nobody trades under the ':-)', and, if these guys don't either, their trademark will soon be unenforceable. But it's still legitimate, as a concept, to trademark the symbol.
The real question here is: in what context did they apply for a trademark in? AFAIK, trademarks are domain-specific, which is why Apple Records and Apple Computers lived side by side for so long without issue. Only when Apple Computers got into the music domain did conflict come up again. Reversely, the:-( emoticon is pretty generic and in common use, but its use as Despair, Inc's logo is quite distinctive, representative of their products, and readily identifies the company -- just like you don't have any problem telling an actual apple fruit and either Apple company apart.
I think that brings up the fact that, in an effort to sell more SSDs today, the manufacturers are really missing the boat on one of the most important aspects of SSDs. Why are they all in the same form factor as existing drives? They could be made so small, but they aren't taking advantage of it.
No. They are taking advantage of the capability for small form factors. Ever seen a micro-SD card, for example? It's just that they're now moving upwards too. In an effort to expand their market, they moved from the traditional and thoroughly explored SD/CompactFlash/Memory Stick cards and Thumb drive markets and into the high capacity, HDD-replacement, market. This goes to show how some of the versatility of flash is already being used.
Beta means "feature complete, but has bugs". The windows version was a beta. Now they squashed enough bugs that they feel comfortable removing the "beta" tag. The whole "problem" (if you want to call it that) is that they didn't have os x or linux versions in beta, not that they moved the one platform that was beta to gold.
Modern mass produced paper is comparatively low quality and has a much higher acid content than older paper, thus aging much, much worse, to the point where early 20th century books are much worse off than much older ones (I assume modern high-end paper has better durability than that though, and old paper is, by definition, the high-end stuff because that's all there was). Not sure how the printer ink itself ages.
Rereading the post, I think it became unclear that the whole "versatility" thing was aimed at python having decent functional capabilities and a rather unusual OOP implementation that really highlights some of the core aspects of OOP, rather than the interactive shell (which is much better than, say, perl's, though).
I don't know how versatile ruby is in this regard, but if we're going to suggest languages rather than paradigms, like the OP asked for, I'd go with python. Which brings us to a long-winded answer to the OP, too: You can start off with the interactive shell to do small stuff, proceed to writing imperative style code as "batch shell" to "save" common interactive shell tasks, evolve into writing programs that are more complex than one-offs (which obviously can't be done as an interactive session) -- This is a very natural progression of ideas.
I implicitly suggested that you should start with imperative, then procedural programming. Those are very natural ways to do things, they are very susceptible to the "cook book" metaphor. Simple recipes are almost purely imperative. More complex recipes are either huge imperative affairs, or much simpler to read and write procedurally, with sub recipes (you refer to the sauce recipe, the side dish recipe, etc). You can also use this metaphor to good effect to highlight a difference: reproducibility. Recipes that are done "sort of like this" yield results that are inconsistent. If you mass produce, say, cakes, you do things much more precisely and consistently (irrespectively of actual quality). Boost that hundredfold, and you have computer programs, which are completely unambiguous (actually, deterministic) from the machine's perspective.
Once you got those concepts down, hopefully your students have had some calculus, and the notion of compound and higher-order functions won't be strange to them. That's when you move on to more functional aspects of python, like mapping anonymous functions to arrays, and other such ideas. Full-fledged functional support is somewhat lacking, so I'd suggest some Lisp dialect after on the second semester, to fully explore what you started before. The key issue here is that you want to rapidly highlight the advantages and disadvantages of functional vs imperative.
Choice of language matters loads too, in my opinion: Mostly, I'd try to do as much as possible on top of one single language. You can hop along from language to language too, but I'd say that keeping to one language that supports all you're trying to teach serves a great purpose: it highlights what differences are a paradigm shift, rather than mixing in the confusion of the change in syntax. This implies you need a language that supports as many paradigms as possible in as unobtrusive a way as possible.
I'd leave OOP for software engineering subjects. I'd say OOP is not so much a programming paradigm per se as it is explicit language support for a number of constructs and concepts that can be put in practice in mostly any language. More than providing more insight into how to express algorithms, it's a way to keep things tidy and avoiding excessively verbose code, so it's not an actual core CS subject.
From there, all of the languages (and even paradigms - we covered the main three) were quite a bit simpler to grasp, as you could look a little deeper into them and ask "What are we really doing here?". Stripping away the mystery of compilers and interpreters simplifies understanding dramatically.
Wrong. Assembler and imperative/procedural languages are based on the mathematical concept of a Turing Machine. Functional Programming is based on the concept of lambda calculus (which is why Lisp and Python use the keyword 'lambda' for pure anonymous functions). That Turing Machines and Lambda Calculus are equivalent is a reasonably deep mathematical result, and the associated thought processes are no different.
The MIDI music on the Wii is using sound samples. Sometimes I think people misunderstand what MIDI is. It's just raw music data, and the output can be anything. I haven't heard FM synthesized MIDI in a long time.
In particular, the whole "MOD sounds better because you have control over the samples used" argument crumbles when you're providing your own MIDI implementation/sound banks.
Implement that and you get everybody going "Damn, all my programs get so damned slow when MS Word is open" because the memory is not being made available to the other running programs to swap into. Sometimes, plans to make your product look better only do the reverse.
There's police roaming the streets making sure people aren't violating my right to property or to physical integrity. There are auditors in banks making sure bank managers aren't doing anything funky with my money (even if those lost a fair bit of credibility recently...). There's plenty of people already in place being paid by governments to make sure their citizens' rights are not infringed upon. Conceptually, that there'd be a copyright police to protect the right to intellectual property is perfectly fine: it's only the ultimate logical conclusion of several other things we take for granted. The real issue at hand is that IP is treated as a right of the individual, rather than a right of society as a whole; the issue is the agenda behind the changes and the editorial lines those changes take. The issue is not that there might be a copyright police, but rather that "copyright police" is a nicer way of saying "government-paid corporate attack dog".
Still, this does not in any way invalidate my point: Enforcing rights is part of the charter of a government. Or, extending your own arguments, we'd conclude that, since there are laws on the books that provide remedy and punishment for car theft, we should just leave it for litigation, and police shouldn't do squat if they witness a car being stolen.
Why should government enforce the rights of creators?
Why should governments enforce the rights of anybody, really? Because, you know, that's exactly what they're there for. Or should we resort to mob rules to enforce rights?
As much as I hate DRM, and as much as the analogue hole was a nice hack around it, from a pure engineering point of view, this makes sense. Why bother checking what type of display you have connected? Either it supports HDCP, or it doesn't. If it doesn't and the token is active, the image is degraded.
It does if you don't have $2400 to spend on a copy of Mathematica.
No, that only makes price, rather than freedom, matter.
Viewable source is strictly better than closed source, at least for technical reasons (and arguably for ethical ones as well). Trust me, on my day-to-day job having source code access to the vast majority of the SAP codebase (ie, everything above kernel level) makes it much, much easier to develop for it. Proper Open Source has, once again, technical advantages (especially BSD-style licenses: it's one of the best ways to make sure that the implementation of a standard is usable across the market), and the Free Software attitude also has several interesting ethical points (which is freer? BSD or GPL? Why?) All in all, despite being so cliché it's painful (here in/., that is), "Is there a F/OSS alternative?" is a very valid question on many angles.
Blizzard spent how much time making this expansion, and then it all got run through in less than 30 hours? That's nuts.
Nobody "ran it through" in under 30 hours. What some people did was say "we beat what we consider the important bits, so we call the game beat". A good analogy would perhaps be completing the Terran campaign in Starcraft and saying "I beat the game, because what matters to me is the Terran campaign". SK/Nihilum probably skipped much of the "leveling" content, decidedly skipped most instances, and rushed straight into the raid game.
The original argument was that Python dicts provide a superb implementation of hash maps. Someone answered that perhaps STL-based hash maps might compete, and I said that those were a hash function away from a full implementation. That's when you brought up IDE-generated hash functions, to which I answered that those would still be a far cry from Python's implementation. Collision resolution was simply something I know that Python has very well optimized, and why it's such a good general-purpose implementation, not making a point that it was something that happened every other request for a value.
Fine, I can accept that people have problems with having to spend all of 30 seconds entering a key code. Some people are just really lazy and stupid.
I never said I have a problem with serials. Hell, a few days ago I even mentioned that it's one of the few reasonably effective methods of copy protection. What I did in my previous post was specifically state a few reasons why DRM makes a product worse for myself as a paying customer:
When I do a full install of a game, I shouldn't have to keep the disc in the drive just so the game can validate I'm a legitimate user. There is no legitimate reason why I shouldn't be able to resell the game (or just give it away) when I'm done with it and a friend wants it. I shouldn't have to dial up the editor of the game when I want to install the game more than x many times over the course of its lifetime, and most of all I shouldn't be dependent on the license server still being up when I want to play it in 10 years' time for old times' sake!
All you have to say to that is that the DRM wouldn't be there if it weren't for the evil pirates, when there are, in fact, very few cases where DRM actually prevented pirating of a game, or a DVD, or whatever else. For example the infamous sony rootkit, which is completely innefectual when you can simply play (and rip) the affected albums under linux.
The way to get rid of it of course, is to stop encouraging piracy or making excuses for it.
Excuses? I'm not making excuses. I'm pissed at the fact that I bought Worms 4, installed it, the piece of shit wouldn't work with my soundcard, and when I uninstalled it I still had the freaking copy protection software left behind. We might argue over whether DRM is legitimate at all, but there simply is no legitimate reason why software houses get to leave it behind when I uninstall their product. And if they can't assure safe removal, they don't have the right to install it in the first place.
you're still a good hash function away from an actual, usable hash map with STL. Plus, python's dicts have very fancy collision resolution, and some other such goodies.
Yes, I thought of that example as well, but figured that, even if logical and actually useful, it'd be too vulnerable to "you're not seriously shipping with debugging turned on" followed by "but you don't need to optimize code before gold". Even if those would be completely barbaric things to say, I wanted to avoid stupid arguments over them:).
And locks on a house don't protect criminals from breaking in. But I bet you a hundred dollars you still have locks on your house.
Indeed, locks don't prevent criminals from breaking in. Both DRM and locks are really meant as deterrents. The real discussion is: how effective are those deterrents? The average lock is pretty effective, since it eats away time a robber doesn't have, making exposure time much longer. Plus, most locks aren't trivial to pick and there is a degree of skill associated. Therefore, and since knocking a door down isn't necessarily feasible, you can actually physically avoid a break in rather than just delay it past the point of comfort for the robber.
In practice, breaking DRM is entirely safe for the original cracker, since there is absolutely no exposure time. Releasing the crack might cause some exposure, but once again, the exposure for the end-user is slim to none. The only associated risk is malware payload, which is why you make sure to run an anti-virus on the crack and use only releases from reputable groups (the definition of reputable being quite loose here:). Once there is one clean crack out there, the DRM is effectively defeated for all copies of the game, so it ends up producing much less effective protection than a simple lock.
And people who steal games are assholes and are ruining the gaming industry, and they should all be shot. Not to mention your hatred of companies protecting their rights is solely cause by pirates, so you too can only agree with that. So what's your point?
Bringing up piracy again and again fails to address the major point: DRM makes the product worse for the end user. Sure, developers might not produce more games, yadda yadda, but, given an actual finished game, there's absolutely nothing about DRM that makes it any better for the consumer. When I do a full install of a game, I shouldn't have to keep the disc in the drive just so the game can validate I'm a legitimate user. There is no legitimate reason why I shouldn't be able to resell the game (or just give it away) when I'm done with it and a friend wants it. I shouldn't have to dial up the editor of the game when I want to install the game more than x many times over the course of its lifetime, and most of all I shouldn't be dependent on the license server still being up when I want to play it in 10 years' time for old times' sake!
Slashdot Mirror
Actually, I've been at "Excellent" Karma for ages. I find that the trick is not playing the system: I post long, I post late, I post reasonably rarely, and I post my own opinion, not some random "must please the /. masses" crud. Sometimes I present my opinion in a heated manner and get modded down for it, but the times when I think before I post, or close the comment tab before posting because I think it'd be inane do most of the upmodding for me. That you even stop to think "how do I game the system?" is already doing it wrong on several levels.
The whole "oh noes, public domain" argument applies to copyright, or to patents -- not to trademarks. I think that nobody in their right mind will disagree that your company has a right to its own image, and that trying to piggyback on it is wrong. This is obviously a scare tactic, because nobody trades under the ':-)', and, if these guys don't either, their trademark will soon be unenforceable. But it's still legitimate, as a concept, to trademark the symbol.
The real question here is: in what context did they apply for a trademark in? AFAIK, trademarks are domain-specific, which is why Apple Records and Apple Computers lived side by side for so long without issue. Only when Apple Computers got into the music domain did conflict come up again. Reversely, the :-( emoticon is pretty generic and in common use, but its use as Despair, Inc's logo is quite distinctive, representative of their products, and readily identifies the company -- just like you don't have any problem telling an actual apple fruit and either Apple company apart.
I think that brings up the fact that, in an effort to sell more SSDs today, the manufacturers are really missing the boat on one of the most important aspects of SSDs. Why are they all in the same form factor as existing drives? They could be made so small, but they aren't taking advantage of it.
No. They are taking advantage of the capability for small form factors. Ever seen a micro-SD card, for example? It's just that they're now moving upwards too. In an effort to expand their market, they moved from the traditional and thoroughly explored SD/CompactFlash/Memory Stick cards and Thumb drive markets and into the high capacity, HDD-replacement, market. This goes to show how some of the versatility of flash is already being used.
Beta means "feature complete, but has bugs". The windows version was a beta. Now they squashed enough bugs that they feel comfortable removing the "beta" tag. The whole "problem" (if you want to call it that) is that they didn't have os x or linux versions in beta, not that they moved the one platform that was beta to gold.
Modern mass produced paper is comparatively low quality and has a much higher acid content than older paper, thus aging much, much worse, to the point where early 20th century books are much worse off than much older ones (I assume modern high-end paper has better durability than that though, and old paper is, by definition, the high-end stuff because that's all there was). Not sure how the printer ink itself ages.
Rereading the post, I think it became unclear that the whole "versatility" thing was aimed at python having decent functional capabilities and a rather unusual OOP implementation that really highlights some of the core aspects of OOP, rather than the interactive shell (which is much better than, say, perl's, though).
I don't know how versatile ruby is in this regard, but if we're going to suggest languages rather than paradigms, like the OP asked for, I'd go with python. Which brings us to a long-winded answer to the OP, too: You can start off with the interactive shell to do small stuff, proceed to writing imperative style code as "batch shell" to "save" common interactive shell tasks, evolve into writing programs that are more complex than one-offs (which obviously can't be done as an interactive session) -- This is a very natural progression of ideas.
I implicitly suggested that you should start with imperative, then procedural programming. Those are very natural ways to do things, they are very susceptible to the "cook book" metaphor. Simple recipes are almost purely imperative. More complex recipes are either huge imperative affairs, or much simpler to read and write procedurally, with sub recipes (you refer to the sauce recipe, the side dish recipe, etc). You can also use this metaphor to good effect to highlight a difference: reproducibility. Recipes that are done "sort of like this" yield results that are inconsistent. If you mass produce, say, cakes, you do things much more precisely and consistently (irrespectively of actual quality). Boost that hundredfold, and you have computer programs, which are completely unambiguous (actually, deterministic) from the machine's perspective.
Once you got those concepts down, hopefully your students have had some calculus, and the notion of compound and higher-order functions won't be strange to them. That's when you move on to more functional aspects of python, like mapping anonymous functions to arrays, and other such ideas. Full-fledged functional support is somewhat lacking, so I'd suggest some Lisp dialect after on the second semester, to fully explore what you started before. The key issue here is that you want to rapidly highlight the advantages and disadvantages of functional vs imperative.
Choice of language matters loads too, in my opinion: Mostly, I'd try to do as much as possible on top of one single language. You can hop along from language to language too, but I'd say that keeping to one language that supports all you're trying to teach serves a great purpose: it highlights what differences are a paradigm shift, rather than mixing in the confusion of the change in syntax. This implies you need a language that supports as many paradigms as possible in as unobtrusive a way as possible.
I'd leave OOP for software engineering subjects. I'd say OOP is not so much a programming paradigm per se as it is explicit language support for a number of constructs and concepts that can be put in practice in mostly any language. More than providing more insight into how to express algorithms, it's a way to keep things tidy and avoiding excessively verbose code, so it's not an actual core CS subject.
From there, all of the languages (and even paradigms - we covered the main three) were quite a bit simpler to grasp, as you could look a little deeper into them and ask "What are we really doing here?". Stripping away the mystery of compilers and interpreters simplifies understanding dramatically.
Wrong. Assembler and imperative/procedural languages are based on the mathematical concept of a Turing Machine. Functional Programming is based on the concept of lambda calculus (which is why Lisp and Python use the keyword 'lambda' for pure anonymous functions). That Turing Machines and Lambda Calculus are equivalent is a reasonably deep mathematical result, and the associated thought processes are no different.
The MIDI music on the Wii is using sound samples. Sometimes I think people misunderstand what MIDI is. It's just raw music data, and the output can be anything. I haven't heard FM synthesized MIDI in a long time.
In particular, the whole "MOD sounds better because you have control over the samples used" argument crumbles when you're providing your own MIDI implementation/sound banks.
Implement that and you get everybody going "Damn, all my programs get so damned slow when MS Word is open" because the memory is not being made available to the other running programs to swap into. Sometimes, plans to make your product look better only do the reverse.
local user privileges are more than enough to use the computer as a zombie in a botnet.
There's police roaming the streets making sure people aren't violating my right to property or to physical integrity. There are auditors in banks making sure bank managers aren't doing anything funky with my money (even if those lost a fair bit of credibility recently...). There's plenty of people already in place being paid by governments to make sure their citizens' rights are not infringed upon. Conceptually, that there'd be a copyright police to protect the right to intellectual property is perfectly fine: it's only the ultimate logical conclusion of several other things we take for granted. The real issue at hand is that IP is treated as a right of the individual, rather than a right of society as a whole; the issue is the agenda behind the changes and the editorial lines those changes take. The issue is not that there might be a copyright police, but rather that "copyright police" is a nicer way of saying "government-paid corporate attack dog".
Still, this does not in any way invalidate my point: Enforcing rights is part of the charter of a government. Or, extending your own arguments, we'd conclude that, since there are laws on the books that provide remedy and punishment for car theft, we should just leave it for litigation, and police shouldn't do squat if they witness a car being stolen.
Why should government enforce the rights of creators?
Why should governments enforce the rights of anybody, really? Because, you know, that's exactly what they're there for. Or should we resort to mob rules to enforce rights?
My knee-jerk reaction was the same. Then I realized the Clinton reference is probably there to provide some term of comparison.
It doesn't if you don't have $2400 to spend on a copy of Mathematica.
Still false. Cf Red Hat + CentOS.
As much as I hate DRM, and as much as the analogue hole was a nice hack around it, from a pure engineering point of view, this makes sense. Why bother checking what type of display you have connected? Either it supports HDCP, or it doesn't. If it doesn't and the token is active, the image is degraded.
It does if you don't have $2400 to spend on a copy of Mathematica.
No, that only makes price, rather than freedom, matter.
Viewable source is strictly better than closed source, at least for technical reasons (and arguably for ethical ones as well). Trust me, on my day-to-day job having source code access to the vast majority of the SAP codebase (ie, everything above kernel level) makes it much, much easier to develop for it. Proper Open Source has, once again, technical advantages (especially BSD-style licenses: it's one of the best ways to make sure that the implementation of a standard is usable across the market), and the Free Software attitude also has several interesting ethical points (which is freer? BSD or GPL? Why?) All in all, despite being so cliché it's painful (here in /., that is), "Is there a F/OSS alternative?" is a very valid question on many angles.
Blizzard spent how much time making this expansion, and then it all got run through in less than 30 hours? That's nuts.
Nobody "ran it through" in under 30 hours. What some people did was say "we beat what we consider the important bits, so we call the game beat". A good analogy would perhaps be completing the Terran campaign in Starcraft and saying "I beat the game, because what matters to me is the Terran campaign". SK/Nihilum probably skipped much of the "leveling" content, decidedly skipped most instances, and rushed straight into the raid game.
The original argument was that Python dicts provide a superb implementation of hash maps. Someone answered that perhaps STL-based hash maps might compete, and I said that those were a hash function away from a full implementation. That's when you brought up IDE-generated hash functions, to which I answered that those would still be a far cry from Python's implementation. Collision resolution was simply something I know that Python has very well optimized, and why it's such a good general-purpose implementation, not making a point that it was something that happened every other request for a value.
No, that's two choices for "them", leaving "us" with two choices if they pick the wrong one.
Fine, I can accept that people have problems with having to spend all of 30 seconds entering a key code. Some people are just really lazy and stupid.
I never said I have a problem with serials. Hell, a few days ago I even mentioned that it's one of the few reasonably effective methods of copy protection. What I did in my previous post was specifically state a few reasons why DRM makes a product worse for myself as a paying customer:
When I do a full install of a game, I shouldn't have to keep the disc in the drive just so the game can validate I'm a legitimate user. There is no legitimate reason why I shouldn't be able to resell the game (or just give it away) when I'm done with it and a friend wants it. I shouldn't have to dial up the editor of the game when I want to install the game more than x many times over the course of its lifetime, and most of all I shouldn't be dependent on the license server still being up when I want to play it in 10 years' time for old times' sake!
All you have to say to that is that the DRM wouldn't be there if it weren't for the evil pirates, when there are, in fact, very few cases where DRM actually prevented pirating of a game, or a DVD, or whatever else. For example the infamous sony rootkit, which is completely innefectual when you can simply play (and rip) the affected albums under linux.
The way to get rid of it of course, is to stop encouraging piracy or making excuses for it.
Excuses? I'm not making excuses. I'm pissed at the fact that I bought Worms 4, installed it, the piece of shit wouldn't work with my soundcard, and when I uninstalled it I still had the freaking copy protection software left behind. We might argue over whether DRM is legitimate at all, but there simply is no legitimate reason why software houses get to leave it behind when I uninstall their product. And if they can't assure safe removal, they don't have the right to install it in the first place.
It might be "good enough", but "good enough" isn't "the fastest implementation available", is it?
you're still a good hash function away from an actual, usable hash map with STL. Plus, python's dicts have very fancy collision resolution, and some other such goodies.
Yes, I thought of that example as well, but figured that, even if logical and actually useful, it'd be too vulnerable to "you're not seriously shipping with debugging turned on" followed by "but you don't need to optimize code before gold". Even if those would be completely barbaric things to say, I wanted to avoid stupid arguments over them :).
And locks on a house don't protect criminals from breaking in. But I bet you a hundred dollars you still have locks on your house.
Indeed, locks don't prevent criminals from breaking in. Both DRM and locks are really meant as deterrents. The real discussion is: how effective are those deterrents? The average lock is pretty effective, since it eats away time a robber doesn't have, making exposure time much longer. Plus, most locks aren't trivial to pick and there is a degree of skill associated. Therefore, and since knocking a door down isn't necessarily feasible, you can actually physically avoid a break in rather than just delay it past the point of comfort for the robber.
In practice, breaking DRM is entirely safe for the original cracker, since there is absolutely no exposure time. Releasing the crack might cause some exposure, but once again, the exposure for the end-user is slim to none. The only associated risk is malware payload, which is why you make sure to run an anti-virus on the crack and use only releases from reputable groups (the definition of reputable being quite loose here :). Once there is one clean crack out there, the DRM is effectively defeated for all copies of the game, so it ends up producing much less effective protection than a simple lock.
And people who steal games are assholes and are ruining the gaming industry, and they should all be shot. Not to mention your hatred of companies protecting their rights is solely cause by pirates, so you too can only agree with that. So what's your point?
Bringing up piracy again and again fails to address the major point: DRM makes the product worse for the end user. Sure, developers might not produce more games, yadda yadda, but, given an actual finished game, there's absolutely nothing about DRM that makes it any better for the consumer. When I do a full install of a game, I shouldn't have to keep the disc in the drive just so the game can validate I'm a legitimate user. There is no legitimate reason why I shouldn't be able to resell the game (or just give it away) when I'm done with it and a friend wants it. I shouldn't have to dial up the editor of the game when I want to install the game more than x many times over the course of its lifetime, and most of all I shouldn't be dependent on the license server still being up when I want to play it in 10 years' time for old times' sake!