Global Orgasm Day

As absurd as it may sound, 22 December 2006 is Global Orgasm Day. Yes! You heard it right: Gobal Orgasm Day. You can read all about it on the official global orgasm day website. A snippet from the website (the following indented content is copyright globalorgasm.com):

WHO?
All Men and Women, you and everyone you know.

WHERE?
Everywhere in the world, but especially in countries with weapons of mass destruction.

WHEN?
Solstic Day – Friday, December 22nd, at the time of your choosing, in the place of your choosing and with as much privacy as you choose.

WHY?
To effect positive change in the engery field of the Earth through input of the largest possible surge of human energy, a Synchronized Global Orgasm.

So, there you go. :-) Thanks to Ammar for offering me to bet on it and consequently making me learn more about the day.

Advertisements

script(1): Logging terminal sessions to files.

There are times when you want the output from a particular command that you’ve run on a Linux terminal in a file. There are even times when you want an accurate log of the entire interactive session you are going to run. While the solution to the former is as simple as piping the output of the command to a file, to go around doing the latter is a bit difficult, unless you are pretty OK with manually copying and pasting everything that appears on the terminal in a file.

If you are not, though, and are looking for a better, more effective, more accurate, and less tiresome solution, then look at “script“. According to the manpage of script(1), it makes a typescript log of a terminal session. Be it a command that is run in the session or an entire interactive session, script logs every detail into a file.

A few examples on how to use it.

ayaz$ script -a file.out
Script started, file is file.out
ayaz$ echo "Now, run any commands you want to run."
Now, run any commands you want to run.
ayaz$ echo "And when you want to exit, type exit."
And when you want to exit, type exit.
ayaz$ exit
Script done, file is file.out

ayaz$ script -a -c "ls -l" file.out
ayaz$ script -a -c "id" file.out

Quick-HOWTO: Setting Samba Shares on Slackware Linux.

I am a little short on time. This is a small write-up, briefly going through the instructions on setting up Samba shares on Slackware.

Samba stores its config and data files in /etc/samba/. Samba uses a single config file named “smb.conf”. If you have not played with Samba on your Slackware machine, chances are there won’t be any smb.conf in /etc/samba. There will, however, be an example smb.conf file by the name of “smb.conf-example”. I suggest you go through that file thoroughly to understand the various options supported by Samba and how the shares are set up.

Let’s quickly create a few shares. As root, create the file /etc/samba/smb.conf. In that file, we are going to list down global options (which, as the adjective suggests, apply globally) and the shares we want to enable access to. I am not going to explain the syntax or what each directive or keyword means. You should read the manpage for smb.conf(5) – type `man smb.conf` on a terminal to access the manpage.

That said, I have the following in my /etc/samba/smb.conf:

[global]
workgroup = homenet
encrypt passwords = Yes

[test]
comment = sec-tools
path = /home/ayaz/downloads/tarball/security
read only = Yes
guest ok = Yes

[home]
comment = home
path = /home/
read only = Yes
guest ok = No

[share]
comment = writable share
path = /home/share/
read only = No
guest ok = No

I have a global block – the one starting with “[global]” and ending before “[test]”. All you need to know right now is that workgroup should be consistent throughout the network, and that Samba should encrypt passwords, otherwise versions of Windows from 2000 upwards won’t be able to communicate with Samba.

Right after the global block, we have defined three share blocks in series. The string that goes within the square brackets is an arbitrary name for the share. Here, we have set up three shares. In order to understand what each keyword in each share means, refer to the manpage of smb.conf(5).

Once you’ve set the global options and shares in the file, you need to create at least a single user with access to the shares. For that, we will use the smbpasswd(8) utility. As root, do the following to create a user “test”:

root# smbpasswd –a test

It will prompt for password for the test user. Again, I suggest you read the manpage for smbpasswd(8) to understand the various options it supports.

After you’re done through with all this, you need to ensure that the smbd and nmbd daemons are running. Ensuring that in Slackware is simple. Simply do the following:

