I see no real difference. The magnitude of a crime makes no difference, unless you allow yourself to be blinded by it. The simple fact is that you have to proof who comitted the crime beyond any doubt -- unless you think it is acceptable that sometimes you put away innocent people for life. The simple fact is, an IP address tells you absolutely nothing about who is sitting behind the computer at the time. It could be me, it could be my gf, it could be my neighbour who has the keys to my house, or it could be the kid on the other side of the street who hacked my router.
For the REAL crimes, there are other ways of getting decent proof (like installing surveillance devices in the houses of suspected criminals, keyboard loggers, camera's, that sort of stuff). The RIAA however is not allowed to do this, nor could it justify it for such a minor crime (if it even is a crime in your country of origin, it isn't in mine), so they have to rely on circumstancial evidence that basically proofs nothing about who actually perpetrated the crime.
That's funny, DRM being used to reduce the appeal of free content, and here I thought it was about enabling the user to partake in a new digital experience! I guess atleast someone in the government realizes what DRM really does:)
Nah, it won't take off. First of all, HDDVD movies aren't all that big, they're about 10-15 GB a piece at 1920x1080x25fps. At this size, they're near perfect. I don't see any encoding artifacts at all, unlike DVD's where I can point them out easily. This is mainly because they're using much more efficient codecs now (H.264) versus the rather old and worn MPEG2 that is used on DVD's.
Second, HDDVD's as a media are already too small. When I got my first CD-ROM drive, CD-ROM's were HUGE. 600 MB.. that was like the same size as my biggest hard drive at the time. When DVD's finally came, 4 GB was already not really a big deal anymore and I never even considered using them for backup purposes because they were too small. Now with HDDVD, I'm looking at a stack of 50 of them just to backup my little 2.5TB raid array, and they're not even commercially available yet at a decent price.
From an economic standpoint, I doubt HDDVD-burning systems will ever be able to compete with today's hard drives, which already are low as 500 GB for $100 (that's about 25 HD-DVD movies in their original format in a smaller and faster package).
Finally, decoding H.264 at 1920x1080 does take some horsepower, but my measly AMD 3000+ can almost do it realtime (only occasional stuttering with MPlayer on Linux, definitely watchable) then I'm sure it will have no problems with it once I upgrade that machine to one of the Core2Duo processors.
I think what they mean is that you are allowed to modify the software (ie, software under the GPL) and then distribute it again without having to worry about being sued, as opposed to modifying closed software and then distributing your changes.
It seems accurate enough to me, although it perhaps is a bit incomplete and over generalized.
That 10 GB also contains a movie that works in said Vista environment. So someone buys a movie legally, copies it to Vista and is allowed to play it. That person than zips up the entire VM (including the movie) and makes a torrent out of it.
End result, everyone can run the VM and watch the movie, then discard the VM again.
I guess that's what they fear. What they really should be worried about though is that they've put themselves in a position they can never hope to win by using DRM.
Both are analog holes. If it's not a digital copy, it's not a quality copy, and thus not in a position to compete with the real thing.
Actually, you are wrong here. Analog copying could be a problem when in the process an analog copy was made multiple times and the content would degrade a bit further each time. However, the first analog copy will be more than acceptable (and might well be indistinguishable from the original by a set of viewers doing a double blind test).
So, if you can make a good analog copy, then digitize that in a format that is not DRM encumbered then it can be copied an infinite number of times without degradation. If it is close enough to the original that people can't tell whether it is the original or just a very good copy, then it doesn't matter anymore -- the damage will have been done, the copy will have spread over the internet and people will have enjoyed it thinking it was a digital rip.
It really is ridiculous to say that only a digital copy is acceptable when it is possible to make very accurate analog copies, take for example my 1600x1200 TFT screen which is connected with an ANALOG VGA cable -- the display automatically tunes itself to this signal and I donot notice the difference between using the analog VGA cable and my digital DVI cable -- that's how accurate an analog copy could be. In other words, even if they manage to close the digital hole it will be pointless without closing the analog hole as well.
Seriously, I think you really should use strong crypto as much as you can. If an issue is made out of it, then perhaps it will become clear once and for all that crypto is here to stay and that you can't stop people from using it.
Strong crypto looks a lot like many other forms of data you will see traveling over a line -- it's practically random. It would be very hard to proof that what you're sending is not plain random data, or say some kind of compression or movie format (possibly with identifying headers stripped out). Or you could even add some of those headers in your crypto stream making it look like an AVI movie, which just happens to not work at all because the contents are all garbled.
I can't really think of any way you could prevent people from sending random data, I can't even think of a good way to identify whether a piece of data is part of a movie, mp3 or zip, and not strong crypto disguised to look like such data.
So you think I couldn't write a program that uses an unencrypted protocol like HTTP to send encrypted content anyway? What are they gonna do? Verify I actually send readable english when I send stuff with HTTP headers?
In other words, it won't be long before my spam filters will automatically mark such mails as spam as well at which point Goodmail will have shot themselves in the foot.
Spam may be a problem for your inbox, but for ISP's, the bandwidth spam takes up is a drop in the bucket. The real bandwidth hogs these days are audio/video streaming and various P2P protocols (especially BitTorrent takes up a sizable chunk of bandwidth).
Or just look at your Dutch neighbours, they have a lot of competing ISP's while Belgium only has a few (and I believe all of them are using the same network which charges very high rates). A little competition goes a long way, because in the Netherlands, ISP's not only offer cheaper service, they offer faster service without data limits (my ISP doesn't even blink when I download 200 GB+ for months in a row).
The Dutch government has forced the owners of the biggest telephony and data networks to open their networks up and offer the use of their network (for reasonable rates) to any other telephony/ISP company that cares for using it.
There's also a government mandated group that keeps an eye on telecom providers making sure everyone behaves (no price fixing, reasonable network pricing, no tricks to keep networks closed or other anti-competitive practices), and they have the power to hand out severe fines when they're in violation and have done often enough in the past.
...or you get some ISP's to compete with each other. Where I live, I can get broadband from a dozen different providers (and that's just DSL) and they compete for their customers. My ISP used to have a "fair use policy", which effectively meant that they would start whining if you used too much bandwidth (apparently using 200 GB/month was not enough to trigger this). Two years ago they discontinued the fair use policy and basically claim there are no limits.
In all the time I have been their customer, I've had almost no downtime (I'm connected 24/7), never even suspected they might be throttling (they're not), and never have I had a reason to think that I may not be getting the full bandwidth while I was downloading something because the line was overbooked.
On top of that, over the years, my bandwidth has doubled several times and the price has declined, paying about $40 for 5mbit/1mbit. For me, this is effectively unlimited as I can't think of ways anymore to use it all up (although I still use about 80 GB up + 80 GB down every month)... What I think is that my ISP has realized what apparently some ISP's haven't yet, at some point, harddisks are full. At 200 GB/month that's pretty fast.
Piracy is not caused by poverty. Professor Zhang of Nanjing University found the Chinese citizens who bought pirate products were mainly middle- or higher-income earners.
LOL, this is priceless. The lower class Chinese citizens can't afford a CD or DVD player -- that's why they don't pirate.
I recently talked to someone in the same situation, and he wanted to create a system with 3x 500 GB disks in a RAID5 configuration. The problem is that it's tough to upgrade later on when you have an odd number of disks in your RAID5 (like 3 or 5 disks). Sets of 4 or 6 are easier to upgrade later on, consider this example:
Let's say you start with 4x 500 GB, for a total effective space of 1.5 TB in RAID5, at some point this array fills up and you want to upgrade. So you buy 2x 1 TB drives. Create two 500 GB partitions on each of these 1 TB drives. Now copy the data from the existing RAID5 to the new drives. Drop your old RAID5 array, and now copy some of the data back to the old 500 GB drives until you have two empty 500 GB drives, and one empty 500 GB partition on each of the 1 TB drives. Create a new four disk array using two 500 GB partitions from the 1 TB drives and two of your old 500 GB drives -- copy your data to the new array. Then create another RAID5 array with the remaining four partitions. You now have two RAID5 arrays of 1.5 TB each and a total of 6 drives.
At some point of course, these two arrays will become full, and you need to upgrade again. This time buy 2x 1.5 TB drives (hopefully they'll exist by then). Create a 1 TB partition and a 500 GB partition on each of the 1.5 TB drives. Now you'll need to move data around again (if needed you may need to temporarily run a degraded RAID5 array with only 3 disks), but the end result should be that you get two RAID 5 arrays again, one consisting of 4x 1 TB (for 3 TB of space), and another which consists of 4x 500 GB. Remove two of the unused 500 GB drives from your server so you have a maximum of 6 drives again.
You can repeat this as often as you want, as long as you can find new drives that are big enough (for each upgrade step you'll need a drive that's as large as your largest and smallest drive combined), so the next step would be adding 2x 2.5 TB drives, copying your data, and removing the two smallest drives.
This method of upgrading only really works with an even amount of disks in a RAID5 array, I personally use arrays of 6 drives (for a total of 9 drives in my server, which have two overlapping RAID5 arrays of 6 partitions each).
Your CPU's run at less than 10C above ambient because it has a huge cooler sitting on top -- the CPU may be cool, but only bacause a lot of heat is extracted from it and pumped out of the system.
One other point I'd like to make, which may also affect your browsing experience, even though a lot of stuff has gotten faster and bigger, a lot of stuff is still about the same as 10 years ago. For example, 10 years ago, I was using a display not that much worse as the one I'm using now (1600x1200 vs 1280x960 then, both in 24 bit), if displays evolved like CPU's, I'd expect to be using a high resolution (300 dpi orso) 8000x6000 display or something by now.
Something similar goes for harddisks -- they still have roughly the same access time as 10 years ago (around 10 ms). Sure they have higher top speeds (10 MB/sec is now like 70 MB/sec) and larger capacity but they're still incredibly slow at loading lots of data from lots of different locations. So if firing up your browser means stuff needs to be loaded from disk, then it will be as slow as always. The only way to speed this up would be to have some intelligent caching (preloading stuff) or making sure everything browser related can be read in one huge chunk of data. I just never unload my browser (and I have swap off) so a new window opens instantly when I want it).
There's one thing I've noticed about modern computers (Windows and Linux). None of them know how to properly manage the disk cache, and they will just keep increasing its size even at the expense of (background) programs. The end result is that when I get back to those background programs, they are sluggish because they're being swapped in. Why these programs deserve to be swapped out to disk so instead of 1.6 GB of disk cache Windows can use 1.7 GB of disk cache is totally beyond me -- eventually I got tired of it and I simply completely disabled swap -- what happens then is a miracle... every program is fast and responsive all the time, even if I hadn't touched it for days.
The worst part of this is though the total stupidity of how disk caching is handled -- a good example is what happens to your system when you watch a movie for 2 hours -- it thinks that (even though we're requesting video data at a rate of like 150 kB/sec) it would be a good idea to completely cache all of this data, to the point of swapping out everything else to disk. After watching your movie, you can make a new coffee before other programs become useable again. So I just keep swap turned off, it will have no choice but the use smaller disk caches and it will leave the stuff I choose to have running alone.
Since C is not Object Orientated Programming, I would classify you as a beginning Java/C#/Perl/Python programmer who will have a LOT to learn (especially in Java where Object Orientation seems to really thrive). I would definitely expect an experienced programmer to understand basic concepts like classes, instances, encapsulation, inheritance and polymorphism, not to mention the dozens of patterns that are used all throughout Java. With only C experience, you will still need years to master OO programming and design.
Actually, I think it's not as bad as you think -- you assume that a 10 times faster CPU actually performs 10 times faster in every way, unfortunately it usually means that the CPU wastes 10 times more cycles waiting on stuff. Yes, there are lots of things that used to take 20 cycles that now take 4000 cycles, but mostly those things are not time-critical anyway (like user interaction, anything that has to access the network or harddisk -- webservers spring to mind). For example, does it really matter if my GUI code runs in 20 cycles vs 4000 cycles? No, it won't make any difference at all -- the bottle neck here is how fast a user can click (and how fast the graphic card can render all those "special" effects users seem to love these days). Optimizing that code to run in 20 cycles won't give any performance increase at all -- optimizing it would not only be a waste of time, but would be like fixing something that already works -- the best case you can hope for is to get a faster piece of code with as much bugs as the original.. usually however it will introduce new bugs.
Now let's take this a bit further -- how much of a performance hit do you take when you access memory that is not in the CPU's cache (or 2nd level cache)? The CPU will have to wait for the memory to be available... optimizing code that frequently accesses memory outside the cache would be useless (and would just mean the CPU has to wait a bit longer). Let's take quicksort, the algorithm isn't particularly hard but accesses memory a lot. Would it matter if one iteration takes 20 cycles or 40 cycles on a modern CPU (let's assume that's the difference between C and Java)? It will make little difference, the CPU has to wait for data anyway. In the end, even in such a low level algorithm, it will make little difference whether we used a very efficient piece of code, or a slightly less efficient one -- the bottleneck is the memory. In other words, as long as the algorithm you use is the same, both pieces of code should be about as efficient.
The only time optimizing is still worth it is when you are doing stuff in tight loops that isn't randomly accessing memory for all kinds of reasons (and which of course is used to do a lot of bulk processing, like video encoding) -- it's hard to even think of a good example, but I suppose it might be worth using more efficient code in signal processing, compression/decompression and rendering applications. Even in those cases however a lot of stuff is handled in optimized libraries for higher level languages.. I mean, it won't make any difference if I use Bash (horribly inefficient!) to call my favourite Unzip program to unzip a multi-megabyte file, or whether I wrote a C program to do the same. It would still take as long.
If by "register", you mean, that it is put into a searchable database that can later be used by evildoers to monitor a certain individuals position, you are wrong. Nobody is extracting license plates, and putting them into a database. Even the government have better things to waste taxpayer money on.
You do realize that any lowly desktop PC is quite sufficient to scan a video stream and extract license plates from it right? Face recognition is not currently possible with such low resources, but license plates are trivial to extract due to their easy recognizable nature. Storing them with a time and location in a searchable database is equally trivial and would hardly have much costs associated with it at all.
In other words, in combination with all the other surveillance devices it will become more and more trivial to plot where a certain license plate was at almost any point in time (for the times you donot have data points you can make educated guesses based on travel time between the data points you do have).
Face recognition may not be computationally feasible right now (or maybe it already is... I do believe a facial scan is one of the new things required to obtain a passport in the UK), it definitely will be as trivial to do as license plate recognition in a few years from now.
On the other hand, if by "register", you mean, that it can be read later by an observer looking at the recording, you are also wrong; the cameras most likely have far too low resolution, and low shutter speed, to capture anything but the license plate of slow-moving or still objects close to the warden, if he looks directly at it.
I doubt it, camera's have come a long way, shutter speed definitely is not an issue in an outside environment (you can capture perfectly sharp stills every second for example). If you only capture every second (more than sufficient for the purpose this is going to serve), then you can also use high resolution without exceeding storage constraints -- that is, if they even bother to store it all, they could also just send it directly to another computer using existing technology.
Slashdot Mirror
For the REAL crimes, there are other ways of getting decent proof (like installing surveillance devices in the houses of suspected criminals, keyboard loggers, camera's, that sort of stuff). The RIAA however is not allowed to do this, nor could it justify it for such a minor crime (if it even is a crime in your country of origin, it isn't in mine), so they have to rely on circumstancial evidence that basically proofs nothing about who actually perpetrated the crime.
That's funny, DRM being used to reduce the appeal of free content, and here I thought it was about enabling the user to partake in a new digital experience! I guess atleast someone in the government realizes what DRM really does :)
Second, HDDVD's as a media are already too small. When I got my first CD-ROM drive, CD-ROM's were HUGE. 600 MB.. that was like the same size as my biggest hard drive at the time. When DVD's finally came, 4 GB was already not really a big deal anymore and I never even considered using them for backup purposes because they were too small. Now with HDDVD, I'm looking at a stack of 50 of them just to backup my little 2.5TB raid array, and they're not even commercially available yet at a decent price.
From an economic standpoint, I doubt HDDVD-burning systems will ever be able to compete with today's hard drives, which already are low as 500 GB for $100 (that's about 25 HD-DVD movies in their original format in a smaller and faster package).
Finally, decoding H.264 at 1920x1080 does take some horsepower, but my measly AMD 3000+ can almost do it realtime (only occasional stuttering with MPlayer on Linux, definitely watchable) then I'm sure it will have no problems with it once I upgrade that machine to one of the Core2Duo processors.
It seems accurate enough to me, although it perhaps is a bit incomplete and over generalized.
End result, everyone can run the VM and watch the movie, then discard the VM again.
I guess that's what they fear. What they really should be worried about though is that they've put themselves in a position they can never hope to win by using DRM.
So, if you can make a good analog copy, then digitize that in a format that is not DRM encumbered then it can be copied an infinite number of times without degradation. If it is close enough to the original that people can't tell whether it is the original or just a very good copy, then it doesn't matter anymore -- the damage will have been done, the copy will have spread over the internet and people will have enjoyed it thinking it was a digital rip.
It really is ridiculous to say that only a digital copy is acceptable when it is possible to make very accurate analog copies, take for example my 1600x1200 TFT screen which is connected with an ANALOG VGA cable -- the display automatically tunes itself to this signal and I donot notice the difference between using the analog VGA cable and my digital DVI cable -- that's how accurate an analog copy could be. In other words, even if they manage to close the digital hole it will be pointless without closing the analog hole as well.
Strong crypto looks a lot like many other forms of data you will see traveling over a line -- it's practically random. It would be very hard to proof that what you're sending is not plain random data, or say some kind of compression or movie format (possibly with identifying headers stripped out). Or you could even add some of those headers in your crypto stream making it look like an AVI movie, which just happens to not work at all because the contents are all garbled.
I can't really think of any way you could prevent people from sending random data, I can't even think of a good way to identify whether a piece of data is part of a movie, mp3 or zip, and not strong crypto disguised to look like such data.
So you think I couldn't write a program that uses an unencrypted protocol like HTTP to send encrypted content anyway? What are they gonna do? Verify I actually send readable english when I send stuff with HTTP headers?
In other words, it won't be long before my spam filters will automatically mark such mails as spam as well at which point Goodmail will have shot themselves in the foot.
Spam may be a problem for your inbox, but for ISP's, the bandwidth spam takes up is a drop in the bucket. The real bandwidth hogs these days are audio/video streaming and various P2P protocols (especially BitTorrent takes up a sizable chunk of bandwidth).
The Dutch government has forced the owners of the biggest telephony and data networks to open their networks up and offer the use of their network (for reasonable rates) to any other telephony/ISP company that cares for using it.
There's also a government mandated group that keeps an eye on telecom providers making sure everyone behaves (no price fixing, reasonable network pricing, no tricks to keep networks closed or other anti-competitive practices), and they have the power to hand out severe fines when they're in violation and have done often enough in the past.
In all the time I have been their customer, I've had almost no downtime (I'm connected 24/7), never even suspected they might be throttling (they're not), and never have I had a reason to think that I may not be getting the full bandwidth while I was downloading something because the line was overbooked.
On top of that, over the years, my bandwidth has doubled several times and the price has declined, paying about $40 for 5mbit/1mbit. For me, this is effectively unlimited as I can't think of ways anymore to use it all up (although I still use about 80 GB up + 80 GB down every month)... What I think is that my ISP has realized what apparently some ISP's haven't yet, at some point, harddisks are full. At 200 GB/month that's pretty fast.
Let's say you start with 4x 500 GB, for a total effective space of 1.5 TB in RAID5, at some point this array fills up and you want to upgrade. So you buy 2x 1 TB drives. Create two 500 GB partitions on each of these 1 TB drives. Now copy the data from the existing RAID5 to the new drives. Drop your old RAID5 array, and now copy some of the data back to the old 500 GB drives until you have two empty 500 GB drives, and one empty 500 GB partition on each of the 1 TB drives. Create a new four disk array using two 500 GB partitions from the 1 TB drives and two of your old 500 GB drives -- copy your data to the new array. Then create another RAID5 array with the remaining four partitions. You now have two RAID5 arrays of 1.5 TB each and a total of 6 drives.
At some point of course, these two arrays will become full, and you need to upgrade again. This time buy 2x 1.5 TB drives (hopefully they'll exist by then). Create a 1 TB partition and a 500 GB partition on each of the 1.5 TB drives. Now you'll need to move data around again (if needed you may need to temporarily run a degraded RAID5 array with only 3 disks), but the end result should be that you get two RAID 5 arrays again, one consisting of 4x 1 TB (for 3 TB of space), and another which consists of 4x 500 GB. Remove two of the unused 500 GB drives from your server so you have a maximum of 6 drives again.
You can repeat this as often as you want, as long as you can find new drives that are big enough (for each upgrade step you'll need a drive that's as large as your largest and smallest drive combined), so the next step would be adding 2x 2.5 TB drives, copying your data, and removing the two smallest drives.
This method of upgrading only really works with an even amount of disks in a RAID5 array, I personally use arrays of 6 drives (for a total of 9 drives in my server, which have two overlapping RAID5 arrays of 6 partitions each).
Your CPU's run at less than 10C above ambient because it has a huge cooler sitting on top -- the CPU may be cool, but only bacause a lot of heat is extracted from it and pumped out of the system.
How about writing a nice adblock extension which downloads the ads, but never actually displays them. Bandwidth is there to be wasted after all :)
Something similar goes for harddisks -- they still have roughly the same access time as 10 years ago (around 10 ms). Sure they have higher top speeds (10 MB/sec is now like 70 MB/sec) and larger capacity but they're still incredibly slow at loading lots of data from lots of different locations. So if firing up your browser means stuff needs to be loaded from disk, then it will be as slow as always. The only way to speed this up would be to have some intelligent caching (preloading stuff) or making sure everything browser related can be read in one huge chunk of data. I just never unload my browser (and I have swap off) so a new window opens instantly when I want it).
The worst part of this is though the total stupidity of how disk caching is handled -- a good example is what happens to your system when you watch a movie for 2 hours -- it thinks that (even though we're requesting video data at a rate of like 150 kB/sec) it would be a good idea to completely cache all of this data, to the point of swapping out everything else to disk. After watching your movie, you can make a new coffee before other programs become useable again. So I just keep swap turned off, it will have no choice but the use smaller disk caches and it will leave the stuff I choose to have running alone.
Since C is not Object Orientated Programming, I would classify you as a beginning Java/C#/Perl/Python programmer who will have a LOT to learn (especially in Java where Object Orientation seems to really thrive). I would definitely expect an experienced programmer to understand basic concepts like classes, instances, encapsulation, inheritance and polymorphism, not to mention the dozens of patterns that are used all throughout Java. With only C experience, you will still need years to master OO programming and design.
Now let's take this a bit further -- how much of a performance hit do you take when you access memory that is not in the CPU's cache (or 2nd level cache)? The CPU will have to wait for the memory to be available... optimizing code that frequently accesses memory outside the cache would be useless (and would just mean the CPU has to wait a bit longer). Let's take quicksort, the algorithm isn't particularly hard but accesses memory a lot. Would it matter if one iteration takes 20 cycles or 40 cycles on a modern CPU (let's assume that's the difference between C and Java)? It will make little difference, the CPU has to wait for data anyway. In the end, even in such a low level algorithm, it will make little difference whether we used a very efficient piece of code, or a slightly less efficient one -- the bottleneck is the memory. In other words, as long as the algorithm you use is the same, both pieces of code should be about as efficient.
The only time optimizing is still worth it is when you are doing stuff in tight loops that isn't randomly accessing memory for all kinds of reasons (and which of course is used to do a lot of bulk processing, like video encoding) -- it's hard to even think of a good example, but I suppose it might be worth using more efficient code in signal processing, compression/decompression and rendering applications. Even in those cases however a lot of stuff is handled in optimized libraries for higher level languages.. I mean, it won't make any difference if I use Bash (horribly inefficient!) to call my favourite Unzip program to unzip a multi-megabyte file, or whether I wrote a C program to do the same. It would still take as long.
In other words, in combination with all the other surveillance devices it will become more and more trivial to plot where a certain license plate was at almost any point in time (for the times you donot have data points you can make educated guesses based on travel time between the data points you do have).
Face recognition may not be computationally feasible right now (or maybe it already is... I do believe a facial scan is one of the new things required to obtain a passport in the UK), it definitely will be as trivial to do as license plate recognition in a few years from now.
I doubt it, camera's have come a long way, shutter speed definitely is not an issue in an outside environment (you can capture perfectly sharp stills every second for example). If you only capture every second (more than sufficient for the purpose this is going to serve), then you can also use high resolution without exceeding storage constraints -- that is, if they even bother to store it all, they could also just send it directly to another computer using existing technology.