You might have asked us what the best sports team is, frankly.

I want to see some Ask Slashdot questions with some depth. The focus on breadth is eating Pez candies day after day, and my teeth are rotten and I want a meal.

I'm going second this recommendation. I've got an RT-16N and it's a pleasure to work with. Between the USB ports, the decent amount of RAM and flash... and the peppy CPU... It's more than one should expect for the price.

Are people bad at math or something?

From their FAQ:

Can I set limits on my deals?

Yes. You can limit the total number of purchasers. You can also set restrictions on how customers use the deal. For example, if you're a restaurant you can limit the use of Groupons per table or per order.

I hope SOPA passes. We'll just fix our geek software even better. Encrypted everything, out of band non-deterministic port hopping.. the only hope they'll have is million dollar stat boxes that make lots of wrong guesses and snip VIP VPNs. Our skin will grow over their bandaid.

when will the day come that "non-believers" is a reference to dogmatic thinking and the believers are those that have faith in logic and the scientific method

There's these nosql things. I am not familiar with them at all. They seem nifty - some of you are way smarter than me, maybe you can correct me. It's like a giant bag with stuff in it, and there are keys tied to all of them hanging out the top of the bag. You just yank on the key and get your thing out. It's massively parallel and redundant, so maybe given enough leeway that bag can span continents, and we can each grab a key marked "file1.blah" and get it reasonably fast. It's got nothing to do with file systems. Am I right so far?

But so then, what I wanna figure out is, how can I set up a thing where I can basically have a file system be mounted locally on a few boxes, and have all that data get replicated on the other boxes as close to realtime as is reasonable... latency, resource sharing, all that. I'd basically like it so that me and my friends can each have the same data locally. We have tons of space, tons of bandwidth (it's local, after all), and we are willing to trade these to each have fully local copies. But what should we use? Lustre? Gluster? There seems like quite a few options. Lustre looks hard and Gluster looks expensive.

Chime in fellow slashdotters. You're all that make this place interesting anymore.

How do you do it without aliasing the interface?

That notion is very alarmist and 1990's era. An ISP can make a pretty good guess of how many lan devices you have using million dollar stat boxes, like sandvine makes. They dont care. ISPs are all media providing machines on another face and they know all your lan devices are just media consuming vehicles with credit card slots strapped on the side. They really don't care. They'll just do metered billing someday and we'll all crab together.

It seems wasteful, but it's a convenient boundary to assign to a customer. v6 makes heavy use of 64 bit subnets. An ISP dolling out 48 bit prefixes can expect their customers to use 16 bits for subnetting information, so customers can reasonably have 65,000 networks to do with as they please.

Look at a 6to4 address: 2002 + your v4 address + ABCD (whatever the heck you want) + 64 bits chosen by your computer.

What does that even mean?

http://www6.ietf.org/rfc/rfc3315.txt

Autoconf currently doesn't assign a prefix delegation.

The catch is that they ran out of 10/8 space for their Internal network and weren't stupid enough to overload it. They deployed v6 to manage the cable modems, and then cable modems needed to be v6, and that was convenient since they're starting to run out of public space addresses, too. Those addresses can't be helped, and they're going to get sucked back into the ISP on the NAT level. Yes, all that malarkey about sharing public v4 addresses with your neighbors is a mathematical inevitability. Read through some current RFCs for a public conversation they are having on the topic of how many customers can you fit on a single v4 address.