I do agree, though. Don't advocate breaking the rules. Advocate better rules.
A friend of mine had to wait two weeks for his new computer to make it from the internal IT dept to his desk. The reason? Some kind of tangled mess involving license keys that were valid, yet didn't work. Lots of time on the phone with Microsoft, and finally he got his new machine. Then he had to go and download the software he needed from various websites, and click through all the questions and license agreements to get it all installed. Total employee time taken? I don't want to know.
Meanwhile, I got my new computer, popped in my Linux disc, and used Aptitude to install my favorite software while I was having lunch. Total employee time taken? A little over one hour.
The reason I could do that is that many people have rejected the conditions that come attached to the major proprietary software packages, and given their support to free software, instead. The same can work for games, too: play the games that don't come with onerous rules, and refuse to play the games that come with too many strings attached. Breaking the rules won't solve the problem, because it doesn't give the right incentives to the producers. We don't want to break the rules, we don't want the rules to be there in the first place!
I completely agree with you that Toyota mishandled this case. As I've posted elsewhere, they did what is quite possibly the very worst thing they could have done by denying the problems and effectively saying that those who were providing them with valuable information about a possible very serious issue were lying - rather than what they should have done: everything in their power to show they were taking it seriously, investigating it with full openness, and erring on the side of safety.
Of course, that is a completely different argument from the one you were making earlier. And to be sure, I agree with you there, too: if it were possible, I would like to be certain that the car is safe, too. The reality is, though, that we just can't be certain of that.
You can say that you are only interested in normal conditions, make a comparison with aircraft, say that I misinterpreted your words, and make a good argument about Toyota having mishandled the case, and I won't disagree with you. But you have to be clear about what you want. To quote your earlier post:
``That rather sounds like cause to deny further sales of these cars until such time that they can be tested and verified as safe.''
I interpreted that as you saying you don't want Toyota to be allowed to sell cars until they can be tested and verified as safe. To me, "tested and verified as safe" means that we must have investigated every possible scenario, and concluded that none of these scenarios result in something that violates the conditions we have set for safety. And I am telling you that that is never going to happen. So if you meant something different, do please explain.
``How bloody difficult is it to shift to neutral in an automatic or put the clutch in on a manual? I can do either of these tasks in a fraction of a second when I find there's a problem.''
Not as easy as one might suppose. Driving depends a lot on trained responses, and shifting to manual is just not one of them. That means it takes conscious effort. And conscious effort is difficult when the world suddenly goes out of control - the first reaction most people have is surprise, and the second reaction usually panic. Rational thought is difficult under those circumstances.
``Isn't this taught in Driver's Ed?''
What is this Driver's Ed you speak of? My experience in California is that you can get a license if you manage to drive a car around a block or two. In the Netherlands, where I got my license, it's at least customary to take several lessons before attempting the exam, but the lessons don't cover emergency scenarios, and those certainly aren't part of the exam. Long story short, if you got this as part of your education, your education is better than what I've seen.
``That rather sounds like cause to deny further sales of these cars until such time that they can be tested and verified as safe. After all, do we expect less from other safety committees and boards? The FDA? The FAA?''
Indeed, we do. The reason is that we _cannot_ expect things to be tested and verified as safe. The first reason for that is that the number of possible interactions is infinite, so you can never test them all. You can verify a model, but that transfer completely to the Real World. We can never be CERTAIN that something is safe.
Secondly, with cars as with many other things, we actually do have certainty, and it's the certainty that they are NOT SAFE. You can get yourself killed with a car, and virtually everybody knows it. So even if it were possible to test and verify them conclusively, there would be no point, because we already know the answer.
Cars aren't 100% safe and almost certainly never will be. Water isn't 100% safe, either. We can debate where to draw the line and say good enough is good enough, but it has to be somewhere before "tested and verified as safe", because we will never get there.
``Software has no business... being in control of braking and acceleration.''
I used to think so, as well. But I've come to realize that it's not software or no software that matters. It's the result. If the result is that I'm safer, I'll take the software. So the real question then is: has the transition to software-controlled braking and acceleration improved or deteriorated safety/reliability/energy efficiency/cost-effectiveness/whatever other metrics are important?
``Dismissing user reports is what got Toyota in trouble in the first place. Keep doing that. See how far it gets you.''
Right. Nobody I know about actually has a problem with there being a defect in the vehicles. The defect should not have been there and it's a great shame that it was, but everybody understands that it happens. If it happens too often, that gives you a poor reputation, but it doesn't happen to Toyota a lot so their reputation there is good.
Where Toyota went wrong is in how they handled the incident. What they should have done was err on the side of caution, notify people of a possible issue, and encourage them to be careful and report anything that might be related to Toyota to help them investigate the issue. Only after they would have done their best to confirm the issue could they have concluded that the issue does not actually seem to occur, and even in that case they should not have told people that there is no issue, especially not the people who report experiencing it.
What they did instead was deny that there was an issue before they had properly investigated it, and effectively called the reporters of the issue liars. Calling your customers liars is a very bad idea, and doing so with those who report a rarely occurring issue not only insults them, but also deprives you of an important source of information. It's probably the very worst thing they could have done.
Figuring out the parallel between this and full disclosure in computer security is left as an exercise to the reader.
I think this sort of thing cannot be decided in general. You would have to consider the individual case.
As far as I am concerned, I believe interpersonal relations should be mutually beneficial. I wouldn't keep someone else alive just because _I_ want them to live; they have to want it as well. Similarly, I wouldn't want others to keep me alive just because I want to live. The last thing I want is for my loved ones to spend all their time, energy, and money so they can watch me suffer longer, when they could instead let me pass away and find happiness with the billions of people still alive.
``If a contractor develops a sensitive military application derived from GPL-licensed code, and that application is subsequently widely deployed within the military, does that constitute "distribution" (i.e. does it mandate disclosure of the source code to anyone who asks for it)?''
That's actually a very interesting point. Suppose you license some software to an organization under the GPL. The organization now has some of their employees work with the software. Does that constitute distribution? I.e. do these employees have a right to seeing the source code? What exactly is the definition of "ditribution"?
``Then Linux came along and somehow "closed source" became a synonym for "proprietary", and "open source" a synonym for "free" (gratis). Microsoft feeds into this by not releasing the source code to Windows. Windows would be an even stronger (proprietary) product, IMO, if the source code were available.''
``The Linux community shares some of the blame by touting libre, gratis, and "open source" in the same breath.''
Well, Linux is libre, gratis, and open source. I feel the problem is not so much with the various open source communities. People in these communities often care about their licenses and are aware of the various distinctions. It's people _outside_ the open source communities that seem to assume that "if I can get it for free, I can do whatever I want with it" - which is generally not true, neither of open source nor of closed source software.
The interesting thing is that proprietary software vendors often turn a blind eye to violations of their licensing terms - e.g. redistribution by third parties of software that is gratis but not freely redistributable. I'm sure they are also largely unaware of when this happens, but they also have a good reason for wanting to turn a blind eye: by letting people believe that they have more freedoms than they really have, they aren't driven to software that comes with fewer restrictions.
By contrast, even though open source software generally allows much more, the rights holders tend to get very upset when the few restrictions in the license are not respected, especially in the case of modifications not being made available in source code form for GPLed software. There are people who make a living prosecuting such cases. Many of them involve Linux.
So I certainly wouldn't say that the Linux community is muddying the waters here. To me, it seems that they are very clear on what is and what isn't granted as part of the license. Most GPL violations I know of are cases of the violator very obviously not abiding by the terms of the license. Had they read the license, they would have known this. Had they asked the rights holders, they would have known this. But of course, licenses are something you just click through, right? That's the way it works in the proprietary software world, anyway. So, again, it's not the Linux community that is causing the confusion.
``-No browser really has a performance advantage across multiple sites (for example Facebook is really optimized for IE for some reason)''
I think they're doing that right. Facebook really is for the (non-tech-savvy) masses these days, and that's where you will find lots of IE users.
Also, if you want to support all browsers, it makes sense to focus your optimization efforts on IE - optimizing things for other browsers is largely taken care of by the people who make them. So if you optimized for, say, Firefox, you would only be widening the gap. Helping the slowest one along makes for a more consistent experience across browsers.
The problem is that straight HTML has become relatively rare. First, it was tag soup with rare pieces of information in between, but at least that could be filtered to find the information. Nowadays, the information often isn't even there until you execute some JavaScript code. Now, I _can_ execute JavaScript code in my mind, but having that interact with the server is a bit too much of a challenge. That leaves me, every text-only browser I know of, every web crawler I know of, and probably loads of other programs in the cold. And often users of browsers other than the latest Firefox or MSIE, too.
As an old-school webmaster, I am sad to see it has come to this. Flashy, interactive pages are nice, but HTML+JavaScript+HTTP is not and has never been the right way to do it. Meanwhile, the information-to-noise ratio has gone down the drain. At least more and more people are breaking away from XMLs grasp and moving to more efficient representations, such as JSON, these days.
I think it's not so much that C programmers aren't thinking hard about memory management, array bounds, etc. I think they _do_ think hard about them, but still get them wrong. And that's really the worst possible outcome: you lose productivity because programmers are forced to think about low-level details, and still get insecure and unstable software. C is a fine programming language, but I really don't get why people insist on writing their applications in it.
``#cue all the "butbutbut that game didn't sell well because I didn't like that game, not because of the lack of DRM" comments.''
Ok, I'll take a crack at that (no pun intended).
Why would the game have sold less well because it lacked DRM, all else being equal?
It can't be because the lack of DRM meant that the game was available for free download, because, as we've seen, that goes for games with DRM, too.
So I'm back to "it didn't sell well for reasons unrelated to DRM", unless someone can point out a good reason why including DRM would have made it sell better.
Or rather, the problem is that there is support for arrays, but it's not generalized so that you can have multi-dimensional arrays or any other kind of collection with the same interface. For example, you may implement sparse arrays, and have elt(xs, 3) return the element at position 3 in xs. But you won't be able to use that with anything that expects arrays, because it will acces your elements as xs[3]. If, by contrast, elt had been a generic function, with an implementation provided for regular arrays, you could implement elt for whatever data type you came up with and have it work with everything that works on arrays.
``It's hard to place the language in any camp, because it does furnish functional programming and object-oriented features without really committing to the dogma of either one. It gives you a ton of interesting features that seem to work really well in concert''
There actually is a camp for languages like that. They're called multi-paradigm languages, and I believe a language that can elegantly express many paradigms is a Good Thing. Languages commonly considered to be multi-paradigm include Ruby, Lua, Common Lisp, and OCaml.
The other question is what portability really means.
Many people think that portability means "your code will run on multiple platforms".
With Java, I feel it is more a case of "your code will run on the Java platform".
The distinction is that, in the latter case, a lot of the facilities that have been implemented for existing platforms have to be re-implemented for the new platform. I feel a lot of effort has gone into creating things for Java that already existed outside it.
By contrast, many other programming languages attempt to fit in and play nice with whatever platform they end up being deployed on. Where Java has your programs run inside a virtual machine which is more or less the same across native platforms, other languages have you create programs that are just like the programs your native platform knows how to run. Where Java has people build functionality on the facilities provided by the virtual machine, other languages have you build functionality on the facilities provided by the native platform.
The approaches are different, and lead to a vastly different feel both during application development and when using an application developed using one approach or the other. Both approaches have their pros and cons.
Java's approach has the advantage that, absent deficiencies in the specification and bugs in the implementation, the Java platform is the same everywhere, regardless of native platform. The disadvantage is that you lose access to the native platform's facilities that are not also in the virtual platform. It also means that your software is almost certain to not really fit in with the native platform.
The other approach leaves you with access to the native platform's facilities, which is a double-edged sword. The disadvantage is that many of those will not be available on all platforms, and code that uses them will therefore be non-portable. The advantage is that you can make your software do anything that would normally be expected of an application on the native platform. Software developed using this approach will thus tend to integrate better with the native platform, and feel less foreign to users.
``It won't work, because all the crackers will have to do is emulate that distant server on your own box and route any traffic Assassin's Creed II sends through 127.0.0.1 (this is a simplification).''
That could work, but it may not be the easiest way, especially if the network protocol uses good encryption.
However, you have the binaries... so you can modify them to not require the interaction anymore.
In the end, it all depends on whether it's worth the effort. I don't know what goes on in every cracker's mind, but I can easily imagine them directing their effort elsewhere. And I can imagine would-be gamers doing the same thing. There are plenty of other games to play that don't require an active Internet connection so the game can send Chtulhu knows what to the Man.
``You must have a constant internet connection, and, if your connection breaks, the game exits. While this has angered many (and justifiably so), most writers on the topic have made an error. They think that this system, like all DRM systems in the past, will be easily broken. This article explains why, as dreadful as the system is, it does have a chance of holding hackers off long enough for the game to make its money.''
Two things, though:
1. Is there any evidence that games do generally _not_ make their money if they lack strong DRM schemes?
2. What evidence is there to support the notion that this DRM scheme will make the suppliers more money?
Although I don't have any evidence to support any claims, it seems clear that implementing any DRM scheme has its costs. First of all, there is the cost of implementation. Then there is the potential of lost customers: people who will be angered by the scheme, or people who buy your product, only to find they can't get it to work, and then return it. I've seen both happen multiple times. Finally, assuming your DRM scheme manages to restrict distribution and use, that means your product has fewer users. That can be a Bad Thing for your sales, especially when network effects come into play.
With several things speaking against an invasive yet effective DRM scheme making you more money, I'm really curious how the numbers turn out in practice.
I wouldn't be too surprised, actually. Oracle pushes Linux a lot. Now that they own ZFS, they could actually contribute that to Linux. Having said that, I am not sure how much of a benefit that would be to them - how much does their database depend on the characteristics of the filesystem?
``So the lesson here is one should not put too much stock on arguments about static vs. dynamic linking, linking vs. network protocols, or other such technical details, because judges will most likely find that none of those details are really the essential issue.''
That makes sense to me. If you use functionality provided by other code in your own, does it really matter if that code is exposed to yours as an.so file, a.a file, a.rb file, or even an executable which you communicate with over pipes or sockets? There is an interface there which you use. If you only want to restrict "linking", where do you draw the line?
On the other hand, let's remember that this is about copyright. You can write in your license whatever you want, but that doesn't mean you necessarily get it. If, for example, I put an executable on my machine that listens for TCP connections and allows other programs to perform certain computations that way, I can write in my copyright license grant that programs that use this interface comply with certain conditions I stipulate - but it is not clear to me that people using the interface would be bound by the license, since they don't seem to be doing anything that copyright restricts.
From there on, things get complicated. Suppose, now, that I make the executable available available under a license that says "if you use this in your program, and you distribute your program, you must make the source code of your program avaialble under the terms of the GPL". The license otherwise allows you to put my executable on your computer and distribute it to others. So you can now run it there and connect to it there. Can you distribute your program to others, under any terms you wish? It's your work, so it would seem to me that you can. Can you distribute my program to others? The license says you can. But since your program depends on my program, and the license to my program says you must make your source available under the GPL, that does seem to restrict your "any terms you wish". I can see arguments for both positions here.
Actually, I've heard on the radio that some researchers (didn't catch their names) have recently demonstrated that the probability of the coin landing with in the same orientation it started with is slightly higher than the probability of landing the other way. And you can train yourself to influence the probability. So 50/50... probably close, but not necessarily, and definitely not for every coin and every person.
Slashdot Mirror
I do agree, though. Don't advocate breaking the rules. Advocate better rules.
A friend of mine had to wait two weeks for his new computer to make it from the internal IT dept to his desk. The reason? Some kind of tangled mess involving license keys that were valid, yet didn't work. Lots of time on the phone with Microsoft, and finally he got his new machine. Then he had to go and download the software he needed from various websites, and click through all the questions and license agreements to get it all installed. Total employee time taken? I don't want to know.
Meanwhile, I got my new computer, popped in my Linux disc, and used Aptitude to install my favorite software while I was having lunch. Total employee time taken? A little over one hour.
The reason I could do that is that many people have rejected the conditions that come attached to the major proprietary software packages, and given their support to free software, instead. The same can work for games, too: play the games that don't come with onerous rules, and refuse to play the games that come with too many strings attached. Breaking the rules won't solve the problem, because it doesn't give the right incentives to the producers. We don't want to break the rules, we don't want the rules to be there in the first place!
I completely agree with you that Toyota mishandled this case. As I've posted elsewhere, they did what is quite possibly the very worst thing they could have done by denying the problems and effectively saying that those who were providing them with valuable information about a possible very serious issue were lying - rather than what they should have done: everything in their power to show they were taking it seriously, investigating it with full openness, and erring on the side of safety.
Of course, that is a completely different argument from the one you were making earlier. And to be sure, I agree with you there, too: if it were possible, I would like to be certain that the car is safe, too. The reality is, though, that we just can't be certain of that.
You can say that you are only interested in normal conditions, make a comparison with aircraft, say that I misinterpreted your words, and make a good argument about Toyota having mishandled the case, and I won't disagree with you. But you have to be clear about what you want. To quote your earlier post:
``That rather sounds like cause to deny further sales of these cars until such time that they can be tested and verified as safe.''
I interpreted that as you saying you don't want Toyota to be allowed to sell cars until they can be tested and verified as safe. To me, "tested and verified as safe" means that we must have investigated every possible scenario, and concluded that none of these scenarios result in something that violates the conditions we have set for safety. And I am telling you that that is never going to happen. So if you meant something different, do please explain.
When will you be running for president? I'll support your health care reform.
``How bloody difficult is it to shift to neutral in an automatic or put the clutch in on a manual? I can do either of these tasks in a fraction of a second when I find there's a problem.''
Not as easy as one might suppose. Driving depends a lot on trained responses, and shifting to manual is just not one of them. That means it takes conscious effort. And conscious effort is difficult when the world suddenly goes out of control - the first reaction most people have is surprise, and the second reaction usually panic. Rational thought is difficult under those circumstances.
``Isn't this taught in Driver's Ed?''
What is this Driver's Ed you speak of? My experience in California is that you can get a license if you manage to drive a car around a block or two. In the Netherlands, where I got my license, it's at least customary to take several lessons before attempting the exam, but the lessons don't cover emergency scenarios, and those certainly aren't part of the exam. Long story short, if you got this as part of your education, your education is better than what I've seen.
``That rather sounds like cause to deny further sales of these cars until such time that they can be tested and verified as safe. After all, do we expect less from other safety committees and boards? The FDA? The FAA?''
Indeed, we do. The reason is that we _cannot_ expect things to be tested and verified as safe. The first reason for that is that the number of possible interactions is infinite, so you can never test them all. You can verify a model, but that transfer completely to the Real World. We can never be CERTAIN that something is safe.
Secondly, with cars as with many other things, we actually do have certainty, and it's the certainty that they are NOT SAFE. You can get yourself killed with a car, and virtually everybody knows it. So even if it were possible to test and verify them conclusively, there would be no point, because we already know the answer.
Cars aren't 100% safe and almost certainly never will be. Water isn't 100% safe, either. We can debate where to draw the line and say good enough is good enough, but it has to be somewhere before "tested and verified as safe", because we will never get there.
``Software has no business ... being in control of braking and acceleration.''
I used to think so, as well. But I've come to realize that it's not software or no software that matters. It's the result. If the result is that I'm safer, I'll take the software. So the real question then is: has the transition to software-controlled braking and acceleration improved or deteriorated safety/reliability/energy efficiency/cost-effectiveness/whatever other metrics are important?
``Dismissing user reports is what got Toyota in trouble in the first place. Keep doing that. See how far it gets you.''
Right. Nobody I know about actually has a problem with there being a defect in the vehicles. The defect should not have been there and it's a great shame that it was, but everybody understands that it happens. If it happens too often, that gives you a poor reputation, but it doesn't happen to Toyota a lot so their reputation there is good.
Where Toyota went wrong is in how they handled the incident. What they should have done was err on the side of caution, notify people of a possible issue, and encourage them to be careful and report anything that might be related to Toyota to help them investigate the issue. Only after they would have done their best to confirm the issue could they have concluded that the issue does not actually seem to occur, and even in that case they should not have told people that there is no issue, especially not the people who report experiencing it.
What they did instead was deny that there was an issue before they had properly investigated it, and effectively called the reporters of the issue liars. Calling your customers liars is a very bad idea, and doing so with those who report a rarely occurring issue not only insults them, but also deprives you of an important source of information. It's probably the very worst thing they could have done.
Figuring out the parallel between this and full disclosure in computer security is left as an exercise to the reader.
``Your life is worth your salary.''
Actually, my life is worth a lot more than that. The boss only pays for what I give him, but there is a lot more I do in life.
I think this sort of thing cannot be decided in general. You would have to consider the individual case.
As far as I am concerned, I believe interpersonal relations should be mutually beneficial. I wouldn't keep someone else alive just because _I_ want them to live; they have to want it as well. Similarly, I wouldn't want others to keep me alive just because I want to live. The last thing I want is for my loved ones to spend all their time, energy, and money so they can watch me suffer longer, when they could instead let me pass away and find happiness with the billions of people still alive.
``If a contractor develops a sensitive military application derived from GPL-licensed code, and that application is subsequently widely deployed within the military, does that constitute "distribution" (i.e. does it mandate disclosure of the source code to anyone who asks for it)?''
That's actually a very interesting point. Suppose you license some software to an organization under the GPL. The organization now has some of their employees work with the software. Does that constitute distribution? I.e. do these employees have a right to seeing the source code? What exactly is the definition of "ditribution"?
``Then Linux came along and somehow "closed source" became a synonym for "proprietary", and "open source" a synonym for "free" (gratis). Microsoft feeds into this by not releasing the source code to Windows. Windows would be an even stronger (proprietary) product, IMO, if the source code were available.''
Actually, Microsoft does make the source code of Windows available. For example, the Chinese government has access to the source code of Windows. Other governments, some businesses, and various individuals (outside Microsoft, too) also have access.
``The Linux community shares some of the blame by touting libre, gratis, and "open source" in the same breath.''
Well, Linux is libre, gratis, and open source. I feel the problem is not so much with the various open source communities. People in these communities often care about their licenses and are aware of the various distinctions. It's people _outside_ the open source communities that seem to assume that "if I can get it for free, I can do whatever I want with it" - which is generally not true, neither of open source nor of closed source software.
The interesting thing is that proprietary software vendors often turn a blind eye to violations of their licensing terms - e.g. redistribution by third parties of software that is gratis but not freely redistributable. I'm sure they are also largely unaware of when this happens, but they also have a good reason for wanting to turn a blind eye: by letting people believe that they have more freedoms than they really have, they aren't driven to software that comes with fewer restrictions.
By contrast, even though open source software generally allows much more, the rights holders tend to get very upset when the few restrictions in the license are not respected, especially in the case of modifications not being made available in source code form for GPLed software. There are people who make a living prosecuting such cases. Many of them involve Linux.
So I certainly wouldn't say that the Linux community is muddying the waters here. To me, it seems that they are very clear on what is and what isn't granted as part of the license. Most GPL violations I know of are cases of the violator very obviously not abiding by the terms of the license. Had they read the license, they would have known this. Had they asked the rights holders, they would have known this. But of course, licenses are something you just click through, right? That's the way it works in the proprietary software world, anyway. So, again, it's not the Linux community that is causing the confusion.
``-No browser really has a performance advantage across multiple sites (for example Facebook is really optimized for IE for some reason)''
I think they're doing that right. Facebook really is for the (non-tech-savvy) masses these days, and that's where you will find lots of IE users.
Also, if you want to support all browsers, it makes sense to focus your optimization efforts on IE - optimizing things for other browsers is largely taken care of by the people who make them. So if you optimized for, say, Firefox, you would only be widening the gap. Helping the slowest one along makes for a more consistent experience across browsers.
The problem is that straight HTML has become relatively rare. First, it was tag soup with rare pieces of information in between, but at least that could be filtered to find the information. Nowadays, the information often isn't even there until you execute some JavaScript code. Now, I _can_ execute JavaScript code in my mind, but having that interact with the server is a bit too much of a challenge. That leaves me, every text-only browser I know of, every web crawler I know of, and probably loads of other programs in the cold. And often users of browsers other than the latest Firefox or MSIE, too.
As an old-school webmaster, I am sad to see it has come to this. Flashy, interactive pages are nice, but HTML+JavaScript+HTTP is not and has never been the right way to do it. Meanwhile, the information-to-noise ratio has gone down the drain. At least more and more people are breaking away from XMLs grasp and moving to more efficient representations, such as JSON, these days.
I think it's not so much that C programmers aren't thinking hard about memory management, array bounds, etc. I think they _do_ think hard about them, but still get them wrong. And that's really the worst possible outcome: you lose productivity because programmers are forced to think about low-level details, and still get insecure and unstable software. C is a fine programming language, but I really don't get why people insist on writing their applications in it.
``#cue all the "butbutbut that game didn't sell well because I didn't like that game, not because of the lack of DRM" comments.''
Ok, I'll take a crack at that (no pun intended).
Why would the game have sold less well because it lacked DRM, all else being equal?
It can't be because the lack of DRM meant that the game was available for free download, because, as we've seen, that goes for games with DRM, too.
So I'm back to "it didn't sell well for reasons unrelated to DRM", unless someone can point out a good reason why including DRM would have made it sell better.
But is MKV actually better? Just because Ogg isn't perfect doesn't mean it's the worst.
Or rather, the problem is that there is support for arrays, but it's not generalized so that you can have multi-dimensional arrays or any other kind of collection with the same interface. For example, you may implement sparse arrays, and have elt(xs, 3) return the element at position 3 in xs. But you won't be able to use that with anything that expects arrays, because it will acces your elements as xs[3]. If, by contrast, elt had been a generic function, with an implementation provided for regular arrays, you could implement elt for whatever data type you came up with and have it work with everything that works on arrays.
Pretty much like "func &" in sh, yes.
And why not? There are a lot of good ideas in the Bourne shell and its successors.
``It's hard to place the language in any camp, because it does furnish functional programming and object-oriented features without really committing to the dogma of either one. It gives you a ton of interesting features that seem to work really well in concert''
There actually is a camp for languages like that. They're called multi-paradigm languages, and I believe a language that can elegantly express many paradigms is a Good Thing. Languages commonly considered to be multi-paradigm include Ruby, Lua, Common Lisp, and OCaml.
The other question is what portability really means.
Many people think that portability means "your code will run on multiple platforms".
With Java, I feel it is more a case of "your code will run on the Java platform".
The distinction is that, in the latter case, a lot of the facilities that have been implemented for existing platforms have to be re-implemented for the new platform. I feel a lot of effort has gone into creating things for Java that already existed outside it.
By contrast, many other programming languages attempt to fit in and play nice with whatever platform they end up being deployed on. Where Java has your programs run inside a virtual machine which is more or less the same across native platforms, other languages have you create programs that are just like the programs your native platform knows how to run. Where Java has people build functionality on the facilities provided by the virtual machine, other languages have you build functionality on the facilities provided by the native platform.
The approaches are different, and lead to a vastly different feel both during application development and when using an application developed using one approach or the other. Both approaches have their pros and cons.
Java's approach has the advantage that, absent deficiencies in the specification and bugs in the implementation, the Java platform is the same everywhere, regardless of native platform. The disadvantage is that you lose access to the native platform's facilities that are not also in the virtual platform. It also means that your software is almost certain to not really fit in with the native platform.
The other approach leaves you with access to the native platform's facilities, which is a double-edged sword. The disadvantage is that many of those will not be available on all platforms, and code that uses them will therefore be non-portable. The advantage is that you can make your software do anything that would normally be expected of an application on the native platform. Software developed using this approach will thus tend to integrate better with the native platform, and feel less foreign to users.
``It won't work, because all the crackers will have to do is emulate that distant server on your own box and route any traffic Assassin's Creed II sends through 127.0.0.1 (this is a simplification).''
That could work, but it may not be the easiest way, especially if the network protocol uses good encryption.
However, you have the binaries ... so you can modify them to not require the interaction anymore.
In the end, it all depends on whether it's worth the effort. I don't know what goes on in every cracker's mind, but I can easily imagine them directing their effort elsewhere. And I can imagine would-be gamers doing the same thing. There are plenty of other games to play that don't require an active Internet connection so the game can send Chtulhu knows what to the Man.
``You must have a constant internet connection, and, if your connection breaks, the game exits. While this has angered many (and justifiably so), most writers on the topic have made an error. They think that this system, like all DRM systems in the past, will be easily broken. This article explains why, as dreadful as the system is, it does have a chance of holding hackers off long enough for the game to make its money.''
Two things, though:
1. Is there any evidence that games do generally _not_ make their money if they lack strong DRM schemes?
2. What evidence is there to support the notion that this DRM scheme will make the suppliers more money?
Although I don't have any evidence to support any claims, it seems clear that implementing any DRM scheme has its costs. First of all, there is the cost of implementation. Then there is the potential of lost customers: people who will be angered by the scheme, or people who buy your product, only to find they can't get it to work, and then return it. I've seen both happen multiple times. Finally, assuming your DRM scheme manages to restrict distribution and use, that means your product has fewer users. That can be a Bad Thing for your sales, especially when network effects come into play.
With several things speaking against an invasive yet effective DRM scheme making you more money, I'm really curious how the numbers turn out in practice.
I wouldn't be too surprised, actually. Oracle pushes Linux a lot. Now that they own ZFS, they could actually contribute that to Linux. Having said that, I am not sure how much of a benefit that would be to them - how much does their database depend on the characteristics of the filesystem?
``So the lesson here is one should not put too much stock on arguments about static vs. dynamic linking, linking vs. network protocols, or other such technical details, because judges will most likely find that none of those details are really the essential issue.''
That makes sense to me. If you use functionality provided by other code in your own, does it really matter if that code is exposed to yours as an .so file, a .a file, a .rb file, or even an executable which you communicate with over pipes or sockets? There is an interface there which you use. If you only want to restrict "linking", where do you draw the line?
On the other hand, let's remember that this is about copyright. You can write in your license whatever you want, but that doesn't mean you necessarily get it. If, for example, I put an executable on my machine that listens for TCP connections and allows other programs to perform certain computations that way, I can write in my copyright license grant that programs that use this interface comply with certain conditions I stipulate - but it is not clear to me that people using the interface would be bound by the license, since they don't seem to be doing anything that copyright restricts.
From there on, things get complicated. Suppose, now, that I make the executable available available under a license that says "if you use this in your program, and you distribute your program, you must make the source code of your program avaialble under the terms of the GPL". The license otherwise allows you to put my executable on your computer and distribute it to others. So you can now run it there and connect to it there. Can you distribute your program to others, under any terms you wish? It's your work, so it would seem to me that you can. Can you distribute my program to others? The license says you can. But since your program depends on my program, and the license to my program says you must make your source available under the GPL, that does seem to restrict your "any terms you wish". I can see arguments for both positions here.
Actually, I've heard on the radio that some researchers (didn't catch their names) have recently demonstrated that the probability of the coin landing with in the same orientation it started with is slightly higher than the probability of landing the other way. And you can train yourself to influence the probability. So 50/50 ... probably close, but not necessarily, and definitely not for every coin and every person.