Yes, I have to agree. Same goes for the BSD releases, and everything else. If it's big news,/. readers need/want/must know about it. But if it's little routine stuff like development steps, and even patch levels of stable releases (unless some major and important fix included), it shouldn't be mainline headlines.
I would like to see a little box that shows what the latest/greatest releases of major OpenSource freeware is, be it Linux, distributions of Linux, BSD, KDE, Gnome, or whatever big popular software it might be. In our preferences we could then pick and choose what software titles we want the/. chipmunks to put in the box for us. Then add some code that highlights the changes we haven't seen, yet
Since this law allows software peddlers to basically trick people and businesses into legally binding contract terms they may very well be unaware of, then why not just add some really nasty terms of your own?
Buyer hereby agrees to install a copy of this software on each and every computer owned by, or in the possession, of the business or organization.
Buyer hereby agrees to uninstall any and all copies of Microsoft Windows, in any version, including
versions obtained for beta evaluation
unlicensed versions
networked copies
copies co-existing with other operating systems
Buyer hereby agrees to make a donation in the amount of $1.00 (one dollar) to The Electronic Frontier Foundation, and a donation in the amount of $1.00 (one dollar) to the Free Software Foundation, for the first computer found running Microsoft Windows, doubling each donation for each instance of an additional computer found running Microsoft Windows.
Buyer hereby agrees, upon penalty of death, to never press either key labeled with a trademark of the Microsoft Corporation.
Well, the above might not fly, but you get the idea. Come up with something you can enforce, and stick it in there.
This is not quite correct. Although CSS lets the DVD consortium control who can make players, it doesn't necessarily control who can produce DVD content, because the use of CSS encryption on a DVD video is optional. There are apparently several 'non-Hollywood' DVD titles in existence that are not encrypted. (I've been told, for example, that "Earthwatch" is one such title, although I haven't yet checked this myself.)
It's optional until the major content producers start pressuring the manufacturers to stop playing back unencrypted media. They will use the fact that pirated content is coming out unencrypted as the excuse for this. The producers can do this even without the consortium being involved by threatening to not include the key for players made by non-cooperating manufacturers in their future releases. As soon as a few manufacturers go along, then the threat would no longer be a bluff, and most of the rest of the manufacturers would step in line.
That would certainly break the ability to play unencrypted material. That could be exactly what the producers want, and it would cover not only the piracy, but the up-starts as well. Just because it hasn't happened yet doesn't mean it can't happen in the future. CSS gives them a tremendous amount of power. They either have not figured out how to use it, yet, or, more likely, are carefully treading the legal waters to find out just how far they really can go, and to allow their campaign of whining about piracy and reverse engineering to develop public, and legislative, sympathy.
Players today may be able to play unencrypted DVDs, but as more and more pirates shift from cloning encrypted DVDs to making unencrypted ones, which is certainly easier to do now, then surely the consortium will be pressuring its manufacturer members to block the playing of unencrypted DVDs in future models. We need to consider that, even though players may not do so today, they could tomorrow not be able to play unencrypted DVDs.
If they do make such a move, it does put them further into the darker side of the gray areas of anti-trust violations, as long as there exists some kind of legitimate business in unencrypted DVDs, which I believe there will be.
One thing I would like to find out is just what technology licenses I need to be able to make a player, to make a recorder, and to manufacture blank and recorded media, in DVD without any encryption (e.g. without using CSS). If some businesses do get into this market, will pirates make illegal copies of unencrypted DVDs for this market? If it's big enough, I'm certain they will. if it happens I'm sure there will be yet another big stink over the whole issue.
Computers in general are a thorn in the side of the audio/video entertainment industry. Computer media itself is beyond the control (so far) of the entertainment industry. US laws that do place restrictions on consumer playback devices with regard to copy protections and copy generation limits do not apply to computer devices. And in much the same way that the Internet will be diffusing the difference between data, radio, TV, and telephone, computers, as they get smaller in size, larger in capacity, and faster in capability, will be diffusing the difference between a data device, and a media device.
It used to be impractical for the average person to build their own playback device that could defeat region codes and other mechanisms of megacorporate monopoly. Computers are changing that landscape since the making process is now just a matter of someone coding software, and someone else downloading it.
In the end, which may be as little as 10 years away, we will either have open art that anyone can utilize on the honor system (or by contract), or we will lose the ability control the software that runs in the very computers we buy, build, and own. Be wary of the piracy scare coming into computers. Next we might have CPUs that require decryption keys just to run programs, and that could mean we can't even program our own computers. Both the entertainment industry as well as the software industry would love that.
It's hard to tell exactly where this is all headed, and evey they may not know. We need to keep our eyes open to every possibility and pay particularly close attention to future laws and computer technology.
Access is like the ability to download it. I have accessed it if I have provided my purchase information validly online and obtained a legal copy via download. I have access if I purchase a DVD in the store. Playing is not access. I already have legitimate rights to the work once I have paid for a legitimate copy. Whatever I then do to view it myself is entirely legitimate. DeCSS is a tool for that process.
You are mistaken on a technical basis. The copy protection is not circumvented by DeCSS. A DVD and/or a CSS encrypted file can be copied without any form of decryption. By simply presenting the keys and the data to any player in exactly the same form that a DVD does, that player can play it. If that form is a duplicate DVD, then it can and will play it and this is a copyright violation.
DVDs are already being pirated. The pirates have obtained the DVD manufacturing equipment (perhaps by theft). Reportedly, one such operation is already running full tilt in Hong Kong. By taking a popular DVD and using it as a master (some processing involved there I am sure), and by copying each and every bit including the key tracks, a new exactly identical DVD is produced and that DVD looks no different than the original to the DVD player. It will index the keys, find the one with its ID, and begin the decrypt and play process using that copied key. This is all a copyright violation and a form of piracy. These clone DVDs are then sold on the black market, depriving the artists, and the investors in the production of the artwork, their returns. It also happens to deprive the original manufacturers of a scale of market but for that aspect I don't perticularly see a violation (although they do tend to be the same organizations as the investors).
Buying a DVD and using DeCSS to play it on the computer of my choice is NOT a copyright violation. Since I have a right (in the USA) to make sufficient personal copies for the purpose of usage (so long as I destroy all of them should I sell, or even lend, my DVD to someone else), then this is legitimate, and is not addressed by the DMCA at all.
Sure, DeCSS does enable one to make an unencrypted version of the DVD, which could be transferred to others over the internet. But DeCSS isn't required to do this. You can capture the audio and video output from an existing player (hardware or software) into a file and transfer that file over the internet. This would be a copyright violation just as much as cloning an encrypted DVD.
If the DVD industry had sanctioned a player program for Linux and BSD systems, which was distributed only in binary form, and would refuse to store decrypted files and only play them, then it could be argued that DeCSS only adds on the ability to create a decrypted file. Since they have not done so, DeCSS has a much more significant role (since statistics show that despite a lot of piracy going on, most people don't engage in piracy, even with media like CDDA that is trivial to pirate) in simply enabling the playing process.
DeCSS has opened our eyes, and potentially the eyes of government investigators, to the potential for the megacorporations to use CSS as a means to squash competitive upstarts (in both production of the artwork as well as manufacturing of players). If the DVD industry was on solid legal ground, they wouldn't need to have Jack Valenti making public pleas with lies about it being only for copying. Now people will see the mechanism by which CSS can not only be a potential anti-trust violation (they would have to actually do it, as the mere existance of the mechanism would not imply the violation), but also be a mechanism of selective price gouging. They need to silence and suppress this "leak".
I agree that the free speech argument is weak and inappropriate here. The correct argument should be that the DMCA does not apply because of reasons such as the fact that DeCSS is not a copying tool and does not particularly enable the copying process. It can decrypt. But decrypting isn't a copyright violation if the output is directly to the viewscreen (or speakers/headphones in the case of audio). My "cp" and "cat" commands can copy CSS encrypted files. The (expensive) DVD manufacturing equipment (as opposed to low end DVD-R devices) can also perform the copying, and can do so w/o even the need for decryption or encryption.
As long as the DVD industry is lying to the judges and as long as the judges are believing them because they are from megacorporations, then injustice continues. The boycott is on!
Easy to argue. The difficulty seems to be making you aware of the fact that this program does nothing to promote the ability to copy a DVD. The DVD related industry is just pissed off that this code is exposing their monopoly control scheme whereby they will be able to prevent upstart competition in both movie/music production, as well as in player manufacturing. They don't like DeCSS, but the reason they don't like it isn't because of the asserted copy features, but rather, because they no longer can control who gets to view their bought and paid for DVDs, and who doesn't.
The argument that computer code is an expression of free speech, however, is an old and tired one. It should not have been used. The proper argument should be that this is a tool to play DVDs, not to copy them.
It's not for copying, it's for playing. Judges are still looking at the false facts in these cases. When the legal system pays more attention to overpaid megacorporate lia^H^Hawyers, we no longer have justice.
Suppose from this source code someone makes two distinct programs. One that plays the files, and one that copies the files, then which one should the injunction be applied to?
I believe the principle of the law is to say that the mere fact that a signiture is digital is not usable to debunk it. So if you argue that it's not valid because it is digital (and this is your only argument) the could would see no defense from you. If the signature is fraudulent because someone else produced it (maybe they broke into your computer and got your keys), or if the signature isn't actually signed by you (because the other party failed to verify it), then you have a case. Hopefully the law isn't going to make it indefensible.
So if it is indeed you that typed your name in the box, then it's valid. If it is not you, then it's not valid. The determining factor is whether it is or is not you who typed it in. This kind of thing would in fact be weak without some other evidence. But if, and when, they can show that you typed it in, this is now as valid as having scribbled something on a piece of paper. The point of typing it in is not about proving it was you (as indeed many people know how to type your name in that box), but about proving that you (if it was you) intended to assert this.
The courts most likely will still have to struggle with the issues of fraud and the technology of cryptography.
That would be a visit to the town hall...electronically, of course.
I'm not really concerned about the business I transact online. I understand cryptography enough to feel safe with much of it. I know the processes involved to make things private, to identify and verify, and to make non-reputable.
My concern is in others that fail to take the proper steps, and assume identity and/or non-reputability when it is not there, and the impact that can have if the transaction was not really conducted by me.
If I am served a summons to appear in court, where the server attests to the delivery, this is on paper, usually in an envelope, which I can no doubt read by simply performing a common practice of opening the envelope and reading the document. When the server attests that the summons was delivered, this is normally acceptable by I have a real opportunity to read it.
I don't know if this law goes so far as to allow the delivery of a summons by e-mail, but it may, given its broad nature to include notifications. I suspect it will just be a matter of time until courts become more experienced with electronic delivery, which they are now about to do, before even summons could be delivered this way.
My concern is that I might not be able to read what was successfully delivered to me. On paper we have basically one way of reading and writing. By computer we have thousands.
You obviously don't understand Public Key Cryptography. The real fear is that most of the general public doesn't, and probably never will. If this bill becomes final law, how many cases will there be that some people, trying to go along with this, will even accept an unsigned document, not knowing that the whole idea is to use technology that is resistance to forgery. And even if they do have it and try to use it, will they use it right?
I haven't seen the details of the bill. However, what electronic signatures are about is that a cryptographically strong hash digest of the document encrypted by your private key, forming a resultant certificate that could only (to the extent the encryption used is strong in this regard) be created with your private key. Your public key is then used to decrypt the certificate, producing a result identify to the regenerated hash digest of the document.
You want to buy a house. You find one on the web for sale, and after doing the virtual tour, you decide to buy. You create a document which is an offer to buy the house. You sign the document with your key and send it to the seller. The seller verifies that you indeed signed the document and decides to accept your offer. She then creates a new document accepting the offer (with all the other stuff attached), and signs it with her key, and returns it to you. You make plans to move in.
In theory it can work. In practice there may be many pitfalls that have not been tested out. If people fail to understand how cryptographic signing works, they could fail to verify that the expected person did indeed sign the document. Human error can still foul things up, and we all know the power of computers is most effective at amplifying human screwups.
I recall a philosophy class I had in college where the professor asserted that there were many things computers simply will not be able to tell us. I immediately rebutted saying, there may indeed be such things, but computers still have the power to make people believe what it says, truthful or otherwise.
I am particularly concerned about things like legal notifications being sent to you via e-mail. For very important documents, even postal delivery is not good enough. Some require a return receipt, and some require identity verification (not so much for privacy, but to verify that delivery was made) for delivery. What mechanisms do we have in place, or just have, that can do all this?
What if I get a court summons delivered electronically in a format that isn't a standardized format, and because of that I am unable to read it (even though the e-mail system has already acknowledged delivery of the mail in which it was an attachment)? One thing we definitely need here is to make sure that any delivery of such things absolutely must be in an open and widely implemented format.
E-mail addresses are not as fixed as postal addresses. If you change ISP, you may end up with a new e-mail address. Or would you feel good about getting your jury duty letter on Hotmail? But then, in about 10 years we'll be serving on juries electronically, anyway.
Not everyone is yet wired. And that probably won't be the case for quite a while. How will they get their important legal e-mail?
My biggest concern, however, is, as you can guess, security. And guess where the least secure computers tend to be.
So the year numbers are off by one. I'll go back to year 1, renumber it as 0. That makes it now 1999. Maybe it can be more easily understood then. Of course you have to renumber the centuries, too, so the first century is now century 0, and this is century 19 (less than a year to go until century 20).
Of the past 2000 years, more years were celebrated with the beginning of the year being NOT january 1, but March 25. Our system of months are based on the original Roman calendar (pre-Julian), as was the beginning of the year. Christians changed that to what made sense to them, March 25 (which could be quite confusing to computers since they don't understand Christianity).
So if you are Christian, the true new year, and thus the next millennium, based on the Day of Annunciation, the conception of Jesus, is less than 2 months from now.
If you are not Christian, none of this matters. But my BIOS won't let me enter the year as 5760, or 157.
Oh... the topic... uh... yeah... last century... my vote is for the steam engine!
A better place to put an observatory is the far side of the main moon. This will allow full spectral seeing without RFI from the earth. The communications can be done by placing the observatory on the far side where it can see the Earth-Moon L4 or L5 point, then put a relay satellite at the L4 or L5 point.
Other than that, I agree that Cruithne is essentially worthless as an observatory. If we wanted one further out than the moon, there's always the Sun-Earth L4/L5 points, as well as other planets, or their Lagrange points, or the larger asteroids. But close in would be suitable for me, as we would need to be generating a lot of data from it to keep all those seti@home computers busy:-)
Hmmm. That's an interesting concept. That would be a usable tool. It would have to be lean and mean. As long as there is a one-to-one correspondence in the HSI variant used for configs and the XML DTD used for configs (and this could surely be done), it may not matter what is really on the inside.
Conceptually, it's no different than, say, using an octal or hexadecimal editor to hand edit the code of each individual byte. Or rather, since the code really are what is in the file, the concept is that the character representation is in fact one way of presenting a view of what is in the file. Whether the contents is XML or HSI, it could be viewed either way, too.
I suppose I should add more comments to my config files. Right now they are very terse. They are virtually raw information. They don't resemble a document at all.
But...
I'm curious how I will parse/etc/fstab if it is written in XML, when libxml.so might not be available yet. Or must I put libxml.so in/lib? Will libxml.so be small enough for my floppy rescue system?
So what about HSI (Hierarchical Structured Information I think was the acronym)?
It's hierarchical, can do comments (my implemetation uses # comments), is simple to read, lightweight to parse, and doesn't use redundancy.
The implementation I am working on also supports binary data in various handy notations. You can enter binary bytes into strings using ^ notation, \ notation, or % hexadecimal notation. The corresponding output functions will generate various notations with preference for the ^ then \ (other than octal) then %.
I'll agree to (a) and (b). How about at the same time also agreeing that the tools need to be improved to the point where no one will feel a need to use a text editor on a config file. I believe this is important because with better tools, this can help shield the human from the ugly details underneath, and the choice of format will relate more to programming than human reading.
HSI basically resembles Algol class programming languages, in a sense, but for data. It's actually rather old. I first encountered it in the early 1980's, and even some of the references were over a decade old. It has variations and they are not as uniform as XML probably is. But you don't have to use all the variations for creating commonly formatted config files.
We do seem to disagree on how bad XML is for hand editing. This may well be influenced further by how often either of us does edit config files (I do so rather freqently, often many times a day).
If GUI tools worked to eliminate all, or even almost all, my needs to hand edit, then XML would to me be a moot point. Perhaps by the time it gets deployed if we go this direction, GUI tools will be fixed. But I have some major doubts because there are lots of people that are saying the GUI tools work fine and won't fix them (probably by applying the age old wisdom, IIABDFI).
I suppose I could say IIABDFI about HSI, but HSI hasn't really been deployed here for the most part. You can see a reasonable variation of HSI in the BIND version 8 named.conf file format. Tools already exist to parse it.
I haven't looked at the lisp/scheme-like format that has been mentioned more than once, so I don't even know what you are comparing XML against, or if it even resembles HSI or not.
Maybe we can use something that looks like FORTH to configure with? Nah!
HTML has more content than tag, so the wordiness of tags isn't a big issue. And many of the tags are dense in usefulness.
But one thing that HTML is NOT is a langauge for defining the namespace of things. if you use a tag to name something, and the tag is as big or nearly as big as the data, and then especially when you duplicate the tag with a / at the end, you end up with as much tag as data.
I don't need to prove that XML is hard to read; I only need to look at it. The closing tags visually obscure the appearance of the data. Sure, I could use a tab between a tag and the data, but in XML, that tab becomes part of the data (I suppose the configurator can then discard spaces and tabs from input after the XML parsing).
My biggest objection of XML is that closing tag. That's entirely redundant. If you simply used some opening/closing character, such as () or {} pairs, then the closing form, e.g. } or ), would pop the stack and close the current item.
If you could nest tags within tags, that could be done in a way that looks like XML, although I don't know if its legal XML. I have not read, nor will I read, a document that describes a language (e.g. XML) for document preparation, because I'm not into doing document preparation. I am into config files, and I would read a document that decribes a language for config files provided that document is strictly about that usage and doesn't waste my time telling me about how document preparation, or anything else, is made better by it.
As for success of HTML based on its readability, even though I do read HTML OK (and prefer not to unless building a web page), take a look at all the web page building tools out there and their explanations "you don't need to read HTML".
To try to retro fit a documentation language into being a configuration language, when others already exist, is what is Stupid(tm).
Be that as it may, the large corps are also striving to become bigger and unseat the competition in many (often illegal, and usually inappropriate) ways. They have to get the competition out of the way if they are going to be successful in screwing the consumer.
Sorry, you cannot get mySQL even started if your system won't run because the configuration is messed up.
Whatever the tool is, it must run on the most screwed up system short of one that needs re-installed (probably explains why so many people have to re-install NT so often).
A text editor like vi does the job (even though I would normally use emacs).
Slashdot Mirror
Yes, I have to agree. Same goes for the BSD releases, and everything else. If it's big news, /. readers need/want/must know about it. But if it's little routine stuff like development steps, and even patch levels of stable releases (unless some major and important fix included), it shouldn't be mainline headlines.
I would like to see a little box that shows what the latest/greatest releases of major OpenSource freeware is, be it Linux, distributions of Linux, BSD, KDE, Gnome, or whatever big popular software it might be. In our preferences we could then pick and choose what software titles we want the /. chipmunks to put in the box for us. Then add some code that highlights the changes we haven't seen, yet
Don't fight it, use it!
Since this law allows software peddlers to basically trick people and businesses into legally binding contract terms they may very well be unaware of, then why not just add some really nasty terms of your own?
Well, the above might not fly, but you get the idea. Come up with something you can enforce, and stick it in there.
It's optional until the major content producers start pressuring the manufacturers to stop playing back unencrypted media. They will use the fact that pirated content is coming out unencrypted as the excuse for this. The producers can do this even without the consortium being involved by threatening to not include the key for players made by non-cooperating manufacturers in their future releases. As soon as a few manufacturers go along, then the threat would no longer be a bluff, and most of the rest of the manufacturers would step in line.
That would certainly break the ability to play unencrypted material. That could be exactly what the producers want, and it would cover not only the piracy, but the up-starts as well. Just because it hasn't happened yet doesn't mean it can't happen in the future. CSS gives them a tremendous amount of power. They either have not figured out how to use it, yet, or, more likely, are carefully treading the legal waters to find out just how far they really can go, and to allow their campaign of whining about piracy and reverse engineering to develop public, and legislative, sympathy.
Players today may be able to play unencrypted DVDs, but as more and more pirates shift from cloning encrypted DVDs to making unencrypted ones, which is certainly easier to do now, then surely the consortium will be pressuring its manufacturer members to block the playing of unencrypted DVDs in future models. We need to consider that, even though players may not do so today, they could tomorrow not be able to play unencrypted DVDs.
If they do make such a move, it does put them further into the darker side of the gray areas of anti-trust violations, as long as there exists some kind of legitimate business in unencrypted DVDs, which I believe there will be.
One thing I would like to find out is just what technology licenses I need to be able to make a player, to make a recorder, and to manufacture blank and recorded media, in DVD without any encryption (e.g. without using CSS). If some businesses do get into this market, will pirates make illegal copies of unencrypted DVDs for this market? If it's big enough, I'm certain they will. if it happens I'm sure there will be yet another big stink over the whole issue.
Computers in general are a thorn in the side of the audio/video entertainment industry. Computer media itself is beyond the control (so far) of the entertainment industry. US laws that do place restrictions on consumer playback devices with regard to copy protections and copy generation limits do not apply to computer devices. And in much the same way that the Internet will be diffusing the difference between data, radio, TV, and telephone, computers, as they get smaller in size, larger in capacity, and faster in capability, will be diffusing the difference between a data device, and a media device.
It used to be impractical for the average person to build their own playback device that could defeat region codes and other mechanisms of megacorporate monopoly. Computers are changing that landscape since the making process is now just a matter of someone coding software, and someone else downloading it.
In the end, which may be as little as 10 years away, we will either have open art that anyone can utilize on the honor system (or by contract), or we will lose the ability control the software that runs in the very computers we buy, build, and own. Be wary of the piracy scare coming into computers. Next we might have CPUs that require decryption keys just to run programs, and that could mean we can't even program our own computers. Both the entertainment industry as well as the software industry would love that.
It's hard to tell exactly where this is all headed, and evey they may not know. We need to keep our eyes open to every possibility and pay particularly close attention to future laws and computer technology.
Access is like the ability to download it. I have accessed it if I have provided my purchase information validly online and obtained a legal copy via download. I have access if I purchase a DVD in the store. Playing is not access. I already have legitimate rights to the work once I have paid for a legitimate copy. Whatever I then do to view it myself is entirely legitimate. DeCSS is a tool for that process.
You are mistaken on a technical basis. The copy protection is not circumvented by DeCSS. A DVD and/or a CSS encrypted file can be copied without any form of decryption. By simply presenting the keys and the data to any player in exactly the same form that a DVD does, that player can play it. If that form is a duplicate DVD, then it can and will play it and this is a copyright violation.
DVDs are already being pirated. The pirates have obtained the DVD manufacturing equipment (perhaps by theft). Reportedly, one such operation is already running full tilt in Hong Kong. By taking a popular DVD and using it as a master (some processing involved there I am sure), and by copying each and every bit including the key tracks, a new exactly identical DVD is produced and that DVD looks no different than the original to the DVD player. It will index the keys, find the one with its ID, and begin the decrypt and play process using that copied key. This is all a copyright violation and a form of piracy. These clone DVDs are then sold on the black market, depriving the artists, and the investors in the production of the artwork, their returns. It also happens to deprive the original manufacturers of a scale of market but for that aspect I don't perticularly see a violation (although they do tend to be the same organizations as the investors).
Buying a DVD and using DeCSS to play it on the computer of my choice is NOT a copyright violation. Since I have a right (in the USA) to make sufficient personal copies for the purpose of usage (so long as I destroy all of them should I sell, or even lend, my DVD to someone else), then this is legitimate, and is not addressed by the DMCA at all.
Sure, DeCSS does enable one to make an unencrypted version of the DVD, which could be transferred to others over the internet. But DeCSS isn't required to do this. You can capture the audio and video output from an existing player (hardware or software) into a file and transfer that file over the internet. This would be a copyright violation just as much as cloning an encrypted DVD.
If the DVD industry had sanctioned a player program for Linux and BSD systems, which was distributed only in binary form, and would refuse to store decrypted files and only play them, then it could be argued that DeCSS only adds on the ability to create a decrypted file. Since they have not done so, DeCSS has a much more significant role (since statistics show that despite a lot of piracy going on, most people don't engage in piracy, even with media like CDDA that is trivial to pirate) in simply enabling the playing process.
DeCSS has opened our eyes, and potentially the eyes of government investigators, to the potential for the megacorporations to use CSS as a means to squash competitive upstarts (in both production of the artwork as well as manufacturing of players). If the DVD industry was on solid legal ground, they wouldn't need to have Jack Valenti making public pleas with lies about it being only for copying. Now people will see the mechanism by which CSS can not only be a potential anti-trust violation (they would have to actually do it, as the mere existance of the mechanism would not imply the violation), but also be a mechanism of selective price gouging. They need to silence and suppress this "leak".
I agree that the free speech argument is weak and inappropriate here. The correct argument should be that the DMCA does not apply because of reasons such as the fact that DeCSS is not a copying tool and does not particularly enable the copying process. It can decrypt. But decrypting isn't a copyright violation if the output is directly to the viewscreen (or speakers/headphones in the case of audio). My "cp" and "cat" commands can copy CSS encrypted files. The (expensive) DVD manufacturing equipment (as opposed to low end DVD-R devices) can also perform the copying, and can do so w/o even the need for decryption or encryption.
As long as the DVD industry is lying to the judges and as long as the judges are believing them because they are from megacorporations, then injustice continues. The boycott is on!
Easy to argue. The difficulty seems to be making you aware of the fact that this program does nothing to promote the ability to copy a DVD. The DVD related industry is just pissed off that this code is exposing their monopoly control scheme whereby they will be able to prevent upstart competition in both movie/music production, as well as in player manufacturing. They don't like DeCSS, but the reason they don't like it isn't because of the asserted copy features, but rather, because they no longer can control who gets to view their bought and paid for DVDs, and who doesn't.
The argument that computer code is an expression of free speech, however, is an old and tired one. It should not have been used. The proper argument should be that this is a tool to play DVDs, not to copy them.
It's not for copying, it's for playing. Judges are still looking at the false facts in these cases. When the legal system pays more attention to overpaid megacorporate lia^H^Hawyers, we no longer have justice.
Suppose from this source code someone makes two distinct programs. One that plays the files, and one that copies the files, then which one should the injunction be applied to?
The boycott goes on!
I believe the principle of the law is to say that the mere fact that a signiture is digital is not usable to debunk it. So if you argue that it's not valid because it is digital (and this is your only argument) the could would see no defense from you. If the signature is fraudulent because someone else produced it (maybe they broke into your computer and got your keys), or if the signature isn't actually signed by you (because the other party failed to verify it), then you have a case. Hopefully the law isn't going to make it indefensible.
So if it is indeed you that typed your name in the box, then it's valid. If it is not you, then it's not valid. The determining factor is whether it is or is not you who typed it in. This kind of thing would in fact be weak without some other evidence. But if, and when, they can show that you typed it in, this is now as valid as having scribbled something on a piece of paper. The point of typing it in is not about proving it was you (as indeed many people know how to type your name in that box), but about proving that you (if it was you) intended to assert this.
The courts most likely will still have to struggle with the issues of fraud and the technology of cryptography.
That would be a visit to the town hall ...electronically, of course.
I'm not really concerned about the business I transact online. I understand cryptography enough to feel safe with much of it. I know the processes involved to make things private, to identify and verify, and to make non-reputable.
My concern is in others that fail to take the proper steps, and assume identity and/or non-reputability when it is not there, and the impact that can have if the transaction was not really conducted by me.
If I am served a summons to appear in court, where the server attests to the delivery, this is on paper, usually in an envelope, which I can no doubt read by simply performing a common practice of opening the envelope and reading the document. When the server attests that the summons was delivered, this is normally acceptable by I have a real opportunity to read it.
I don't know if this law goes so far as to allow the delivery of a summons by e-mail, but it may, given its broad nature to include notifications. I suspect it will just be a matter of time until courts become more experienced with electronic delivery, which they are now about to do, before even summons could be delivered this way.
My concern is that I might not be able to read what was successfully delivered to me. On paper we have basically one way of reading and writing. By computer we have thousands.
You obviously don't understand Public Key Cryptography. The real fear is that most of the general public doesn't, and probably never will. If this bill becomes final law, how many cases will there be that some people, trying to go along with this, will even accept an unsigned document, not knowing that the whole idea is to use technology that is resistance to forgery. And even if they do have it and try to use it, will they use it right?
I haven't seen the details of the bill. However, what electronic signatures are about is that a cryptographically strong hash digest of the document encrypted by your private key, forming a resultant certificate that could only (to the extent the encryption used is strong in this regard) be created with your private key. Your public key is then used to decrypt the certificate, producing a result identify to the regenerated hash digest of the document.
You want to buy a house. You find one on the web for sale, and after doing the virtual tour, you decide to buy. You create a document which is an offer to buy the house. You sign the document with your key and send it to the seller. The seller verifies that you indeed signed the document and decides to accept your offer. She then creates a new document accepting the offer (with all the other stuff attached), and signs it with her key, and returns it to you. You make plans to move in.
In theory it can work. In practice there may be many pitfalls that have not been tested out. If people fail to understand how cryptographic signing works, they could fail to verify that the expected person did indeed sign the document. Human error can still foul things up, and we all know the power of computers is most effective at amplifying human screwups.
I recall a philosophy class I had in college where the professor asserted that there were many things computers simply will not be able to tell us. I immediately rebutted saying, there may indeed be such things, but computers still have the power to make people believe what it says, truthful or otherwise.
I am particularly concerned about things like legal notifications being sent to you via e-mail. For very important documents, even postal delivery is not good enough. Some require a return receipt, and some require identity verification (not so much for privacy, but to verify that delivery was made) for delivery. What mechanisms do we have in place, or just have, that can do all this?
What if I get a court summons delivered electronically in a format that isn't a standardized format, and because of that I am unable to read it (even though the e-mail system has already acknowledged delivery of the mail in which it was an attachment)? One thing we definitely need here is to make sure that any delivery of such things absolutely must be in an open and widely implemented format.
E-mail addresses are not as fixed as postal addresses. If you change ISP, you may end up with a new e-mail address. Or would you feel good about getting your jury duty letter on Hotmail? But then, in about 10 years we'll be serving on juries electronically, anyway.
Not everyone is yet wired. And that probably won't be the case for quite a while. How will they get their important legal e-mail?
My biggest concern, however, is, as you can guess, security. And guess where the least secure computers tend to be.
So the year numbers are off by one. I'll go back to year 1, renumber it as 0. That makes it now 1999. Maybe it can be more easily understood then. Of course you have to renumber the centuries, too, so the first century is now century 0, and this is century 19 (less than a year to go until century 20).
... the topic ... uh ... yeah ... last century ... my vote is for the steam engine!
Of the past 2000 years, more years were celebrated with the beginning of the year being NOT january 1, but March 25. Our system of months are based on the original Roman calendar (pre-Julian), as was the beginning of the year. Christians changed that to what made sense to them, March 25 (which could be quite confusing to computers since they don't understand Christianity).
So if you are Christian, the true new year, and thus the next millennium, based on the Day of Annunciation, the conception of Jesus, is less than 2 months from now.
If you are not Christian, none of this matters. But my BIOS won't let me enter the year as 5760, or 157.
Oh
see Subject.
A better place to put an observatory is the far side of the main moon. This will allow full spectral seeing without RFI from the earth. The communications can be done by placing the observatory on the far side where it can see the Earth-Moon L4 or L5 point, then put a relay satellite at the L4 or L5 point.
:-)
Other than that, I agree that Cruithne is essentially worthless as an observatory. If we wanted one further out than the moon, there's always the Sun-Earth L4/L5 points, as well as other planets, or their Lagrange points, or the larger asteroids. But close in would be suitable for me, as we would need to be generating a lot of data from it to keep all those seti@home computers busy
Hmmm. That's an interesting concept. That would be a usable tool. It would have to be lean and mean. As long as there is a one-to-one correspondence in the HSI variant used for configs and the XML DTD used for configs (and this could surely be done), it may not matter what is really on the inside.
Conceptually, it's no different than, say, using an octal or hexadecimal editor to hand edit the code of each individual byte. Or rather, since the code really are what is in the file, the concept is that the character representation is in fact one way of presenting a view of what is in the file. Whether the contents is XML or HSI, it could be viewed either way, too.
I suppose I should add more comments to my config files. Right now they are very terse. They are virtually raw information. They don't resemble a document at all.
/etc/fstab if it is written in XML, when libxml.so might not be available yet. Or must I put libxml.so in /lib? Will libxml.so be small enough for my floppy rescue system?
But...
I'm curious how I will parse
So what about HSI (Hierarchical Structured Information I think was the acronym)?
It's hierarchical, can do comments (my implemetation uses # comments), is simple to read, lightweight to parse, and doesn't use redundancy.
The implementation I am working on also supports binary data in various handy notations. You can enter binary bytes into strings using ^ notation, \ notation, or % hexadecimal notation. The corresponding output functions will generate various notations with preference for the ^ then \ (other than octal) then %.
I'll agree to (a) and (b). How about at the same time also agreeing that the tools need to be improved to the point where no one will feel a need to use a text editor on a config file. I believe this is important because with better tools, this can help shield the human from the ugly details underneath, and the choice of format will relate more to programming than human reading.
HSI basically resembles Algol class programming languages, in a sense, but for data. It's actually rather old. I first encountered it in the early 1980's, and even some of the references were over a decade old. It has variations and they are not as uniform as XML probably is. But you don't have to use all the variations for creating commonly formatted config files.
We do seem to disagree on how bad XML is for hand editing. This may well be influenced further by how often either of us does edit config files (I do so rather freqently, often many times a day).
If GUI tools worked to eliminate all, or even almost all, my needs to hand edit, then XML would to me be a moot point. Perhaps by the time it gets deployed if we go this direction, GUI tools will be fixed. But I have some major doubts because there are lots of people that are saying the GUI tools work fine and won't fix them (probably by applying the age old wisdom, IIABDFI).
I suppose I could say IIABDFI about HSI, but HSI hasn't really been deployed here for the most part. You can see a reasonable variation of HSI in the BIND version 8 named.conf file format. Tools already exist to parse it.
I haven't looked at the lisp/scheme-like format that has been mentioned more than once, so I don't even know what you are comparing XML against, or if it even resembles HSI or not.
Maybe we can use something that looks like FORTH to configure with? Nah!
"... sucks" is an opinion, proof is irrelevant.
HTML has more content than tag, so the wordiness of tags isn't a big issue. And many of the tags are dense in usefulness.
But one thing that HTML is NOT is a langauge for defining the namespace of things. if you use a tag to name something, and the tag is as big or nearly as big as the data, and then especially when you duplicate the tag with a / at the end, you end up with as much tag as data.
I don't need to prove that XML is hard to read; I only need to look at it. The closing tags visually obscure the appearance of the data. Sure, I could use a tab between a tag and the data, but in XML, that tab becomes part of the data (I suppose the configurator can then discard spaces and tabs from input after the XML parsing).
My biggest objection of XML is that closing tag. That's entirely redundant. If you simply used some opening/closing character, such as () or {} pairs, then the closing form, e.g. } or ), would pop the stack and close the current item.
If you could nest tags within tags, that could be done in a way that looks like XML, although I don't know if its legal XML. I have not read, nor will I read, a document that describes a language (e.g. XML) for document preparation, because I'm not into doing document preparation. I am into config files, and I would read a document that decribes a language for config files provided that document is strictly about that usage and doesn't waste my time telling me about how document preparation, or anything else, is made better by it.
As for success of HTML based on its readability, even though I do read HTML OK (and prefer not to unless building a web page), take a look at all the web page building tools out there and their explanations "you don't need to read HTML".
To try to retro fit a documentation language into being a configuration language, when others already exist, is what is Stupid(tm).
<signature><sigbody>
/<signame><person>Skapare</person></signame>
</sigbody></signature>
Be that as it may, the large corps are also striving to become bigger and unseat the competition in many (often illegal, and usually inappropriate) ways. They have to get the competition out of the way if they are going to be successful in screwing the consumer.
Sorry, you cannot get mySQL even started if your system won't run because the configuration is messed up.
Whatever the tool is, it must run on the most screwed up system short of one that needs re-installed (probably explains why so many people have to re-install NT so often).
A text editor like vi does the job (even though I would normally use emacs).