• List of Pidgin projects for 2009
• Pictures from the weekend
• Notes from the sessions
• A few kind people arrived to the area early and spent a few days in a documentation “sprint.” They created a summer of code mentoring guide

The conference was super cool. I got to be humbled by talking to a whole bunch of really smart open source people. Here are my notes:

On One Laptop Per Child (“OLPC”)

I’ve been wondering for a while whether the OLPC program could actually make a difference. One session, led by Bryan Berry of Sugar Labs, makes me think that it can and already has. Bryan is the co-founder and CTO of OLE Nepal, an organization helping deploy OLPC in Nepal, and creator of Karma, a framework for creating interactive activities for the Sugar environment using javascript and html5.

Seeing demos of the exercises they’ve created and hearing his first hand stories was pretty incredible. At least some schools in Nepal teach by having the teacher recite something (e.g. “one plus two is three”), and all the students repeat it and memorize. But this often fails to teach the students why one plus two is three. In one example a student was asked “what is one plus two” and they replied with “three.” But the same student was not able to answer “what is two plus one.”

Children in third world countries generally want to learn–more so than children in the US. They realize that education can help them achieve something greater in life. And computers are interesting to them. Combine students, computers, and engaging lesson plans about math, geography, etc. and the students will have a more varied education and will learn better.

On Forking Open Source Projects

• Forking helps keep people motivated. It increases competition, keeps developers on their toes.
• A fork could be like a “research and development” branch. People work on crazy fun new features in the forked project, and the good stuff gets merged back into the original.
• The smaller the project, the more willing the maintainer should be to give people access. There is a natural inclination to be protective of your project–it’s your code, your baby. But you must be willing to give up control for there to be forward progress. This reminds me of dictator governments like Cuba/Fidel Castro and North Korea/Kim Jong-Il. The dictator is afraid to relinquish control for fear of what might happen.
• Benefits of a fork? Developers have more freedom to do what they want, which allows for innovation. The best project will survive–if developers want their project to survive then they must make decisions that benefit the community at large.
• Downsides of a fork? Development effort is divided. Users might not know which project to use. Distributors may not know which package to distribute; distributing both means more work.

Miscellaneous

• STUN – A protocol used to determine your public IP by asking a server on the “outside” Internet
• TURN – A protocol used to proxy traffic through an intermediate server. Written with SIP in mind. Increases the likelihood of being able to establish a connection to another party, but it also introduces an additional hop, which leads to lagginess, which is bad for voice/video communication.
• ICE – A protocol that describes a method for establishing a direct connection with another peer. Written with SIP in mind. It uses an exhaustive algorithm to try every possible IP address for yourself in the hopes that one will work. You construct a list of your host’s IP addresses plus your public IP address determined by using STUN. This information, along with a fallback TURN server, is sent to the other party, who begins attempting to connect.
• OpenAFS is under active development, and is used by some very large organizations
• I should change my alias for grep to enable the color option
• I should read Zen and the Art of Motorcycle Maintenance

On Trolling (this session was half intended as a joke)

• I should read the UNIX-HATERS Handbook
• I should read the Sokal paper
• “Linus==troll”
• “Version con-trolling”
• “We had this problem where people had to download our software and type ‘make’” –Marty Connor
• Adding support for the old school Unix talk command to Pidgin could be a fun April Fools joke

The major IM protocols (AIM, MSN, Yahoo, etc) are fairly well thought out and logical. But sometimes things go horribly wrong. An example that I recently learned about, and the impetus for this post, is the format used for Yahoo IMs. Here’s a handy pocket reference:

1. Mixture of ANSI escape sequences and HTML
   Bold, italic, underline and font color are specified using ANSI escape sequences, but font size and font face are specified using the <font> HTML tag.

2. HTML tags aren’t closed
   Subsequent tags just override the value of the previous tags. Message formatting is more linear than hierarchical. For example, “<font face=’Georgia’>test1<font face=’Courier’>test2.”

3. HTML font tag size attribute is in points
   For example, “<font size=’14′>test.” Normally the size given in the font tag is a relative value between 1 and 7, with 1 being “small” and 7 being “large.”

4. Special HTML entities aren’t escaped
   For example, if an IM contains a less than sign it is sent as “alien < predator.” Normally < > and & are written as &lt; &gt; &amp; in HTML documents so that programs can accurately determine if a < is the start of an HTML tag or is a literal less than sign.

   Why does this matter? It means the user cannot send this IM, because it is interpreted as a font tag instead of plain text: “<font size=’32′>Huge text.” This generally isn’t a problem for normal users, but can be a nuisance for web developers, who may want to IM that text to a friend and have it appear the way they typed it.

