Imagine the outcry if the courts were to legalize patents on English prose. Suddenly, you could get a "literary patent" on novels employing a particular kind of plot twist, on news stories using a particular interview technique, or on legal briefs using a particular style of argumentation. Publishing books, papers, or articles would expose authors to potential liability for patent infringement. To protect themselves, writers would be forced to send their work to a patent lawyer before publication and to re-write passages found to be infringing a literary patent.
Sounds like a plot element from a Jasper Fforde novel.
Good to hear. If PowerShell becomes vaguely universal on Windows (which, given that it wasn't installed by default up through Vista AFAIK, might now happen as soon as two more Windows versions from now), it might be actually useful for system automation.
Plus, it will become more possible to actually have a meaningful discussion about the merits of the competing OSes' CLIs, and see whether the *nix-style shell actually is as superior as I think it is. With the obvious inferiority of cmd.exe (which is virtually identical to command.com in at least 80% of relevant respects), and the near-universal unavailability of PowerShell, it's been impossible to talk about the subject...
it's somewhat like going to a restaurant, either you return it to the kitchen or you eat it. RMS insists I'm not free unless I get to go into the kitchen and give the dish a do-over. Don't tip, don't return and give bad reviews seems to work for the rest of the world.
The analogy breaks down in that you can readily go elsewhere, or even just eat your own food, if you don't like the particular restaurant, and refraining from giving them your business won't affect the rest of your life - but you can't necessarily do the same (go to another vendor or write it yourself) with nearly the same facility in the software world, and refusing to give one vendor business can be difficult or impossible if you have to work with other people who *do* give them business (because of file-format compatibility and so forth).
If it were as practical to "vote with your wallet" that way for software as it is for e.g. restaurants, then your analogy would be a pretty good argument. The trouble is that it isn't that practical, and hasn't been for a very long time - if, indeed, it ever was.
convincing fortune 500 CIO's that getting paid for your product is fundamentally evil is a hard sell.
Getting paid for your product is not fundamentally evil.
There are plenty of other things which are, however, and Microsoft does quite a few of them. Some of them are listed in TFA. "Charging for its software" is not on that list.
Not when they are a one of hundreds of vendors providing DRM-capable playback devices.
A computer is not just a playback device. There are very few "vendors" providing computer OSes, on the level under discussion, and Microsoft is by far the most dominant.
Microsoft includes DRM software in their operating systems to allow consumers to view certain media on their computers. Microsoft didn't put the DRM on the media, the DRM doesn't affect your personal files, and Windows sure as hell isn't enabling anything, unless you're talking about "enabling" a consumer to view something they have legally purchased.
Yes, it is.
It's enabling the people who put the DRM on that media to restrict what I can do with the media on my computer. (Or, well, not my computer - I don't run Windows, for this reason among others - but the same principle applies.) Without Microsoft's cooperation, they wouldn't be able to restrict it that way.
You are arguing that the only alternative is to not have the media be playable at all. This is nonsense. It would be entirely possible to have software which can play the media and neither actively cooperate with nor actively ignore the DRMers' attempts to restrict it; indeed, that would have been the path of least resistance, the easiest way to go.
Microsoft chose to actively cooperate with the aims of the DRM crowd, instead of either rejecting them or remaining neutral. Because they are actively cooperating in the DRM effort, it is entirely legitimate to blame them, in addition to blaming the people who put the DRM on the media itself.
The argument for DRM is that content producers should be able to do what they want with their content, including hiding it behind DRM if they believe it will protect their profits, regardless of whether it will actually protect their profits, and that you don't have the moral authority to tell them that they can't produce content under their own terms -- that you'll outright change the terms to your favour after they produce it.
And the counterargument is that the "should" you cite is not enough to outweigh or otherwise override the fact that the content producers "should" not be able to take control over, or otherwise dictate, what people can do with their own computers.
The law already restricts what people are *permitted* to do. DRM goes beyond that and tries to restrict what people are *able* to do. That's a very significant distinction, and a potentially very significant line to cross.
DRM may infringe on rights (which is actively being argued in court these days), but to simply provide software that allows current laws to be enforced is not evil.
I think I disagree.
Or rather, I would say that if you voluntarily (as opposed to under coercion and protest) cooperate with the attempts to do evil, you are yourself doing evil. Thus, if DRM itself is evil (as many seem to think), then providing software which *has no other purpose than to make DRM more possible* is necessarily also evil.
Further, it is most certainly NOT the responsibility of the software vendor to aid you in circumventing the wishes of the content owner (ie: by providing a system that can decode DRM-encumbered content without enforcing restrictions).
Perhaps not. But it's also (and at least equally) not the responsibility of the software vendor to aid the content owner in imposing their wishes on you.
Microsoft should not be colluding with the content owners to enforce DRM. If the content owners want to use DRM, they should have to do all the necessary work for that themselves.
Neither Microsoft nor the content owners, nor for that matter the law, should be able to dictate what someone can or can not do with their own computer; only the technical limitations of the hardware and software should be able to do that. It might be legitimate for the law to constrain what someone *may* do, but it is definitely not legitimate for it to constrain what they *can* do. DRM attempts to constrain what people *can* do, not just what they are allowed to do, and in doing so it steps over the line.
This will become more of an issue if copyright on DRMed material is ever allowed to expire, such that the material enters the public domain, but is still inaccessible because it's covered by the DRM...
This is bad argument. What constitutes a "real" complaint?
Requiring Battlenet accounts for each copy of SC2 sold
This is how software works in the modern age.
It shouldn't be.
and no ability to resell SC2
Just don't put other games on the account you use with SC2 and you can sell the game+account.
Why should one person *have* to have multiple accounts, just to retain an option they've had since the beginning of the industry?
For that matter, why should someone *have* to have an account at all in order to play?
With WoW it makes sense; the design of the game inherently requires connecting through a central server and uniquely identifying the connector. (It would have been possible to design in a locally-hosted single-player mode, but it wouldn't have made a lot of sense, and it wasn't done in any case.)
As historical network play has demonstrated in past Blizzard RTSes, the game design does *not* inherently require connecting through a central server, much less uniquely and permanently identifying the connector.
no ability to hold large LAN events without cooperation of Blizzard
I don't see that anywhere. Blizzard will try to sell "LAN party services", of course. But you can organize whatever games you want however you want.
I think he's talking about the fact that, if Battle.net - or even this particular incarnation of it, which includes compatibility with whatever exact protocols the game speaks - goes down or is taken down, network play becomes impossible. As long as Blizzard remains a going concern and plays nice, this won't be an issue - but if it ever goes under, or if its data centers go haywire, or if it decides it doesn't want to support the game anymore, then it's suddenly a major issue for anyone who wants to play at that point.
Alternately, he might be referring to something mentioned in the comments on the other recent Blizzard story - large numbers of people connecting from a location which has them all show up as a single IP, and then that IP getting banned for having too many simultaneous connections...
Or something else I haven't though of, in which case hopefully he'll explain.
In the original Diablo, only one of the three classes was strictly mana-dependent: the Sorcerer. The Warrior and the Rogue were dependent on other factors (primarily Health, and in the Rogue's case arrows), and could get away with paying little or no attention to mana.
In Diablo II, every single class was mana-dependent; all of them relied heavily on their active abilities, and all of those required mana. Ignoring mana would inevitably get you killed in fairly short order.
Warcraft III's heroes also tended to be mana-dependent (or so, at least, the "games built on top of War3" such as DotA seem to indicate), though perhaps not to the same extent, since those heroes were far from the only means of doing things in the game.
World of Warcraft has moved away from this somewhat, in that the (very differently designed) Warrior and Rogue now rely on Rage and Energy respectively, but it's still by and large a very mana-dependent game; ignoring mana will still get you very dead. For many classes this makes sense (Mage, Priest, Warlock, Shaman, Druid), but for others it doesn't necessarily fit as well; it's arguably also odd that intuitively mana-dependent classes so far outnumber ones which would not be.
Will Diablo III have any non-mana-dependent classes?
By contrast, in the organization where I cut my other-people's-computers admin teeth, we specifically avoided moving computers to follow people except in special cases (mainly, when the person involved was high in the hierarchy and didn't want to hear a "no"). That might explain part of why you consider this a more viable solution, whereas I wouldn't touch it with a ten-foot pole if I had a choice in the matter.
Why in the world would there be a DNS entry for every workstation?
And you want to reconfigure (or, more likely, reimage) the machine if it gets moved anyway. Renaming it is not a difficult thing to add in at that point.
I agree about the database-record-ID point, but the inconvenience of having to do a database lookup (or equivalent) every time you want to figure out "okay, which machine is this?" (or the reverse) outweighs the inconveniences of having to update the workstation name on the comparatively rare occasions when the machine gets moved. Include the unique ID (and I agree that the asset tag is a good choice) in the name, yes, but include the location there too.
Not to mention things like remote-control sessions for helpdesk purposes, and assigning images for "on next reboot", and associating applications for installation, and so forth. Being able to easily tell from the name which machines are which can be very helpful indeed.
I don't advocate naming the computer after the user, though - at least not when there's a more useful "location" to provide. For laptops, which get carried around from place to place, sometimes the name of the assigned user is the most helpful location information you can be certain of.
At my previous employer, we kept three pieces of information in the workstation name (we never used them as hostnames):
* The facility/complex/campus/whatever-you-call-it to which the machine was assigned, in the form of a two-digit ID number. * Where at that facility to look for the machine, in the form of either the username of the assigned user (in the case of non-generic laptops) or a mostly-freeform string which was left up to the discretion of the tech assigned to that facility. * The barcode number which constituted the asset tag for that particular computer.
All three of these were useful to be able to see at a glance. There were some issues with the "location" part not being updated, but since by and large only techs were allowed to move the equipment from room to room, and since laptops had to be turned in to the tech when the assignee left, there really weren't that many of them; the convenience of being able to know immediately from a computer name where it was located, or from a computer's location what its name would be, far outweighed any such problems.
I don't know if I'd necessarily use that exact system if designing a naming scheme for an organization of my own, but I would very likely use something similar, for the reasons cited above. It's certainly far better than most of the others I've seen suggested so far, at least for an "organizational deployment" sort of environment. (A home network, or a group of servers, could be very much another story.)
This is an example of why using (or, at least, relying on - which in practice is the same thing) actual data as primary keys is a bad idea. Even if there data contains something which is supposed to be guaranteed unique and is theoretically never supposed to change, you should generate an arbitrary unique key and use that as the primary ID; that avoids so many potential pitfalls from use cases, such as this one, which weren't thought of in advance.
Care to read what RMS says [fsf.org] on the subject? He says he specifically put in the "anti-TiVo" clause because while you can get the source code you can NOT run it on the TiVo.
Yes, exactly.
The entire point of the GPL is to make sure that people can edit the software they use (refer back to the semi-famous "RMS and a bad printer driver" story), or more particularly, to guarantee them some basic freedoms about what they can do with that software. If, after editing, they can't use it anymore, then that's a problem.
What those edits involve has absolutely no bearing on that central point.
If TiVo didn't want to have people able to edit the code running on the TiVo unit, they shouldn't have released it under the GPL - including, if necessary, not re-using already-GPLed code from other people. They discovered a loophole by which they could fulfill the letter of the GPL but not its intent or spirit - allow people to edit the code, but not run it. RMS quite naturally wanted to close that loophole, to prevent them or others from doing the same thing in the future; the GPLv3 was his way of doing so.
(And no, "but you *can* edit it, you just can't run it afterwards" doesn't fly - because at that point, you're no longer editing the code you *are* running, you're editing code you *aren't* running and never will be able to run.)
How does XKCD work as a book? Half of the joke is only seen when you hover over the cartoon.
According to the NYT article which is the (real) FA, the mouse-over text will appear in fine print in place of the traditional print comic's "copyright someone-or-another YYYY-MM-DD" string.
This does, apparently, also mean that the book itself is being released without copyright, though exact details weren't provided.
If that happens way more than people realize, then people are unaware of these sites. If people are unaware of these sites, then they don't visit them, in which case they cannot be competition to the AP.
Not necessarily.
In order for someone to realize that that has happened, they need to both see the story on the blog and see the story attributed to the AP. I don't find it particularly implausible that many or most people reading such a blog might not read the AP directly; I'm not positive I've ever read a story directly from the AP, as opposed to a citation of an AP story by someone else. (A case where their prominence works against them; many people (and more news organizations) cite AP reports in their own stories, but few people - other than those doing the citing - seem to feel the need to read the originals.)
If most people see the story in only one place, then most people won't realize that the story is being copied wholesale. If the one place where they see the story is the AP and they don't visit the blogs, that's fine; if the one place where they see the story is the blog and they don't visit the AP, then that's not so fine. The argument would be that the latter is what is happening.
According to TFA, the blue tint disappeared within a week, and the regained mobility didn't manifest till the sixth week (at which point they killed the rat to dissect it) - so I doubt that this will be a long-term problem.
They did mention that they were surprised, upon dissection, to find out that the spinal cord was still blue even at the six-week mark. I imagine that even that would go away with time, though.
But as far as I've ever seen, PowerShell doesn't come "set up and ready to go" on a new Windows install; you have to go out and get (and install) it yourself. (Thus, "Windows doesn't... come with" it.)
Combined with the near total lack of publicity and marketing for PowerShell, that means the vast majority of normal users will never even realize it exists, much less make use of it. It also means that people writing scripts to run on Windows can't rely on its being available for any given machine, whereas they can be quite certain that a POSIX-compatible shell (and, very probably, bash itself) will be available on any *nix machine.
Combined, these two points mean PowerShell verges on being useless for most purposes. If it were near-universally installed, that would be different; however, since it isn't, it might as well not exist.
You know what I want? A tag based filesystem. WTF should I have to manage directories?
Interesting you should mention that on this particular story.
I no longer use Gmail's Web interface, but last I heard, they had pretty much ignored the concept of folders/directories per se, choosing instead to present "views" (not their term, IIRC) based on user-defined searches. (This leads to annoyances such as their refusal to store more than one copy of a message, as determined by Message-ID, but that's another topic.) I remember having also been able to tag messages explicitly as one thing or another, and do so in an automatic fashion based on pattern-matching rules; having done so, you can then define a "view" for all messages with that tag.
I don't like Gmail's interface, for various reasons, but this underlying idea is interesting; it looks like much the same type of thing you're asking for, and I think it's the first "live" implementation of something like that I've ever come across.
I don't know if they've implemented this same kind of taggability and "view"ability for Google Apps documents (I don't use that service at all), but it wouldn't surprise me if it were possible.
Furthermore, given the recently-reported upcoming "Chrome OS", it's not impossible that you'll see something resembling a filesystem with this capability before terribly long...
Slashdot Mirror
From TFA:
Imagine the outcry if the courts were to legalize patents on English prose. Suddenly, you could get a "literary patent" on novels employing a particular kind of plot twist, on news stories using a particular interview technique, or on legal briefs using a particular style of argumentation. Publishing books, papers, or articles would expose authors to potential liability for patent infringement. To protect themselves, writers would be forced to send their work to a patent lawyer before publication and to re-write passages found to be infringing a literary patent.
Sounds like a plot element from a Jasper Fforde novel.
Good to hear. If PowerShell becomes vaguely universal on Windows (which, given that it wasn't installed by default up through Vista AFAIK, might now happen as soon as two more Windows versions from now), it might be actually useful for system automation.
Plus, it will become more possible to actually have a meaningful discussion about the merits of the competing OSes' CLIs, and see whether the *nix-style shell actually is as superior as I think it is. With the obvious inferiority of cmd.exe (which is virtually identical to command.com in at least 80% of relevant respects), and the near-universal unavailability of PowerShell, it's been impossible to talk about the subject...
100% agree. Another excellently insightful post. Mods, please take notice.
it's somewhat like going to a restaurant, either you return it to the kitchen or you eat it. RMS insists I'm not free unless I get to go into the kitchen and give the dish a do-over. Don't tip, don't return and give bad reviews seems to work for the rest of the world.
The analogy breaks down in that you can readily go elsewhere, or even just eat your own food, if you don't like the particular restaurant, and refraining from giving them your business won't affect the rest of your life - but you can't necessarily do the same (go to another vendor or write it yourself) with nearly the same facility in the software world, and refusing to give one vendor business can be difficult or impossible if you have to work with other people who *do* give them business (because of file-format compatibility and so forth).
If it were as practical to "vote with your wallet" that way for software as it is for e.g. restaurants, then your analogy would be a pretty good argument. The trouble is that it isn't that practical, and hasn't been for a very long time - if, indeed, it ever was.
convincing fortune 500 CIO's that getting paid for your product is fundamentally evil is a hard sell.
Getting paid for your product is not fundamentally evil.
There are plenty of other things which are, however, and Microsoft does quite a few of them. Some of them are listed in TFA. "Charging for its software" is not on that list.
Not when they are a one of hundreds of vendors providing DRM-capable playback devices.
A computer is not just a playback device. There are very few "vendors" providing computer OSes, on the level under discussion, and Microsoft is by far the most dominant.
Microsoft includes DRM software in their operating systems to allow consumers to view certain media on their computers. Microsoft didn't put the DRM on the media, the DRM doesn't affect your personal files, and Windows sure as hell isn't enabling anything, unless you're talking about "enabling" a consumer to view something they have legally purchased.
Yes, it is.
It's enabling the people who put the DRM on that media to restrict what I can do with the media on my computer. (Or, well, not my computer - I don't run Windows, for this reason among others - but the same principle applies.) Without Microsoft's cooperation, they wouldn't be able to restrict it that way.
You are arguing that the only alternative is to not have the media be playable at all. This is nonsense. It would be entirely possible to have software which can play the media and neither actively cooperate with nor actively ignore the DRMers' attempts to restrict it; indeed, that would have been the path of least resistance, the easiest way to go.
Microsoft chose to actively cooperate with the aims of the DRM crowd, instead of either rejecting them or remaining neutral. Because they are actively cooperating in the DRM effort, it is entirely legitimate to blame them, in addition to blaming the people who put the DRM on the media itself.
The argument for DRM is that content producers should be able to do what they want with their content, including hiding it behind DRM if they believe it will protect their profits, regardless of whether it will actually protect their profits, and that you don't have the moral authority to tell them that they can't produce content under their own terms -- that you'll outright change the terms to your favour after they produce it.
And the counterargument is that the "should" you cite is not enough to outweigh or otherwise override the fact that the content producers "should" not be able to take control over, or otherwise dictate, what people can do with their own computers.
The law already restricts what people are *permitted* to do. DRM goes beyond that and tries to restrict what people are *able* to do. That's a very significant distinction, and a potentially very significant line to cross.
DRM may infringe on rights (which is actively being argued in court these days), but to simply provide software that allows current laws to be enforced is not evil.
I think I disagree.
Or rather, I would say that if you voluntarily (as opposed to under coercion and protest) cooperate with the attempts to do evil, you are yourself doing evil. Thus, if DRM itself is evil (as many seem to think), then providing software which *has no other purpose than to make DRM more possible* is necessarily also evil.
Further, it is most certainly NOT the responsibility of the software vendor to aid you in circumventing the wishes of the content owner (ie: by providing a system that can decode DRM-encumbered content without enforcing restrictions).
Perhaps not. But it's also (and at least equally) not the responsibility of the software vendor to aid the content owner in imposing their wishes on you.
Microsoft should not be colluding with the content owners to enforce DRM. If the content owners want to use DRM, they should have to do all the necessary work for that themselves.
Neither Microsoft nor the content owners, nor for that matter the law, should be able to dictate what someone can or can not do with their own computer; only the technical limitations of the hardware and software should be able to do that. It might be legitimate for the law to constrain what someone *may* do, but it is definitely not legitimate for it to constrain what they *can* do. DRM attempts to constrain what people *can* do, not just what they are allowed to do, and in doing so it steps over the line.
This will become more of an issue if copyright on DRMed material is ever allowed to expire, such that the material enters the public domain, but is still inaccessible because it's covered by the DRM...
I wish I had mod points right now.
Very well said, sir.
None of these seem like real complaints.
This is bad argument. What constitutes a "real" complaint?
Requiring Battlenet accounts for each copy of SC2 sold
This is how software works in the modern age.
It shouldn't be.
and no ability to resell SC2
Just don't put other games on the account you use with SC2 and you can sell the game+account.
Why should one person *have* to have multiple accounts, just to retain an option they've had since the beginning of the industry?
For that matter, why should someone *have* to have an account at all in order to play?
With WoW it makes sense; the design of the game inherently requires connecting through a central server and uniquely identifying the connector. (It would have been possible to design in a locally-hosted single-player mode, but it wouldn't have made a lot of sense, and it wasn't done in any case.)
As historical network play has demonstrated in past Blizzard RTSes, the game design does *not* inherently require connecting through a central server, much less uniquely and permanently identifying the connector.
no ability to hold large LAN events without cooperation of Blizzard
I don't see that anywhere. Blizzard will try to sell "LAN party services", of course. But you can organize whatever games you want however you want.
I think he's talking about the fact that, if Battle.net - or even this particular incarnation of it, which includes compatibility with whatever exact protocols the game speaks - goes down or is taken down, network play becomes impossible. As long as Blizzard remains a going concern and plays nice, this won't be an issue - but if it ever goes under, or if its data centers go haywire, or if it decides it doesn't want to support the game anymore, then it's suddenly a major issue for anyone who wants to play at that point.
Alternately, he might be referring to something mentioned in the comments on the other recent Blizzard story - large numbers of people connecting from a location which has them all show up as a single IP, and then that IP getting banned for having too many simultaneous connections...
Or something else I haven't though of, in which case hopefully he'll explain.
In the original Diablo, only one of the three classes was strictly mana-dependent: the Sorcerer. The Warrior and the Rogue were dependent on other factors (primarily Health, and in the Rogue's case arrows), and could get away with paying little or no attention to mana.
In Diablo II, every single class was mana-dependent; all of them relied heavily on their active abilities, and all of those required mana. Ignoring mana would inevitably get you killed in fairly short order.
Warcraft III's heroes also tended to be mana-dependent (or so, at least, the "games built on top of War3" such as DotA seem to indicate), though perhaps not to the same extent, since those heroes were far from the only means of doing things in the game.
World of Warcraft has moved away from this somewhat, in that the (very differently designed) Warrior and Rogue now rely on Rage and Energy respectively, but it's still by and large a very mana-dependent game; ignoring mana will still get you very dead. For many classes this makes sense (Mage, Priest, Warlock, Shaman, Druid), but for others it doesn't necessarily fit as well; it's arguably also odd that intuitively mana-dependent classes so far outnumber ones which would not be.
Will Diablo III have any non-mana-dependent classes?
And of course, as a result, your servers never die.
By contrast, in the organization where I cut my other-people's-computers admin teeth, we specifically avoided moving computers to follow people except in special cases (mainly, when the person involved was high in the hierarchy and didn't want to hear a "no"). That might explain part of why you consider this a more viable solution, whereas I wouldn't touch it with a ten-foot pole if I had a choice in the matter.
Why in the world would there be a DNS entry for every workstation?
And you want to reconfigure (or, more likely, reimage) the machine if it gets moved anyway. Renaming it is not a difficult thing to add in at that point.
I agree about the database-record-ID point, but the inconvenience of having to do a database lookup (or equivalent) every time you want to figure out "okay, which machine is this?" (or the reverse) outweighs the inconveniences of having to update the workstation name on the comparatively rare occasions when the machine gets moved. Include the unique ID (and I agree that the asset tag is a good choice) in the name, yes, but include the location there too.
Not to mention things like remote-control sessions for helpdesk purposes, and assigning images for "on next reboot", and associating applications for installation, and so forth. Being able to easily tell from the name which machines are which can be very helpful indeed.
I don't advocate naming the computer after the user, though - at least not when there's a more useful "location" to provide. For laptops, which get carried around from place to place, sometimes the name of the assigned user is the most helpful location information you can be certain of.
At my previous employer, we kept three pieces of information in the workstation name (we never used them as hostnames):
* The facility/complex/campus/whatever-you-call-it to which the machine was assigned, in the form of a two-digit ID number.
* Where at that facility to look for the machine, in the form of either the username of the assigned user (in the case of non-generic laptops) or a mostly-freeform string which was left up to the discretion of the tech assigned to that facility.
* The barcode number which constituted the asset tag for that particular computer.
All three of these were useful to be able to see at a glance. There were some issues with the "location" part not being updated, but since by and large only techs were allowed to move the equipment from room to room, and since laptops had to be turned in to the tech when the assignee left, there really weren't that many of them; the convenience of being able to know immediately from a computer name where it was located, or from a computer's location what its name would be, far outweighed any such problems.
I don't know if I'd necessarily use that exact system if designing a naming scheme for an organization of my own, but I would very likely use something similar, for the reasons cited above. It's certainly far better than most of the others I've seen suggested so far, at least for an "organizational deployment" sort of environment. (A home network, or a group of servers, could be very much another story.)
This is an example of why using (or, at least, relying on - which in practice is the same thing) actual data as primary keys is a bad idea. Even if there data contains something which is supposed to be guaranteed unique and is theoretically never supposed to change, you should generate an arbitrary unique key and use that as the primary ID; that avoids so many potential pitfalls from use cases, such as this one, which weren't thought of in advance.
Care to read what RMS says [fsf.org] on the subject? He says he specifically put in the "anti-TiVo" clause because while you can get the source code you can NOT run it on the TiVo.
Yes, exactly.
The entire point of the GPL is to make sure that people can edit the software they use (refer back to the semi-famous "RMS and a bad printer driver" story), or more particularly, to guarantee them some basic freedoms about what they can do with that software. If, after editing, they can't use it anymore, then that's a problem.
What those edits involve has absolutely no bearing on that central point.
If TiVo didn't want to have people able to edit the code running on the TiVo unit, they shouldn't have released it under the GPL - including, if necessary, not re-using already-GPLed code from other people. They discovered a loophole by which they could fulfill the letter of the GPL but not its intent or spirit - allow people to edit the code, but not run it. RMS quite naturally wanted to close that loophole, to prevent them or others from doing the same thing in the future; the GPLv3 was his way of doing so.
(And no, "but you *can* edit it, you just can't run it afterwards" doesn't fly - because at that point, you're no longer editing the code you *are* running, you're editing code you *aren't* running and never will be able to run.)
How does XKCD work as a book? Half of the joke is only seen when you hover over the cartoon.
According to the NYT article which is the (real) FA, the mouse-over text will appear in fine print in place of the traditional print comic's "copyright someone-or-another YYYY-MM-DD" string.
This does, apparently, also mean that the book itself is being released without copyright, though exact details weren't provided.
If that happens way more than people realize, then people are unaware of these sites. If people are unaware of these sites, then they don't visit them, in which case they cannot be competition to the AP.
Not necessarily.
In order for someone to realize that that has happened, they need to both see the story on the blog and see the story attributed to the AP. I don't find it particularly implausible that many or most people reading such a blog might not read the AP directly; I'm not positive I've ever read a story directly from the AP, as opposed to a citation of an AP story by someone else. (A case where their prominence works against them; many people (and more news organizations) cite AP reports in their own stories, but few people - other than those doing the citing - seem to feel the need to read the originals.)
If most people see the story in only one place, then most people won't realize that the story is being copied wholesale. If the one place where they see the story is the AP and they don't visit the blogs, that's fine; if the one place where they see the story is the blog and they don't visit the AP, then that's not so fine. The argument would be that the latter is what is happening.
According to TFA, the blue tint disappeared within a week, and the regained mobility didn't manifest till the sixth week (at which point they killed the rat to dissect it) - so I doubt that this will be a long-term problem.
They did mention that they were surprised, upon dissection, to find out that the spinal cord was still blue even at the six-week mark. I imagine that even that would go away with time, though.
But as far as I've ever seen, PowerShell doesn't come "set up and ready to go" on a new Windows install; you have to go out and get (and install) it yourself. (Thus, "Windows doesn't ... come with" it.)
Combined with the near total lack of publicity and marketing for PowerShell, that means the vast majority of normal users will never even realize it exists, much less make use of it. It also means that people writing scripts to run on Windows can't rely on its being available for any given machine, whereas they can be quite certain that a POSIX-compatible shell (and, very probably, bash itself) will be available on any *nix machine.
Combined, these two points mean PowerShell verges on being useless for most purposes. If it were near-universally installed, that would be different; however, since it isn't, it might as well not exist.
You know what I want? A tag based filesystem. WTF should I have to manage directories?
Interesting you should mention that on this particular story.
I no longer use Gmail's Web interface, but last I heard, they had pretty much ignored the concept of folders/directories per se, choosing instead to present "views" (not their term, IIRC) based on user-defined searches. (This leads to annoyances such as their refusal to store more than one copy of a message, as determined by Message-ID, but that's another topic.) I remember having also been able to tag messages explicitly as one thing or another, and do so in an automatic fashion based on pattern-matching rules; having done so, you can then define a "view" for all messages with that tag.
I don't like Gmail's interface, for various reasons, but this underlying idea is interesting; it looks like much the same type of thing you're asking for, and I think it's the first "live" implementation of something like that I've ever come across.
I don't know if they've implemented this same kind of taggability and "view"ability for Google Apps documents (I don't use that service at all), but it wouldn't surprise me if it were possible.
Furthermore, given the recently-reported upcoming "Chrome OS", it's not impossible that you'll see something resembling a filesystem with this capability before terribly long...