html code snippets

use <code>...</code> for inline code snippets
use <pre>...</pre> for block code snippets

design your internal css styling

for example, mine is
  code {background:lightgrey;padding:0px;color:black;}
  pre {width:99%;background:lightgrey;padding:0px;color:black;}

test in w3schools sandbox

edit your blogspot template, and insert your internal css styling within the <head>...</head> tags

blogger --> Template --> Edit HTML

parse your code, if you see it interpreted

debian stretch kernel compile


# apt-get install linux-source
current kernel source

# apt-get install build-essential
required to build debian packages

# apt-get install fakeroot
root not required, not recommended, to build packages.

# apt-get install libncurses5-dev
for menuconfig

# apt-get install pkg-config libqt4-dev
for xconfig

# apt-get install libglade2-dev libgtk2.0-dev
for gconfig
unless you use/prefer gnome, not worth installing bloatware dependencies.

$ mkdir ~/kernel
$ cd ~/kernel
$ tar -xaf /usr/src/linux-source-{version}
$ ln -s linux-source-{version} linux
$ cd linux
$ cp /boot/config-{version} .config
$ make oldconfig

$ make menuconfig
$ make clean
$ nice -n19 make -j3 deb-pkg LOCALVERSION=-nixventure

if you get such warnings
warning: File::FcntlLock not available; using flock which is not NFS-safe
ignore them, or
# apt-get install libfile-fcntllock-perl

a successful build at the end of make about half-a-dozen files in the parent directory. the most interesting to us is the kernel (linux-image-*.deb), and perhaps the headers (linux-headers-*.deb).

$ sudo dpkg -i ../linux-image-{version}.deb

dpkg will trigger an update of your bootloader. all you need to do now is reboot, and test your brand new shiny kernel.

