The Insider News

DataSift Developers[^]:

Whilst our cluster size isn't really comparable with the largest Hadoop deployments in the medical or physics fields, at just under 1 PetaByte and doubling in size every 3 months, it's probably a lot larger than the average amount of data most companies have to deal with. Since the announcement of our closed alpha, the demand for historical Twitter access has been huge, so we knew early on that we couldn't release a service that would collapse with just a couple of queries or that took forever to process data: if you start a query now, you don't want results in 15 days.

Ralph Barbagallo's Self Indulgent Blog[^]:

Advertisers love the AR because it involves users having to physically interact with a product: pick up a cereal box and you are 3/4 of the way to buying it. For most applications however, AR is still a gimmick. Having to wave your phone around at an object to play a game is a huge hassle. A compelling business case hasn’t been made yet–this is evidenced by the fact that most AR conferences feel more like amateur science fairs than bustling hives of commerce.

Scripting News[^]:

Distribution was the key idea of Public Radio Exchange. The big stations only had 24 hours a day to broadcast, just like the smaller-market stations. Podcasting overturned that idea. With the Internet there is no concept of a 24-hour broadcast day. You can upload as many hours of MP3s as you like, and if there are people who care, you will get listened to. Eventually that battle was settled and today PRX is a thriving venture, distributing podcasts of course.

Input Output[^]:

Nowadays, we take Ethernet for granted. We plug a cable jack in the wall or into a switch and we get the network. What's to think about? But it didn't start that way. In the 60s and 70s, networks were ad hoc hodgepodges of technologies with little rhyme and less reason. But, then Robert “Bob” Metcalfe was asked to create a local area network (LAN) for Xerox's Palo Alto Research Center (PARC). His creation, Ethernet, changed everything.

Xconomy[^]:

The Internet may be hurtling toward collapse under the strain of too much traffic. But PARC research fellow Van Jacobson thinks he knows how to fix it. He’s done it before. Back in the mid-1980s, when the Internet was seeing its first modest surge in usage, Jacobson noticed that data packets were piling up on the message routers of the day, like cars waiting for cross-traffic to clear before entering an intersection. Working with fellow Berkeley computer science instructor Mike Karels, he came up with a small change to the Transmission Control Protocol (TCP) that, in essence, allowed packets to ease into the intersections gradually, curing the congestion.

Revolution Wi-Fi[^]:

A lot of press has been released this week surrounding the cracking of MS-CHAPv2 authentication protocol at Defcon. All of these articles contain ambiguous and vague references to this hack affecting Wi-Fi networks running WPA2 security. Some articles even call for an end to the use of WPA2 authentication protocols such as PEAP that leverage MS-CHAPv2. But they fail to paint a true and accurate picture of the situation and the impact to Wi-Fi networks. I think this is misleading, and that any recommendations to stop using PEAP are flat-out wrong!

Bits Up![^]:

HTTP has been a longtime abuser of TCP and the Internet. It uses mountains of different TCP sessions that are often only a few packets long. This triggers lots of overhead and results in common stalling due to bad interaction with the way TCP was envisioned to be deployed. The situation is so bad that over 2/3rds of all TCP packet losses are repaired via the slowest possible mechanism (timer expiration), and more than 1 in 20 transactions experience a loss event. That's a sign that TCP interactions are the bottleneck in web scalability.

Jet Propulsion Laboratory[^]:

Considerable efforts have been invested by many different organizations in the past on the development of coding standards for the C programming language. The intent of this standard is not to duplicate the earlier work but to collect the best available insights in a
form that can help us improve the safety and reliability of our code. By conforming to a single institutional standard, rather than maintaining a multitude of project and mission specific standards, we can achieve greater consistency of code quality at JPL.