Programming Languages

Vol. 9 No. 3 – March 2011

Programming Languages

Articles

A co-Relational Model of Data for Large Shared Data Banks

Contrary to popular belief, SQL and noSQL are really just two sides of the same coin.

A co-Relational Model of Data for Large Shared Data Banks

Erik Meijer and Gavin Bierman, Microsoft

Contrary to popular belief, SQL and noSQL are really just two sides of the same coin.


Editor's note: Some of the characters in this article will not display properly in some browsers.
If you have trouble, try using another browser or download the PDF file.

Fueled by their promise to solve the problem of distilling valuable information and business insight from big data in a scalable and programmer-friendly way, noSQL databases have been one of the hottest topics in our field recently. With a plethora of open source and commercial offerings (Membase, CouchDB, Cassandra, MongoDB, Riak, Redis, Dynamo, BigTable, Hadoop, Hive, Pig, ...) and a surrounding cacophony of technical terms (Paxos, CAP, Merkle trees, gossip, vector clocks, sloppy quorums, MapReduce, ...), however, it is hard for businesses and practitioners to see the forest for the trees.

The current noSQL market satisfies the three characteristics of a monopolistically competitive market: the barriers to entry and exit are low; there are many small suppliers; and these suppliers produce technically heterogeneous, highly differentiated products. 12 Monopolistically competitive markets are inconsistent with the conditions for perfect competition. Hence in the long run monopolistically competitive firms will make zero economic profit.

by Erik Meijer, Gavin Bierman

Porting with Autotools

Using tools such as Automake and Autoconf with preexisting code bases can be a major hassle.

Porting with Autotools

Using tools such as Automake and Autoconf with preexisting code bases can be a major hassle.


Dear KV,

A piece of C code I've been working on recently needs to be ported to another platform, and at work we're looking at Autotools, including Automake and Autoconf, to achieve this. The problem is that every time I attempt to get the code building with these tools I feel like a rat in a maze. I can almost get things to build but not quite.

by George Neville-Neil

Articles

Successful Strategies for IPv6 Rollouts. Really.

Knowing where to begin is half the battle.

Successful Strategies for IPv6 Rollouts. Really.

Knowing where to begin is half the battle.

Thomas A. Limoncelli, Google, with an introduction by Vinton Cerf


Introduction

The design of TCP/IP began in 1973 when Robert Kahn and I started to explore the ramifications of interconnecting different kinds of packet-switched networks. We published a concept paper in May 1974,2 and a fairly complete specification for TCP was published in December 1974.1 By the end of 1975, several implementations had been completed and many problems were identified. Iteration began, and by 1977 it was concluded that TCP (by now called Transmission Control Protocol) should be split into two protocols: a simple Internet Protocol that carried datagrams end to end through packet networks interconnected through gateways; and a TCP that managed the flow and sequencing of packets exchanged between hosts on the contemplated Internet. This split allowed for the possibility of realtime but possibly lossy and unsequenced packet delivery to support packet voice, video, radar, and other realtime streams.

By 1977, I was serving as program manager for what was then called the Internetting research program at DARPA (U.S. Defense Advanced Research Projects Agency) and was confronted with the question, "How much address space is needed for the Internet?" Every host on every network was assumed to need an address consisting of a "network part" and a "host part" that could uniquely identify a particular computer on a particular network. Gateways connecting the networks of the Internet would understand these addresses and would know how to route Internet packets from network to network until they reached the destination network, at which point the final gateway would direct the Internet packet to the correct host on that network.

by Thomas A. Limoncelli, Vinton G. Cerf

Weapons of Mass Assignment

A Ruby on Rails app highlights some serious, yet easily avoided, security vulnerabilities.

Weapons of Mass Assignment

Patrick McKenzie, Kalzumeus

A Ruby on Rails app highlights some serious, yet easily avoided, security vulnerabilities.


In May 2010, during a news cycle dominated by users' widespread disgust with Facebook privacy policies, a team of four students from New York University published a request for $10,000 in donations to build a privacy-aware Facebook alternative. The software, Diaspora, would allow users to host their own social networks and own their own data. The team promised to open-source all the code they wrote, guaranteeing the privacy and security of users' data by exposing the code to public scrutiny. With the help of front-page coverage from the New York Times, the team ended up raising more than $200,000. They anticipated launching the service to end users in October 2010.

On September 15, Diaspora released a "pre-alpha developer preview" of its source code. I took a look at it, mostly out of curiosity, and was struck by numerous severe security errors. I spent the next day digging through the code locally and trying to get in touch with the team to address them, privately. The security errors were serious enough to jeopardize the goals of the project.

by Patrick McKenzie