root# chmod +x /etc/rc.d/rc.samba
root# /etc/rc.d/rc.samba start

That’s it.

Why did I decide to go for Ruby?

I mostly write code in Perl, with C and C++ coming along once in a while. Perl is a dangerously powerful language. You can do most everything in it in a few lines of code. While that is Perl’s best feature, the code written in Perl can get hard to read really easily. The syntax is OK (not as clean as one may expect, although Perl gurus claim that it has a clean syntax), but the fact that a single task can be accomplished in multiple ways (which is Perl’s motto: [TIMTOWTDI] There Is More Than One Way To Do It) coupled with the compactness of code make maintaining of code a nightmare. The point of existence of a scripting language, such as Perl, is to provide a very high-level of programming abstraction to quickly write code to accomplish tasks. Being prone to getting real messy, the syntax Perl has to offer makes Perl a double-edged sword: You can write fast but you can write dirtily. You can write really clear code in Perl, but doing so, of course, takes time to thoughtfully lay out your code in a manner in which it is easy to read and consequently maintain. That sure beats the purpose of a scripting language, I am inclined to think. Write faster yet more difficult to read code; write slower but less difficult to read code. Do you see the point I’m making?

I have not studied Perl’s object oriented (OO) features enough to make a truly informed comment about, but Perl’s OO functionality, well, sucks. If it does not suck, it is stifled and unnatural, and has weird syntax. I have been writing code in Perl for the last two years or so, and I cannot say I have even once used its OO features. That is really OK as long as you are writing system administration scripts and small scripts to do really simple or even moderately complex tasks. But once the length the code runs to starts stretching way beyond the editor screen can manage gracefully, and tasks become complicated and start piling up, you wish Perl had a better interface to its OO features.

I moved to Ruby because I wanted to code in a scripting language that supported properly-designed and thought-out object oriented functionality, with a clean, clear syntax. Ruby just does not come close: It hits the nail right on the head.

Ruby is a true (or, like they call it, pure) object oriented language. Everything is an object. And working with objects is fun and easy. If that was not enough, Ruby extracts most of the best features from a large set of programming languages, both old and new, especially Perl and Python. It borrows its syntax heavily from Perl and Python. The syntax is clean. And I mean, real clean. And flexible. Python has a neat syntax (which is from where Ruby has borrowed its), but it imposes a restriction on the coder: Indentation of code is a must and, therefore, indentation rules should be followed strictly. What Ruby did is to take Python’s syntax, take out the stupid restriction imposed by Python as regards to indentation and throw it away. There you go. You have a clean, neat syntax available that is also very flexible.

If you know Perl and/or Python, you can transition to writing code in Ruby smoothly. Using Ruby, I have the clean syntax of Python, pure OO interface and functionality of many OO languages, and the dangerously powerful features of Perl (especially the all-powerful Regular Expressions) at my disposal. Ruby is like a single package packed up with all the good things from many languages.

There is a lot more to Ruby than meets the eye or than what I have spoken of, but these have been the primary reasons of my moving to Ruby. I still code in Perl. Only, I am now more inclined to do it in Ruby.

Dell Desktop PC!

After collecting suggestions from people on desktop PCs, I finally got myself a refurbished branded Dell desktop PC. It is a cute, black, flat desktop, neatly assembled, with the following specifications:

  • 2.26 GHz Intel Processor
  • 512 MB Physical Memory
  • 40 GB IDE Hard-disk
  • CD-WR+DVD-RD

I did not bargain over the price because it seemed like a reasonable acquisition.

External USB keyboard for Laptop.

I finally bought an external USB keyboard to use with my laptop. It is jet black, small, and sexy. And it just works on Linux. The ps/2-to-usb adapter I bought doesn’t work at all. I am glad this USB keyboard worked. Otherwise, I would have been struggling with a few more loose keys on the laptop’s keyboard popping out there and there.