all that glitters..??

"Never buy low serial numbers." Easy advice to give, but hard to follow. Witness the modern-day genius of pre-marketing: every time a neat new hi-tech gadget gets announced, a virtual army of unsuspecting consumers turns out to pay for the privilege of becoming beta-testers. Egging them on are "reviewers" (possibly hired shills), who write glowing reviews of the as-yet unmanufactured product in question. Occasionally, we are treated to videos of consumers camping out overnight in front of an electronics store for the privilege of being first in line to purchase a shiny new experimental gizmo that the manufacturer needs to get rid of before a greatly-improved version 2.0 is launched a few months later...

I could haven't have written it any better than Robert Storey, as above.

i found an old .iso in my archives. wondering why i had it in the first place, i started exploring it... i am most impressed by WattOS R4. i couldn't believe how fast it boots, how efficient it's footprint is, and still functional. i have it installed now and think i am going to keep it.

i am using wattos4 as a browser appliance - extremely nimble and fast. who would have believed it from an ubuntu base! so, i plonked for it's latest iteration WattOS R6, and found it to be slightly worse than wattosr4.

i have reviewed antix before, but i can't recollect. i will have a look and update this post here.


my wm journey moves on... from various bloatwares to fluxbox to ratpoison to spectrwm to dwm... now to evilwm :-)
i hope to keep this post updated, and accumulate my evilwm experience.

i did a memory profile on some window managers on my radar, and found evilwm to be using the least memory of them. that made me look at it in more detail, and i find i like it better than dwm that i'm currently using.

evilwm install in debian
[code]# apt-get update && apt-get install evilwm[/code]

edit .xinitrc (.xsession if you use any dm). change current wm with evilwm.
[code]exec evilwm -term gmrun -nosoliddrag[/code]

keyboard meta is ctrl-alt
my most used are

1-8 - change virtual desktop
left - prev virtual desktop
right - next virtual desktop
f - (un)fix window

x - maximise current window (toggle)
= - maximise current window vertically (toggle)
HJKL - shift window
hjkl - move window
yubn - move window to screen corner

alt+tab - cycle through windows (don't use meta key)

to maximise window horizontally: use = and x alternatively and repeat to toggle.
to move windows between virtual desktops: fix window, change desktop, unfix window.

manual says "To make evilwm exit, you have to kill the process". i completely agree - providing spurious buttons is bloat - not the job of a wm. and why would you want to exit x? to shutdown?

just shutdown
$ sudo halt

if i do have to quit evilwm
$ killall -9 evilwm

as i have mapped gmrun to evilwm default term, i bring up a command-line with ctrl-alt-enter and enter the above commands.

or you could map the commands to a keyboard shortcut of your choice. if that is how you like it, use xbindkeys.

as this is an extremely efficient wm, for any additional functionality you can use other extremely efficient apps to add features you may need.

gmrun - command-line application launcher
xbindkeys - custom keyboard shortcuts

ref links:

downsizing android

i have been on a continuous quest to reduce resource requirements. i think this is affecting my personal life too - simplifying my own demands is making me live happier :) but, back to the topic on hand - android!

i have tpt'd yet again, and now have a 120m /system, with a whopping 334m for /data. i don't know how to repartition to an arbitrary size, or i would reduce /system further. i would very much like to reduce /system to 100m and use the rest for /data. i only use 101m in /system. so i stuff some .apks in there, to not waste free space.

lots of bloatware have disappeared from /system/app (most google bloatware) and /system/media (any >50k). google apps should be kept in /data/app, rather than /system/app. i have replaced many apps with older (much smaller) and more efficient apps. i don't need the latest greatest features, particularly those i don't need or use or the battery-drains.

apps which have been trashed are listed below:
google play -> replaced by google market 1.82 (613k)
google maps -> replaced by waze & rmaps
google search
google talk -> replaced by slick
gmail -> replaced by k-9 mail
email -> replaced by k-9 mail
home apps

apps which i have added for core functionality
simple home

i uninstall google play/market apps and replace them by their equivalent open-source apps from f-droid. i routinely replace apps of larger size by smaller size equivalents. i have 225 apps installed, which i could not dream of previously. almost all apps are installed in /data, except a very few on /sdcard. i still use the original 2g sdcard.

