loopkid: Category English

finding large directories

Stefan — Tue, 30 Oct 2007 23:49:25 +0100

Every once in a while there is the need to clear out the system. The question that inevitably pops up is: Where has all the disk space gone ? The solution of course lies in locating the largest directories. With WhatSize and OmniDiskSweeper there are two great tools on Mac OS X. There are also feasible Tools on Linux like Filelight, but if you’re administering a remote server and you don’t want to use remote x11 access you need a solution that can be controlled either on the command line or via browser. Of course you could use sturdy old du.


# Find all directories with the largest directories on top
$ sudo du -Sx / | sort -nr | less
# Find directories over 100MB with the largest directories on top
$ sudo du -Sh / | grep ^[1-9][0-9][0-9][0-9\.]*M | sort -nr

Or you could hack together some fancy perl script, but wouldn’t it be nice to have an interactive graphical visualisation through which you could comfortably navigate ? This is where Philesight pops in, which offers both command line and browserbased control. Putting it up on Debian is a breeze. Just install cairo and berkley db and their ruby bindings and then get rolling.


$ wget http://zevv.nl/code/philesight/philesight-2035.tgz
$ tar xvfz philesight-2035.tgz
$ sudo apt-get install libcairo2 libcairo-ruby
$ sudo apt-get install libdb4.2 libdb4.2-ruby1.8
# Generate index
$ sudo ./philesight --db base.db --index /
# Check if image is correctly generated
$ ./philesight --db base.db --path / --draw base.png

Firing up the web interface is just three small steps further. First configure the CGI-File.


# philelight.cgi
db = "./base.db"
default_path = "/"

Then create a reasonably named subdomain and after that just add a few lines to your lighttpd configuration file (or the corresponding lines to the webserver of your choice).


$HTTP["host"] =~ "philesight.yourdomain.net" {
  cgi.assign = ( ".cgi" => "/usr/bin/ruby" )
  alias.url = ( "/" => "/path/to/philesight/philesight.cgi")
  server.document-root = "/path/to/philesight"
}

That’s all there’s to it. Have fun.

bittorrent is a resource hog !

Stefan — Tue, 07 Nov 2006 21:42:00 +0100

After upgrading the memory of my Powerbook to a more reasonable amount, I did some testing with heavy weight applications to see how much more free memory there would actually be available when working with real life documents. The results were quite satisfying, but during testing I noticed something else. The Bittorrent Client I had running in the background consumed more than 20(!) percent of my cpu resources even though it was only handling two downloads at that time. Even for a greedy filesharing application this seemed like an awful lot of cpu usage to me.

I did some evaluation of Bittorrent clients a while ago, but only in terms of user interface and not in terms of cpu usage. I decided this might be a good moment to catch up on that. As my partner in crime I chose Peek-a-Boo, a very useful monitoring application. The competitors in my evaluation where the original Bittorrent Client, Transmission, BitRocket and Bits on Wheels. The task was simply to handle a dozen downloads simultaneously with the user interface minimized to the dock.

After initializing the downloads I waited a few minutes for the applications to connect to their peers and then opened a usage history window for each of them. The results where quite interesting and proved me right in my suspiciousness concerning the Bittorrent Client being a little too wasteful with cpu resources.

Due to the dynamic scaling of the graphs you can see that these applications actually play in different leagues concerning their cpu usage. The Bittorrent Client operated in the 20% scale, BitRocket and Bits on Wheels were both located in the 10% scale and Transmission was in the 5% scale. They all seemed to perform around equally well in terms of their download rate. These graphs are of course by no means scientific, but from my observation they do show representative values.

An interesting thing to note besides that, is that each application seems to generate a distinct shape when utilizing the cpu. The Bittorrent Client produces a very regular sawtooth-like pattern and Bits on Wheels shows a similar shape, but has a little more spikes. BitRocket has the most irregular shape of all applications and Transmission has the smoothest curve. After having observed these curves for a while - beware, now it’s getting really nerdy - I felt like it probably wouldn’t be too hard to identify the application by its cpu usage curve. Before I start getting carried though let me wrap this up by stating that my new default application for downloading torrents on Mac OS X is of course the wonderful Transmission, which also happens to have a quite polished minimalistic interface and very intuitive preferences. Congratulations to Eric Petit and his collaborators!

donationware as a business model ?

Stefan — Tue, 05 Sep 2006 11:25:00 +0200

More generally thinking I asked myself how many people actually do Paypal donations on “donationware”? Would these little applications make a better profit if they sell for $10 instead of $25? — Oliver Wrede

Actually I really do like the concept of donationware and have bought several little Mac apps this way, mostly between $5 and $20. I think this a really great small scale business model because it involves trust.

Another nice option for programmers of small applications in my opinion is the selling of devotional objects via some online retailer. One of my favorite investments from this category has been the Cyberduck Mug from David Kocher’s Cafepress store. Talking about great ftp clients, this strategy of course isn’t solely an option for donationware, a purchase at Panic Goods in addition to buying a license for Transmit or Unison sure won’t hurt those guys neither.