I think the world is better off with free software. I don’t have anything against closed source or non-free software, I just think typical development processes for free software produce better products in the long run. They produce something that meets the needs of users better, with less fluff.

And I guess I feel like I can have a positive impact on open source software. Working on Pidgin is like my way of giving back to the authors of all the other free software that I use.

And I take a lot of pride in the code that I write. It is a reflection of who I am. If I write something that’s buggy then it makes me look bad. So you don’t need to try to talk me into fixing something that I wrote, because I care regardless. I care a lot more than you do, believe me. And it pains me when I don’t have time to fix my bugs.

Let’s use a text editor as an example. Say you have a grocery list saved on your computer. You open the grocery list and add three lines to it, but before you can save it a rabbit gnaws through your computer’s power cable and it turns off! You replace the power cable, boot your computer and start the text editor. It should:

1. Open your grocery list automatically
2. Restore the three lines you added before you lost power
3. Realize that the three lines have not been saved to the file yet
4. Let you “undo” repeatedly until the grocery list is back to what it was originally

But they got two things wrong:

1. The mouse cursor doesn’t change when hovering over the new buttons. With the old buttons the cursor changed to a little clicky hand thing, and you knew the thing was a button and you could click on it. The new buttons don’t seem clickable.
2. The new buttons look the same as the new drop-down menus (other than the little black triangle on the right side). Buttons and menus should look different.

I once heard someone lament that as soon as a user does a web search and the browser asks “you’re submitting information that’s not encrypted, do you want us to warn you about this in the future?” the user invariably says, “no, I don’t care.”

And that’s unfortunately because it means that if the user happens upon a web site that doesn’t force them to use https, then that user might accidentally submit their username and password over an insecure connection and the web browser isn’t able to warn them about it.

My question is, why couldn’t browsers add this additional check: “Show a warning dialog when I submit passwords that are not encrypted?” It’s as simple as checking if the HTML form performing the HTTP POST contains an <input type=”password”/> input box. In fact, you could just modify the current check for submitting unencrypted information to only warn if there is a password field, because that check is pretty useless as-is.

Can anyone think of any reason NOT to do this? I’ll file a feature request in Firefox Bugzilla if people think it’s a good idea.

Edit:
Done: https://bugzilla.mozilla.org/show_bug.cgi?id=476797

First of all, Stanford. At the school I went to, NC State, most people have the mindset that they’ll graduate, get a job at a normal, low profile, stable company for a while. Maybe get promoted. Maybe switch to a different company, etc.

But Stanford is different. For some reason it seems like most computer science graduates from Stanford have a hunger to come up with a crazy new idea and start their own company, get funded by a venture capital firm and build the company into something big or sell it for a lot of money. It’s like Stanford breeds computer startups.

Just living in the bay area is crazy. I swear half the people in my local climbing gym work at tech companies. It’s like everyone living in this area exists to support the software created here.

There are a few popular websites that cover startup companies. You should check these out if you want to get a feel for the crazy ideas people come up with:

• TechCrunch
• VentureBeat
• Valleywag
• Mashable
• AllThingsD

It works especially well for clients. For servers, if you want to take advantage of multiple processors or multiple cores then you either have to spawn threads or use multiple processes.

We use MySQL a lot at work. And we use C a lot. Unfortunately the C API for MySQL is synchronous. This means if you perform a query then the entire application sits idle until the database server responds. This is extremely inconvenient. There are various hacks and 3rd party libraries you can use to perform asynchronous queries, but they’re a bit ugly and don’t work that well. We ended up writing a proxy server that runs on the local machine and proxies queries to the database. So the client connects to the proxy and submits a query, control is returned to the client immediately, the client’s event loop watches the socket connected to the proxy server and calls a callback function once the proxy has returned the result from the database.

It works well enough, but I feel like the world would benefit from a solid asynchronous MySQL C API. Or maybe we should just switch to PostgreSQL.

P.S. epoll is ridiculously sweet. If you’re concerned about the performance of a network-heavy application then use epoll (or kqueue if you’re on BSD)! The difference is night and day.

Update 2010-02-26:
People suggested some projects in the comments. Also see:
https://launchpad.net/myconnpy
http://cv.arpalert.org/mysac.html

Anyone know of any other common functions with the same behavior?