my battery lasts about 4 days now!! :D

update: i have found some devs maintaining roms with the same thoughts

rom downgrade (Android 2.3.5)

have you ever downgraded? was it too painful to switch from more to less?

i believe, less is more! more than what you really need or actually consume is inefficient & wasteful. i keep learning from experience... bloatware (in any way, shape, or form in life) cripples us!!

i miss my old nokia phones. i could charge those, and not worry about battery running out for about a week and then some... :-)

i like my smartphone, and without it now i would feel handicapped. what a change from the good old days, eh? all you could do was call or text... now that is something we do the least on our phone.

yet, this is called a smartphone for a reason - it needs to be a phone first & foremost, and then the rest of it's smartness is just the icing on top. when i carry it around, the most important priority is for it to be available to receive/make calls. if the battery does not last long enough, because some google (or another) app wants to continue running or transfer your data sneakily in the background, my requirement has failed!

hence why i'm on a continuous mission to prune my phone of bloatware. the more stuff sneakily running in the background, the less useful it becomes to me.

this next episode downgrades my android phone from 2.3.7 to 2.3.5. i'd been thinking for a long while to go back to the manufacturer's stock rom, and prune it down ending up with only what i really use. at the very least, i will have a stable platform with optimum battery use. the next best thing is a mod of the stock rom, improved(?) upon by folks like more experienced.

so my journey takes me to the Swedish Snow. read more about it at KonstaT is a highly respected developer. i like him particularly because he is ruthless with bloatware like me. bells n whistles are nice-to-haves, but only after primary requirements are satisfied.

i chose his all-in-one tpt install, which will downgrade my clockworkmod recovery from v5.0.2.0 to i am not sure what i will lose, but cwr can be easily flashed again. if you find a changelog for clockworkmod, please let me know.

this tpt further slims down /system leaving more for /data. /system should be static, and only used for frozen apps, not for volatile apps like google apps which ideally should be in /data. as market insists on putting yet another update in /data, we have no need for apps in /system too, especially when /system space is kept limited. my internal storage will be re-partitioned to 128m /system, 326m /data, 2m /cache.

my partition layout with cm7.2 is 138m /system, 316m /data, 2m cache. if i wanted to keep this layout, i need not have used the tpt install. it so happens that my system is <128m. i am hoping to keep this partition size if/when i change roms again. i will need to remember to prune (easily done) any roms before i install. if i was not using the tpt method, i'd just flash the rom from recovery. since i want a clean slate, i'd format each partition, except /sdcard!
clockworkmod recovery -> mounts and storage -> format ...
NOTE: DO NOT FORMAT /sdcard! did you hear that?

so we have the tpt downloaded into the root of sdcard. now unzip that file.
$ unzip

now we are ready to proceed. all systems go!

step 1:
first things first: take a full nandroid backup of the whole system... remember the milk?
pull this backup off the phone, just in case :-)
$ adb pull /sdcard/clockworkmod/backup/

now read this whole post from top to bottom, and undertand it, before you do anything.

step 2:
power off the phone. pull the battery out for >10s.

press & hold volume+ menu power buttons, till you see green text on the screen. skip the rest of this step.

if you see the green android, this didn't work. repeat step2 again.

if your tpt is corrupt, step2 will not be successful. recreate/download your tpt again. verify the checksums yourself.
$ md5sum -c nandroid.md5

tpt reference:

step 3:
enjoy your new rom! :-)

android app cache

i do quite a bit of fiddling around inside the internals of android. i have noticed that occassionally rebooting helps to stabilise the system. although i could never work out the need, as android is essentially linux. but sensing what google wants to do it, i suspect it might be heading the microsoft windows way.. becoming bloatware (it probably already is)!

the next step is to clean out the cache. though you could do so by manually clearing the filesystems, i find it simpler (and safer perhaps) to do so from the recovery. i used clockworkmod. there are two caches - the dalvik cache and the system cache. both can be wiped from recovery. you might reclaim some diskspace too. android will create the required caches from scratch, on the next reboot. this boot will take a rather long time - be warned! watching the phone doesn't help. find something else to do and come back in good time. patience is of essence here.. :-)

there are some other ways to hack out some more space in /data, which is where all user apps are installed.

