1. I'm Swedish and capable of reading the verdict. I'm only saying what has been written by the court.
2. No, I am not a lawyer - I bet you and most people commenting here aren't either.
The verdict is very easy to understand. If you understand Swedish, you should read it. In particular pages 75-76, because that is where most of the "TPB only hosts links, non-infringing content, etc." arguments are dealt with.
On page 76 of the verdict it is quite clear that what ultimately killed TPB is the fact that they, even though they knew of infringing material, didn't act to remove it.
The court had quite a good grasp of BitTorrent. What they stated was that:
1. When someone does something illegal (copyright infirngement)...
2....anyone involved, however tangentially (the tracker operator), can be held accountable...
3....but, and this is the big one, you must have either purposefully aided the illegal act, or acted with willful blindness.
On page 76, the court discusses letting the accused off due to them being "service providers", and while finding them to in fact be service providers, asserts that a service provider that assists in infingement, is notified that they are doing so, and keeps on assisting, is indeed party to the infringement.
Note the the next TPB: Do what YouTube did and have a legal department. Cooperate with rights holders. Take stuff down.
Won't work. The problem is that you may get the rename before the write, so if your code crashes between the rename and the fsync, you end up with lost data - the rename goes through, but no data has been written yet.
The solution is to stuff a fsync() after the first fclose().
In all other caching schemes I'm aware of, there are rules as to how one may reorder the operations.
One option would be to separate writing the data from delineating transactions. For example, we could have an "io barrier" (analogous with a memory barrier), that says that no operation may be moved across io-barrier calls, but this gives no guarantee of the data having been written to disk.
So, you could have:
fwrite();
fclose();
io_barrier();// 1
rename();
io_barrier();// 2
This would prevent the rename from being moved up above the first io-barrier, or the write from being moved below the first. (The barrier calls themselves may not be moved around relative to any io-operation or each other.) This means that if the rename() has really executed and been written to disk, then we know for sure that the fwrite() and fclose() have run. However, we only guarantee the order of operations, not that we've actually written stuff to disk, so there is no disk-thrashing.
They could get what they needed by promising to do best-effort deletion of the material. For example, if they have already sent ads containing your photo to the magazines, then those ads will run - even if you delete the photo. But they can't use it for future ads.
The research ignores one aspect of pay vs. free: Doing work in the "business" (as opposed to the "social") realm is harder.
For example, you helping me with something as a buddy means that if you break something, I'd typically not charge you anything. If I hire you to do work for me, and you break something - you pay.
From your point of view, doing free work for friends means you don't have to worry about ensuring payment, liability for accidents, etc.
The Java launcher has two VMs to choose between - the server and the client VM. Unless forced by command-line switches, it chooses automatically.
The client VM does a lot on an "as needed" basis - classloading, JIT compilation, etc. The server does most work upfront, before the app starts. This means client = faster startup and less resources consumed, server = faster execution and more resources consumed.
On Ubuntu Phoronix ran the OpenJDK Server VM, and got the same times as the stock VM. On Windows, they ran the stock VM and got worse performance. I know that on Windows, with a setup like the one they use, the launcher will always select the client VM.
I would be interested to know which VM (client or server) was used on the benchmarks. I strongly suspect they ended up with the server VM on Ubuntu and client on Windows.
Slashdot Mirror
1. I'm Swedish and capable of reading the verdict. I'm only saying what has been written by the court.
2. No, I am not a lawyer - I bet you and most people commenting here aren't either.
The verdict is very easy to understand. If you understand Swedish, you should read it. In particular pages 75-76, because that is where most of the "TPB only hosts links, non-infringing content, etc." arguments are dealt with.
On page 76 of the verdict it is quite clear that what ultimately killed TPB is the fact that they, even though they knew of infringing material, didn't act to remove it.
The court had quite a good grasp of BitTorrent. What they stated was that:
1. When someone does something illegal (copyright infirngement)...
2. ...anyone involved, however tangentially (the tracker operator), can be held accountable...
3. ...but, and this is the big one, you must have either purposefully aided the illegal act, or acted with willful blindness.
On page 76, the court discusses letting the accused off due to them being "service providers", and while finding them to in fact be service providers, asserts that a service provider that assists in infingement, is notified that they are doing so, and keeps on assisting, is indeed party to the infringement.
Note the the next TPB: Do what YouTube did and have a legal department. Cooperate with rights holders. Take stuff down.
The same person (Andrew Hamilton) is behind this website:
Inside Black Holes
Which has a lot cooler CG.
Won't work. The problem is that you may get the rename before the write, so if your code crashes between the rename and the fsync, you end up with lost data - the rename goes through, but no data has been written yet.
The solution is to stuff a fsync() after the first fclose().
I agree with parent.
In all other caching schemes I'm aware of, there are rules as to how one may reorder the operations.
One option would be to separate writing the data from delineating transactions. For example, we could have an "io barrier" (analogous with a memory barrier), that says that no operation may be moved across io-barrier calls, but this gives no guarantee of the data having been written to disk.
So, you could have: fwrite(); // 1 // 2
fclose();
io_barrier();
rename();
io_barrier();
This would prevent the rename from being moved up above the first io-barrier, or the write from being moved below the first. (The barrier calls themselves may not be moved around relative to any io-operation or each other.) This means that if the rename() has really executed and been written to disk, then we know for sure that the fwrite() and fclose() have run. However, we only guarantee the order of operations, not that we've actually written stuff to disk, so there is no disk-thrashing.
They could get what they needed by promising to do best-effort deletion of the material. For example, if they have already sent ads containing your photo to the magazines, then those ads will run - even if you delete the photo. But they can't use it for future ads.
The research ignores one aspect of pay vs. free: Doing work in the "business" (as opposed to the "social") realm is harder.
For example, you helping me with something as a buddy means that if you break something, I'd typically not charge you anything. If I hire you to do work for me, and you break something - you pay.
From your point of view, doing free work for friends means you don't have to worry about ensuring payment, liability for accidents, etc.
The Java launcher has two VMs to choose between - the server and the client VM. Unless forced by command-line switches, it chooses automatically.
The client VM does a lot on an "as needed" basis - classloading, JIT compilation, etc. The server does most work upfront, before the app starts. This means client = faster startup and less resources consumed, server = faster execution and more resources consumed.
On Ubuntu Phoronix ran the OpenJDK Server VM, and got the same times as the stock VM. On Windows, they ran the stock VM and got worse performance. I know that on Windows, with a setup like the one they use, the launcher will always select the client VM.
I would be interested to know which VM (client or server) was used on the benchmarks. I strongly suspect they ended up with the server VM on Ubuntu and client on Windows.
With C, you have the target architecture to worry about. Word size, alignment issues, memory models... There is no single standard there either.
Just because you found a C compiler for your dialect doesn't mean your binary will be compatible across platforms.