Friday, October 24, 2008

Interfacing the Wiimote with Blender

Looking at ways to interface my recently bought Wiimote with Blender has made me to actually learn a lot of Blender. It has a really *steep* learning curve, but once you get comfortable with the interface it’s fun to play around with.

The physics engine in Blender did impress me quite a bit — it makes 3D graphics look so easy. Take my word, go try it. Blender is extensible through Python scripts and plugins, there’s ought to be a good way to interface it with an external input device like Wiimote.

GlovePie which stands for Glove Programmable Input Emulator supports the Wiimote and emulates it as a keyboard or a joystick! Nifty, I should get down to trying this but from the looks of it, this is just what I needed. Hook it up with some 3D graphics engine and you can move around and explore through virtual space.

There’s some more good stuff here. Looks like they have got a course on “expressive games” which uses Wiimote and Blender. So much fun!

Saturday, May 31, 2008

Memory usage of a process in Linux

I learnt something interesting today. Something that I was not aware of.
The way I often used to check the memory usage of a process was something like this

[root@n0000 ~]# ps -C <process name> -o vsize,pmem
VSZ %MEM
4204 0.2

Fair enough. I go and check out the man page just to reaffirm.

%mem %MEM ratio of the process’s resident set size to the physical
memory on the machine, expressed as a percentage.
(alias pmem).

vsz VSZ virtual memory size of the process in KiB
(1024-byte units). Device mappings are currently excluded;
this is subject to change. (alias vsize).

This ain’t too tough, I felt. The usual way in which this is implemented is by leveraging the information exported by the kernel in procfs. Digging into it further, I found out that’s quite the way it is done and most of the code in ps does the job of parsing and pretty-printing! Take a look here.
Mini ps implementation from busybox

And I would have been a happy-camper otherwise until I discovered this.

The VSIZE reports the address space allocated to that process. The per-process memory mapping is usually divided into it’s private memory and shared memory. Further, the RSS (Resident Set Size) determines the number of memory pages actually resident in the memory.

The complete shared and private memory information per-process is present in
/proc/$PID/smaps

I stumbled upon a script which parses this information and presents the memory usage of all the processes in a digestible format. Here goes -

Script to find out actual memory usage of a process

[root@n0000 adkulkar]# ./ps_mem.py
Private + Shared = RAM used Program

80.0 KiB + 316.0 KiB = 396.0 KiB klogd
76.0 KiB + 432.0 KiB = 508.0 KiB agetty
112.0 KiB + 432.0 KiB = 544.0 KiB portmap
260.0 KiB + 340.0 KiB = 600.0 KiB udevd
372.0 KiB + 264.0 KiB = 636.0 KiB rpc.idmapd
304.0 KiB + 340.0 KiB = 644.0 KiB crond
128.0 KiB + 520.0 KiB = 648.0 KiB syslogd
460.0 KiB + 240.0 KiB = 700.0 KiB dhclient
140.0 KiB + 584.0 KiB = 724.0 KiB rpc.statd
144.0 KiB + 592.0 KiB = 736.0 KiB init
376.0 KiB + 400.0 KiB = 776.0 KiB mingetty (6)
620.0 KiB + 676.0 KiB = 1.3 MiB slurmd
832.0 KiB + 620.0 KiB = 1.4 MiB bash
1.7 MiB + 1.0 MiB = 2.7 MiB sshd (2)

Private + Shared = RAM used Program

Warning: Shared memory is slightly over-estimated by this system
for each program, so totals are not reported.

A worthwhile discovery, I must say :)

Wednesday, April 30, 2008

Graphical boot screens (splash) in Linux

I decided to do a quick survey of the available options to do graphical boot screens (better known as bootsplash) in Linux. There seem to be a lot of ways to do it, the most common these days being splashy. I did a screen using bootsplash days back which turned out to be quite well. But the only nag with bootsplash is patching the kernel and recompiling it. perceus.jpg

IMHO, considering the shift towards desktop computing these graphical bootsplashes add a certain bling for the first-time users as opposed to the console bootup messages flying across the screen.

Here goes -

Bootsplash

Features

  • Nice graphics (JPEG)
  • Antialiased text /rendering (TrueType)
  • Animations (MNG)
  • Progress Bar
  • Display of boot messages above or below a graphic. (”verbose” and “silent” modes)
  • Fully themeable

*Requires a kernel patch
http://www.bootsplash.org/

(NOT ACTIVE ANYMORE)

Fbsplash (formerly gensplash)

The Framebuffer Splash - is a feature that allows displaying
images in the background of consoles that use fbcon. The project is
partially descended from bootsplash.

fbsplash is distro-neutral and can in principle be used on any Linux system which supports the framebuffer, but integration of fbsplash with the initscript system requires writing customized code for different Linux distributions.

http://fbsplash.berlios.de/wiki/doku.php

(ACTIVE - Latest update 20 Apr 2008)

Used by Gentoo, Sabayon Linux, Arch Linux

Splashy

Splashy is fully configurable from 2 XML files and mostly all features can be turn on or off at will.
Splashy is a next generation boot splashing system for Unix-like systems. Unlike other splashing systems, it needs no patches to the kernel and it’s installed like a normal package.

  • Require zero kernel patches/full functionality in user-space
  • Boot/halt/reboot/runlevel-switch support
  • Progressbar support (with optional border)
  • Initramfs support
  • TrueType2 fonts support
  • Lots of image/animation file formats supported: jpg, png, gif, mpg, swf
  • Low dependencies and code in C to best perform

http://splashy.alioth.debian.org/wiki/

Used by OpenSuSE, Xandros, SuSE, Fedora, and of course, Debian

(ACTIVE - Latest update 10 Jan 2008)

Monday, March 24, 2008

Ramback

There has been a recent proposal to improve the Linux VM by Daniel Phillips, who’s a Linux Kernel hacker at Google and leads the Zumastor Linux network storage server project.

The idea behind ramback is that the whole of system memory (RAM) is turned into a ramdisk but with automatic synchronization to persistent storage media (like the hard disk).

Ramback is a new virtual device with the ability to back a ramdisk
by a real disk, obtaining the performance level of a ramdisk but with
the data durability of a hard disk. To work this magic, ramback needs
a little help from a UPS. In a typical test, ramback reduced a 25
second file operation[1] to under one second including sync. Even
greater gains are possible for seek-intensive applications.

The ramback patch lists the complete details of what works, the bugs and what’s planned. Using ramback, the application I/O is blazingly fast, almost by a factor of about 25 and the kernel worries about synchronizing the changes with the persistent storage media

I can see repercussions of this to diskless clustering where the system image loaded in RAM can be synced with a shared filesystem storage for a more persistent system state in the nodes across the cluster.
It’s just a matter of time before these improvements in the Linux kernel and advancements in computer architecture are harnessed to build faster and more efficient high performance computing systems.

Saturday, March 22, 2008

The Kick Off

I have been looking for a flat-file blog engine since eons, so that I could just spin up a quick blog on our CS servers.
Flatpress is a simple, light-weight, easy-to-setup (Trust me, setting this up didn’t take more than 10 minutes) blogging engine that requires no database to work. That means. it uses flat files to store it’s configuration data and also the blog data. Another “side-effect” of this is that, I can easily backup my blog posts or move them on to any other blogging engine (like say SPB).

I’m impressed!
Time to start taking notes…