Over the 8 years of my acquaintance with computers valuable data has been lost at an average of twice per annum. I have tried all kinds of solution to help my situation only to fail miserably by forgetting to back up some important bits and pieces of information before upgrading my distro.
Backup solutions can mostly be factored into two approaches of archiving and cloning. If space is limited, you can archive your important data using utilities such as
tar. This in fact was the approach I had been using until now. The downside appeared to be lesser accessibility of the files inside the backup. Say, I needed a small text-file from a 200 GB archive. It’d take me around 20 minutes to “get” to its location in the archive.
Which is why, I decided to shift to a newer approach. My laptop has a 320 GB hard disk and I own another 320 GB Western Digital Passport for extra data. To utilize the similitude, I bought another 500 GB Passport, transferred the “extra” data to it and then cloned the entire laptop hard disk to its 320 GB external cousin.
$ dd if=/dev/sda of=/dev/sdb
That is all.
dd‘s performance was questionable, as it took around 15 hours to clone the entire 320 GB. Nevertheless, this time around I was satisfied with the final backup. Not only was it a bit-by-bit replica of my original data but also an accessible repository which I could access easily by plugging in the USB.
, Open Source
, Western Digital
A match made in heaven.
Using IRC in a reliable way has turned out to be kind of a challenge for me in the past couple of months. I had my cellphone connected 24/7 to the IRC channels I needed to idle in. Unfortunately, I don’t live in a 3G country so any voice-calls interrupted the whole thing.
I also wanted to use my laptop for IRC-ing whenever I was at home. But the inconsistent internet connection didn’t make thing any easier. There was always this lingering fear of missing important messages during one of the disconnections. I couldn’t foresee a solution which would fix all of the mentioned issues until someone recommended using Irssi along with GNU Screen.
This not only fixed every little issue I had ever had with IRC but also made full utilization of my love for all things command-line. In summary: I now have this “permanent” IRC session running at an SSH server in Lithuania. Whenever I feel like it, I can “attach” my laptop or my mobile and start using Irssi. If I receive any voice-calls, the IRC session still continues to work and I can “reattach” later on. Simply put, the session continues running even when I’m not attached to it through either device and at any time of the day I can simply connect to it and resume working through that day’s IRC activity.
Here’s a screenshot that shows me connected to the
#gsoc channel on Freenode first on my laptop and then on my E71 using the same
PuTTY for Symbian is used for SSH-ing on the Nokia phone. If I ever rank top 5 situations where CLI absolutely pwns GUI in terms of efficiency and usage, this nifty setup is definitely going to make the list.
, Open Source
, Series 60
I could start off with an intro paragraph here but I’ll prefer keeping it sweet and simple: command-line is addictive.
For many kinds of tasks — ranging from system administration to organizing folders — I find CLI to be extraordinarily more productive than GUI clicking. For example,
vim-ing through a code, if I decide I need to lookup a particular symbol in the current directory, I can quickly do a recursive
grep without even taking my hands off the keyboard. Similarly, I find utilities such as
cp to be significantly faster than GUI file managers’ equivalent features. The learning curve is definitely steep and I also am not implying that everyone should find it equally productive but for me at least, it works like a charm.
It wouldn’t be an exaggeration to say that CLI provides a terrible amount of power at fingertips of its users. While that power is tremendous fun, it also can be a source of epic fails if not handled with caution. The fact of the matter is, as one grows accustomed to quickly doing work through text-based input, overlooking those cautions almost becomes second nature. It’s not uncommon to find a commandaholic holding his head in his hands while staring at the screen in disbelief. GUI does get credit for being a little more prone to accidental mistakes by consistently providing a visual view of what’s about to happen.
Moving on from the ill-starred mischief that I posted about last week, I thought I should compile a list of all time worst incidents of me cursing my fingers for being so familiar with the CLI. Here they are:
Sometimes, I blame Christopher Sholes for putting the
C keys so close on the keyboard. ‘Nuff said.
Deleting the wrong partition in
(parted) help rm
rm NUMBER delete partition NUMBER
NUMBER is the partition number used by Linux. On MS-DOS disk labels,
the primary partitions number from 1 to 4, logical partitions from 5
If you’re wondering why deleting a partition is placed so low on the list, the answer is TestDisk. Mere seconds after I deleted my primary partition containing all my data, I stopped all activities, booted into a rescue mode and used the God-sent utility to restructure my partition table like before with a cumulative data-loss of 0%.
e2fucking a mounted file-system
[root@orthanc ~]# e2fsck /dev/sda2
e2fsck 1.41.4 (27-Jan-2009)
/dev/sda2 is mounted.
WARNING!!! Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.
Do you really want to continue (y/n)?
See that SHOUTING WARNING? I did too. But back then, I ignored it as casually as anyone ignores licensing agreements. Needless to say, the results weren’t as inconsequential as clicking “I accept” and moving on without a hint of doing something legally binding.
rm -rfing the wrong directory
ignore nonexistent files, never prompt
-r, -R, --recursive
remove directories and their contents recursively
If the last tool had the F-word in its title as the warning, this one should be read as
rm --recursive-fuck. The H-bomb of command-line tools, once you detonate it on a directory you didn’t mean to set it upon, even
CTRL-C won’t be able keep you in one piece because of
rm‘s ruthless speed and efficiency. The only ray of hope is ext3grep, but depending on numerous factors (partition structure, number of files, file types, alignment of stars etc.) your recovery prospects would range anywhere from ±100% to ±100%. You read that right.
mkfsing the wrong partition
mkfs is used to build a Linux file system on a device, usually a hard
disk partition. filesys is either the device name (e.g. /dev/hda1,
/dev/sdb2). blocks is the number of blocks to be used for the file
The granddaddy of all command-line fuckups. If you have confused
/dev/sda (an easy slip up — as I learned the hard way), it’s time to move on. Sure, you will find people selling tools for recovering data from formatted Ext3 partitions; expecting those tools to work would be a lot like expecting the King of Pop to miraculously pop up from his coffin on Tuesday and perform a ground-breaking reenactment of 83’s Motown performance.
“Blessed are the forgetful; for they get the better even of their blunder.” — Friedrich Nietzsche
, Open Source
If you’re using KDE, KSnapshot can do the job for you. If you’re using GNOME, gnome-screenshot can also achieve the task with quite perfection. So why would someone ever need tinkering with command-line utilities to generate screenshots?
The answer is:
xwd is useful because not everyone uses KDE or GNOME and those who don’t usually despise installing needless extra applications for something as trivial as capturing a screenshot.
xwd comes with the X.org server itself, while almost all distributions by default provide the necessary software needed to convert
xwd screenshots into more popular formats. Moreover, KSnapshot and gnome-screenshot have a plethora of dependencies on their relative desktop environments whereas
xwd is a small, neat and efficient solution for capturing. Let’s start with the requirements: (more…)
, Open Source