$ apt-cache search linux-patch
$ apt-cache search kernel-patch
# apt-get install {linux/kernel}-patch-{??}
$ cd ~/kernel/linux
$ make clean
$ zcat /usr/src/kernel-patches/diffs/*/*.patch.gz | patch -p1

ubuntu phone touch emulator

disappointed with android bloatware getting worse, incompatible releases, and an unstable roadmap.

i was an early android adopter, actively contributing to firmware development. we wanted to make android slimmer, a minimalist system focussing on extracting more battery life and performance. but the bells & whistles lobby won! alas, over the years, i've seen android (particularly the google stacks) become more & more bloatware, only suitable for higher end devices. which means every year or so, you need to buy the yet another new/expensive device just to continue running with android.. unless you are a hacker, know your way around the internals, and not concerned with losing the warranty.

every android release seems to be incompatible with existing versions. if you can't update your phone, you end up with an expensive paperweight. so my recommendation is to purchase the cheapest android device you can live with this year.

windows10 promises updates for the life of your device, unlike android devices which get abandoned soon as you've purchased them. i've seen seemless upgrades from win8 to win10, increasing my confidence in the product. but for the notoriety and past tactics of microsoft!

looking at opensource linux alternatives for mobile devices

the only feasible alternatives i see currently on the horizon are linux devices. there seems to be a few running in the fringes. none yet anywhere near mainstream.

emdebian seems to have lost track somewhere, and become abandoned :-( despite showing great promise some years ago.

ubuntu phone emulator
ubuntu wiki:
image server:

an emulator is a wonderful starting point & showcase to demonstrate to the world, and allows a massive userbase to get comfortable with something new, without bothering to purchasing a device, and ending up with an expensive paperweight.

for most devs, an emulator allows them to hack without bricking any equipment. opensource allows most users to support themselves and/or their peers, reducing expensive support costs/infrastructure. bugs are quickly found & fixed by volunteers!

to ubuntu's credit, they have released emulators for stable (current release, necessary for supporting existing user base) and devel (future releases, necessary for supporting roadmaps) channels.

unfortunately, these emulators are restricted to ubuntu installations only. even more unfortunately, they don't work for most people who have taken the trouble. it seems only the ubuntu devs who released these emulators use them successfully!?

try it! let me know, if you have better luck.. :-)

# apt-get --install-recommends install ubuntu-emulator
only in this instance. usually i never install recommends.

before you create an instance, understand the directories used, and ensure enough diskspace.

~/.cache/ubuntuimage contains images you downloaded
~/.local/share/ubuntu-emulator contains instances you created

the devel channel is unstable, and has too many problems unless we are bug testing/fixing. so we use the stable channel.

$ sudo ubuntu-emulator create {myinstance} --arch=i386 --channel=stable
downloaded >2G in .local/share/ubuntu-emulator. ensure target dir has enough diskspace.

$ ubuntu-emulator run {myinstance} --scale=0.7

first run only. wait till init complete.
$ adb shell sudo shutdown -h now
$ ubuntu-emulator snapshot --create=pristine {myinstance}

use as normal now.
$ ubuntu-emulator run {myinstance} --scale=0.7

devel channel build has too many errors. adb device always offline.
stable channel seems more.. er adb connects as expected.
neither successfully came up with an interface. just a black window.

if canonical wants ubuntu phone to become more popular, and i would like it so, the least they can do is release a stable emulator/product, which works for most devs. unless the opensource community gets behind this, it is simply not going to take off.

to become more mainstream, the emulator should be made more widely available, for example on debian.


how did i not discover this earlier :? such an efficient tool! no loitering binary/cryptic config files all over the system, or bloatware dependencies like networkmanager.


# apt-get install wpagui

# vi /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev

two things to note in the above file:
1. update_config=1 to allow users to change config. if not, make it 0.
2. users need to be in netdev (or relevant group, need not be netdev).

$ wpa_gui launches a gui window, and a systray icon. click on the systray icon to show/hide the gui. closing the gui window will not close the app.

$ wpa_gui -t starts with gui hidden, which is probably what you want in startup scripts.

wpa_gui will create a new instance each time you launch it. you will see yet another systray icon.
closing the gui window merely hides it. hide/unhide by clicking the systray icon.
quit from the menu. the systray icon will disappear.

quitting wpa_gui terminates the wpa_gui instance only, and will not terminate/affect network connections.

and finally, networkmanager has been purged from my systems.. what a relief at so much cruft gone! if we don't need all the features, using a smaller/lighter tool is much more efficient.

recompile wpa_supplicant with the qt4 flag, and wheel group in conf.
wiki says either qt5 or qt4. but i couldn't qt5 it.
# USE="qt4" emerge --ask wpa_supplicant

network group in conf
# pacman -S wpa_supplicant_gui

NetworkManager (again) and Xubuntu

I now recommend Xfce to n00bs yet undecided on exactly which WindowManager they need.
NetworkManager seems to be very temperamental, if you do use that Gnome bloatware!

On Xubuntu, edit the file

and comment out this line
AutostartCondition=GNOME3 unless-session gnome

like so
#AutostartCondition=GNOME3 unless-session gnome

Now this Gnome applet, that everyone has become so dependent on, will behave better, even if you do not use gnome.

Update: Every gnome-related update seems to break previously fixed issues. This particular solution does not seem to be reliable!

Alternatives: wpa_gui, connman-ui, dhcpcd-qt, dhcpcd-gtk.

Update: I now use and recommend wpa_gui.

grub rescue btrfs

to play more seriously with yet another distro, i needed to install it. so i had some fun resizing/moving partitions around to clear some freespace for a new partition. during this, the partition numbering changed. i couldn't boot ubuntu's btrfs partition. i didn't understand why, till i discovered that partition numbers are hardcoded into the grub boot record.. tsk tsk! yet another reason why i seem to be going off grub2. i'm playing around with extlinux, and i seem to like it more & more. but that's another story for another time.

trawling through the net, you might see many experts making dubious claims that btrfs cannot be used for /boot partition, or grub doesn't work with btrfs, etc. i have a few systems on btrfs.. booting with grub or extlinux. i haven't noticed any issues yet. and i always keep root & boot together.

am i moving to btrfs? umm.. no! it is early days for btrfs, still considered experimental. i prefer efficiency over feature-bloat. and btrfs seems to be more efficient than the current ones on the scene. on that note, there seems to be another worthy contender hovering on the horizon.. bcachefs: open-source is good for the soul :-)

but i digress again.. back to our topic.

trying to boot the ubuntu btrfs partition would end up at grub rescue prompt as below. understanding troubleshooting concepts and the grub/btrfs architecture can help us recover from such problems. if you are not on ubuntu or btrfs, customise the below process accordingly. if you follow all the steps below, hopefully there is enough for you to find your own way. i had to attempt multiple times, and each time i got a bit closer. knowing this your (or my later) attempts should be far fewer.

grub rescue>

this is a very limited grub shell, containing a tiny subset of commands from normal grub.

stage 1: diagnostics

we gather all the information, and understand what needs change. our intention is to get to the normal grub prompt. for that we need access to the /boot/grub directory, which contains the grub modules.

let's find out what is hard-coded by grub

grub rescue> set

list all disks & partitions. identify where we are.

grub rescue> ls
grub rescue> ls /

step-by-step, we reach the grub modules.

grub rescue> ls (hd0,9)/

debian installer doesn't create btrfs subvolumes, but ubuntu does and calls it '@'. we need to remember to use this '@' for all disk operations.

grub rescue> ls (hd0,9)/@/
grub rescue> ls (hd0,9)/@/boot/
grub rescue> ls (hd0,9)/@/boot/grub/

if we see the directory listings we expect, we know this is the correct partition. so we can set our root & prefix.

grub rescue> set root=(hd0,9)

grub rescue> set prefix=(hd0,9)/@/boot/grub/

this allows us to escape grub rescue, and reach the normal grub. or even better, the expected grub menu.

grub rescue> insmod normal

grub rescue> normal

there now we can breathe a sigh of relief.. but it's not over yet!!

what we do from here is pretty standard. choose the menu entry, and boot. if this fails, as it probably would.. we start our diagnostics again. but this time, we are in the normal grub, with it's full suite of commands at our disposal.

we start by checking the grub settings again, to find what is incorrect.

grub> set

now that we know all the settings we need, we can attempt to boot our kernel.

grub> insmod part_msdos
grub> insmod btrfs

grub> insmod {gzio|xzio|lzopio|??}
grub> insmod linux

grub> set root=(hd0,9)
grub> linux  /@/boot/vmlinuz-3.19.0-26-generic root=/dev/sda9 ro rootflags=subvol=@
grub> initrd /@/boot/initrd.img-3.19.0-26-generic
grub> boot

sit back and watch your os boot :-)

if it didn't, you now know what you need to do. start all over again. hopefully each attempt will get you a bit closer, as our understanding grows. i had to make many attempts before i actually understood all this. hence why, i want to document all this, before i forget. hopefully, i might not be doing this very often. but now, i have a ready reference.

hopefully all is well with our os, and any problem was grub only. so let's login, and confirm everything ok.

as of yet, we have not made any change to our system. now we resolve this problem.

# dpkg-reconfigure grub-pc

confirm no errors, and reboot.

i was on ubuntu this time. if your system is not debian based, you won't have debian toolkit to automate everything. then we do it the grub way.

# update-grub
# grub-install /dev/sda9

confirm no errors, and reboot.

slackware netinstall

you won't see many docs about minimal netinstall slackware. indeed, you might see many experts saying there is no such thing. and your only option is to download the entire lot. sad, i know!

slackware can be installed over the network without downloading that humunguous recommended dvd. not everyone wants gnome, kde, compilers, etc. netinst is most efficient, particularly if you need a minimal install.

if you don't have a dvd-drive to boot, then you are not left with much choice. you also need to consider, if bandwidth is an issue. do you need to download that whole dvd content, if you are only installing a minimal system?

however, if you are a slackware newbie, you might install multiple times before you get it right. in that case, a one-time download might be more efficient. still, unless one is installing all the bells n whistles, an entire dvd worth of installs is a bit ott!

choose a nearby mirror from
ps: the main mirrors - | - are throttled and may ban you, if you connect multiple times. so choose another mirror.

go to /slackware-current/usb-and-pxe-installers
download usbboot.img

ignore all of that, but create your usb bootable slackware installer.
boot it, and start setup.

when asked to choose your install source media, select "4 Install from FTP/HTTP server"

server is your mirror from above. for eg,

location is the directory containing PACKAGES.TXT. for eg, /slackware/slackware-current/slackware/

that's it!

extlinux (syslinux) debian style

my path away from grub2 took me via lilo to extlinux. i stayed with lilo for a while. syslinux was on my mind, but for something rather trivial/straightforward i couldn't crack. i finally got my head around it, and my usb sticks were the first ones to get it.

next stop was debian on my laptop, which has just been converted. the below steps are for debian systems only. if you want a how-to for other systems, let me know.

# apt-get --no-install-recommends install extlinux
step 1: install the package(s)
i always exclude the recommended packages (bloatware?). interestingly extlinux is smaller than lilo, which pleasantly surprised me.

# extlinux-update
step 2: create configs
this step generates the config files in /boot/extlinux/.

# extlinux-install {/dev/sda7}
step 3: install the bootloader to pbr (or mbr, if you want)
i always install bootloaders to pbr, thereby keeping each system independent along with bootloader/file configs. change the active partition to boot, without worrying about what else you might break.

that's it! reboot, and enjoy your new spartan bootloader :-)

something very interesting is that i can boot live .iso/.img files from the boot menu, without any additional complexity. simply copy those files into /boot/, and run step 2 again.

debian no systemd

debian jessie was steam rolling in to stable with talks of systemd. it all sounded so wonderful.. then i decided to have a look at the internals of systemd, and took arch for a spin. and o boy, what a spin that was for my head! that was when i decided not to let that garbageware into my stables. it never was (and still isn't) stable, is it? my long love affair with debian, seems to be coming to an end with this episode!

systemd - rollout to stable - a shameful episode in debian - forcing the debian tc (technical committee) to make a dodgy decision without giving them enough choices or time - three of the five tc resigned soon after! wonder who's pulling the debian strings??

so now, i continue rolling with wheezy to oldstable, and then maybe to oldoldstable, to perhaps it's grave! meanwhile, i'm looking at alternatives.. openbsd, crux, alpine, slackware. they remind me of debian's younger days.. when i started with potato.

meanwhile, there are lots of behind the scenes developments in the debian land of now dodgy developers trying to sneak in systemd to even those who definitely do not want it. what a change in the attitudes of open source proponents! maybe microsoft strategy is winning here??

i've had to reinstall wheezy from scratch. and the first thing to do was making sure systemd is not welcome here.

# vi /etc/apt/preferences.d/systemd

Package: *systemd*
Pin: origin ""
Pin-Priority: -1'

this ensures that any packages dependant (even indirectly) on systemd will not get installed overtly or covertly, thereby pulling in systemd.

for now, the strategy is to install debian wheezy minimal, do the above, and follow through building the rest of the system. do not upgrade to jessie.. sadly, the latest and the greatest are not always the best for us!


grub2 has become bloatware afaiac, and i'd been meaning to move away for a while. i just didn't have the time, patience, and redundancy on my systems.

if you've been following me, you might have noticed that i like to trash bloatware. i'm always seeking smaller packages, and removing bigger ones. bloatwares are not just unnecessary resource hogs, but security concerns (malware?) too. bigger the code base, the easier it is to hide malware traits. smaller the code, easier it is to read/understand.

my path away from grub2 took me to lilo. small & sweet, lilo reminded me of my early linux days - not so pretty, but extremely efficient, and very functional. i did briefly consider grub, or grub-legacy as some call it.

migrating to lilo was rather easy.

step 1: install the package

# apt-get --no-install-recommends install lilo

step 2: edit config carefully noting your root/boot partition

# vi /etc/lilo.conf



menu-title="lilo menu"


append="3 ipv6.disable=1 quiet"

append="3 ipv6.disable=1 quiet"


step 3: finally install to pbr (or mbr if you prefer)
# lilo -v -C /etc/lilo.conf

notice that lilo backups your current bootloader pbr (or mbr, if you so chose). copy it safely elsewhere, if you might want to revert.

reboot, and enjoy your lilo menu!

my dread was unnecessary. lilo does have some quirks, occasionally misfiring. but it is very easy to reset from a rescue disk. no need to trawl through hoops fscking grub2. just boot from any rescue/system, and run step 3 with *your* lilo.conf.
# lilo -v -C /mnt/etc/lilo.conf

finally reboot once again, to confirm you can boot, before saying good riddance to yet another bloatware!

# apt-get purge --auto-remove grub2
what a great feeling it is to reclaim your system, and see bloatwares (along with all their dependencies) being purged!


i seem to have come full circle, through quite a lot of wm/de back to the rather humble jwm. and i'm quite pleasantly surprised. jwm replaces my current openbox/tint2 setup quite well, and perhaps even better.. more efficient, smaller, faster, simpler and very customisable. i think this is the end of my openbox saga.

i installed jwm, and themed it to look & feel almost exactly the same as my crunchbang waldorf with openbox/tint2. it took a lot less effort. and it uses quite a lot less of resources too. purging that redundant lot reclaimed some resources too. all on the journey towards reclaiming resources from bloatwares, and all those big-is-beautiful fanatics!

the only reason we seem to need to buy bigger/faster hardware is just to keep up with bigger/slower software. in the end, you still end up with about the same memory, and processing power leftover to do what you actually procured a computer for. more efficient/smaller systems which can perform the same/better is what i expect on a development lifecycle of things getting better. i should be able to use the same old hardware much better with newer software, or i'm moving backwards. can you think back about a decade, and check whether your computer was faster than now?

i for one will continue on my quest. i don't have a need to show-off, or prove to anyone else. i'm happy using older hardware, and my systems are much quicker/faster than my neighbour's latest toy. guess i should re-title this post!?

to get back on topic. this one single simple file is a replacement for quite a few complicated (directories of) config files littered in various directories all over the filesystem. compared to all those various openbox/related config files, this is so beautiful.

vi ~/.jwmrc


iceweasel -private

lxterminal -e tmuxj

lxterminal -e plink -v -ssh localhost
skype --disable-api


leafpad ~/.profile
leafpad ~/.xinitrc
sudo shutdown -r -t5 now
sudo shutdown -h -t5 now

leafpad ~/.jwmrc


xload -nolabel -bg black -fg gray70 -hl yellow


















exec:lxterminal -e alsamixer
exec:amixer set Master 0
exec:amixer set Master 5%+
exec:amixer set Master 5%-

exec:dmenu_run -i -nb black -nf gray
exec:lxterminal -e htop

exec:firefox -private-window
exec:lxterminal -e bash
exec:lxterminal -e tmuxj
exec:lxterminal -e alsamixer

exec:jwm -restart
exec:jwm -exit

exec:sudo shutdown -r -t 5 now
exec:sudo shutdown -h -t 5 now

that doesn't show correctly on here! any tips on how to embed some code snippets on this blog?

most popular posts