Lazy Reading for 2012/04/29

I go a bit beyond presenting links and comment on them too, this week.  Not too much!  Enjoy.

Your unrelated link of the week.  Youtube Poop.  As far as I can tell, ‘Youtube Poop’ are glitched videos made from Youtube content but with segments repeated, frames modified, or new sentences constructed from reassembling the frames.  Sometimes noisy, sometimes rude.  Also, an art form that can only exist now, and never really before.  Reminds me of the old Fensler Films, or that odd series out of Japan.  I find the idea of assembling new rhythms and music out of non-musical items fascinating, but I would, wouldn’t I?

(Turn your volume down before trying some of those links.)

Google Summer of Code: the projects

Each of the 4 DragonFly participants for Summer of Code have posted an introductory email and details of their projects.  Here’s direct links to their posts for your reading convenience:

(Yes, same format as my last post, but now the links are to their posts, not the sparse Google info pages.)

Google Summer of Code projects announced

Google has announced their projects accepted for Summer of Code: DragonFly has 4 projects of the 1,212 funded:

(Hopefully those links are to visible pages) We had way more good proposals than available mentors/slot, unfortunately.  So if you didn’t get in, think about next year, or maybe look at doing the work on your own; there’s some great ideas out there that I’d like to see happen.

Lazy Reading for 2012/04/22

Enjoy!

Your unrelated link of the week: One Thing Well.  The BSD tag might be the most useful.

Lazy Reading for 2012/04/15

It’s a good week when I can start collecting new Lazy Reading material right after posting the previous week’s summary.

Your unrelated link of the week: Quigley’s Cabinet Followups.  There’s about a bazillion links there to follow about weird history.

 

Optimized scoreboard for SACK

DragonFly now has a optimized scoreboard for SACK, thanks to Sepherosa Ziehau.  What’s that mean?  SACK is a way to make sure only the needed parts of a TCP transmission get retransmitted, when multiple packets are lost.  The scoreboard is where the packets needing retransmission are tracked.  So, the result of these improvements is better performance in packet-lossy situations.

(Please correct me if your understanding is better than mine; my explanation is based on stumbling around the Internet for a few minutes of reading.)