kernel compile debian way

1. prepare your system

verify you have sufficient diskspace. about 1g or so.
you do not need root. normal user can compile.
you do not need to compile on your own system. another system, with faster cpu, more memory, spare demand, etc can compile your kernel.

using tmpfs

i find my ram usage doesn't go much over 512k. apart from some of my trusty older friends, most of my systems have ample ram left over. how do i make more efficient usage of extra ram?

ram is fast. disk is slow. move more operations from disk to ram, depending on how ram is spare.

partition table recovery

my last tryst with openbsd left me in tears.. my partition table destroyed! but thankfully, i gained my wits before any data was written to disk. so now i need to recover partition table back.. any tips?

gparted gave me a great big warning that it will take too long. it didn't take too long, and it couldn't recover my partition table either.

gpart took a bit longer, but failed as well.

testdisk seems to be making progress, but it is awfully slow.. much slower than either of the above. i have spent the entire night watching it count each cylinder as it attempts to recreate my partition table. it is still counting, and now it is early morning. i should catch a few winks, or i'll be wasted today.

update: all is well :)

openbsd install ends in tears

my last adventure with openbsd 5.1 was very positive. so i wanted another look, and decided to install openbsd to multi-boot my main computer.

what should have been a realtively quick & easy task last night, has runover :'( alas, i spent the rest of the night trying to recover my partitions. openbsd wiped my partition table and replaced with it's own version, without even confirming!!

lesson learnt.. no playing with unknown toys in live production systems!

update: to multi-boot openbsd, create a partition of type openbsd, before starting openbsd installer. otherwise, openbsd installer just assumes that the whole disk belongs to it. no questions asked!

xda: [MOD] Extended power menu

http://forum.xda-developers.com/showthread.php?t=2171818

as i couldn't reply to this thread in the xda dev forum, i am posting this here and hoping this might be useful to the developer and/or any users.

sqlite quickstart

prefer sqlite3, not sqlite2 or sqlite

$ sqlite3 --help

batch script like so..

$ sqlite3 -header {database}.db '.schema'
$ sqlite3 settings.db delete from system where name like 'lock%'

.. or interactive

$ sqlite3 {database}.db
sqlite> .show
sqlite> .headers on
sqlite> .databases
sqlite> .tables
sqlite> .tables t%
sqlite> .schema {table}
sqlite> select * from test;
sqlite> update {table} set {column1}=99 where {column2}='red';
sqlite> .exit

fortune bible

probably not to everyone's tastes, but may generate some ideas for others ;)

i grew weary of the random quotes, and wanted something more inspirational O:)

#! openbox background/wallpaper

i keep only openbox relevant stuff in the openbox/autostart, and moved everything .xsession. this way, i can seemlessly change wm.

my ~/.xsession contains:
hsetroot -solid "#000000" -fill ~/.wallpaper &
...
exec openbox-session

i have commented out wallpaper settings in ~/.config/openbox/autostart, like so:
## Set root window colour
#hsetroot -solid "#2E3436" &

## Group start:
## 1. nitrogen - restores wallpaper
## 2. compositor - start
## 3. sleep - give compositor time to start
## 4. tint2 panel
#nitrogen --restore && \
(\
cb-compositor --start && \
sleep 2s && \
tint2 \
) &

my problem:
hsetroot in ~/.xsession correctly sets my wallpaper. at some point during openbox startup, the wallpaper settings are reset, and i end up with a blank grey background at the end of openbox startup.

my question:
what/where is this happening?

---

thanks for the hint to look at openbox configs. i suspected something running from somewhere in my user configs. it is rather strange that openbox would contain hard-coded configs overwriting user settings. i would consider this a bug. would this be openbox upstream or crunchbang specific?

/usr/bin/openbox-session calls
1. /etc/xdg/openbox/environment
2. $HOME/.config/openbox/environment
3. /usr/lib/openbox/openbox-autostart

/usr/lib/openbox/openbox-autostart sets background, resetting any user settings for background/wallpaper. then it calls
1. /etc/xdg/openbox/autostart
2. $HOME/.config/openbox/autostart
3. /usr/lib/openbox/openbox-xdg-autostart

which means that any ~/.xsession settings, conflicting in any of the above files, would be overwritten. openbox expects all user x configs to be within openbox only, which i think is plain wrong.

i have commented out the background color section in /usr/lib/openbox/openbox-autostart, which resolves my op. thanks porkpiehat :)

/etc/X11/openbox/ is yet another directory with openbox configs

i am loathe to edit system configs, as they might conflict with upstream upgrades later when i might not remember what/why i changed something. hence why i keep them pristine, preferring to keep my settings in local user configs. this also help me seemlessly switch wm and/or carry them over to other machines.

would openbox expect users to call ~/.xsession at the end of ~/.config/openbox/autostart? that would be crazy logic :o

---

ref: http://crunchbang.org/forums/viewtopic.php?id=31614

debian time

check whether your system uses utc or localtime
$ cat /etc/adjtime

if utc, all is well. you might find hwclock set to localtime.

it is recommended to use utc for every os.