Andrew Cowie's talk in FOSS.in 2006

He gave a talk on "Solving fundamental structural problem of free software movement" where he addressed various problems.

He addressed the fact that it is indeed not very easy to contribute code for someone who is interested in participating. There is a long learning curve, and inherently centralized approach to get your patches accepted. The root of problem is the fact that everyone uses cvs and subversion, and he highlighted other emerging tools which approach the problem at the process level itself i.e. doing patch management in very different, decentralized manner.

Second problem is the difficulty of having to set up the build mechanism using make, autoconf and host of other tools, and he and others are working towards a simplified tool that could help the process (buildtool).

Third problem he addressed was the fact that bug tracking tools are indeed very bad - in the sense that for a given problem one faces, it is very difficult to trace back to the root of problem, which end up in some bug tracking system set up within project contexts, and end up as frustrating experience - especially considering that different libraries of same projects will use different bug-tracking systems altogether. Solution? To create a unified bug tracking mechanism.

And finally he also gave a lot of insights in ongoing Microsoft and Novell agreement related issues. And the fact that Microsoft can resurrect long-forgotten patents. He quoted example of DOS file system patent, which was resurrected after about 16-17 years or so...

People like me, who can't contribute on continuous basis, but can once in a while identify bugs and do small enhancements will indeed want to see some interesting things happen. I recently wanted to add a simple support for privoxy - to make it select a proxy from a list of proxies provided during runtime (something like switchproxy that is available as firefox plugin). I wanted this so that networking roaming is simplified and I can make privoxy the only proxy all my applications should configure and use; so I don't have to worry about switching proxies of every app when I roam. I knew exactly what code I wanted to write, but I couldn't get the build environment setup in quick enough time. (Especially considering that I wanted the binaries for windows).... and finally gave up on the idea.

Perhaps the approach for things like making bug tracking uniform is to let each system give out ATOM feeds with specialized entry types (i.e. of type "bug"). Agreeing on schema will always be a problem, but we can still do something.  The feed aggregators can then ensure that they identify these entries and provide a uniform look and feel at client-end. And we require a mechanism to capture dependencies, and associate raw errors with high level errors. (For e.g. "xyz.h not found" should be translated to "Package xyzxyz not installed on your system."). The ATOM feed approach also helps offline users who are connected to internet intermittently...

And same approach should be usable for build system itself i.e. whatever will be accepted as replacement for CVS/Subversion on large scale...

-Vinod

FOSS 2006 - I would like to meet interested folks!

I am here at FOSS 2006 in Bangalore. Would like to meet other people from Pune. (Some 4-5 of us from my organization are here.) 

Some of my interests, and if you have same interests, we could try to meet! (Mail me at vinod dot kulkarni at gmail dot com).

• Web-top concepts - Making browser front end the de-facto desktop, supported by native web server. Essentially integrate web and desktop in a way that it can give Linux an edge. (In this context, I would like to discuss role of ATOM protocols for some of the things.)
  
• Wiki systems - We use twiki as our enterprise Knowledge Management (and several other) platform. If you are tracking Wiki's we can get in touch. (And in general, content management systems ...)
  
• Bringing Web2.0 to enterprise and a better P2P approach for the same.

In particular, if you have open source projects in these areas (or may be in other areas as well), let me know!

So let me know if you are interested!

-Vinod

Unbelievable - Very high density, paper based storage?

This deccan Herald story is truly unbelievable. A student has used a very different approach (of geometric figures to pack more data) and print them on paper. When scanned, one can retrieve the contents back. And what sizes are we talking about? You get an idea here:

In a demo at his college laboratory, this author could see text typed on 432 pages of foolscap paper being stored in a four square inch paper. The author was even shown a 45-second video clip of a Malayalam film stored on an ordinary paper piece.

This seems to be a legitimate news because (a) Deccan Herald is respected news paper, and (b) The approach seems to be new, and probably not tried out before.

So if we try to analyze the paper based data storage, using regular scanners and printers we get in market (and assuming no loss, which in any case can be compensated by good encoding techniques), here is a guess about best of parameters that one would expect:

• About 10^2 distinct geometric shapes per 'location'
• About 10^3 distinct colours
  
• About 10x10 pixels for one geometric shape
• You have about  10^3x10^3 dpi (best achievable printing/scanning, given that we have about 4800x1200 today) pixels.  That is about 10^4 locations per square inch.
  

So basically we have about 10^4 * 10^2 * 10^3 = 10^9 bits that you can accomodate in square inch.  And that is approx. 1GB, or about 100Megabytes.  Give or take an order or two of magnitude, and you have at least 1 Megabytes per square inch. And that was what was the kind of numbers which were reported.

So it seems like there is indeed some potential!



Technorati Tags: mass-storage paper