Myths have a very long half-life, especially when it has to do with operating systems. Let’s say version N of some software was really bad at doing something, which got fixed in version (N + 2). It won’t be until version (N + 5) or so that most people will realize that the problem has been fixed. Until then, this will remain a hot topic for discussion each time the subject comes up.
You know what the best part is? Not one of these people would have used any version of the OS for the past five years. For instance, a typical complaint would go like this: “I used Linux (read, Red Hat Linux 7, from the Dark Ages) sometime ago (read, six years ago) and the screen resolution sucked!” Obeying the rules of gossip, this gets translated into, “The resolution on Linux sucks!”
Unfortunately, everyone not using Linux will continue to believe this myth until someone demonstrates that the screen resolution on Linux is actually awesome. Note that it is insufficient to demonstrate that the screen resolution on Linux is as good as that on any other system. That’s just too mundane to catch on.
This phenomenon works all six ways (Linux, Windows, Mac = factorial(3)). Windows and Mac being more ‘mainstream’, however, their features and releases receive greater publicity.
It is interesting how these different groups interact with each other, almost as if they were following their own religion. Blind faith, superstition — it has all the elements except physical violence. Maybe one of these days, governments will force their citizens to use one or the other piece of software. Then, countries will go to war over operating systems.
I like to keep my software up-to-date, so I sync it with the repository every day, and see if there’s anything that needs updating.
And yet, I don’t like the fact that it takes time to perform the update, or that there is a chance that my stable system could be broken by the change, or that a package may fail to build.
So I run the update command, hoping that there’s nothing new.
The title of this post was supposed to be “I Have A Macbook Pro Now”, but this one seemed just as appropriate. I am one of those guys who watches in disdain as others argue about “being a PC” or “being a Mac” (it’s Linux all the way for me, baby) but then I figured one must try everything in life. Yeah, I know I’m twisting a perfectly legitimate philosophy for the sake of personal gain, but this is my blog after all. Live with it.
Even the village idiot would have figured out by now that I’ve purchased a new Macbook Pro. I haven’t used a Mac before, except on rare occasions, so I’m still learning. That being said, there isn’t much to learn, apart from keyboard shortcuts. This operating system is Unix-y enough for me to feel comfortable — for example, I copied over my zshrc file from my desktop to the laptop, and voila! I have a terminal that behaves exactly like the one on my good ol’ Gentoo box.
One of the disadvantages of being a Mac user though, is that almost every silly piece of software costs $20 or more. This is slightly mitigated by the fact that almost everything comes out of the box, except for Office software (no problem though, grab a copy of OpenOffice.org before they run out of copies). But I guess that’s a totally different world, where software is free (as in speech).…
If you’re running an SSH server on a machine exposed to the Big Bad Internet, it is best to disable password authentication. Public-key authentication is a far safer option. Here’s a typical snippet of my server logs that explains why:
Nov 20 10:24:01 [sshd] Invalid user backup from 220.127.116.11
Nov 20 10:24:03 [sshd] Invalid user info from 18.104.22.168
Nov 20 10:24:04 [sshd] Invalid user shop from 22.214.171.124
Nov 20 10:24:06 [sshd] Invalid user sales from 126.96.36.199
Nov 20 10:24:07 [sshd] Invalid user web from 188.8.131.52
Nov 20 10:24:09 [sshd] Invalid user www from 184.108.40.206
Nov 20 10:24:11 [sshd] Invalid user wwwrun from 220.127.116.11
Nov 20 10:24:12 [sshd] Invalid user adam from 18.104.22.168
Nov 20 10:24:14 [sshd] Invalid user stephen from 22.214.171.124
Nov 20 10:24:15 [sshd] Invalid user richard from 126.96.36.199
Nov 20 10:24:17 [sshd] Invalid user george from 188.8.131.52
Nov 20 10:24:19 [sshd] Invalid user michael from 184.108.40.206
Nov 20 10:24:20 [sshd] Invalid user john from 220.127.116.11
Nov 20 10:24:22 [sshd] Invalid user david from 18.104.22.168
Nov 20 10:24:23 [sshd] Invalid user paul from 22.214.171.124
Nov 20 10:24:27 [sshd] Invalid user angel from 126.96.36.199
Nov 20 10:24:30 [sshd] Invalid user pgsql from 188.8.131.52
If you install Linux for the first time and are greeted with an ugly set of fonts -
- Make sure you install all the popular TrueType fonts (Microsoft’s common fonts are generally available via your distribution’s repositories).
- Remember to enable anti-aliasing of fonts. Anti-aliasing can be turned on through the desktop-environment’s configuration, for example, KDE’s Control Center.
- Set the hinting to ‘medium’ while enabling anti-aliasing of fonts.
- Change the user-interface fonts to something that looks good, like Verdana, DejaVu or Calibri. Firefox also comes with an ugly set of default fonts, so you may also want to change those defaults too.
After I switched from KDE to XFCE as my desktop environment, I had to abandon KMail as my email client (since I would rather not run KDE-based applications in a non-KDE environment). The replacement I settled on was mutt, something I had already tried and liked a lot.
So what’s the big deal about console applications, you ask? I don’t know, but they’re just much nicer than GUI clients. It must be genetic or something.
So here’s how I’ve set up mutt:
- I can read my Gmail messages (actually, Google Mail for my domain).
- I can send email using Postfix, which routes messages through Gmail’s server
- The recipient’s address is automatically added to my addressbook when I send email
- I can look up or autocomplete addresses while composing email
- Messages are signed using GnuPG before they are actually sent
I don’t like to manually check my email. Instead, I’ve set up a mail-notification applet (a ‘biff’) to check my email every couple of minutes and play a sound when there are new messages. Reading, deleting and composing mail are all just a few keystrokes away. Additionally, there is no need to open any heavy application — the terminal window pops up within seconds.
The wait is finally over. KDE 4.1 is now in the official portage repository, which means that Gentoo users can upgrade to it without having to unmask any packages or setting up an overlay.
I upgraded to the new and shiny KDE 4.1 today for the first time. I could have easily gotten it from an overlay a long time ago, but then I figured it was best to wait for it to mature. Like its predecessor (KDE 3.5), this version of KDE looks quite unpolished until you spend some time customizing it. For instance, I cannot fathom the reasons behind not enabling font anti-aliasing by default. Without this tweak, all fonts look jagged and ugly. KDE also seems to have taken the path of Microsoft’s Windows Vista in terms of its color scheme: gray and black seem to be the norm.
Overall, I am not too disappointed with the upgrade, but I realize now that I’m going to have to wait for future releases for many pieces of functionality that I used to love in KDE. This is one of the downsides of having software redesigned from scratch. For instance, Amarok 2 (still in beta) included in this version of KDE, is missing several key features, such as track-queuing and equalizer support. I just wish the KDE developers had focused on having a 4.1 release that was on par with 3.5.10 in terms of features, rather than worry about the details.
Regular expressions (regexes) are one of those concepts that sound innocuous, turn out to be frighteningly complex when you approach them, but aren’t that big a deal when you actually get to know them.
The idea behind a regex is quite simple: it is a single concise series of symbols that can be used to represent a class of expressions exactly. For example, a regex could be used to represent “a sequence of characters that begins with the letter C” or “a sequence beginning with b, ending with d and any number of x’s in between.” Regexes are extremely expressive, and can come in handy at odd times.
Regular expressions are built on simple rules. The following is not a comprehensive list, but should provide an idea of what regular expressions look like -
- Alphabets and numbers represent themselves. So do a large number of punctuation characters. These are case-sensitive.
- A dot “.” represents a single instance of any character.
- An asterisk “*” indicates that the preceding character may be repeated zero or more times.
- An plus “+” indicates that the preceding character may be repeated one or more times.
- A carot “^” is an anchor for the start of the line.
- A dollar “$” is an anchor for the end of the line.
- The “<” and “>” symbols are anchors for start and end of a word respectively.
- Et cetera.
For example, ^Cof*e+$ would match Coffee, Coeeeeee or Coffffffe but not Coffff, coffee or Cofeen. Regexes can be much more complicated in practice, but the basics are sufficient for many common cases.
The most important advantage of understanding regexes is that it opens up the doors to a huge collection of Unix tools, such as
awk. Most Unix text editors also support regexes to some degree.
grep is the most well-known amongst these tools — it is used to find lines that match a given expression —
sed aka ‘the stream editor’ is perhaps the most useful, because it can actually manipulate text. For instance, when I migrated more than a hundred old posts into this blog a couple of weeks ago, I needed to replace a whole bunch of
<div> tags with
<p> tags. That’s when sed came in useful: it took just ten minutes and a single command to get the job done.
It’s amazing how much can be achieved with the help of a few scripts. If you come to think of it, scripts are the original mashups that Web 2.0 has venerated in recent times.
Today, I decided that I would have a “Now Listening” box shown on my blog — I’m not sure if it is visible at this moment — which would display the name of the artist of the currently playing track on my computer. So here’s what I came up with -
- A Bash script that would use DCOP to query Amarok, determine the currently playing song, and update a temporary file accordingly.
- A small PHP script that would read the file and display this information, but only if it is available.
- A set of CSS rules to format the generated XHTML.
- A cron job to execute the script every minute.
Voila! It’s done…almost like magic.
Don’t try this at home, kids.
- Open a console window on your trusty old Linux box.
- Find a WordPress plugin you don’t need.
- Start typing
rm -fr /path/to/wordpress/plugin-name.
- Instead, type
rm -fr /path/to/wordpress and press enter.
- Spend a few hours setting up your blog all over again.
Step #5 is the part I love the most.