I had really wanted to seed the initial few hours of the release on my new server because of its great amount of network bandwidth, but that’s an opportunity I lost because of a crash like this:

Caught Segmentation fault, dumping stack: KB] [Port: 6924]                                                                                                                                                                                                                   [U 76/0] [D 0/0] [H 0/32] [S 3/86/768] [F 4/128]
0 rtorrent [0x41ea5d]
1 rtorrent [0x421488]
2 /lib64/libc.so.6 [0x3a76a322a0]
3 /usr/lib64/libtorrent.so.10 [0x3a78e4caf4]
4 /usr/lib64/libtorrent.so.10 [0x3a78e50683]
5 /usr/lib64/libtorrent.so.10 [0x3a78e4f704]
6 /usr/lib64/libtorrent.so.10(_ZN7torrent9PollEPoll7performEv+0x5d) [0x3a78e24d55]
7 rtorrent [0x440379]
8 rtorrent [0x41f645]
9 /lib64/libc.so.6(__libc_start_main+0xfa) [0x3a76a1e32a]
10 rtorrent(_ZNSt8ios_base4InitD1Ev+0x49) [0x40cc79]
Aborted

that kept happening.  Up to this point, I have never had a problem with rTorrent, alhamdulillaah, but still – that one time you really need it, and it goes?  The worst part is, when searching the problems I was having, it was due to memory consumption.  4GB is not enough to seed a couple of hundred peers?  I could seed almost 100 on my older hardware with only 1GB of RAM, and I never had the mainline client (which is written in Python) give me such problems.  rTorrent is written in C++, which I thought would help with these kinds of cases.  Shouldn’t, theoretically, a compiled application require less memory than one running within a virtual machine environment — maybe my understanding on computer science is lacking, but I always thought that was the prevailing wisdom.

Anyway, I didn’t want to turn this into a rant about rTorrent, but the emotions are strong enough to drive me to at least say something, especially because the crash happened during (my) nighttime, so I couldn’t restore the seeding until after I woke up and got back from fajr prayer.

If anyone has any recommendations on how to avoid the problem I had with rTorrent or on a better, more stable client that can handle such massive transfers and load, please let me know.

Alhamdulillaah, after loading up all blog-post pages (i.e., going to the bottom of each page and clicking for the next page), I’ve fixed all old posts that had HTML errors (according to the HTML Validator Firefox plugin).

This actually is a relief for me because amongst the major reasons I enjoy using WordPress is the work the developers put into it to make it a clean & standards-compliant application.  I’ve avoided themes that are not.  So, alhamdulillaah, it seems that all the posts are fixed.  I haven’t bothered with the pages that I’ve created, though, because I’m likely going to redo those shortly anyway, in shaaʾ Allaah.

That is all.

Alhamdulillaah, I’ve been able to make some major- and sorely-needed-upgrades to Audio Islam.  Interestingly enough, for the vast majority of people, these changes won’t really be that visible as they are all behind-the scenes.

The desire to upgrade Audio Islam has been around for a long time, and I still have many more changes, particularly in relation to the code, that are pending.  But I decided to focus on performance due to the vast surge in visitors that will come during the month of Ramadhaan, in shaaʾ Allaah.  Therefore, I had to polish some things, upgrade others, and in some cases, fundamentally change them!

Prior to today, Audio Islam was running a typical LAMP setup – Red Hat Enterprise Linux 4, Apache HTTP Server, MySQL database server, & PHP Hypertext Preprocessor.  Also typically, at the behest of the PHP developers, my Apache HTTP server was configured to operate in prefork mode, which, to put it simply, causes the web server to assign one process per web request.

For a site like Audio Islam, where currently the programming logic is rather limited and the bulk of the action involves downloading of large files, the cautions that call for using the prefork mode, as opposed to the more performant multi-threaded worker mode, are less urgent, so I opted for the more efficient mode due to Audio Islam’s need for very high concurrency on rather modest server hardware.  I’ve had to set the maximum number of clients in my webserver to over 700 and also offset the more popular mode of download to be FTP just to keep the website accessible, so I am very keen to seek out as much optimization as I can until I can move to another server that will sustain the site as well as this one in terms of bandwidth (currently, 20Mbit/s unmetered is keeping the site afloat, alhamdulillaah).

However, here is where the multi-threaded madness of PHP reared its ugly head.  In truth, I am not entirely sure that I can lay the blame solely on PHP here, but as PHP is not generally multi-threaded enabled and intends to stay that way, I don’t feel so keen on removing them from the blame completely, either.

