Four short links: 15 May 2009

LIfe After socket(), Imminent Death of Web 2.0, Breathalyzer Lameness, and Open Source Science Publishing

Whither Sockets? -- ACM Queue article on how sockets as a model for network programming have become an obstacle to where networking is going. All of these calls have one thing in common: the calling program must repeatedly ask for data to be delivered. In the world of client/server computing these constant requests make perfect sense, because the server cannot do anything without a request from the client. It makes little sense for a print server to call a client unless the client has something it wishes to print. What, however, if the service being provided is music or video distribution? In a media distribution service there may be one or more sources of data and many listeners. For as long as the user is listening to or viewing the media, the most likely case is that the application will want whatever data has arrived. Specifically requesting new data is a waste of time and resources for the application. The sockets API does not provide the programmer a way in which to say, "Whenever there is data for me, call me to process it directly." (via Slashdot)
Game Web 2.Over? (Meg Pickard) -- update of the classic "wall o' Web 2.0 logos" showing which have folded or been bought. I'm glad to see how many have folded; many were the inevitable "me too"ing of initial successes, and many were simply bad ideas. Death is a natural part of the Darwinian marketplace, painful as it is to those who are naturally selected out of the meme pool. I'm glad to see how many were acquired, showing they had something someone wanted. The diagram's incomplete now, of course: it doesn't show the companies launched after the wall o'logos was made. (via Waxy)
Breathalyzer Source Code Sucks -- 2. Readings are Not Averaged Correctly: When the software takes a series of readings, it first averages the first two readings. Then, it averages the third reading with the average just computed. Then the fourth reading is averaged with the new average, and so on. There is no comment or note detailing a reason for this calculation, which would cause the first reading to have more weight than successive readings. Nonetheless, the comments say that the values should be averaged, and they are not... I periodically worry that I've been so long out of hardcore coding that my skills are rusty and I'd never survive at the coal face again. Then I see something like this and I punch the air and wheeze "I still got it!" as I reach for my cane. (via BoingBoing)
Bloomsbury Science Free Online -- Sir John Sulston, Nobel prize winner and one of the architects of the Human Genome Project, has teamed up with Bloomsbury to edit a new series of books that will look at topics including the ethics of genetics and the cyber enhancement of humans. The series will be the first from Bloomsbury's new venture, Bloomsbury Academic, launched late last year as part of the publisher's post-Harry Potter reinvention. Using Creative Commons licences, the intention is for titles in the imprint to be available for free online for non-commercial use, with revenue to be generated from the hard copies that will be printed via print-on-demand and short-run printing technologies. (via Glyn Moody)

Dale Brayden [16 May 2009 12:50 PM]

Wouldn't the average actually give less weight to the earlier readings? If I understand right, the algorithm for the 1st 4 readings would be

(((((a+b)/2)+c)/2)+d)/2

which evaluates to

(a + b + 2c + 4d)/2.

gnat [16 May 2009 02:36 PM]

@Dale You're right, the bit I quoted totally got it backwards! Well spotted. Each value has a 1/(2^(N-n)) weight where n = position counting from 0, N = number of items. Thanks!

Alex Tolley [16 May 2009 03:27 PM]

Dale - the formula isn't even giving weight to the value as I understand 'weight', it is just computing the average incorrectly.

e.g a=1, b=1, c=2

=> ((1 + 1)/2 + 2)/2 => 1.5
correct value = 4/3 = 1.333.

The correct formula (I think) is:

newAve = (PrevAve.(n + 1) + newVal)/(n+2)

where n = cumulative number of averages already done.

Tom [16 May 2009 05:35 PM]

"This Lint program has been used for many years. It uncovered that there are 3 error lines for every 5 lines of source code in C."

Lint doesn't find errors, it finds lines that are written in a way such that they _may be_ errors. I wish finding errors were that easy!