American geeks: if you want to fix your congress using your preexisting l33t hacker skillz rather than getting directly involved in politics (and who could blame you,) then here is my best advice:

Force your legislature to start using version control.

* No more sneaking revisions through in the middle of the night without anyone noticing.

* Being able to do `git blame` style operations to resolve individual clauses down to individual lawmakers, then back to lobbyists.

* Simple diffing would prevent deliberate obfuscation tactics like burying provisions deep inside piles of irrelevant stuff.

* You could build a sweet github-style outward facing interface allowing the public to track the progress of bills in real time, increasing democratic awareness and participation.

* Legally mandated commit messages accompanying each change justifying and explaining it; force them to write these in simple english. This alone would spin 'em around so hard they wouldn't know what day it is.

* Use your imagination. I'm sure you can think of 100 reasons why this would be awesome.

Build it, open source it, then start your own lobbying/PR machine to demand that they use it. Constantly ask for justifications as to why they are not willing to use it, given the massive, obvious benefits it would bring. Ask what they have to fear from the extra scrutiny and accountability it would bring. Surely the "social media generation" can out-lobby the lobbyists? That sounds like it should be the kind of thing we're good at.

Or just forget about that entirely and try to think of some way to decimate the lobbying industry in the same way that hackers are destroying the content distribution industries and all that other stuff.

Great analysis, missed a huge point though.

A fraction of an industrial machine makes zero napkins.

Your analysis is spot on, the problem can be solved more efficiently with a large scale production. The capital expenditure cost however is similar (43M vs 50M). You point out they huge disparity in labor costs $25M vs .09M but labor is 'free' in India (which is to say there is so much of it available that the price is a lot less than elsewhere).

The incremental solution here wins because a small increment in cash instantly starts feeding the supply of napkins. The 'big machine' solution loses because it takes a huge investment to get to the point where you can make the napkins and nobody is willing to fund that.

There is another problem which are transportation costs. The infrastructure in India is, by all reports, spotty in the rural areas. By creating the manufacturing in the towns themselves you mitigate the transportation problems. That would not be possible with a centralized industrial machine. Further the folks who 'make' the napkins can also sell them so you have a personal relationship with someone in the town.

The incremental nature, the fact that India is labor rich and infrastructure poor, and the comparable capital costs make this an extraordinarily good solution to the problem.

I don't know this poster, but I am pretty familiar with the problem he's encountering, as I am the person most responsible for the Chrome build for Linux.

I (and others) have put a lot of effort into making the Linux Chrome build fast. Some examples are multiple new implementations of the build system ( http://neugierig.org/software/chromium/notes/2011/02/ninja.h... ), experimentation with the gold linker (e.g. measuring and adjusting the still off-by-default thread flags https://groups.google.com/a/chromium.org/group/chromium-dev/... ) as well as digging into bugs in it, and other underdocumented things like 'thin' ar archives.

But it's also true that people who are more of Windows wizards than I am a Linux apprentice have worked on Chrome's Windows build. If you asked me the original question, I'd say the underlying problem is that on Windows all you have is what Microsoft gives you and you can't typically do better than that. For example, migrating the Chrome build off of Visual Studio would be a large undertaking, large enough that it's rarely considered. (Another way of phrasing this is it's the IDE problem: you get all of the IDE or you get nothing.)

When addressing the poor Windows performance people first bought SSDs, something that never even occurred to me ("your system has enough RAM that the kernel cache of the file system should be in memory anyway!"). But for whatever reason on the Linux side some Googlers saw it fit to rewrite the Linux linker to make it twice as fast (this effort predated Chrome), and all Linux developers now get to benefit from that. Perhaps the difference is that when people write awesome tools for Windows or Mac they try to sell them rather than give them away.

Including new versions of Visual Studio, for that matter. I know that Chrome (and Firefox) use older versions of the Visual Studio suite (for technical reasons I don't quite understand, though I know people on the Chrome side have talked with Microsoft about the problems we've had with newer versions), and perhaps newer versions are better in some of these metrics.

But with all of that said, as best as I can tell Windows really is just really slow for file system operations, which especially kills file-system-heavy operations like recursive directory listings and git, even when you turn off all the AV crap. I don't know why; every time I look deeply into Windows I get more afraid ( http://neugierig.org/software/chromium/notes/2011/08/windows... ).

One of the first things we were taught in EMT training is that if you ever need something from a crowd of bystanders you can't ask the mass, you have to pick a very specific person and address them directly. "Someone get me a crowbar" will get no response, but "You, in the red jacket, get a crowbar or something to open this" will usually get the effect you want.