Before going further, here’s a summary of the specific versions of each package (before/after)

• Apache HTTP Server: 2.2.0/2.2.9
• MySQL database server: 5.0.16/5.0.67
• PHP Hypertext Preprocessor: 5.1.6/5.2.3

As I install all my servers from source on my aging Red Hat platform in order to get the latest versions easily, that means I have the pleasure of compiling all my packages from source (I haven’t figured-out how to make my own RPMs yet…).  So, my first step was to compile Apache HTTP server, ensuring I enabled the worker MPM mode to enable multi-threading (a simple mistake I noticed when I saw the config summary included the old prefork MPM).

My configure command was as follows:

./configure --enable-modules=all --enable-mods-shared=all --with-mpm=worker

This went along very well. My next step was to compile MySQL, as I needed access to the client library in order to compile PHP with support for the database backend.  Note that the coming of PHP 5.3 should obviate this as it will feature a native MySQL driver for PHP which shares the same license as PHP, which sparked the whole problem of the separation between PHP the MySQL client library.

Before I show the MySQL configure command, let me present the PHP one:

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql --with-zlib --with-bz2 --enable-mbstring --with-mysqli --with-pdo-mysql --enable-zip

This is a pretty basic PHP configuration script, rather slim, but sufficient for what I needed.  However, the configure script complained about a missing library for MySQL named “libmysqlclient_r”.  I looked for it on my system, and while I found it, it was the wrong version.  This is when I realizzed that I had to enable the thread-safe client in MySQL.  So, I did this, using this configure command:

./configure --enable-thread-safe-client

After a rather lengthy make & make install process, PHP was still complaining.  I looked for libmysqlclient_r and found it, but PHP still kept complaining that it wasn’t under “/usr/local”.  It didn’t matter that I explicitly instructed it to look at the install directory of my MySQL installation.

Anyway, after spending several hours trying to figure this out by researching online and trial-and-error, I decided enough was enough, and I was going to follow PHP’s recommendation of running it under FastCGI.  However, I do not have a lot of experience getting Apache to run under FastCGI.  Morever, as I didn’t need Apache’s power & flexibility for Audio Islam, I decided now was the time to go where I’ve wanted to go for a while – to host Audio Islam using lighttpd.

lighttpd (pronounced lighty) is a lightweight yet powerful HTTP server that is designed for low overhead and high performance. Despite these goals, it still hosts a slew of features that sufficed it to be the backend for Audio Islam, alhamdulillaah.  Once I realized that I was going to go through with it, I stopped all my efforts at getting Apache HTTP working and focused on installing lighttpd.  Amazingly enough, I discovered that the latest stable version, 1.4.19, was already available via yum for RHEL4!  I quickly went ahead and install it and its fastcgi module.  And, a short while later, after some configuration, I had Audio Islam up-and-running on lighttpd!  Alhamdulillaah!  It was rather surprising to see how it worked perfectly out of the box once I redirected it to my newly-fastcgi-compiled PHP.  For reference, here’s the final configure command I used for compiling PHP to ultimately work on lighttpd:

./configure --enable-fastcgi --enable-discard-path --enable-force-cgi-redirect --with-mysql --with-zlib --with-bz2 --enable-mbstring --with-mysqli=/usr/local/mysql/bin/mysql_config --with-pdo-mysql=/usr/local/mysql/bin/mysql_config --enable-zip

The first three arguments are from the lighttpd documentation, and the rest are what I wanted in the first place.

So, there you have it! Audio Islam is now running on top of lighttpd, alhamdulillaah.  In shaaʾ Allaah this setup will enable the server to sail through Ramadhaan far smoother than previous years.  I guess we’ll find out in a couple of weeks, in shaaʾ Allaah.

Alhamdulillaah, my good friend Belal Khan of Leechon Films fame has started (a while back, actually) a program called Message Mastery.  You should get the full explanation from the website, but the basic gist of it is that it is a training seminar focused on developing masterful messages through the medium of video.

He’s released a few videos that are freely available that are samples of what the entire program entails.  I found the one entitled “Three POWER Principles of Filmmaking” to be quite refreshing in how simple, yet effective, such techniques can be.  Even more beneficial is that the tips he provides, while framed around the production of video media, are general enough to be beneficial in almost any context.

Give his site a check-out and leave some comments as he’s very keen on getting & responding-to feedback from his visitors & members of his program.

