Autarchy of the Private Cave

Since some WP release, the comment author’s link in comments is broken – it has ‘ external nofollow’ attached straight to the href attribute (which breaks the link).

I assume that the problem is caused by Google Analytics, namely the “track outgoing clicks” feature (as recalled, might be inaccurate feature name). “Track outgoing links” adds some JavaScript code to all outgoing links, and that script has tick characters like this one ‘ which, incidentally, are also used for delimiting the values of comment anchor tags.

To fix:
Read the rest of this entry »

Recently, I installed Debian Etch 4.0r1 onto my laptop. However, after the first boot into plain console, computer was dead-frozen after some console usage. I rebooted using the Power button – this time to gdm; and again, after some keyboard input system was hanging dead.

I found the reason here. Basically, it’s the PC speaker module (pcspr) not functioning correctly. I suspect this problem manifests itself only on some types of laptops. The solution is either to somehow reconfigure the pcspkr module, or just disable it. More on how to disable the module below.
Read the rest of this entry »

To start: as of the latest MySQL, syntax presented in the title is not possible. But there are several very easy ways to accomplish what is expected using existing functionality.

There are 3 possible solutions: using INSERT IGNORE, REPLACE, or INSERT ... ON DUPLICATE KEY UPDATE.

Imagine we have a table:

Now imagine that we have an automatic pipeline importing transcripts meta-data from Ensembl, and that due to various reasons the pipeline might be broken at any step of execution. Thus, we need to ensure two things: 1) repeated executions of the pipeline will not destroy our database, and 2) repeated executions will not die due to 'duplicate primary key' errors.

Method 1: using REPLACE
Read the rest of this entry »

Today, setting up a relatively serious (in CPU resources needed) web-system, I ran into a weird problem of python scripts ending prematurely. After some investigation, it looked like any process which uses up more than 20 seconds of CPU time, is automatically killed. To verify this, I wrote an infinite loop in C,

compiled it and executed several times on the GoDaddy shared hosting server. I did observe the program running for the maximum of 20 seconds of CPU time, not a second more. Please note, that 20 seconds of CPU time can be much more of "real" time, if the script isn't using 100% of CPU, which often the case for shared hosting. Thus if you have in your php.ini max_execution_time set to, say, 60 seconds, your php script may actually execute as long as one minute; but I'm pretty sure that if your script has lots of CPU-intensive procedures, then as soon as it uses 20 seconds of CPU time, it will be terminated (however, this statement still needs checking - anyone?).

To verify, I also created a cron job with the same file. It ran for 30 seconds CPU time.

Strangely, this behaviour is not documented anywhere.

This limit may also explain a number of other problems, if you have heavy web-applications: they just might be killed before they are finished, causing errors.

I do understand the reason for this limitation, and am sure similar limitations exist in other shared hosting environments. The only important thing here is that this limit should have been documented and even put upfront somewhere in the hosting plans descriptions.

I also wonder if the limit is the same for all godaddy shared hosting plans, or if it differs. 20 seconds when executed from PHP, and 30 seconds when executed as a cron job were observed on the Deluxe Linux Hosting plan.

Extensions, additions and comments are welcome.