we can move some app caches to sdcard. this might make those apps slower, if your sdcard is not that fast. for some apps with huge caches, we might be more concerned about reclaiming disk space and sacrificing some speed. note that caches might not necessarily be a bad thing.

let's identifying the apps with the biggest caches. do this after you have been using the phone regularly for a few days without any reboots/cleanup, for best results.

$ du -s /data/data/*/cache | sort -n

if the above command didn't work for you, enable superuser mode and try again.
$ su

the next step is to move some of these caches to the sdcard. we need to decide on some rules to identify the best candidates. i have focussed on the biggest caches where this process actually makes a noticable difference. for me the two apps are market and browser. you need to consider the security implications, as chmod permissions don't work on sdcard fat filesystems, i.e. your sdcard content is world readable.

now move each of them to sdcard, like so

$ mkdir -p /sdcard/cache/browser
$ cd /data/data/
$ rm -r cache
$ ln -s /sdcard/cache/browser cache

note that the app should not be running, not even in the background. go to settings -> applications -> manage applications and verify whether they are running. force close them if necessary. it might be far simpler to boot into recovery and do everything there!

mbr in linux

fdisk /mbr
ever used the above in dos? but this doesn't work in linux. there are times when i have a need for this. i usually install bootloaders on specific partitions than on the mbr.

dd can be used for such requirements. the following will wipe your mbr clean

# dd if=/dev/zero of=/dev/xxx bs=446 count=1
where xxx is your disk.

how/where do i use this? i have been playing with many different os for a long time. every os wants to install their own bootloader into the mbr. but, we can't really have that, can we? not if we want them to exist simultaneously on the same disk.

i always install the bootloader on the same partition as the os, and wipe the mbr clean. then use fdisk to make a partition active and reboot to load that os. an os could do whatever with its bootloader and not bother me. this method can also be used to play with multiple bootloaders, each on a separate partition. i arrived at this method, after much grief from trashed bootloaders.

caution: just in case, make a backup of your mbr, before you wipe it.
# dd if=/dev/xxx of=xxx-mbr.raw bs=446 count=1

and restore it, like so
# dd if=xxx-mbr.raw of=/dev/xxx

opera 12 issues

just installed opera 12, and rolled it back right away. this is not a stable version.
issues: toolbars (specifically main-menu), multimedia (flash videos), indic fonts (malayalam?)

opera 12.00 starts up with a useless empty bar on top with just one button, wasting screen estate. see image below.

don't bother trawling through the opera forums, as opera developers seem to be windows kiddies. after eating some more of my leftover hair, i find a workaround. go to

Opera -> Settings -> Preferences -> Advanced -> Tabs -> Additional Tab Options -> Show close button on each tab (enable)

this is not ideal, as now every tab has an unnecessary " x" at the end. but is better than an empty line of wasted screen estate.

the next issue is flash. i just can't play any videos. instead i see an empty static black box, where the video is supposed to be. no buttons, no clicks, ...nothing. like this

opera 12 has "Experimental hardware acceleration WebGL support" which need to be activated by enabling two settings in opera:config, ie set them to 1 (autodetect), or 2 (on). they are initially set to 0 (disabled).
opera:config#UserPrefs|EnableHardwareAcceleration and opera:config#UserPrefs|EnableWebGL

i play with different combinations of these settings wondering if these were the cause of my youtube problems. but every permutation i try gives me the same static black box in youtube.

back to opera forums "Opera for *nix - Linux/FreeBSD", and the first sticky is this post: Flash problems on Linux?
it seems a bit dated for 14/12/2009, but as opera lists this at the top, i expect this to be current. so i trawl through this, and do what it asks:

$ find / -name '' 2> /dev/null

$ ldd /usr/lib/flashplugin-nonfree/ => (0x00007fff560a7000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda2350f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda232fc000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda23094000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda22df5000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda22bbe000) => /lib/x86_64-linux-gnu/ (0x00007fda229a1000) => /lib/x86_64-linux-gnu/ (0x00007fda22799000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda22158000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda21ea3000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda21c80000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda21a55000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda21834000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda21627000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda2132c000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda210de000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda20e8e000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda20c8a000) => /lib/x86_64-linux-gnu/ (0x00007fda20992000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda20751000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda20524000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda201e7000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1ffc1000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1fdbd000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1fbb7000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1f978000) => /lib/x86_64-linux-gnu/ (0x00007fda1f774000) => /lib/x86_64-linux-gnu/ (0x00007fda1f4f1000) => /lib/x86_64-linux-gnu/ (0x00007fda1f16a000)
/lib64/ (0x00007fda24d48000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1ef4a000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1ed42000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1eb27000) => /lib/x86_64-linux-gnu/ (0x00007fda1e910000) => /lib/x86_64-linux-gnu/ (0x00007fda1e6e5000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1e4e3000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1e2e1000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1e0da000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1dd88000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1db86000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1d97c000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1d77a000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1d56a000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1d362000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1d158000) => /lib/x86_64-linux-gnu/ (0x00007fda1cf30000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1cca9000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1caa5000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1c89b000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1c68d000) => /lib/x86_64-linux-gnu/ (0x00007fda1c450000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1c24c000) => /usr/lib/x86_64-linux-gnu/ (0x00007fda1c047000) => /lib/x86_64-linux-gnu/ (0x00007fda1be42000) => /lib/x86_64-linux-gnu/ (0x00007fda1bc21000) => /lib/x86_64-linux-gnu/ (0x00007fda1ba0b000)

at this point, i give up on that post and go back to troubleshooting on my own. tells me this:

What does my browser support?
Video tag [y], h.264[!], WebM [!]

Note the answer to the above question, when a few lines above it says that Opera 10.6+ supports WebM. What does [!] mean?

opera:plugins lists all plug-ins and their status.

then i wonder, if youtube has any other issues. so i uninstall opera 12.00, reinstall opera 11.64, and try youtube. voila... it works! so it has to be opera 12 and not anything else on my system!

update: for now, i have installed opera 12.00 & 11.64 side-by-side on the same system. i don't seem to have the above issues on 11.64. so i guess, i'll continue using 11.64 for now.

i'm still sticking with opera, as i find it to be lean, small & fast, when all the others are going bloatware. i only use iceweasel (firefox, for the uninitiated ;-) when opera doesn't suffice. for eg, when i need to work with indic fonts, which opera won't render properly.

reclaiming android foss

i am gradually removing google apps, as they continue to bloat.

if you are looking to buy a new phone, i will only recommend those phones which have a sizable open-source developer community behind it. if you don't want to end up with a paperweight, do not buy any phones, which can't be hacked!

cyanogenmod logo
the first thing i do when i get an android phone is to remove the stock android firmware, wipe it and replace it with a custom mod. all spurious apps and bells n whistles like wallpapers, bootanims, startup music are purged. no wallpapers, black background, set most apps with black background. any apps becoming bloatware are immediately replaced with smaller, leaner & more focussed apps.

this should make your battery last a lot longer. note that, you have to remove/purge these default apps to get any benefit. always keep backups!

f-droid logo
google play store is simply not suitable for a phone, perhaps for a desktop or even a tablet. use foss alternatives, which supply foss apps. you will have apps with vetted source codes. no hidden surprises in code.

android foss repository has a client app. download fdroid.apk and install it. it lists each app version with size, and allows you to install any (older) version. if an open source app is not listed in the f-droid repos, you can suggest it to be added. you can also add custom repos, and/or disable the default f-droid repos.

for eg. to add the guardian project's repo. do
Menu -> Manage Repos -> New Repository ->
Menu -> Update

some other bloatwares can be replaced as under:

google maps: navfree world, waze
google books: wordoholic reader (ebooks from pg)
gmail: k9-mail
google calendar: calendar pad
browser: zirco browser, opera mini
google drive: skydrive for android
gallery: quickpic
google reader: sparse rss
facebook: browser (no app)
twitter: cheepcheep, tweetsride

android roadmap?

i'm not sure which way google are going, but they seem to want to turn the android into a desktop os, rather than a handheld os. google are doing to android, what microsoft did to windows.. make it bloatware & proprietary locking everyone out, till people give up on it.

i can still install and use windows 95 on that old hardware. i might not be able to install the latest software versions, but i can install those versions which came along at that time, and use them just fine. but like newer versions of windows demanding ever increasing hardware requirements just to exist, every android release seems to demand bigger and more expensive hardware. and any older hardware would just not function.

google's sustainability strategy is not translating into actual practice!

google market has been replaced with google play store, mimicking apple store. the older market app which came on your phone will not work. market started out as a small and sleek app, which progressively kept growing bigger, and the newer google toys will not even install on older android phones. and if it does fit, you would need to delete all your other apps to make space for this google garbage. why would anyone even think of watching movies on an old android phone? if only google allowed the older market app versions which came on the older phones to connect, people could continue using those older android phones. but google, in it's infinite wisdom will not allow even their own older apps to function, rendering all older android devices useless.

don't get me wrong, i am not saying that all the older phones should work with the latest apps. but the phones, which we bought a few years ago, should work as they did at that time. but google won't allow them to connect to market, maps, contact, calender, and anything else on the network. so you could use them, but not as a smartphone. which begs the question, why would you not rather use a non-smartphone, if you only need to make calls/sms, as they would have much better battery life.

the only silver lining here is the google strategy remaining officially open source. the bad news is none of their apps are. google apps have become proprietary closed-source bloatware. from initial app size of a few kb to the current many mb, google apps are growing without restriction. and this is hitting a crunch point.

my mobile phone does not have unlimited disk space, memory or battery. although i have unlimited net, at some point it will not be, and i need to prep for it. so i need lean focussed apps, than all-in-one behemoths running in the background all the time without my explicit permission.

google maps started out so well, that i was using it to the point of excluding everything else. now google maps is more focussed on bells n whistles than making its core functionality more efficient. bells n whistles that i have no need of. so, out goes google maps from my phone. likewise with gmail, google play store, etc. market was a lean app, which has now become play store with books, movies and billboard advertisements. do i really need that on my phone?

android permissions are out of control. seemingly any app can request and is allowed any permissions it asks for, not necessarily what the app actually needs, or the user would actually want to allow. and the user has no idea. there are apps which start at boot (read almost all), and want to keep running all the time. user be damned! in a mobile phone, the most important resource is the battery. anything that can potentially drain it, is malware!

i look forward to more choice on my mobile phone, like on my computer. the primary requirement is open source, using minimal diskpace & memory. idle battery use should be ~nil, which would preclude covert background tasks/activities. i still wait for emdebian to mature.

mobile linux is gaining momentum, but i don't think they are on the right road. if their starting point is firefox, gnome and/or ubuntu, they are a long way ahead from being lean. firefox bloatware used so much space, that i promptly removed it from my phone. i have no idea what kind of hardware the developers work with! perhaps they use their pc for development/testing and expect their apps to behave the same of phones with much lesser hardware specs...

leaner code is cleaner code is more efficient code

leaner code is cleaner code is more efficient code. a program with 100 lines of code is better than a program with 10,000 lines of code. less prone to bugs and (un)intentional security holes, easier to decode/maintain, cheaper to run... etc.

of course, comments are not code and documentation is to be encouraged. but documentation should be maintained separate from code; not maintained within the code. any documentation change should not result in code change requests.

i'm gradually migrating to the console, which is where it all started! :-) i strongly prefer working from the console, mainly because console apps are leaner and not dependant on unnecessary services like mouse or window manager. i fire up x, only only when i need to use gui apps. i work on the console within tmux (previously screen), which allows me to keep my environment when i transfer between console and x.

i am on a constant quest for more efficient apps. soon as i find one, i change over. efficiency means smaller code, focussed approach. for example, i changed over from screen to tmux a while back, and from ratpoison to dwm more recently.

openbsd 5.1

i had to have a go.. and i just did :) i've been reading & hearing much about bsd lately. looking at the various bsd flavours floating about, i narrowed down my focus to two - freebsd & openbsd - based on popularity. i chose openbsd, for it's emphasis on clean code and security.

i was pleasantly surprised to find that openbsd used only 455m diskspace for a full & complete installation, including x and a few default window managers. i chose not to install the compilers. and the whole install took only minutes! i'm going to spend more time with openbsd and really look at migrating over.

debian would use about that same space for a minimal base install. and that was after i really hack a minimal base install. much more space is then required for installing x/dependencies for a functional system. after cutting and pruning down my system, i'd still end up with 1g plus, after a lot of work. my brief flirtation with arch required about 700m plus for the just the base install. and about 2g for a functional system. though i really like the arch philosophy, i reluctantly returned back to debian, my on-off long-term relationship since the potato days.

i had a quick look at freebsd, to whet my curiosity for its popularity. install cd is 502m, more than twice the size of openbsd's install cd. diskspace required for minimal install is 1.1g, about 2.5x openbsd full install. i guess the popularity results from it being a free-for-all accepting closed-source binaries from anywhere.

my brief notes from openbsd install follows:

* read openbsd faq
i mean really read it, and keep it open during install.

* download install51.iso for offline standalone install
i had no idea, how many times i would need to do the install to end up with a stable system. so i chose to download the full-cd for an off-the-network install. otherwise, there are much smaller downloads for alternative install-media, like netinstalls.

* boot from install-cd
: boot prompt, hit enter

* dmesg shows white text on blue background
logged at /var/run/dmesg.boot

* (i)nstall to create new openbsd system with new partitions
(u)pgrade only for upgrading from just the previous version, ie 5.0 only.
for older versions, you need to do each intermediate version upgrade. in that case, a full install might be more appropriate.

* install prompts:
at any install prompt, ! creates a shell. exit the shell, to return back to the same install prompt.
^c to quit installation.

* network interfaces
openbsd creates new interfaces for each different network driver like fxp0 xl0, rather than generic device names like eth0 eth1 in linux. i can see the pros & cons to both. personally, i would ln -s eth0 to whatever netdev in openbsd, to ensure my scripts don't break. i'm still very new to openbsd. i'm pretty sure that there might be better options and i need to discover those.
virtio is not understood. so don't use it, if you are installing on a virtual machine.

* dhcp yes. ipv6 no. sshd no. ntpd no.

* x yes. xdm no. com0 no.

* new user yes.
this user will be a member of wheel group, and can su.
i found that this user cannot sudo, by default.

* timezone europe/london

* disks (e)dit mbr. (w)hole disk will remove existing partitions.
i prefer one swap and one root partition, as i don't know how much space i (don't) need. later, i can always resize these partitions for optimum use. add multiple swap partitions on separate disks for optimum performance.
virtio is not understood.

* location cd
http for netinstall

* filesets all, except comp51.set
-comp51* [enter]

* et voila!

first boot:

* login root and read mail. read afterboot.

* swap
i noticed that my system was not using the intended swap disk. there was no swap.
fdisk & disklabel to identify swap partition. populate /etc/fstab with duid. reboot to test.

* packages
pkg_info listed nothing
pkg_add firefox
pkg_delete firefox
pkg_info lists a lot of junk now
these commands simply execute silently & promptly. i didn't get any info and/or confirmation prompts. i wish there was some way to customise the pkg defaults, presumably using conf files or env variables.

* login as normal user

my toolkit

i am on a constant quest for more efficient apps. soon as i find one, i change over. efficiency means smaller code, focussed approach. leaner code is cleaner code is more efficient code. a program with 100 lines of code is better than a program with 10,000 lines of code.

i strongly prefer working from the console, if i can. i fire up x, only only when i use gui apps. i'm gradually migrating to the console, which is where it all started! :-)

what do i currently use? read on for a summary...

os: emdebian, debian testing, tiny core, arch
wm: dwm, ratpoison, sscrotwm?, spectrwm, tinywm, evilwm
browser: elinks-lite, links2, opera, iceweasel, uzbl
pdf: epdfview, xpdf, zathura
image viewer: sxiv, qiv
editor: leafpad
term emulator: pterm, st
screenlock: slock, xtrlock

mux: tmux, screen
editor: busybox vi, nano-tiny
file mgr: links2, ncdu,
pager: most
mail: mutt
rss: newsbeuter
irc: irssi
torrent: rtorrent
multimedia: mplayer2, mplayer no-gui
iradio: shell-fm
mixer: rexima
downloader: axel
cd/dvd writer: wodim
android: adb

virtualisation: kvm, qemu

the crossed ones were preferred at one time. i still like their philosophy, which is why they are on this list. i might yet go back, if the scales tip again. after using screen & ratpoison for years, i have recently migrated to tmux & spectrwm respectively. same for some others too. hence, this post... :-)

since, busybox is installed. i tend to use most of the busybox applets instead of the debian default utils which i purge to reclaim space. i find that smaller apps are quicker using less memory/diskspace.

i am waiting for emdebian to mature on x86. i'll migrate to emdebian with kvm! :-)

additional references:

root passwd reset

edit your (grub/syslinux/lilo?) boot command line and append
... init=/bin/sh

remount root partition in read/write mode
# mount -o remount,rw /

change password with the command
# passwd

binary to decimal tip

how to convert binary to decimal in your mind very easily

You only need to remember 2 things:

(1) the first 8 numbers:
000 0
001 1
010 2
011 3
100 4
101 5
110 6
111 7

(2) shifting to left by one digit multiplies the number by 2 (10b):
1010 = 101 x 10 = 5 x 2 = 10
10100 = 101 x 100 = 5 x 4 = 20
101000 = 101 x 1000 = 5 x 8 = 40

When you see something like 101011, you can process it this way:
101011 = 101000 + 11 = 5 * 8 + 3 = 43

1110101 = 7 * 16 + 5 = 117
and so on.

It is easier than it looks at first glance :)

source: vik korneev at

mtrr cleanup

having just done an upgrade, i went through the logs and found some mtrr #fail issues.

$ dmesg | grep -i mtrr
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000] MTRR variable ranges enabled:
[    5.811624] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
[    5.811628] [drm] MTRR allocation failed.  Graphics performance may suffer.

$ cat /proc/mtrr
reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable
reg01: base=0x000000000 (    0MB), size= 4096MB, count=1: write-back
reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back
reg03: base=0x0bf700000 ( 3063MB), size=    1MB, count=1: uncachable
reg04: base=0x0bf800000 ( 3064MB), size=    8MB, count=1: uncachable

the above doesn't seem to add up right. note that i have 4gb of memory on this machine.
debian testing 3.2.0-2-amd64 #1 SMP Fri Jun 1 17:49:08 UTC 2012 x86_64 GNU/Linux

i found many recommendations to enable_mtrr_cleanup, including this: so i added the kernel bootoptions
enable_mtrr_cleanup mtrr_spare_reg_nr=1
to the grub commandline, and here is the result.

$ dmesg | grep -i mtrr
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000] MTRR variable ranges enabled:
[    0.000000] original variable MTRRs
[    0.000000] Found optimal setting for mtrr clean up
[    0.000000] New variable MTRRs

$ cat /proc/mtrr
reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0bf700000 ( 3063MB), size=    1MB, count=1: uncachable
reg03: base=0x0bf800000 ( 3064MB), size=    8MB, count=1: uncachable
reg04: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back
reg05: base=0x0d0000000 ( 3328MB), size=  256MB, count=1: write-combining

now this look much better! i'm keeping this kernel bootoption. have a go yourself, and post your (before/after) results below.

net monitor

$ lsof -i -P

linux ip

the linux world might be moving towards the ip command suite of iproute2, leaving behind some familiar unix tools, thereby potentially deprecating ifconfig, route, arp, netstat, etc. i list the traditional commands and their equivalent ip commands, for reference.

$ ifconfig -a
$ ip addr
$ ip link

# ifconfig eth0 {up/down}
# ip link set eth0 {up/down}

# ifconfig eth0 netmask
# ip addr add dev eth0

# ip addr show dev eth0
# ip addr add dev eth0
# ip addr add dev eth0
# ip addr del dev eth0

# ifconfig eth0:1
# ip addr add dev eth0 label eth0:1

$ route
$ netstat -rn
$ ip route

# ip route add via
# ip route del via

$ arp
$ ip neigh

# ifconfig -arp eth0
# ip link set dev eth0 arp off

working with ipv6 is easy. use the -6 option.

ip commands can be shortened to their initial characters, if you feel lazy :)
$ ip a
$ ip r

netcat tar backup

debian netcat-openbsd is leaner, cleaner & more efficient than debian netcat-traditional. if you get a choice, prefer the openbsd version.

i now use busybox wherever i can, including nc and tar. small, simple, clean, standard, available the same everywhere.

$ busybox nc

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Open a pipe to IP:PORT or FILE

-e PROG Run PROG after connect
-l      Listen mode, for inbound connects (use -l twice with -e for persistent server)
-p PORT Local port
-w SEC  Timeout for connect
-i SEC  Delay interval for lines sent
-f FILE Use file (ala /dev/ttyS0) instead of network

$ busybox tar

Usage: tar -[cxtZzJjahmvO] [-f TARFILE] [-C DIR] [FILE]...

Create, extract, or list files from a tar file

        c       Create
        x       Extract
        t       List
        f       Name of TARFILE ('-' for stdin/out)
        C       Change to DIR before operation
        v       Verbose
        Z       (De)compress using compress
        z       (De)compress using gzip
        J       (De)compress using xz
        j       (De)compress using bzip2
        a       (De)compress using lzma
        O       Extract to stdout
        h       Follow symlinks
        m       Don't restore mtime

at {destination}:
$ nc -l -p {port} | tar xpv[z|j]f -

at {source}:
$ tar cpv[z|j]f - {directory} | nc {destination host/ip} {port}

[z|j] compression: use over slower networks. ignore for faster networks and/or slower computers.

tar streams much faster copying than scp 'ping-pong', especially when you have lots of files.

copy files from {some-server} to your machine:
$ ssh {some-server} ‘cd /some/dir && tar cz dir’ | tar xz

and the other direction:
$ tar cz dir | ssh {some-server} `cd /some/dir && tar xz`

image a disk across the network from {box1} to {box2}:

at {box2}:
$ nc -l {port} [-vv] | dd of={disk.img} bs=1M

at {box1}:
$ dd if=/dev/sda bs=1M | nc {box2 host/ip} {port} [-vv] -q 10

[-vv] use at the box1 (and/or box2, if fast enough)

restore this image in {box2} to {box3}:

at {box3}:
$ nc -l {port} [-vv] | dd of=/dev/sda bs=1M

at {box2}:
$ dd if={disk.img} bs=1M | nc {box1 host/ip} {port} [-vv]

compressed backup

at {box1}:
$ tar cpvJf - {directory} | nc {box2 host/ip} {port}

at {box2}:
$ nc -l -p {port} | dd of={directory}.tar.xz bs=1k



skype's debian apt repository seems to have gone kaput! .deb intall packages give errors, due to missing dependencies. also noticed that the 64bit .deb wanted many 32bit dependencies. skype need to get their act together. losing confidence... only reason to use this is my friends using this. chicken-and-egg? you bet!

and the shambles started after microsoft took over skype. i can remember a time when skype client was lean clean & efficient. now it is humungous bloatware spyware crapware

slashdot says Microsoft Won't Say If Skype Is Secure Or Not. Time To Change?
as usual, the comments provide more insight.

i recommend voip to my friends. talking becomes enjoyable again.

personally i await the dawn of federated voip

adb reference

adb - Android Debug Bridge

# adb {start|kill}-server
$ adb [dis]connect {host}:{port}
$ adb devices
$ adb reboot [recovery|bootloader]

$ adb shell mount -a
$ adb remount

$ adb shell ls -lhSr /system/app/

$ adb shell am start -a android.intent.action.MAIN -n
$ adb shell am start -a android.intent.action.MAIN -n

$ adb logcat
$ adb get-state
$ adb status-window
$ adb shell dumpsys activity

adb on 64bit

there are two ways you can get adb to run on 64bit systems.

(1) install 32bit libraries
# apt-get install ia32-lib
this is messy, especially if you don't use many other 32bit apps, which you shouldn't.

(2) use adb 64bit version
download the single file from somewhere, like
or, compile it yourself, which means a lot of garbage on my system, when i don't do any (android) development on my primary system.

i prefer (2) over (1).

now, we can have some adb fun:
# adb start-server
$ adb devices
$ ...
# adb kill-server

usb tethering

connect your phone via usb to your computer.
enable tethering on your phone.
Settings > Wireless & networks > Tethering & portable hotspot > USB tethering

if you don't see the above setting, your mobile phone provider has probably disabled it. use an open-source rom, like cyanogenmod.

load usbnet module
# modprobe usbnet

verify usb interface
$ ifconfig -a

modify network interface configuration
# vi /etc/network/interfaces
iface usb0 inet dhcp

bring the interface up
# ifup usb0

et voila!

most popular posts