Nope, not at all... $2,000 is actually really cheap IMHO. Try to find a way to connect 68 drives cheaply (RAID cards and SATA multiplier backplanes are both pretty expensive). Don't forget that you also need a custom case, motherboard, ram, cpu, PS, and cooling for everything.

No, it does not "block brute force attacks"... If you are using WEP 64-bit you are *very* vulnerable regardless of what magical bullshit the marketing people put into your little router's brochure.

#1) Nobody seriously attacking 64-bit WEP is going to try an online brute-force attack of the key. This scheme so stupid and the key space so large that it has never been seriously proposed AFAIK. There are much easier and more effective ways of getting your key in minutes (vs. centuries)!

#2) Even if some idiot did try to brute-force the key, and your router indeed has some kind of additional "lockout", they would only have to change their adapters MAC every 10 tries.

That is not how it works... Your router cannot "block" someone from collecting IVs. Once they have enough they can calculate the correct key.

Disagree....

The authorities are trying to sidestep the issue by claiming they don't need to know the password... they just need her to unlock the laptop for them. While I believe this alone is a direct violation of the fifth amendment, there is a much more subtle distinction here...

If the defendant demonstrates knowledge of the password (e.g. unlocking the laptop for authorities) she also automatically incriminates herself as having been in control of that laptop and the encrypted data on it. This type of self-incrimination is EXACTLY what the fifth amendment is designed to protect. In other words, if you place the defendant on the stand and ask "Is this your encrypted data on this laptop?", she can plead the fifth. If you jail her for contempt until she incriminates herself by decrypting the laptop you've taken that fifth amendment right away from her!

Furthermore, what happens in cases where the laptop legitimately doesn't belong to the defendant, or they legitimately cannot decrypt it? What would prevent me from hiding an encrypted laptop in my arch-enemies house, anonymously phoning in a terrorist plot, and then watching them rot in jail indefinitely for contempt of court. THIS is why the fifth amendment exists! The founding fathers knew that you could not have a just legal system if a court can arbitrarily punish you for failing to assist them in prosecuting you!

Why not!? You most certainly can quote the maxmimum burst speed and the total transfer as two separate quantities (total data cap and maximum data rate). They are two completely unrelated quantities with different units! Every other tiered data provider on the planet does it. (e.g. comcast has a 250GB cap while allowing a maximum rate that would exceed that cap if used continuously.... AT&T has had very similar wireless tiered data pricing for the past year. You can colocate a server on a GigE port with only 1TB of transfer, etc. etc. etc. )

It isn't ambiguous, misleading, or dishonest as long as both quantities are available to the purchaser (i.e. up to 4G LTE speeds when network and wireless conditions allow for it, 2GB maximum transfer per month). Furthermore, a burstable solution serves end users better in most applications. In this case, I'd rather be able to burst to 30mbits when I NEED to load that youtube cat video rather than being rate limited to 6 kilobits per second 24/7 (2 GB / 30 days -> kilobits per second).

The billing cycle is evenly distributed on verizon wireless (I suspect it had something to do with paper billing)... Mine starts on the 8th of the month.

I've wondered about this as well... My guess as to how they implement this :

The content is encrypted with a key, stored along with the content. This key is encrypted with your password. (e.g. similar to HDD encryption)
When you make something public your client changes the password protecting the encryption key on that content to something specified by the Wuala public web server.

This implementation :
- prevents your password from ever leaving your computer
- prevents the content from having to be re-encrypted or re-uploaded when you choose to make it public.. you just have to re-upload the newly encrypted key (a few bytes).

2010b did not include GPU array indexing support (among other things), making it fairly worthless for anything moderately complex.
2011a DOES do indexing on GPU arrays. It works very well in my experience so far.

Thanks for the clarification. I understand your proposal a lot better now. The problem is that in your system, every single time a file was opened for reading/writing the user would have to slosh through an open/save dialog box provided by the OS. This includes intermediate files, temporary files, preferences, multiple output files, etc. etc. etc. Furthermore, in your system you would never be able to automate this dialog box without losing the security benefits. I'm sure that there's a way to cut down on the amount of individual files than an application needs to access, but advanced workflows would still need access to multiple files simultaneously. Security always has to be balanced against usability (e.g. an isolated computer in a locked room is very secure... but not very usable). While your proposal would make trojans more difficult, it's a far more cumbersome system for both programmers and end users than the current state of affairs.

That makes absolutely no sense... the OS cannot possible understand every single file format that every single one of your applications will ever want to write... that means the OS would just blindly have to write anything your application demands. Your application can still instruct the OS to destroy a file by overwriting it with 0's, or writing a nasty virus, etc. etc.... How is this any different than the current way of doing things (i.e. file dialog returns filename/path for the app to write... app uses std file calls to write the file. Permissions are managed by filesystem).