Free hosting for facebook apps

I recently stumbled upon free hosting for facebook apps. [1] One has to wonder what motivates companies to provide services such as these. It could be sheer benevolence, but I suspect there are some statistics and information mining that must be the driving factor. In any case it's something to be aware of.


[1] - http://www.joyent.com/developers/facebook/

Ever wished you had taken that college course?

A physics professor at the age of 71 has become an internet web star, because of his freely available physics lectures. [2]

From the website:

OCW shares free lecture notes, exams, and other resources from more than 1800 courses spanning MIT's entire curriculum. [1]

Wow. I may have found my new years resolution.

[1] - http://ocw.mit.edu/OcwWeb/web/home/home/index.htm
[2] - http://www.nytimes.com/2007/12/19/education/19physics.html?_r=2&hp&oref=slogin&oref=slogin

Crowd Sourced Cloud Computing?

Projects like seti@home [1] have been around for awhile, I'm not sure how long. There are a few others that I can't seem to find right now. The articles about Google's cloud computing [2] got me to thinking, why isn't there a crowd-sourced general purpose version of these networks?

Some company creates the libraries and test facilities for writing MapReduce [3] programs. Then they provide a free program that people can download and run, like in [1]. Companies would pay to have their programs run on the network, and the profits would be passed on to the individuals who's computers ran some of the processing ...

I know there are a lot of tiny details to get right, security, validation of results (IE, rogue machines purposely calculating invalid results quickly to game the system), but it feels like it could be insanely profitable.

Someone has to have thought of this already. If someone out there knows of this, please let me know.

[1] - http://setiathome.berkeley.edu/
[2] - http://www.abetterkindofangry.com/2007/12/googles-algorithms.html
[3] - http://en.wikipedia.org/wiki/MapReduce

Google's Algorithms

A friend of mine sent me this article [1] which isn't bad, but is kinda long for what it's trying to say.

Mostly it drew my attention to the types of algorithms that google uses for it's large scale processing. They're based on MapReduce [2] which is fascinating in and of itself, but also of Hadoop [3] which is google's open source java implementation of a MapReduce. Eventually I made it to [4] which looks like it's a fascinating read. I almost got stuck in a wikipedia feedback loop [5] but managed to escape by realizing that I should print and read the research paper instead of continuing.


[1] - http://www.businessweek.com/magazine/content/07_52/b4064048925836_page_4.htm
[2] - http://en.wikipedia.org/wiki/MapReduce
[3] - http://en.wikipedia.org/wiki/Hadoop
[4] - http://labs.google.com/papers/mapreduce.html
[5] - http://xkcd.com/214/

python-ogre Linux package

Congratulations are in order to Andy Miller for taking python-ogre so far, and specifically for producing an excellent linux build.

It's now much easier to just download the bindings and start hacking. Included in the build are 3D rendering libraries, GUI libraries, Physics Libraries and some other surprises, like support for Caelum. This gives me much motivation to try to get involved again.

On Python vs Ruby

http://tabo.aurealsys.com/archives/2007/04/26/on-python-vs-ruby/

Made my day.

Gedit, plugins and complete wastes of time

Gedit has a nice plugin interface and includes python bindings. I sat down tonight to learn this interface in the hopes that I might be able to build myself a plugin I had been wanting for awhile. This plugin would use Divmod's Combinator (a reasonable tool for projects in SVN) and list all my projects in the left hand side tool pane of Gedit. The plan was to give an easy way to edit code from the current branch of these projects. Starting a gedit plugin using the tutorial was dead easy, I was up and going in 10 minutes. At this point I felt confident enough to start on the real implementation of my plugin.

First, I need to be able to list directories and files on the side pane. Now, directory listings are part of every operating system I've ever used, and I figured that Gnome had solved this nicely by now. I first looked at the pygtk reference material, and nothing jumped out at me. So I figured I'd have a quick look at the filebrowser plugin that comes with gedit. First obstacle, it's written in C. Oh well, I have a good enough understanding of C so I grab the source. Wow, that's quite a few files. I start poking through them, and to my surprise, they were huge!

Running sloccount on the directory produces:

SLOC Directory SLOC-by-Language (Sorted)
7375 filebrowser ansic=7375


Totals grouped by language (dominant language first):
ansic: 7375 (100.00%)




Total Physical Source Lines of Code (SLOC) = 7,375
Development Effort Estimate, Person-Years (Person-Months) = 1.63 (19.56)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.64 (7.74)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 2.53
Total Estimated Cost to Develop = $ 220,187
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

7k lines of code!? To embed a filebrowser into an editor!? WTF!? It's not like this particular filebrowser implements any special features for the editor either. Besides, gnome already has a filebrowser. Nautilus. Surely nautilus provides an embeddable widget that can be re-used. And if it doesn't then why didn't this time get spent on making one for it! What is wrong with people that they figure re-implementing yet file management all over again is a reasonable use of their time?

Theo de Raadt recently espoused some very well informed views on licensing, and their repercussions [1]. He has a lot of good things to say, and the overall point of his post is very convincing: Those who make use of and extend BSD code should be considerate of the original authors. Specifically, they should think before re-licensing the derivative work it in such a way as to exclude it from being used by the original authors. The OpenBSD community is responsible for a large, very well written code base, and everyone should thank them for that by giving back. Even if their views on licensing are different from ours.

However, I want to focus on a particular paragraph of his:

GPL fans said the great problem we would face is that companies wouldtake our BSD code, modify it, and not give back. Nope -- the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out. Just like the Linux community, we have many companies giving us code back, all the time. But once the code is GPL'd, we cannot get it back.

Ironic.

Social issues aside, this section implies that it is the users of the GPL that are at fault for locking the BSD users out of re-using the dual-licensed code. However, the reality is that is the combination of the licenses that prevents it. The users of both licenses choose their licenses for a reason, and must deal with the ramifications, not the least of which is that BSD code cannot borrow from GPL code without changing the manner in which the BSD code may be used. So, when Theo chose the BSD he made a conscious decision to restrict himself from re-using GPL code, so ... it's not strictly the fault of the GPL users. The OpenBSD guys could choose and use a license which doesn't have this restriction if they wanted to.

In other words. The cause of the restriction is based on your frame of reference or point of view.

[1] - http://undeadly.org/cgi?action=article&sid=2007090104165

Linus is a troll

C is a useful choice in many cases, and may even be the right choice for git [1]. If only for the fact that Linus is fluent in it and he produces great software. But that doesn't detract from the fact that Linus acts like a 3-year-old on a regular basis. Heck, he makes Theo-de-raadt [2] look like a polished orator.

[1] - http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
[2] - http://undeadly.org/cgi?action=article&sid=20070901041657

Python - Getting out of my Way

I'm an INTJ which, among other things, means that inefficiencies really get under my skin. In programming, I find that most languages get in my way more often than not. Python on the other hand has always made me more efficient for using it. Apparently, I'm not alone:

I've come to understand that with programming, it's not really about which language you use but what you do with it. Computers are fast enough today to trade speed for comfort at an acceptable level of performance. After all, a programming language should work for you, not bury you.[1]

"With Python, the code gets out of my way, so I can get to the problem am I actually trying to solve, very soon." -Bruce Eckel [2]

[1] - http://problemboard.com/bio/?p=145

[2] - http://www.artima.com/intv/tippingP.html