> I have never understood how a device with a handful (50 in this case?) computing elements can do better
A thousand cubits can do some really interesting things. If cubits follow Moore's law and double every two years, a thousand cubits is nine years away.
Another nine years would be a million cubits. A million-cubit quantum computer may change our lives much as the classical CPU has done.
Elliptic curve isn't particularly resistant to quantum attacks. It's actually less resistant than good old RSA, given currently popular key sizes for each. If much larger (and slower) keys were used, ECC might survive the first few years of practical quantum computers.
The category of algorithms you use with Truecrypt isn't vulnerable to quantum attacks, as far as we know. Those are symmetric key algorithms, where the same key is used to encrypt and decrypt. AES is the currently recommended symmetric cipher.
I say "as far as we know" they aren't vulnerable because every few years another algorithm gets cracked. We can't be sure which ones will be cracked in the next five years or ten years. We do know some have been used a long time without ever being cracked in the past. We also know that with classical computers, algorithms are normally half cracked years before they are fully cracked - so we get a warning a a few years ahead of time. A new crack using a new kind of computer in clever way might completely defeat any given encryption in one step, though.
What *is* known to be subject to quantum attacks are public key algorithms, where you have a public key and a private key, a pair. These are used for PGP/GPG, TLS, and other instances in which two people need to communicate securely. Quantum-resistant public key algorithms may include the Stehleâ"Steinfeld variant of NTRU. McEliece signature using random Goppa codes hasn't been broken in 30 years, so it looks like a contender. There are many approaches which are likely quantum-resistant. Over the next few years cryptographers with advanced degrees in mathematics will analyze the options and probably come to a rough consensus about which two algorithms are best to adopt next.
Because there will undoubtedly be some suprises once clever people start actually using quantum computers in unexpected ways, it might be prudent to use some sort of belt-and-suspenders approach rather than assuming that one particular algorithm will survive the next 20 years or so.
Reed-Solomon is a block-based ECC rather than stream-based (convolutional) memory errors would effect only that one block.
Probably the most convenient way to use Reed-Solomon, where the math works out nicely, is to apply it to 512-byte blocks. That also happens to be the native size of hard drive sectors, so that's how it's most often used. Each sector has it's own ECC. The ECC of one block doesn't effect any other block. There are several decoding algorithms for Reed-Solomon which may have different characteristics as far as how many bits in that block might be affected by a memory error of one bit.
Extended binary Golay code uses represents 12 bits of data with 24 encoded bits and corrects up to three errors in those 12 bits. It can detect up to seven errors. A memory bit-flip wouldn't be a problem, but eight flipped bits could result in all 12 bits being read incorrectly.
The other class is convolutional (stream-based) codes. As a class, convolutional codes aren't limited to a fixed-size block, so some set of errors could propagate. Of course smart people design these codes, so I can't think of any off hand that are designed such that they actually propagate errors in an unbounded way. The general type would most likely be one that looks a bit like a cross word puzzle of many dimensions - a single bit gives information about many otherwise unrelated bits.
Convolutional codes are typically used "close to the metal", with analog values rather than digital.
Consider you're applying ECC to the electrical signal in a cable, or a wireless signal. The protocol may specify that 1 volt positive (or higher) is logical true, 1 volt negative (or lower) is logical false. Suppose you're using triple modular redundancy, which simply means you send each signal three times. You might read the following values: +1.8 -0.6 +0.3
Even though two of the three values are invalid, we can see that they are clearly biased toward the positive and therefore treat it as logical true. Space probes sending pictures from millions of miles away require convolutional coding with high redundancy.
More generally, be careful of cascading error correction. Some types by nature will not cascade (these can generally be thought of as 1-dimensional), other types should check for a cascading effect before doing a correction.
The magic phrase to Google is "error correction codes" (ECC).
PAR2 uses Reed-Solomon error correction. parchive is the ECC file format specification, for Linux you will want PyPar or par2tbb, and on Windows you use a GUI called QuickPar.
Btrfs can be set to use ECC on a single disk.
You can slice a single disk into partitions and then use RAID1 or LVM mirroring, or RAID5 or RAID6. LVM can alao be useful to divide (and combine) any number of drives into any number of volumes, then you can RAID across the volumes.
If you Google "ecc disk", "ecc backup", or "ecc archive" you'll find other options, with details about each option.
> How would your algorithm handle a eminent scientist making a claim so controversial
If it's controversial, that's the answer Google should give (with the list of links as usual). Where credible sources disagree, there's your quick-answer search result: credible sources disagree.
That's exactly the same (partial) counter-example I thought of when I wrote the post you replied to. I suspect we both thought of that exact same thing, rather than some other statement, precisely because it's so unusual. However, before, during, and after Pauling's vitamin C fetish, other reputable sources showed that Pauling was mistaken (many times). Therefore the algorithm as I described it would not be fooled.
Truth cannot be determined by consensus, of course. However, you can get close (high probability of truth), and the interesting thing is, it's basically just another application of the PageRank algorithm which made Google.
Suppose I showed you sources written by two people who won Nobel prizes in chemistry both saying the same about some chemistry fact, and a Google search revealed no similarly credible sources who disagree. We'd say the laurettes are very likely telling us the truth.
If you look at all of the sources cited in Encyclopedia Britannica, that'll give you a list of pretty credible sources; not perfect but pretty good. The second-order list of sources which are in turn referenced by two or more of the Britannica sources is a much larger list of pretty credible sources. If two or three or four of these sources agree on some statement, AND none disagree, the statement is very likely true.
Here's the information that I found in about two minutes:
The Asterisk community has known about the Sprint patents for many years, and has looked at them.
They probably never affected Asterisk. One patent, however, is about a specific method of silence suppression. Asterisk used some method of silence suppression. It's possible that in the past it used the patented method.
The Asterisk community has had many years to adjust, such as by switching to a different method of silence suppression if needed.
Sprint has sued the big phone companies whose infringement is worth hundreds of millions of dollars. It's probably not worth it to them to sue some company handling dozens of calls per day even if your infringement were flagrant and intentional.
To me whether the judgement is good or bad depends on the facts. The court ruled that Time Warner intentionally broke the law. If that's true, then it's good that the court saw that.
That's a good point. If the complaint itself doesn't already have your name on it, you may not want to give them your name.
Partially that *may* depend on what you can determine about your ISP's policies. What will the ISP do if you don't respond? Also the any demands in the letter.
With a web site, a person who wants the file (or part of the file) sends a request via tcp and the computer that has the requested data the responds by sending it.
With BitTorrent, a person who wants the file (or part of the file) sends a request via tcp and the computer that has the the requested data responds by sending it.
See if you can spot the difference between the two statements above by reading them carefully.
The sending of the (copyright protected) file is the same in either case, and that's the part that runs afoul of copyright law. What's different is only how you *advertise* the availability of the content. A web site might post a web address in a forum. A BitTorrent client posts their address in a tracker. Hosting a file via http or via torrent is still hosting the file either way. I don't think that anywhere in the DMCA you'll find a distinction between tcp port 80 and tcp port 6881.
I have some servers in some racks, connected to some ISPs. With these I provide web hosting services. Some servers are owned by company and shared between clients, some are owned by my company and leased to specific clients, and some are owned by the clients. When we get a DMCA notice, it doesn't matter if it's a client who leases the server from us, a client who owns the server, or a client on a shared server. Regardless, since the material is coming from our IP space, we have to handle it under a certain section of the DMCA, or else lose our safe harbor.
I also have a stack of devices connected to a different ISP. They are not in our IP space. They are in Time Warner's IP space, because they are in my house. Network-wise, they are in Time Warner's network. If these machines unlawfully serve up copyrighted material from Time Warner's network, that fits the same section of the DMCA as my hosting customers serving up such content on my network. If I have a www server on TWC's network, their network is hosting that material just as much as I host my client's sites. If I have a BitTorrent machine offering up the same content, that's no different than offering it up via http.
The DMCA is a bit long at 60 pages, but it's not too complex to read and I find it interesting. I read several drafts as it was being worked on. The slightly tricky part is, as you hinted, keeping the different entities straight. A different type of entity than those discussed above is a pure *transit* provider, where the material does not originate from the IP space. Those entities have no control over the endpoints since they are in some other ISP's network.
You *do* in fact need to store a *lot* of water up hill if you want to have energy when the weather isn't cooperating for a few days at a time, and power electric cars, etc. To provide for all of our energy needs, replacing petrol, heating oil, etc, we need three times as much electricity as we have now.
I did the geographic modeling for the US. Obviously Germany has different geography, but this will give you a general sense to scale. To have three days of pumped storage sufficient to provide for the energy needs of the US, we'd need to flood 1/3rd of the continental United States. Of course that number goes down significantly if you want only a few hours of storage, running nuclear or traditional power plants when the weather isn't suitable for renewable, and if you continue to use gasoline, heating oil, etc for most of your energy needs.
First, I should point out that the letter says the submitter was "sharing" (uploading) the material via a file sharing network. The submitter said "downloaded", but it's the uploading part of torrent, gnutella, etc that is a bigger concern.
The submitter isn't in the US, but people in the US who receive an incorrect notice forwarded by an ISP (including a web host) should respond by writing back a statement that the the received notice is incorrect. This is called a "counter-notice" under the DMCA and basically an ISP must treat the counter-notice as true.
To oversimplify a bit, the DMCA basically says that:
The ISP should cut off the upload / distribution of the material (possibly by cutting off internet access) UNLESS The accused sends back a "counter-notice" saying "no, I didn't do that". Once they receive a counter-notice, the ISP is no longer involved and if the copyright holder wants to pursue it further they have to sue in federal court.
I have to hand it to him, Trump may be rather nuts overall, but he is actually doing what he said he would do, and he is the first person in office to actually address this issue (or even mention it).., which is more than you can say for either the R's or D's that have been president up to now. (I don't really consider Trump to be an 'R', either, for what its worth..he is following his own agenda mostly unrelated to the R party from what I can see.
I also voted against Trump. I also got my wife to come vote for her first time, against Trump. Mostly because a) he said obnoxious things and b) had no political experience. Though on point (a) I know he's made a career of saying things to get media attention - like Hpward Stern, he says stuff to get press converage, and largely believes "there's no such thing as bad publicity". Compare most politicians including Hillary who say whatever they think will get *good* press. Anyway, the dude is obnoxious, though in part that's calculated.
On the other hand, I live in the US, so I want the US President to be a good one. He's the President, so I want to see him do well. He's gotten busy doing exactly what he said he would do. Unlike almost all major politicians, he's not *dependent* on large donors. As you said, he's not really a Republican, hence the whole "Never Trump" thing. The real leader of the Republican party, speaker Paul Ryan, wouldn't endorse Trump. Heck Trump funded the Clinton campaign last time. Not really a Republican. Unfortunately, perhaps, the primary votes from people who wanted a Republican were split between several similar candidates, while Trump very successfully positioned himself as different, as the alternative to "all those guys" (and he *is* different).
Quite clever. Let's be a tad more clear. Is there something you saw tried regarding death penalty policy that has worked so well in Oklahoma that you want to apply the same approach more broadly?
Or are you pointing that the approach you favor for all issues has utterly and completely failed when applied to the death penatly debate?
> And more relevant to this case, the BSD license vs the GNU license. Generalizing, the BSD license lets you do whatever you want with open source. OTOH if you use GNU-licensed open source to create something, you are required to release what you do as GNU-licensed open source itself. > > Honestly I don't know for certain which is actually better, or if one is better in some situations, the other better in other situations.
It seems to me that each fits different needs slightly better. Certainly, the GPLv2 has been wildly successful, with Linux and millions of other software packages. We all know what the BSD licenses are, more or less, so apparently they are successful too - you don't know about the Morris Public License, because it wasn't successful. What I choose for a particular project depends on my goals and how I expect it to be used.
We'll see how GPLv3 does compared to GPLv2. Personally, I don't use GPL v3 at all, if I have the option.
The protection isn't in the Javascript. The protection is that the content is encrypted with AES. Only a user with the key can decrypt the content. The Javascript is "clever" only in that it manipulates html tags that the browser doesn't natively understand, etc.
> there will be a script to rip the content in -3 seconds,
Absolutely. EME doesn't provide any protection whatsoever against an authorized user ripping the content. That's outside the scope of EME. The one decryption that option that's required to be supported, Clear Key (simple, unadorned aes) *only* ensures the content is available only to authorized users (who have the key). It has no protection against ripping or anything else done by authorized users.
> making the DRM pointless.
Right, there is no DRM in EME, or required by EME. EME is a small set of functions for a browser to find out how it should play some content. That "how" is separate from EME. EME could be used to say "this video is compressed zip version 9, unzip it with a compatible program before playing it". Or it could be used to tell the browser "this video is available in four bitrates and three codecs." Or it could be used to say "decode this video with a module called opendrm". Those things are separate from EME.
> Nobody has a EME implementation for ARM, MIPS... It will mean the beginning of the Intel-only web.
That is factually incorrect. See Chromium for one open source example. EME can call any CDM, only one is required, called Clear Key. Clear Key is basically "the video is encrypted with AES, prompt the user to copy-paste the key". Clear Key (and therefore EME) can be implemented in nothing more than (clever) Javascript, so any platform that can run Javascript can run EME.
Of course it isn't *normally* implemented in Javascript, but it can be.
Bad code, and bad coders, sure are very common. I can absolutely relate to what you said.
Bad code isn't in any way limited to declarative programming, or imperative, or procedural, functional, object-oriented...
Poorly educated programmers can make a mess in every paradigm, and those who continually study for many years to become highly competent can be highly competent with any paradigm. The language or paradigm isn't what makes the difference.
Right now, at work, I'm fixing some bad SQL written by the founder of the company. (Who wrote a huge system by himself in a hurry, with limited programming knowledge.) Some of the SQL is pretty bad. I'm also fixing his bad Perl, which is even worse. Procedural programming (Perl, Java) didn't make him any better or worse than he was using SQL.
If a programmer can learn to use C, Perl, Java, or Erlang well, they can learn to use SQL well. If they can learn to use C, Perl, Java, or Erlang poorly, they can learn to use SQL poorly.
> As soon as you introduce selective DRM for selected platforms and devices, it's not universal anymore.
"Selected platforms and devices" is what we get without a standard. We know that because we've tried that for 25 years. How many years could Linux users not access Netflix. When I first got involved with the IETF (web standards group), ActiveX was the popular way to implement DRM. Meaning you could only see the content using Internet Explorer on Windows. Talk about "selected platforms"! Later DRM on the web commonly used Java for a few years, then Flash. Flash-based DRM lasted for many years, and there are still many sites that require the security nightmare known as Flash because that's how they do their DRM.
Note in the above paragraph I never used the word "should". This isn't about what publishers "should" do, or what we'd like them to do. It's about what they actually do. What they actually do is require Flash in the best case DRM, and implement the Sony rootkit in other cases. Of course there are almost as many different ways of doing DRM as there are publishers using it - there is no standard.
On the other hand, we've long had standards for video and images such as mpeg and jpeg. Are those limited to "selected platforms and devices"? No, the entire point of standardization is that a standard can be implemented on any platform and device.
I've personally made the case against DRM to probably 100 of my customers (qho arw publishers) yet so many of them decide to go ahead and use DRM. About half choose a DRM solution that means I can't see their content on my device. Would a rather they each come up with their own incompatible, annoying DRM that doesn't let me view the content, or would I rather they use a compatible, cross-platform standard that anyone can view, developed with input from users? Given the options we actually have, I'd rather be involved in developing a usable standard than have another generation of Flash-based sites and Sony rootkits.
Slashdot Mirror
> I have never understood how a device with a handful (50 in this case?) computing elements can do better
A thousand cubits can do some really interesting things. If cubits follow Moore's law and double every two years, a thousand cubits is nine years away.
Another nine years would be a million cubits. A million-cubit quantum computer may change our lives much as the classical CPU has done.
Elliptic curve isn't particularly resistant to quantum attacks. It's actually less resistant than good old RSA, given currently popular key sizes for each. If much larger (and slower) keys were used, ECC might survive the first few years of practical quantum computers.
The category of algorithms you use with Truecrypt isn't vulnerable to quantum attacks, as far as we know. Those are symmetric key algorithms, where the same key is used to encrypt and decrypt. AES is the currently recommended symmetric cipher.
I say "as far as we know" they aren't vulnerable because every few years another algorithm gets cracked. We can't be sure which ones will be cracked in the next five years or ten years. We do know some have been used a long time without ever being cracked in the past. We also know that with classical computers, algorithms are normally half cracked years before they are fully cracked - so we get a warning a a few years ahead of time. A new crack using a new kind of computer in clever way might completely defeat any given encryption in one step, though.
What *is* known to be subject to quantum attacks are public key algorithms, where you have a public key and a private key, a pair. These are used for PGP/GPG, TLS, and other instances in which two people need to communicate securely. Quantum-resistant public key algorithms may include the Stehleâ"Steinfeld variant of NTRU. McEliece signature using random Goppa codes hasn't been broken in 30 years, so it looks like a contender. There are many approaches which are likely quantum-resistant. Over the next few years cryptographers with advanced degrees in mathematics will analyze the options and probably come to a rough consensus about which two algorithms are best to adopt next.
Because there will undoubtedly be some suprises once clever people start actually using quantum computers in unexpected ways, it might be prudent to use some sort of belt-and-suspenders approach rather than assuming that one particular algorithm will survive the next 20 years or so.
Reed-Solomon is a block-based ECC rather than stream-based (convolutional) memory errors would effect only that one block.
Probably the most convenient way to use Reed-Solomon, where the math works out nicely, is to apply it to 512-byte blocks. That also happens to be the native size of hard drive sectors, so that's how it's most often used. Each sector has it's own ECC. The ECC of one block doesn't effect any other block. There are several decoding algorithms for Reed-Solomon which may have different characteristics as far as how many bits in that block might be affected by a memory error of one bit.
Extended binary Golay code uses represents 12 bits of data with 24 encoded bits and corrects up to three errors in those 12 bits. It can detect up to seven errors. A memory bit-flip wouldn't be a problem, but eight flipped bits could result in all 12 bits being read incorrectly.
The other class is convolutional (stream-based) codes. As a class, convolutional codes aren't limited to a fixed-size block, so some set of errors could propagate. Of course smart people design these codes, so I can't think of any off hand that are designed such that they actually propagate errors in an unbounded way. The general type would most likely be one that looks a bit like a cross word puzzle of many dimensions - a single bit gives information about many otherwise unrelated bits.
Convolutional codes are typically used "close to the metal", with analog values rather than digital.
Consider you're applying ECC to the electrical signal in a cable, or a wireless signal. The protocol may specify that 1 volt positive (or higher) is logical true, 1 volt negative (or lower) is logical false. Suppose you're using triple modular redundancy, which simply means you send each signal three times. You might read the following values:
+1.8
-0.6
+0.3
Even though two of the three values are invalid, we can see that they are clearly biased toward the positive and therefore treat it as logical true. Space probes sending pictures from millions of miles away require convolutional coding with high redundancy.
More generally, be careful of cascading error correction. Some types by nature will not cascade (these can generally be thought of as 1-dimensional), other types should check for a cascading effect before doing a correction.
Just in case anyone is unaware, UC Berkeley has over $4 billion.
The magic phrase to Google is "error correction codes" (ECC).
PAR2 uses Reed-Solomon error correction. parchive is the ECC file format specification, for Linux you will want PyPar or par2tbb, and on Windows you use a GUI called QuickPar.
Btrfs can be set to use ECC on a single disk.
You can slice a single disk into partitions and then use RAID1 or LVM mirroring, or RAID5 or RAID6. LVM can alao be useful to divide (and combine) any number of drives into any number of volumes, then you can RAID across the volumes.
If you Google "ecc disk", "ecc backup", or "ecc archive" you'll find other options, with details about each option.
> How would your algorithm handle a eminent scientist making a claim so controversial
If it's controversial, that's the answer Google should give (with the list of links as usual). Where credible sources disagree, there's your quick-answer search result: credible sources disagree.
That's exactly the same (partial) counter-example I thought of when I wrote the post you replied to. I suspect we both thought of that exact same thing, rather than some other statement, precisely because it's so unusual. However, before, during, and after Pauling's vitamin C fetish, other reputable sources showed that Pauling was mistaken (many times). Therefore the algorithm as I described it would not be fooled.
Truth cannot be determined by consensus, of course. However, you can get close (high probability of truth), and the interesting thing is, it's basically just another application of the PageRank algorithm which made Google.
Suppose I showed you sources written by two people who won Nobel prizes in chemistry both saying the same about some chemistry fact, and a Google search revealed no similarly credible sources who disagree. We'd say the laurettes are very likely telling us the truth.
If you look at all of the sources cited in Encyclopedia Britannica, that'll give you a list of pretty credible sources; not perfect but pretty good. The second-order list of sources which are in turn referenced by two or more of the Britannica sources is a much larger list of pretty credible sources. If two or three or four of these sources agree on some statement, AND none disagree, the statement is very likely true.
In a secret box IBM has a quantum computer. It' ready to ship. And it's not. They call it Computer Advanced Technology, or CAT.
Here's the information that I found in about two minutes:
The Asterisk community has known about the Sprint patents for many years, and has looked at them.
They probably never affected Asterisk. One patent, however, is about a specific method of silence suppression. Asterisk used some method of silence suppression. It's possible that in the past it used the patented method.
The Asterisk community has had many years to adjust, such as by switching to a different method of silence suppression if needed.
Sprint has sued the big phone companies whose infringement is worth hundreds of millions of dollars. It's probably not worth it to them to sue some company handling dozens of calls per day even if your infringement were flagrant and intentional.
To me whether the judgement is good or bad depends on the facts. The court ruled that Time Warner intentionally broke the law. If that's true, then it's good that the court saw that.
That's a good point. If the complaint itself doesn't already have your name on it, you may not want to give them your name.
Partially that *may* depend on what you can determine about your ISP's policies. What will the ISP do if you don't respond? Also the any demands in the letter.
With a web site, a person who wants the file (or part of the file) sends a request via tcp and the computer that has the requested data the responds by sending it.
With BitTorrent, a person who wants the file (or part of the file) sends a request via tcp and the computer that has the the requested data responds by sending it.
See if you can spot the difference between the two statements above by reading them carefully.
The sending of the (copyright protected) file is the same in either case, and that's the part that runs afoul of copyright law. What's different is only how you *advertise* the availability of the content. A web site might post a web address in a forum. A BitTorrent client posts their address in a tracker. Hosting a file via http or via torrent is still hosting the file either way. I don't think that anywhere in the DMCA you'll find a distinction between tcp port 80 and tcp port 6881.
I have some servers in some racks, connected to some ISPs. With these I provide web hosting services. Some servers are owned by company and shared between clients, some are owned by my company and leased to specific clients, and some are owned by the clients. When we get a DMCA notice, it doesn't matter if it's a client who leases the server from us, a client who owns the server, or a client on a shared server. Regardless, since the material is coming from our IP space, we have to handle it under a certain section of the DMCA, or else lose our safe harbor.
I also have a stack of devices connected to a different ISP. They are not in our IP space. They are in Time Warner's IP space, because they are in my house. Network-wise, they are in Time Warner's network. If these machines unlawfully serve up copyrighted material from Time Warner's network, that fits the same section of the DMCA as my hosting customers serving up such content on my network. If I have a www server on TWC's network, their network is hosting that material just as much as I host my client's sites. If I have a BitTorrent machine offering up the same content, that's no different than offering it up via http.
The DMCA is a bit long at 60 pages, but it's not too complex to read and I find it interesting. I read several drafts as it was being worked on. The slightly tricky part is, as you hinted, keeping the different entities straight. A different type of entity than those discussed above is a pure *transit* provider, where the material does not originate from the IP space. Those entities have no control over the endpoints since they are in some other ISP's network.
You *do* in fact need to store a *lot* of water up hill if you want to have energy when the weather isn't cooperating for a few days at a time, and power electric cars, etc. To provide for all of our energy needs, replacing petrol, heating oil, etc, we need three times as much electricity as we have now.
I did the geographic modeling for the US. Obviously Germany has different geography, but this will give you a general sense to scale. To have three days of pumped storage sufficient to provide for the energy needs of the US, we'd need to flood 1/3rd of the continental United States. Of course that number goes down significantly if you want only a few hours of storage, running nuclear or traditional power plants when the weather isn't suitable for renewable, and if you continue to use gasoline, heating oil, etc for most of your energy needs.
First, I should point out that the letter says the submitter was "sharing" (uploading) the material via a file sharing network. The submitter said "downloaded", but it's the uploading part of torrent, gnutella, etc that is a bigger concern.
The submitter isn't in the US, but people in the US who receive an incorrect notice forwarded by an ISP (including a web host) should respond by writing back a statement that the the received notice is incorrect. This is called a "counter-notice" under the DMCA and basically an ISP must treat the counter-notice as true.
To oversimplify a bit, the DMCA basically says that:
The ISP should cut off the upload / distribution of the material (possibly by cutting off internet access) UNLESS
The accused sends back a "counter-notice" saying "no, I didn't do that".
Once they receive a counter-notice, the ISP is no longer involved and if the copyright holder wants to pursue it further they have to sue in federal court.
The counter-notice needs to include certain information, so using a template makes sense.
https://www.google.com/search?...
I have to hand it to him, Trump may be rather nuts overall, but he is actually doing what he said he would do, and he is the first person in office to actually address this issue (or even mention it).., which is more than you can say for either the R's or D's that have been president up to now. (I don't really consider Trump to be an 'R', either, for what its worth..he is following his own agenda mostly unrelated to the R party from what I can see.
I also voted against Trump. I also got my wife to come vote for her first time, against Trump. Mostly because a) he said obnoxious things and b) had no political experience. Though on point (a) I know he's made a career of saying things to get media attention - like Hpward Stern, he says stuff to get press converage, and largely believes "there's no such thing as bad publicity". Compare most politicians including Hillary who say whatever they think will get *good* press. Anyway, the dude is obnoxious, though in part that's calculated.
On the other hand, I live in the US, so I want the US President to be a good one. He's the President, so I want to see him do well. He's gotten busy doing exactly what he said he would do. Unlike almost all major politicians, he's not *dependent* on large donors. As you said, he's not really a Republican, hence the whole "Never Trump" thing. The real leader of the Republican party, speaker Paul Ryan, wouldn't endorse Trump. Heck Trump funded the Clinton campaign last time. Not really a Republican. Unfortunately, perhaps, the primary votes from people who wanted a Republican were split between several similar candidates, while Trump very successfully positioned himself as different, as the alternative to "all those guys" (and he *is* different).
Quite clever. Let's be a tad more clear. Is there something you saw tried regarding death penalty policy that has worked so well in Oklahoma that you want to apply the same approach more broadly?
Or are you pointing that the approach you favor for all issues has utterly and completely failed when applied to the death penatly debate?
> And more relevant to this case, the BSD license vs the GNU license. Generalizing, the BSD license lets you do whatever you want with open source. OTOH if you use GNU-licensed open source to create something, you are required to release what you do as GNU-licensed open source itself.
>
> Honestly I don't know for certain which is actually better, or if one is better in some situations, the other better in other situations.
It seems to me that each fits different needs slightly better. Certainly, the GPLv2 has been wildly successful, with Linux and millions of other software packages. We all know what the BSD licenses are, more or less, so apparently they are successful too - you don't know about the Morris Public License, because it wasn't successful. What I choose for a particular project depends on my goals and how I expect it to be used.
We'll see how GPLv3 does compared to GPLv2. Personally, I don't use GPL v3 at all, if I have the option.
> Clear Key will not work on ANY site, so its existence is irrelevant.
It *is* working, and has been working.
It always amuses me when people predict the *past* and still manage to get it wrong.
> if the only protection is clever javascript
The protection isn't in the Javascript. The protection is that the content is encrypted with AES. Only a user with the key can decrypt the content. The Javascript is "clever" only in that it manipulates html tags that the browser doesn't natively understand, etc.
> there will be a script to rip the content in -3 seconds,
Absolutely. EME doesn't provide any protection whatsoever against an authorized user ripping the content. That's outside the scope of EME. The one decryption that option that's required to be supported, Clear Key (simple, unadorned aes) *only* ensures the content is available only to authorized users (who have the key). It has no protection against ripping or anything else done by authorized users.
> making the DRM pointless.
Right, there is no DRM in EME, or required by EME. EME is a small set of functions for a browser to find out how it should play some content. That "how" is separate from EME. EME could be used to say "this video is compressed zip version 9, unzip it with a compatible program before playing it". Or it could be used to tell the browser "this video is available in four bitrates and three codecs." Or it could be used to say "decode this video with a module called opendrm". Those things are separate from EME.
Yeah the web has been a complete failure under W3C and IETF. I'd never use the web, and I'm sure you wouldn't either.
> Nobody has a EME implementation for ARM, MIPS ...
It will mean the beginning of the Intel-only web.
That is factually incorrect. See Chromium for one open source example. EME can call any CDM, only one is required, called Clear Key. Clear Key is basically "the video is encrypted with AES, prompt the user to copy-paste the key". Clear Key (and therefore EME) can be implemented in nothing more than (clever) Javascript, so any platform that can run Javascript can run EME.
Of course it isn't *normally* implemented in Javascript, but it can be.
Bad code, and bad coders, sure are very common. I can absolutely relate to what you said.
Bad code isn't in any way limited to declarative programming, or imperative, or procedural, functional, object-oriented ...
Poorly educated programmers can make a mess in every paradigm, and those who continually study for many years to become highly competent can be highly competent with any paradigm. The language or paradigm isn't what makes the difference.
Right now, at work, I'm fixing some bad SQL written by the founder of the company. (Who wrote a huge system by himself in a hurry, with limited programming knowledge.) Some of the SQL is pretty bad. I'm also fixing his bad Perl, which is even worse. Procedural programming (Perl, Java) didn't make him any better or worse than he was using SQL.
If a programmer can learn to use C, Perl, Java, or Erlang well, they can learn to use SQL well. If they can learn to use C, Perl, Java, or Erlang poorly, they can learn to use SQL poorly.
> As soon as you introduce selective DRM for selected platforms and devices, it's not universal anymore.
"Selected platforms and devices" is what we get without a standard. We know that because we've tried that for 25 years. How many years could Linux users not access Netflix. When I first got involved with the IETF (web standards group), ActiveX was the popular way to implement DRM. Meaning you could only see the content using Internet Explorer on Windows. Talk about "selected platforms"! Later DRM on the web commonly used Java for a few years, then Flash. Flash-based DRM lasted for many years, and there are still many sites that require the security nightmare known as Flash because that's how they do their DRM.
Note in the above paragraph I never used the word "should". This isn't about what publishers "should" do, or what we'd like them to do. It's about what they actually do. What they actually do is require Flash in the best case DRM, and implement the Sony rootkit in other cases. Of course there are almost as many different ways of doing DRM as there are publishers using it - there is no standard.
On the other hand, we've long had standards for video and images such as mpeg and jpeg. Are those limited to "selected platforms and devices"? No, the entire point of standardization is that a standard can be implemented on any platform and device.
I've personally made the case against DRM to probably 100 of my customers (qho arw publishers) yet so many of them decide to go ahead and use DRM. About half choose a DRM solution that means I can't see their content on my device. Would a rather they each come up with their own incompatible, annoying DRM that doesn't let me view the content, or would I rather they use a compatible, cross-platform standard that anyone can view, developed with input from users? Given the options we actually have, I'd rather be involved in developing a usable standard than have another generation of Flash-based sites and Sony rootkits.