What Chris said. Go watch Eben's talk, it really is worth it. I'm going to watch it again.
Chris had a nice quote, but you can skip randomly to any part and get other equally nice quotes.
"The patent has become a real estate entitlement, not based upon the social value it produces, but rather irrespective of the social harm it may induce."
What I find most interesting about Mughsot is the team's total and no-bullshit commitment to making new and interesting software which doesn't suck.
I love the way they say their design process "isn't a checklist of activites you must do - it's an idea list, suggestions for how to work smarter". I love the way they prototyped a photos feature using flickr but were willing to drop it again after trying it on real people. I love the way they lock themselves in a room, leaving their laptops behind, and give themselves the time to hash out ideas properly.
I hope Mugshot itself is a success. But, more than that, I hope they help change the way the rest of us make software.
As part of the work I've started doing on Stateless Linux, I've found myself hacking on device-mapper's snapshot support. It's actually been really good fun to do a bit of kernel hacking again after such a long time ... and this time I feel like I actually have some clue what I'm doing.
I'm really behind the times when it comes to all the new fangled revision control systems out there like bzr, git, mercurial, svn etc. - cvs and manual patch mangling is all I know.
So, when agk pointed me at quilt, I was a bit dubious at first but gave it a shot. It turned out to be a really simple and useful way of maintaining your own patchset in parallel with an upstream codebase.
Even though it's a really simple tool, it seems to me to have some of the important advantages of other systems like distributed offline branches and change sets. If I had time to hack on GNOME again, I'd use quilt a lot for offline branches alongside CVS. It's given me an appetite for looking at other systems too.
Aren't discussions via blogs fun? :)
Federico: two points:
Using the new GObject instance private data API, rather than the private data scheme that GNOME hackers have always used, is a small optimization in itself - the private data is allocated in the same chunk as the object itself.
As with all optimizations, you weigh up the benefit against the code obfuscation. In this case, I don't think the GObject scheme makes the code more difficult to understand ... especially since it's likely to become as much of a second-nature idiom as the old scheme. It's also one less opportunity to leak memory.
Using the GObject scheme, instance private data could have been added without the runtime hit you were seeing ... even where the object structure couldn't be extended without breaking ABI.
To do so, you'd just go back to something similar to Owen's initial
suggestion for how the API should be used - in a static variable,
you'd store the offset between the address of the object structure
and the private data and use that offset for efficient access to
the data. add_private() originally returned this offset, but it no
longer does, so you'd need to calculate the offset in
instance_init() - but it is guaranteed to be constant.
Granted, that's a nasty hack which would genuinely obfuscate the code ... but at least it would actually be possible to add private data, whereas it wouldn't be possible with the old scheme.
Update: Tim points out that the offset to the private data isn't constant across all instances - the offset will be larger for subtypes since the private data is allocated after all object data.
Yesterday I posted some code which shows how to use Fedora Directory Server's "persistent searches" using OpenLDAP's client library. Here's that same code, but as a Python module.