Disclaimer:  Belal is just my friend – I am neither associated with Message Mastery nor am I enrolled in the program…yet.

I’m going to start a new, easy-lifting tutorial series that I’ve been meaning to do for a while. It’s focus will be useful exploitation of the X/HTML standard for marking-up your pages in an elegant yet standards-compliant way. I will make an attempt to reference other excellent sources that exist throughout the webiverse wherever appropriate, but for the most part, a lot of these ideas have just come from my own exploration and experimentation with the specification.

Some of the things I will be covering in this tutorial series include (but are not limited to):

• The usage of lesser-known but fully-supported X/HTML tags for common & useful purposes
• Emphasis on a semantic presentation of content
• Minimization of unnecessary markup
• Strict adherence to both the spirit & the letter of the pertinent standards
• Examples of how to exploit the synergy between pertinent standards (e.g., X/HTML, CSS, etc.)
• How to avoid using deprecated tags, attributes, and techniques in favor of more sanctioned alternatives

Comments, questions, and suggestions related to the topics presented are always welcome, and I will do my best to answer them, but no promises are being made.

X/HTML is as ubiquitous as a standard can be, yet it is rarely used to its full potential (or correctly, for that matter). There are many aspects of this elegant language that, while fully-supported by nearly all standard browsers (Internet Explorer, Mozilla Firefox, Opera, & Konquerer [and, therefore, more-or-less, Safari]), are extremely under-utilized. This, in fact, leads to a lot of effort to duplicate their functionality through less-appropriate means – whether via static graphics, Javascript, or even (*shudder*) attempting to mimick their layout through the use of tables. What follows is a brief tutorial introducing these often-neglected tags & practices that can bring with them some tremendous advantages in terms of development time, efficiency, & standards-compliance.

I keep referring to HTML or XHTML as X/HTML simply because, for the most part, the specifications of HTML 4.01 and XHTML 1.0 can more or less be losslessly decomposed into one-another back-and-forth, so there are very few actual differences between the two. The focus of XHTML 1.0 was to take HTML 4.01 and convert it into a valid XML application. So, while I will be sticking to XHTML syntax throughout my examples (lower-cased tag & attribute names, all tags must be closed, etc.), all tags and their usages are completely valid between the two specs, should you choose one over the other for any particular reason.

I am looking forward to sharing this joint experience with you guys, and I do hope you’ll enjoy & benefit from reading it, as I am sure I will  in writing it, in shaa Allaah.

His XTech 2006 presentation (warning: PDF file) provides a few more details as well as some information of a browser-based slide editor (not as interesting to me…). What is most excellent about Slidy is the fact that it uses the best practices of web design (standards compliance, semantics, & browser compatibility) to provide a truly intuitive web-base slide presentation tool. It’s usability cannot be overstated. Its features include:

• Move forward & backward through pages using right- & left-arrow keys, along with page down & page up
• It supports incremental displays
• It supports linking to individual pages within the presentation without losing any of the forward/backward features
• All content is stored in one XHTML file
• All presentational elements are executed via CSS
• All features are available in all browsers, or at least degrade gracefully (requires some additional user work, such as providing a bitmap alternative to an SVG image)
• All dynamic code is contained in one Javascript file (Slidy.js)
• All Slidy-related materials (code, examples, etc.) are available via the WC3’s Software & Document licenses (The W3C Software license is said to be GNU compatible)

I’m really looking forward to seeing this standard used more & more. Considering it is pretty much free from incompatibilities, I intend to start using it ASAP for any presentations I need to make. The best part is that, because it is based on XHTML Strict, it is also a valid XML document, and so it should easily losslessly convert to other media without too much difficulty, while also because pretty future proof. XML doesn’t seem to be fading out anytime soon.

It may not be immediately obvious, but I am a staunch advocate of standards compliance, the semantic web, & the separation of content from presentation. The most vivid examples of all three of these is utilizing XHTML to semantically markup what it is you wish to present, share, or demonstrate, while utilizing CSS to style it. Properly implemented, these concepts will yield:

• Low maintenance websites & pages
• Vastly easier restyling in the future
• Sites that are much more optimized for search engines
• Greater accessibility for alternative media formats (screen, print, audio)
• Warm-fuzzy feelings knowing you’ve designed for the future, rather than the here-&-now

I have a few articles queued-up in my ever-lengthening post backlog that address several of the issues mentioned above (some more obviously related than others). Maybe some comments might pull me out of my production slump (work-induced, I assure you) and get me back on track. ; )