Categories
Public Transport Travel

On Bangalore’s Road Traffic

I’ve been observing the road while I ride my old bike between my home and office (good job right?) and I’ve come to the conclusion that the autorickshaw drivers are almost always responsible for slowing down the rest on the roads. Unoccupied autos are even worse. They loiter around on the road driving in a jovial, not-really-busy way which comes to those of us who’re in a hurry as some sort of a mockery. Previously, I thought the new (and rising) breed of car driving population (many a time with just one person in the car) were the real culprits.

Bangalore is riddled with one-ways and “speedbreakers”. The one-ways are sort of understandable; they not only double the (band)width which helps in “ironing” out the traffic over a long distance, they rule out the accidents that may occur in a two-way road without a divider. The speedbreakers on the other hand, suck big time. They slow down four-wheelers (like cars) a lot. Think about all the gear-switching, the fuel consumption and most importantly, time wasted. It’s terrible.

I started hating autos more after seeing what they’re capable of. Apart from the sort of inconsiderate driving mentioned above, they’re a dangerous in a “worst-of-both-worlds” sense. Autos are three-wheelers (here in India): their width is slightly less than that of the substandard Maruti 800 and instead of a steering wheel, they have a two-wheeler-style handle. So, what this means to you on the road is, there’s this three-wheeler almost as wide as a car that’s going to invariably (if you’re used to it) or unexpectedly (if you’re new to it) perform sharp sideward movements (abrupt right or left turns) like the ones two-wheelers are capable of. Such awkward, dangerous movements are to be expected from an auto in front of you when there’s a red-signal up ahead and the vehicles in your flow are all slowing down and that auto tries to fit in (as if we’re all in a best-possible-packing competition (filesystem fragmentation reference >_>)) with the vehicles around it.

So, yeah, autorickshaw drivers are the first set of roadusers to hate. They’re way too many in the first place and safe autorickshaw drivers are just as rare as the availability hygienic fresh juice parlours in Bangalore.

Next, four-wheeler drivers who’re driving alone (come on!)

And then this is something mostly autorickshaws do, but I’ve seen two-wheelers and four-wheelers guilty of it too: Parking in the most inappropriate locations which causes traffic slowdown. Jeez. Outright stupidity or socially-inconsiderate: usually a combination of both.

Lane driving is something almost nobody respects. Some four-wheeler drivers do, but they’re rare. That short-term gain one might get by taking that abrupt turn or cutting someone else off from his course on the road drastically affects the general flow of traffic on the road. Long-term throughput is affected. I’m not going to talk about the benefits of using public transport. It’s something that should be fairly obvious (Of course, the lack of sufficient public transport isn’t an excuse to not do something about it. It’s your tax money. Oh, do you even pay taxes?)

Many a time, I’ve felt like stopping right there and blasting the offender on the spot. Alas, I’m neither that courageous nor patient nor capable of putting my message across successfully enough to actually make the person stop being a douche on the road in the future. Here’s to hoping that this blog post is going to help. Cheers!

Categories
Linux/BSD

On resizing filesystems and LVM2 logical volumes

I’ve been using Debian squeeze/sid for a while now (with apt-pinning) and for the past few days I’ve been facing the “no space left to write” problem. I used the default LVM2-based disk partitioning scheme offered by the Debian installer. I thought it was okay to have a 6.5G root partition and the rest for the swap and my home partitions. Looks like 6.5G wasn’t enough for me. And the root and home partitions used the ext4(!) file-systems.

Now, here’s how you go about reducing your home’s size and increasing your root’s size.

  1. Reduce the filesystem size of the partition which has enough free space to spare using resize2fs.
  2. Then reduce the logical volume in which this filesystem resides using lvreduce.
  3. Now extend the logical volume in which the “starving” filesystem resides  using lvextend by the same amount you used in step 2.
  4. Then simply issue resize2fs /dev/VGNAME/LVNAME which should simply fill up the unallocated space in the logical volume it resides.
  5. (optional), if your reduced filesystem doesn’t mount due to a block-size mismatch, e2fsck it and apply step 4. to it.

Glad that it all worked out fine. I didn’t have to use a live cd to do this (was too lazy for that anyway). I dropped into a vt, unmounted my home (which has the “important” data) and performed steps 1 and 2 on it. My root was still mounted while I did steps 3 and 4 on it.

Categories
Emacs Linux/BSD Software

Playing with LISP on Debian Squeeze

I haven’t looked up at how you play with LISP using Vim. Not really interested either since I’m committed to Emacs *rolls eyes*.
So, assuming you’ve already done aptitude install emacs23, Let’s go ahead and aptitude install sbcl cl-asdf slime. When in doubt aptitude show sbcl or aptitude show cl-asdf.

My motivation for this post in the first place was to document the quirks with the installation I was facing last night. If you happen to notice the following with the above aptitude install:

Setting up cl-asdf (1:20090819-3) ...
Reinstalling for sbcl
Recompiling Common Lisp Controller for sbcl
/usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc.
; loading system definition from /usr/lib/sbcl/sb-grovel/sb-grovel.asd into
; #
; registering # as SB-GROVEL
;
; compilation unit aborted
; caught 1 fatal ERROR condition

Error running init-common-lisp-controller-v4: Lock on package SB-IMPL violated
when interning NATIVE-FILE-KIND.
See also:
The SBCL Manual, Node "Package Locks"
mv: cannot stat `sbcl-new.core': No such file or directory
FAILED

Done rebuilding
Setting up cl-swank (1:20090908-1) ...
Setting up emacs (23.1+1-4) ...
Setting up sbcl (1:1.0.25.0-1) ...
/usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc.
; loading system definition from /usr/lib/sbcl/sb-grovel/sb-grovel.asd into
; #
; registering # as SB-GROVEL
;
; compilation unit aborted
; caught 1 fatal ERROR condition

Error running init-common-lisp-controller-v4: Lock on package SB-IMPL violated
when interning NATIVE-FILE-KIND.
See also:
The SBCL Manual, Node "Package Locks"
mv: cannot stat `sbcl-new.core': No such file or directory
FAILED

Your slime setup isn’t going to be functional. Fret not. Read on.

From Debian BTS bug #549528

=======BEGIN PATCH===================
--- /usr/share/common-lisp/source/common-lisp-controller/post-sysdef-install.lisp.orig 2009-10-21 14:42:00.000000000 -0400
+++ /usr/share/common-lisp/source/common-lisp-controller/post-sysdef-install.lisp 2009-10-21 14:40:59.000000000 -0400
@@ -61,7 +61,7 @@
#+sbcl
(defun get-owner-and-mode (directory)
(when (eq :directory
- (sb-impl::native-file-kind (namestring directory)))
+ (sb-impl::unix-file-kind (namestring directory)))
;; check who owns it
(multiple-value-bind (res dev ino mode nlink uid gid rdev size atime mtime)
(sb-unix:unix-stat (namestring directory))
=======END PATCH=================

Followed by,

dpkg-reconfigure cl-asdf
dpkg-reconfigure sbcl

Append the following to your .emacs, if you haven’t already.
;; Slime
(add-to-list 'load-path "/usr/share/common-list/source/slime/")
(setq inferior-lisp-program "/usr/bin/sbcl")
(require 'slime)
(slime-setup)

And your Emacs is ready to roll.