Why don't you do it on a whiteboard then? My at-home space has a three-monitor sit-stand desk, with a whiteboard directly behind my chair. All I have to do is stand up, hit the button, and everyone on my video conference can see my whiteboard. Agreed they can't write on that board, because it is an actual white board, but it still gives you that free-form space to express your ideas just as you would in an in-person conference room. And based on experience, whiteboard sessions are typically not that collaborative. Most collaboration consists of another member of the group writing something on the side, or erasing what you wrote and writing their own interpretation. I'm not saying it does not happen; I'm saying that a remote experience does not have to be as negatively impactful as may be assumed.

Sigh. One word. Cloud. Or, to tie it a little closer to Microsoft's home, Azure. This is a Big Data play people. Big Data requires Big Compute, and Big Storage. This is likely because Microsoft wants to make R work better on its cloud offering than any other vendors. We will have to see if that means locking other cloud vendors out or not, but I'm hoping that with the new direction (open sourcing .NET anyone?) they will not try that tactic again. Only time will tell. I'm not suggesting that we let our guard down, but at the same time let's not jump to conclusions.

Where is Perl in the relative rankings of programming language usage today? I'm not suggesting any correlation, let alone causation, but it is interesting to ponder the question.

Visual R is already a product called RStudio.

A successful DDOS attack makes actual, valid, requests to the victim host. If it is a web browser, then it makes actual HTTP requests, possibly to the home page, possibly taking a random URL off that home page, in the same domain, and crawling the web site. Simply replying with an Ack isn't going to do squat. There are services out there that can scrub the requests for you. I'm not going to mention the name of the company, but you can research it if you want. Basically, once you sign up traffic normally goes to your site. However, if you are attacked they can use BGP to make your traffic go through their systems, and they scrub the traffic using proprietary methods, and only send clean non-DDOS traffic to your site. There are other things you can do also, if you have the right gear. You can inject a HTTP cookie if you get more than x requests from a particular IP address within y seconds, and then any future requests may get dropped (if you have a complying web browser or HTTP stack on the other end). Or, you can just keep a list of IP's that appear to be infected and drop the traffic if it is from those IP addresses. That's what is behind Cisco's and TippingPoint's, and just about any other decent IPS vendor's "reputation services" or whatever they brand it as. There is a lot you can attempt to do about DDOS, but "simply replying with an Ack" isn't a good one.

I'd say it is more of a problem of incorrectly configured QoS, or hardware with insufficient QoS capabilities, rather than large buffers. Obviously they are not using WRED or other methods, or the thresholds per queue are set too high to activate WRED or other packet drop mechanisms. This results in the buffers always being near 100% full, during periods of congestion. There are a slew of QoS capabilities on different hardware from different manufacturers, and even from the same manufacturer. Cisco, for example, has different QoS capabilities on almost every different piece of hardware they sell. So, you have to be fairly diligent that you are configuring QoS correctly on each individual piece of equipment, many of which will have very different capabilities, to be able to ensure an overall QoS strategy for the whole network.

However, this proper functioning of QoS is, as anyone who really knows QoS, dependent on the proper configuration on every node in the network. If you are talking VoIP, for instance, just one improperly configured node, or even a single link on a node, can break QoS on the entire network (or at least flows going through that node/link). Since most cheap home equipment does not have configurable QoS settings, or at least not to the extend that Internet infrastructure devices do, they may well be part of the problem.

However, as far as the Internet infrastructure devices, if Comcast, or any other ISP, is suffering from "buffer-bloat" on their equipment I'd blame them for not configuring QoS appropriately.

You don't really know what you are talking about, do you? Tail bits? That's going to get you around egress filtering? Also, as pointed out by others, ISP's do ingress filtering, not egress. Egress filtering is what companies that have their own firewalls and/or routers are encouraged to do, but the ISP should be doing ingress filtering also.

Absolutely correct. One of my brothers reached his lifetime limit, and can no longer work in nuclear power plants. It doesn't matter that he could request to avoid "hot" jobs, he just plain simply can't work in an areas where radiation is known to be present.

Oh come on. Not speaking for anyone else or any particular comment, I'd guess 90% of the snotty responses are in jest. One thing we do know, is that snotty responses get the attention of MS, and upset them. So, even if MS does something worthy of praise, the amount of praise would likely never exceed 10-30% of total comments, just because we like poking MS.

There is also the "once bitten twice shy" syndrome. MS has such a horrible past that even when they do something worth of praise it is very difficult to trust that there is not some hidden scheme with ulterior motives. So please understand forgive if us /. snots continue to have fun at the expense of MS.

With the usual caveat of IANAL, I don't believe the voicemail is the property of Buckyballs. They left the voice mail, but they left it on someone else's voice mail system. The recording is owned by the receiver of the message, not the sender. Now if the message were recorded on a tape, CD, or some other device, and the device was sent to the recipient, I suppose an argument could be made that the original recording is copyright Buckyballs, but not a traditional voice mail. There is probably relevant case law on the matter, but again IANAL. As far as the images, that all depends on where they were obtained from. Many, if not most, social networking sites, which I'm assuming these were grabbed from, explicitly state in their terms that you give up copyright on anything that you post. So even the images may, in fact, be non-infringing. So, there are really two issues here. One issue is the original complain in the voice mail, which I don't believe BuckyBalls has a leg to stand on in court. The second issue is the use of copyrighted material (the voice mail and the images of the BuckBalls guy acting like an idiot), which BuckyBalls may or may not have a valid claim on. Don't confuse the comparison of the products with the DCMA take down notice. Cheers!

Yes, he's entitled to the money he makes. Others are not. Speaking of a warped sense of entitlement!

If you are funded by the US government, then I would say no, don't waste any more of your time our our money on this. If you are privately funded, then sure, go ahead.

Sigh. Understand the protocol before commenting, or at least RTFA. There IS an individual key per user. But, there is also a shared key used for broadcast traffic. The problem is that the shared key is not authenticated, so a user who knows the shared key (i.e., anyone with access to the wireless network), can use the shared key to spoof the AP and send messages to other users, and force them to give up or change their unique per-user keys. A "fix" would be getting rid of the shared key for broadcast, but that would require the AP to send a separate "broadcast" packet to each user individually, using their unique per-user key, instead of just one packet.

There is an out-of-band key exchange. It is called a trusted certificate. You know, just like how HTTPS works. This is for WPA2 Enterprise, of which there are many different EAP methods possible, but for which most do include an out of band key exchange (i.e., certificates, or EAP-FAST PAK). In any case, there's also the old DH key exchange, which worked fine for IPsec for years.

You obviously missed the article way back about the sapphire monitors...