Though I don't agree with him, he quite clearly said he believed people who know how to compile the code would compile any popular program for each package format. He did not say that everybody would compile from source. Read a little more carefully next time.
EVERY SINGLE SONG is already available pirated, so removing DRM will in no way increase the supply.
I think the result of removing DRM is going to reduce piracy. Currently the only way to get non-DRM music is to get a pirated version. If that is now available legally, at least some people (maybe very few but not zero) will switch from pirated copies to legal purchases. There is also a huge number of people (such as me) who are not buying or pirating anything, but would start buying it if the DRM was removed. So even if piracy does not increase or decrease, legal sales will increase substantially.
I don't think that guy has any idea what he is talking about. The Windows IDE and DirectX support C++ quite well, DirectX works *better* with C++ than C#, and most games are C++, and far more DirectX is written in C++ than C#. It is pretty insane to take a program already in C++ and convert it to C#. This is so bogus that I kind of find it hard to accept anything else he says.
Huh? You must mean something like multithreaded graphics *contexts*. OpenGL has long supported many contexts drawing to the same surface, each from a different thread. A context cannot be shared between threads, though.
Still not sure what a multithreaded "context" means, though. Adding a lock around every graphics call is NOT "multithreading" (actually Microsoft is somewhat better than Unix in this respect, take a look at the horrible way libc added a lock around every single stdio call and thus killed it's performance). All I can guess is that DirectX "contexts" store no state? If the state is a big structure passed to the "context" then maybe it works, but in that case you might as well consider that structure to be the "context" and thus it is not multithreaded.
You are completely ignoring infrastructure, such as DNS itself, which is entirely designed as FOSS and "copied" by MS and Apple.
But I can give you that, as most people do not even think about it as "software". Certainly I agree that FOSS things that resemble boxed software are copies. But your cheap shot that the reason is that the writers want it for "free" is obviously bogus.
It is plenty obvious that about 80% of the desire to copy commercial software is to make a version that works on Linux.
About 15% of the rest (and 15% of the reason for Linux itself) is to add features that the commercial software refuses to do. Such as scriptability, or a point-to-type gui, etc.
I'll be VERY generous and say that 5% of the rest is to make a "free as in speech" version. But even most of that is not out of alturism. It is due to a need to publicize yourself as the author of it.
Exactly ZERO percent is the desire to make a "free as in beer" version. You are talking about MONTHS at least of development effort, that is not in the least sense "free". People who want "free" software pirate it which gets you a fully functional version at about 1/1000th the effort.
The Gates quote is exactly 2 replies above yours, dofus.
He ended by saying "DRM is not where it should be, but you won't get me to say that there should be usage models and different payment models for usage. At the end of the day, incentive systems do make a difference, but we don't have it right with incentives or interoperability."
I have not bought anything from iTunes, despite owning an iPod and an iPod Mini. I can assure you that I would be buying plenty of stuff from it if they got rid of the DRM. I do not think I am alone. Removing the DRM will help iTunes sales considerably and would be very good for Apple.
Sounds like what they called "attach" back in DOS 3 or so. They removed that feature, I thought.
It would certainly have allowed drive letters to be deleted. A program could have switched the current drive to the system drive immediately on startup and then never had to use a drive letter (including c:) again. This would actually fix about 90% of the trouble we have with drive letters although I suspect it does not work on w2k which we are still using...
Does the mounted-to directory have to exist, like in Unix, or does it have to *not* be there. Personally having it not be there makes more sense, I never liked how Unix mount works and all I can think is that it is that way for a technical reason and nobody wants to admit that. I would prefer if mount worked more like a symbolic link. In fact "/dev/hd/whatever" should *be* the file system, mount is just like a symbolic link (except maybe it provides some extra information about how/who can access the file system)
I am unaware of anything that makes drive letters other than C: work. Actually C: is the only one *NOT* needed if your program assummes the systemdrive is the current one. All I can guess is you are thinking of volume names but since readdir() does not return a list of these it is easier to use the DOS calls to list drive letters, besides that returns names people expect (plus if volume names are the excuse than "C" would not be "required" either)
"Get rid of drive letters" means that readdir("/") will either return the directories that are the roots of drives, or that you can recursively call on directories in there and eventually arrive at the roots of the drives.
I was not talking about the rm program. The unlink() system call works.
As for "reparse points" and "junctions" (and also "attach" if you remember back that far), every one of them has been subtly broken so that they could not be used.
The problem is that they didn't ever really support "hard" links either. In DOS if you tried to remove a directory that was not empty, you got an error. This stupid behavior persists even though they have long supported filesystems where unlinking is possible. So all the file management programs that want to delete a directory will recursively delete every file in it. This is probably not what is expected if the user tries to delete a symbolic link to a directory.
There are plenty of other ways to fix this, however. For instance they could make readdir() return nothing for "foo" if foo is a symbolic link, but work for "foo/.". This should prevent any such programs from failing, and is probably preferrable in many ways to the Unix behavior. Also the "is this a directory" test could return false for symbolic links. Or they could disallow deletion of a file when the path contains a symbolic link (painful but not as limiting as not being able to make them!)
I suspect this is actually an excuse. Microsoft has refused to make symbolic links work for decades now, because they want to control the file system and insure incompatability with Unix. If symbolic links were available plenty of cross-platform software would stop supporting drive letters, and people would be told to make a "home" directory with pointers to their personal parts of the "My Documents", etc.
That is not exactly the problem. If a privledged program can take an arbitrary filenam, and does a stat to see if the user has access to the file, the test will work for symbolic links as well. If they don't do such a test they are broken and can be fooled without symbolic links.
The problem is when the privledged program generates it's *own* filename that it assummes is going to be a new file or something owned by the user or nobody, but the user has cleverly set a symbolic link at the name he knows the privledged program will use, so that the program ends up reading or writing a file that the user does not have permission for.
What about the opposite? Isn't there increasing evidence that Mars lost all it's surface water and a significant amount of atmosphere some hundreds of millions of years ago? That is a pretty significant climate change. Was there any corresponding change on Earth?
Okay I just wasted a lot more time reading about this.
First of all, my "simple atomic rename" would not work correctly. In my implementation, the following code:
mkdir a
mkdir b
mkdir a/c
mv a/c b/c
would result in b/c/.. pointing at a, not at b like the user of the rename command expects. So the rename command would still need to know about directories and change this link as well, and there may be problems with doing this atomically. Also the unmodified rename command could create circular dependencies, despite the impression that it is quite impossible to do so.
More of a concern is that I found several suggestions that the only problem was the lack of a true garbage collector in the file system. These were shot down in responses by others who sounded quite knowledgable, with elaborate examples showing how such schemes will quickly result in it being impossible for software to manage the file system. So I guess the inability to hard link to a directory is a well-researched thing and there are much more important reasons for it than my naive explanations.
You are right, they changed the text in the newer man pages. Also "man 2 link" seems to indicate that directories will never work, it says it will return an error, with no mention of superuser or system limitations.
The underlying file system does support such hard links, however, as this is how ".." and "." are implemented. Plenty of Unix software relies on getting the inode extracted by readdir (ie it cannot be done by code that parses filenames at the slashes). This seems to me that there is no efficient way to implement this except by having hard links to directories, though the file system could have no interface for creating them.
The prevention thing is a bit strange. It prevents a simple implementation of atomic rename. The "man 2 rename" seems to imply that it somehow does it using links anyway (rather than a different vfs api), but I have no idea how: "EMLINK oldpath already has the maximum number of links to it, or it was a directory and the directory containing newpath has the maximum number of links".
Also, maybe I'm stupid, but couldn't circular dependencies be avoided by only disallowing links to a parent of a link? Or the leak could be prevented by marking such links as "soft" ones that don't increment the reference count? I have been trying to find a way to create a circle with these restrictions and it looks impossible.
My best guess is that this restriction dates from the times of disk quotas. Even without circular dependencies, links to directories would either cause the same disk area to be counted twice, or for one user to steal the disk space from another.
Actually that is a restricion in Unix, it refuses to create such hard links long before the file system sees the attempt. This was done to make it impossible to create circular dependencies. I don't know why they felt this restricion was necessary, it does not really match the Unix design philosophy. Underlying file systems certainly do support hard links to directories, as this is how the "." and ".." files work.
You are absoltuly right that a watermarking scheme where only the "key" is secret would be the strongest one possible. A bunch of math geniuses can prove that combining N copies with different unknown keys is astronomically unlikely to cause any of the keys to stop decoding the watermark. That would be far, far stronger than any attempt to just obscure the scheme.
It would also allow anybody to add their own watermarks. This means that any content producer, not just somebody who can afford a "license", has all the capabilities of any other producer.
You are missing the fact that the watermark-reading software is *secret*. It does not matter how much computing power you have, without the ability to test whether you have removed the watermark it will be impossible to remove it.
The biggest problems with this scheme are 2:
1. There are idiots in management who will fail to realize that the detector must be secret, and will try to turn this into a DRM scheme. This will instantly provide a simple and fast test to see if the watermark is removed (check to see if it plays) and will destroy the entire scheme.
2. There are non-idiots who know that the real reason for DRM is not to stop piracy. It is to enforce pay-per-view and to lock out "amateur" content producers who cannot buy a drm encryption license. However they require piracy as an excuse for DRM, so this idea will be buried as it solves piracy without drm.
If you destroy the first then the second won't allow the media to be used
No, that won't work. They can add "additional" DRM if they want, but NOTHING can depend on the original watermark, such DRM mush have no effect on the watermark and must in no way be effected by it. If they do what you propose, then it is trivial to test if your modified file has sufficiently removed the watermark (because it plays), and the whole scheme is worklesss.
Lots of people have suggested this, but you have to realize that 20 or so bits of information is being hidden in a 1g or so file. There is a huge amount of redundant space in there. If you compare two copies you will find huge numbers of bits are different, and if you merge them together into something that plays, it is extremely likely that the id of *both* source files can be extracted.
The real trick is to keep the extraction software secret. Otherwise if is trivial to figure out if you have removed the watermark, by running the extraction software. In this case "security through obscurity" really works, because there literally is no way to figure out if you have broken it or not.
2. There is uncertainty as to whether the mark is removed
3. It isn't used to apply DRM
Not that #2 *requires* #3. DRM means there is a simple test to see if the mark is removed: if it plays then it was removed.
The biggest problem with this scheme is all the pea-brain managers who will not see this and will try to make it apply DRM, thus completely destroying the whole reason it works.
Slashdot Mirror
Though I don't agree with him, he quite clearly said he believed people who know how to compile the code would compile any popular program for each package format. He did not say that everybody would compile from source. Read a little more carefully next time.
EVERY SINGLE SONG is already available pirated, so removing DRM will in no way increase the supply.
I think the result of removing DRM is going to reduce piracy. Currently the only way to get non-DRM music is to get a pirated version. If that is now available legally, at least some people (maybe very few but not zero) will switch from pirated copies to legal purchases. There is also a huge number of people (such as me) who are not buying or pirating anything, but would start buying it if the DRM was removed. So even if piracy does not increase or decrease, legal sales will increase substantially.
I don't think that guy has any idea what he is talking about. The Windows IDE and DirectX support C++ quite well, DirectX works *better* with C++ than C#, and most games are C++, and far more DirectX is written in C++ than C#. It is pretty insane to take a program already in C++ and convert it to C#. This is so bogus that I kind of find it hard to accept anything else he says.
Huh? You must mean something like multithreaded graphics *contexts*. OpenGL has long supported many contexts drawing to the same surface, each from a different thread. A context cannot be shared between threads, though.
Still not sure what a multithreaded "context" means, though. Adding a lock around every graphics call is NOT "multithreading" (actually Microsoft is somewhat better than Unix in this respect, take a look at the horrible way libc added a lock around every single stdio call and thus killed it's performance). All I can guess is that DirectX "contexts" store no state? If the state is a big structure passed to the "context" then maybe it works, but in that case you might as well consider that structure to be the "context" and thus it is not multithreaded.
More explanation would be nice.
You are completely ignoring infrastructure, such as DNS itself, which is entirely designed as FOSS and "copied" by MS and Apple.
But I can give you that, as most people do not even think about it as "software". Certainly I agree that FOSS things that resemble boxed software are copies. But your cheap shot that the reason is that the writers want it for "free" is obviously bogus.
It is plenty obvious that about 80% of the desire to copy commercial software is to make a version that works on Linux.
About 15% of the rest (and 15% of the reason for Linux itself) is to add features that the commercial software refuses to do. Such as scriptability, or a point-to-type gui, etc.
I'll be VERY generous and say that 5% of the rest is to make a "free as in speech" version. But even most of that is not out of alturism. It is due to a need to publicize yourself as the author of it.
Exactly ZERO percent is the desire to make a "free as in beer" version. You are talking about MONTHS at least of development effort, that is not in the least sense "free". People who want "free" software pirate it which gets you a fully functional version at about 1/1000th the effort.
The Gates quote is exactly 2 replies above yours, dofus.
He ended by saying "DRM is not where it should be, but you won't get me to say that there should be usage models and different payment models for usage. At the end of the day, incentive systems do make a difference, but we don't have it right with incentives or interoperability."
I have not bought anything from iTunes, despite owning an iPod and an iPod Mini. I can assure you that I would be buying plenty of stuff from it if they got rid of the DRM. I do not think I am alone. Removing the DRM will help iTunes sales considerably and would be very good for Apple.
Sounds like what they called "attach" back in DOS 3 or so. They removed that feature, I thought.
It would certainly have allowed drive letters to be deleted. A program could have switched the current drive to the system drive immediately on startup and then never had to use a drive letter (including c:) again. This would actually fix about 90% of the trouble we have with drive letters although I suspect it does not work on w2k which we are still using...
Does the mounted-to directory have to exist, like in Unix, or does it have to *not* be there. Personally having it not be there makes more sense, I never liked how Unix mount works and all I can think is that it is that way for a technical reason and nobody wants to admit that. I would prefer if mount worked more like a symbolic link. In fact "/dev/hd/whatever" should *be* the file system, mount is just like a symbolic link (except maybe it provides some extra information about how/who can access the file system)
I am unaware of anything that makes drive letters other than C: work. Actually C: is the only one *NOT* needed if your program assummes the systemdrive is the current one. All I can guess is you are thinking of volume names but since readdir() does not return a list of these it is easier to use the DOS calls to list drive letters, besides that returns names people expect (plus if volume names are the excuse than "C" would not be "required" either)
"Get rid of drive letters" means that readdir("/") will either return the directories that are the roots of drives, or that you can recursively call on directories in there and eventually arrive at the roots of the drives.
I was not talking about the rm program. The unlink() system call works.
As for "reparse points" and "junctions" (and also "attach" if you remember back that far), every one of them has been subtly broken so that they could not be used.
The problem is that they didn't ever really support "hard" links either. In DOS if you tried to remove a directory that was not empty, you got an error. This stupid behavior persists even though they have long supported filesystems where unlinking is possible. So all the file management programs that want to delete a directory will recursively delete every file in it. This is probably not what is expected if the user tries to delete a symbolic link to a directory.
There are plenty of other ways to fix this, however. For instance they could make readdir() return nothing for "foo" if foo is a symbolic link, but work for "foo/.". This should prevent any such programs from failing, and is probably preferrable in many ways to the Unix behavior. Also the "is this a directory" test could return false for symbolic links. Or they could disallow deletion of a file when the path contains a symbolic link (painful but not as limiting as not being able to make them!)
I suspect this is actually an excuse. Microsoft has refused to make symbolic links work for decades now, because they want to control the file system and insure incompatability with Unix. If symbolic links were available plenty of cross-platform software would stop supporting drive letters, and people would be told to make a "home" directory with pointers to their personal parts of the "My Documents", etc.
That is not exactly the problem. If a privledged program can take an arbitrary filenam, and does a stat to see if the user has access to the file, the test will work for symbolic links as well. If they don't do such a test they are broken and can be fooled without symbolic links.
The problem is when the privledged program generates it's *own* filename that it assummes is going to be a new file or something owned by the user or nobody, but the user has cleverly set a symbolic link at the name he knows the privledged program will use, so that the program ends up reading or writing a file that the user does not have permission for.
I'm pretty certain the ice age cycle is many many times faster than plate tectonics!
What about the opposite? Isn't there increasing evidence that Mars lost all it's surface water and a significant amount of atmosphere some hundreds of millions of years ago? That is a pretty significant climate change. Was there any corresponding change on Earth?
Patents would not require the code to be closed source.
You are probably confusing patents with copyrights on the submitted code.
The only way patents make code closed is when a company thinks they may be violating a patent and wants to hide it.
Okay I just wasted a lot more time reading about this.
First of all, my "simple atomic rename" would not work correctly. In my implementation, the following code:
mkdir a
mkdir b
mkdir a/c
mv a/c b/c
would result in b/c/.. pointing at a, not at b like the user of the rename command expects. So the rename command would still need to know about directories and change this link as well, and there may be problems with doing this atomically. Also the unmodified rename command could create circular dependencies, despite the impression that it is quite impossible to do so.
More of a concern is that I found several suggestions that the only problem was the lack of a true garbage collector in the file system. These were shot down in responses by others who sounded quite knowledgable, with elaborate examples showing how such schemes will quickly result in it being impossible for software to manage the file system. So I guess the inability to hard link to a directory is a well-researched thing and there are much more important reasons for it than my naive explanations.
Whoops. No it is easy to create a loop:
mkdir a
mkdir b
ln a b/link
ln b a/link
a is now also a/link/link.
You are right, they changed the text in the newer man pages. Also "man 2 link" seems to indicate that directories will never work, it says it will return an error, with no mention of superuser or system limitations.
The underlying file system does support such hard links, however, as this is how ".." and "." are implemented. Plenty of Unix software relies on getting the inode extracted by readdir (ie it cannot be done by code that parses filenames at the slashes). This seems to me that there is no efficient way to implement this except by having hard links to directories, though the file system could have no interface for creating them.
The prevention thing is a bit strange. It prevents a simple implementation of atomic rename. The "man 2 rename" seems to imply that it somehow does it using links anyway (rather than a different vfs api), but I have no idea how: "EMLINK oldpath already has the maximum number of links to it, or it was a directory and the directory containing newpath has the maximum number of links".
Also, maybe I'm stupid, but couldn't circular dependencies be avoided by only disallowing links to a parent of a link? Or the leak could be prevented by marking such links as "soft" ones that don't increment the reference count? I have been trying to find a way to create a circle with these restrictions and it looks impossible.
My best guess is that this restriction dates from the times of disk quotas. Even without circular dependencies, links to directories would either cause the same disk area to be counted twice, or for one user to steal the disk space from another.
Further information: according the the man page the ln command can make hard links to directories, but root privledges are required.
Actually that is a restricion in Unix, it refuses to create such hard links long before the file system sees the attempt. This was done to make it impossible to create circular dependencies. I don't know why they felt this restricion was necessary, it does not really match the Unix design philosophy. Underlying file systems certainly do support hard links to directories, as this is how the "." and ".." files work.
You are absoltuly right that a watermarking scheme where only the "key" is secret would be the strongest one possible. A bunch of math geniuses can prove that combining N copies with different unknown keys is astronomically unlikely to cause any of the keys to stop decoding the watermark. That would be far, far stronger than any attempt to just obscure the scheme.
It would also allow anybody to add their own watermarks. This means that any content producer, not just somebody who can afford a "license", has all the capabilities of any other producer.
You are missing the fact that the watermark-reading software is *secret*. It does not matter how much computing power you have, without the ability to test whether you have removed the watermark it will be impossible to remove it.
The biggest problems with this scheme are 2:
1. There are idiots in management who will fail to realize that the detector must be secret, and will try to turn this into a DRM scheme. This will instantly provide a simple and fast test to see if the watermark is removed (check to see if it plays) and will destroy the entire scheme.
2. There are non-idiots who know that the real reason for DRM is not to stop piracy. It is to enforce pay-per-view and to lock out "amateur" content producers who cannot buy a drm encryption license. However they require piracy as an excuse for DRM, so this idea will be buried as it solves piracy without drm.
If you destroy the first then the second won't allow the media to be used
No, that won't work. They can add "additional" DRM if they want, but NOTHING can depend on the original watermark, such DRM mush have no effect on the watermark and must in no way be effected by it. If they do what you propose, then it is trivial to test if your modified file has sufficiently removed the watermark (because it plays), and the whole scheme is worklesss.
Lots of people have suggested this, but you have to realize that 20 or so bits of information is being hidden in a 1g or so file. There is a huge amount of redundant space in there. If you compare two copies you will find huge numbers of bits are different, and if you merge them together into something that plays, it is extremely likely that the id of *both* source files can be extracted.
The real trick is to keep the extraction software secret. Otherwise if is trivial to figure out if you have removed the watermark, by running the extraction software. In this case "security through obscurity" really works, because there literally is no way to figure out if you have broken it or not.
2. There is uncertainty as to whether the mark is removed
3. It isn't used to apply DRM
Not that #2 *requires* #3. DRM means there is a simple test to see if the mark is removed: if it plays then it was removed.
The biggest problem with this scheme is all the pea-brain managers who will not see this and will try to make it apply DRM, thus completely destroying the whole reason it works.