Police are legally allowed to possess contraband in the course of an investigation; private-sector entities aren't

I consider that to be a real problem with the current laws. There are some data, which can be used for good or for bad purposes. Google has lots of data, they also have the computing architecture to store and process all of this data, and they have the expertise. I firmly believe Google is in a better position to do this sort of data mining than authorities. It is not just about images of child abuse, but also about correlating that with other data, which would not be illegal on its own.

If Google by performing mining across a little bit of child pornography along with lots of legal data is able to produce an output, which can track down the people who were abusing the child in the first place, then I consider that to be a good use of the data, regardless of what the law says about that practice.

The potential for Google to help track down some of these kids and get them out of the abuse is so important, that it is unfortunate that such efforts are jeapordized by the current laws. That makes it only so much nicer to hear that Google is doing an effort in this area. Whether Google is breaking the law or not in the current effort is not important to me, as the goal of the effort is to go after much worse crimes.

I consider abuse of children to be a much worse crime than possession of child pornography. Most people agree that it is worse, but some people seem to think it is not that much worse. Would the average person think it was ok to let 100 people guilty of possession of child pornography go without punishment, if it meant one more person guilty of child abuse could get caught?

If that sort of reasoning was considered valid, we should also outlaw all new inventions, that could make any other profession unnecessary. We need to accept, that nobody has a right to make a living within a profession, that nobody need anymore.

But I don't think we are close to that point yet. Even if we had free access to all culture older than 20 years, there would still be people willing to pay for something new.

So if I paint ONE painting and sell it, ANYONE can then copy it (since it isn't available for purchase?)

Sounds fair to me. There is a market for copies, if the copyright holder has no intention of supplying that market, then that opportunity should be open for others. Regardless of who is selling the copies, the price of the original will still be much higher than that of the copies.

What if I want to make a limited edition book?

Why would you? If all the ones you printed are sold, you can surely make money from another print. If you don't do another print, you are not losing any money from somebody else doing so.

The binary packages (*.deb files) are not signed. It's the "Release" file that is signed. It contains checksums of the "Package" files that contain checksums of the "*.deb" files.

Those are probably not checksums, but actually cryptographic hashes. And assuming they are actually cryptographic hashes, then signing the hash or signing the input is pretty much the same thing. You never sign the actual files in the first place (since they are too large to be input into the signing algorithm), you always hash the data to be signed and then sign the hash. Adding more layers of hashing before you sign is really just constructing a hash tree, which is just another way of hashing data before you sign it.

The main difference between a sequential hashing algorithm and a hash tree is that the tree structure allows for parallel computations of the hash, as well as allows for checking just those parts of the data which you are interested in rather than having to work through the entire computation.

What these money-hungry Hollywood and publishing executives don't seem to realize is that everything DRM'ed will be lost in time, like tears in the rain.

Publishers should be forced to choose whether they want protection from DRM or from copyright. They should not be allowed to have protection from both. So if they choose to release it with DRM, the copyright will immediately expire.

Except that copyright is already tied to the life of the author. It's just the life of the author plus a really stupidly long time...

That additional time is so long, that it removes all incentive to attempt influencing the expiry time. Either the author is already dead, in which case the expiry time can only be changed by changing the law. Or the author is still alive, in which case the copyright of the work will last for so many years into the future, that no living person will care about the exact date. It is easier to influence the expiry time by having the laws changed, which is happening faster than copyrights are expiring.

I personally, in this current system, would limit copyright for all works to a mere five years. With a requirement to retain attribution for maybe another five or ten years after that. But, ten to fifteen years after a work is first published, or say twenty after it is first recorded (if not published), make it fall into true public domain, without even the requirement for attribution.

I agree it should be tied to the publication date. But I think five years is too short. I consider 20 years from the first publication (with author's permission) to be more appropriate. It should come with certain requirements, such as the work remaining available for purchase. Attribution requirements should last longer, but derivative works should be possible. If a product is leaked without author's permission, then the time shouldn't start ticking yet. But there need to be a limit on how many years can pass between such a leak and the actual publication, if full term copyright is to be retained. There also need to be rules preventing any loopholes from making money off a staged "leak" and then retaining copyright after a later "publication" date.

The solution is obviously things like mulitpath-TCP.

That didn't exist at the time. But on a longer term I definitely think multipath TCP looks promising. If multipath TCP gets widely deployed, then we may be able to reach a point where a bundle of network links for all practical purposes work at least as good as a single link at twice the speed.

It does make me a bit sad to see how much the multipath TCP design was restricted by the need to work through NAT devices. But the designers do deserver kudos for the effort in producing a design, which can work with subchannels going through different NAT devices. Multipath could have been even better, if NAT hadn't been part of the equation.

16 bit? What are you even talking about?

My bad. I just checked what Wikipedia had to say. And it turns out the 6502 is actually an 8 bit CPU (even though it has 16 bit addresses).

It is actually pretty simple and straightforward to get a second interface to share the work load.

It depends on the workload. Each TCP connection stays on one interface. The fewer TCP connections you have, the harder it is to spread load evenly. In the most extreme real world scenario I have experienced, there was a need to push 1.3Gbit/s over a single TCP connection, and the machine had a bundle of two 1Gbit/s interfaces. Needless to say, the throughput did not reach the 1.3Gbit/s, which was needed.

Pity lunix doesn't have a feature like FreeBSD's securelevel.

You can't expect to have that sort of features on a 16 bit architecture. Managing to produce a unix system with just the basic features and capable of running on only 64KB of RAM is quite a feat.

I call Bullshit, HD video can be streamed to a 100Meg host.

There was not a single word about video streaming in the posting you replied to.

No, the next step is to get a second NIC.

Have you not noticed all the places in this thread, where that suggestion was made already? A bundle of two interfaces does not behave the same way as a single interface at twice the speed. If don't want to deal with the additional complexity from bundling and all the performance tweaking needed to get traffic evenly distributed on the interfaces, then a 10Gbit/s interface is the only option that I know of.

Then you should have bought some 10 gig interfaces

Unfortunately in order to make room for a 10 Gbit/s interface, we would have needed to remove another card, which was even more important to those servers operation.

or dropped in more 1gigs and bonded them.

We had multiple 1Gbit/s interfaces on board, and we were bundling them. But a bundle of two 1Gbit/s interfaces doesn't give you twice the performance of a 1Gbit/s interface. In some usage patterns the bundle does not give you any additional throughput. We had situations where we needed more than 1Gbit/s on a single TCP connection. You don't get that with bundling of 1Gbit/s interfaces, regardless of how many you use.

Your LACP bond still limits a single stream to a single link.

That is very true indeed. And I have experienced a real world use case, where that was a severe limitation. Since then TCP has been extended to take advantage of multiple links, but that feature is not yet widely supported. In performance tests, it has been shown possible to push 50Gbit/s over a single TCP connection run across a bundle of 6x10Gbit/s.

Even with multiple streams, you would have to have a lot in order of them to hash out to all the links.

One stream per link should be sufficient to utilize all links, assuming an adaptive hashing algorithm is used. It is ok to move a stream from one link to another mid stream. The brief performance drop as the stream is moved to another link is acceptable, if it means the stream gets moved to a less congested link and gets more throughput for the rest of its lifetime.

How on earth does this take 10Gb.

Who said it does? If you need 1.1Gbit/s of sustained traffic, then a 1Gbit/s link will not be sufficient. The next step upwards is 10Gbit/s.