breaking the Pareto principle?

quotes from http://howsoftwareisbuilt.com/2009/11/18/interview-with-greg-kroah-hartman-linux-kernel-devmaintainer/

To give an example, for the 2.5 to 2.6 kernel development series, which took about two years, the top 30 people did 80 percent of the work. Now, the top 30 people do 30 percent of the work. The sheer number of developers has also increased. We were running a couple hundred developers, and now we're running a couple thousand.


We're also increasing the rate of change in our development. The same amount of work one of the top 10 developers did last year wouldn't have even made it into the top 20 this year. Our individual developers have got the work flow down, so we can actually contribute more, to an extent that's amazing.

perspectives, take 2...


This was in response to someone asking about network security while backpacking for a whole year through South America!


stop the internet!


Subject: "despite a .NET upgrade overseen by Accenture"

Posted Thursday 26th November 2009 13:40 GMT

Hahaha hahahaha hahahahaha hahahaha <gaaaaaaaasp> ha haha hahahaha
hahahahahaha hahaha.

Stop the internet, nothing can ever beat the humour of this statement.

the ubuntu "mono" culture

lovely comment at http://www.linuxtoday.com/news_story.php3?ltsn=2009-11-25-031-35-OS-CY-0019 argues that the slow infiltration of mono-apps in Ubuntu was probably planned that way, and the more such apps get added the easier for non-mono apps to be rejected in favour of a notionally equivalent mono app.

Read the full comment; makes a very cogent point.


finally, something interesting in Brooke's tale

until now, it was pretty boring. I never really liked her blog --
maybe it was too disjointed? or maybe I like my salacity in larger
doses? I don't know.

but this is cool:
-- an early warning system that depends on googlewhacking


(git) finally...!


This will fix a long-standing problem for git use at work, and give me
more confidence in saying to people "just stick to the GUIs and you
can't go wrong for most normal operations". I''d sent in the patch in
June but it got lost somewhere that time; this time it got accepted...


directory level access control via gitolite

I'd like comments on this from my readers.  Don't worry if you don't know what git is.

All you need to know about git/gitolite to understand this post and comment is: (1) git is a modern version control system for source code, (2) git makes using branches (different development lines for the same project; like "release", "maint", "customer-specific", etc) almost trivial, and (3) gitolite is an access control layer that sits underneath it and implements restrictions based on branch name (ie., only the QA guy can push to the "QA-done" branch).

The question was: we need "path-level" restrictions also (I can only change files in subdirectory-A, you can only change files in subdirectory-B, etc).

Here's the email I sent the person who asked me for this feature, and on which I want your comments.


I have a small philosophical objection to this sort of restriction.  Let me explain.

I want the computer to catch mistakes that are easy to make, and hard to reverse.  Pushing the wrong branch is a good example (esp if some branches have similar names), so gitolite is focused on branch permissions.

Touching a file in another directory is a mistake that is hard to make and easy to detect and stop.

Normal workflow is that devs only push to their own branches, from where their code is picked up for QA and (if accepted) moved to the main branch by someone with that authority.  If QA can't even detect that the wrong files have been touched, you have a bigger problem than gitolite can solve :(

Automating subdirectory based restrictions seems as if you are using gitolite as a substitute for internal team communications.  And maybe even trust.


tutorial: how to watch a movie when you're supposed to be working...

You can do it, it's easy!  Here's how.

(Pre-requisite: a full-day business trip to Mumbai)

Step 1: plan your trip so that all flights (outbound and return) are the "first flight in the morning" kinds.  Mine were a 6am departure outbound and a 6:25am departure on the return.  A 1hr 15 min flight means I'm well in time to be at work by 9am on both days.

An advantage is that delays to first flight in the morning are highly unlikely (except due to fog in Delhi in winter, which is why we chose Mumbai for this tutorial)

(corollary to step 1: this means you have to wake up at 4am or so, but you take those things in your stride)

Step 2: make sure at least one of the flights is Jet Airways.  Bonus points if a Kingfisher flight crashed (no one injured, thankfully) the previous day, blocking half of a usable runway or something, but this is beyond your control.

Step 3: enjoy the movie

Eh what?  I missed a step?  Sure but those are not *your* steps.  Jet will take care of those.  I stole a flight suprintendent's notepad and copied these notes from the back of his book (they were written in invisible ink so I had a bit of trouble, but I'm persistent):

Step 1: most people don't know that the so-called "first flight in the morning to Hyderabad" is not what we in the trade call "AOG" (aircraft on ground).  It comes from Sharjah or Jeddah or Dubai or one of those middle-eastern sounding, why-in-blazes-would-I-ever-want-to-live-there[*] places.  This tricks a lot of people into thinking the flight is safe from delays, especially *in*frequent flyers.

[*] one good reason to live in those places: they don't have any terrorism. Sort of like Indonesia doesn't have any expensive Nike shoe stores maybe?

Step 2: make sure that flight is delayed about 30 minutes.  Also make sure it is parked as far away from the domestic terminal as possible.

Step 3: make sure at no time do you announce a delay more than 10-15 minutes;  20 minutes tops...]

Step 4: as soon as some passengers (already irritable from having to wake up at 4am), start arguments about breakfast coupons due to the delay, announce boarding.  Have them go through the final security guard and approach the bus that will take them to the aircraft.

Step 3.9: err, we forgot -- go back to just before step 4 and make sure there is no bus actually waiting.  The passengers cannot re-enter the building and pick a fight with you now; security will stop them.  This is a useful technique to use when passengers get irritable for silly little things like delays and breakfast, and the lack of any update that goes beyond 20 minutes.

Step 5: eventually find a bus and send the PAX to the aircraft.  Finish all the boarding formalities but don't take off for about 1hr 30 minutes.

Step 6: Blame DGCA/ATC for everything.


Author's note: some of the fault *was* indeed the DGCA/ATC/Mumbai airport, but Jet could have done a lot to mitigate it.  They did *nothing*.  To add insult to injury, they sent out a 7:40 departure flight on time (while we were cooling our heels inside the aircraft till 9:45).


(funny) slashdot comment on cloud

(though the original article may not have had anything to do with it, but hey this is /.)

Re:Buzzwords, because thinking is hard
by megamerican (1073936)

"No officer, I'm not naked. I'm a trend setter in cloud clothing. That man over there is wearing pants for me. Honest."


(git) clearcase speed

from http://permalink.gmane.org/gmane.comp.version-control.git/132311,
in response to someone touting CC's ability to track partial repos and
asking why git can't do that:

> My (limited) experience with ClearCase is that it's so slow that you'd do *anything* to track fewer files in your working copy, so they put a lot of work into exactly that, and no work into performance.


made my day...

The maintainer of a very popular library in the perl world (LWP.pm) is using gitolite and wrote to me to say thanks and it is working well for him :-)

He probably wrote more perl in a month than I wrote in all my life so this is a "wow" moment for me!