One of the things I continue to like Python for is what I call 'bangingrocks together': quickly programming relatively small but non-trivialthings, on the order of a few hundreds lines and anywhere from anafternoon to a few days of time. A representative example would be thebasic UDP request/response bandwidth tester that I recently wrote; itcame to a bit under three hundred lines of Python with some comments,and took me perhaps a day or two of time to write, tune, make more

Since very few real applications just blindly fire UDP packets at atarget, when you want to know what UDP bandwidth you can get you aregenerally interested in the speed at which you can have a UDP-basedconversation between two sides. In other words, you need a bidirectionaltester, not just the sort of simple unidirectional one you can use withTCP bandwidth testing.

(Of course, TCP is actually bidirectional too. It's just that theconversation inherent in TCP is already handled by your TCP stack.

The traditional way that Unix kernels boot is to perform some very basicsystem setup, declare the running code to be a kernel process with PID 1,initialize all of the various important subsystems (such as networking),initialize drivers, mount the root filesystem from whatever device youtold them was the root device, and then just exec() (from inside thekernel) /sbin/init . At least in the somewhat old days, Linux was noexception to this.

The problem for initrds is that the job