breaking the Pareto principle?
quotes from http://howsoftwareisbuilt.com/2009/11/18/interview-with-greg-kroah-hartman-linux-kernel-devmaintainer/
There's a theory that says "if you put a million monkeys in front of a million typewriters, in a few years you can get the collected works of Shakespeare".
There's another theory that says the internet was invented precisely to test this :-)
quotes from http://howsoftwareisbuilt.com/2009/11/18/interview-with-greg-kroah-hartman-linux-kernel-devmaintainer/
at 13:30 0 comments
http://ask.slashdot.org/comments.pl?sid=1460432&cid=30264494
This was in response to someone asking about network security while backpacking for a whole year through South America!
at 10:48 0 comments
http://forums.theregister.co.uk/forum/1/2009/11/26/lse_crash_again/#c_635437
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.
at 11:15 0 comments
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.
at 07:58 0 comments
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:
http://www.timemachinego.com/linkmachinego/2009/11/16/me-and-belle-de-jour-could-it-be-brooke/
-- an early warning system that depends on googlewhacking
at 22:01 0 comments
http://git.kernel.org/?p=gitk/gitk.git;a=commit;h=70a5fc443acbd1fe69cc21c10190375facabaf93
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...
at 15:03 0 comments
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.
at 10:25 1 comments
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).
at 10:14 0 comments
(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."
at 16:25 0 comments
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.
at 10:07 0 comments
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!
at 14:53 0 comments