Found this one very informative: 6 steps to stop content theft.

Also: 5 content theft myths, and why they are false.

And more links:

• free internet fax
• anti-spam email 1 (recommended)
• anti-spam email 2
• create on-demand snapshot (archive) of the cited web-page

Today I moved my blog and gallery into MySQL5 databases from an elderly MySQL4. Also, both WP and gallery are now updated to the latest versions. Soon I’ll change the WP and G2 themes – for the lighter, less cluttered – and will remove some ads… and will also add some others instead

Update generally went well, except for the message I got on the main page:

Sorry, but you are looking for something that isn’t here.

It was quite easy to figure out that new WP conflicts with an elderly “Sideblog” plugin – so I had to deactivate that one, and will have to update all the active plugins to avoid some other less evident problems… (actually, just completed updating all the plugins… quite a time-eater, that was.)

Also, there will be a slight change to what and how I write. No other details for now – but stay tuned! All the changes with no exceptions are planned for the good of readers, and for the users’ benefits!

If you want to fetch emails from some of your POP3-enabled mail accounts to Gmail, there’s a help article detailing the process. However, when using Ukrainian Gmail UI, clicking the link which should bring up the dialog box to add one out of maximum five Fetcher accounts, I got instead an offer to add the email address which I can use in the From field of my outgoing emails – and absolutely not a word about fetching emails from other POP3 accounts.

When I switched to English (UK) UI, everything went just as described in the help article, and I added one address to fetch emails from.

After fetching some mails, I switched back to Ukrainian UI, and – quite expectedly – the Fetcher part disappeared from the Settings/Accounts. Now I’m waiting to see if the Fetcher is nonetheless functional, or if it is also disabled… It’s functioning! So the only thing which was really changing in this case was the portion of the Settings/Accounts page not displayed while using Ukrainian UI.

The moral of the story is: when you think that some functionality is missing in the Google service you’re using – just switch to English UI!

Just a minute ago, I was shocked after logging in to mail.bigmir.net: instead of the bigmir’s own, HTML-only email interface, I got redirected at the gmail’s “Terms and conditions”, after accepting which I found my emails in the classic gmail mailbox.

First thing to think about: at least they did transfer all my emails to the new account.

Second: hey, they had given up their own email interface! Are they leaving the web-portal market of Ukraine? Was the part of their team (which later formed MI6) too important to handle their exodus with no consequences? Is that just a desire to give customers “better” interface and not invest anything into development?

I hope this won’t be a trend, for every service to have Google behind their servers. Or even just behind the name, to avoid extra complexity of having a server.

Finally, I think I’ll get used. But it was only yesterday, that I read the Google anti-utopia, where Big Brother’s name is (evidently) Google, and it’s webcams and microphones and search history define each person’s future AND guilt. Scary…

And I wonder which will be the next service of bigmir.net, “outsourced” like their email.

Update: there’s now a much more recent post on how to install libmp3lame-enabled ffmpeg on shared linux hosting.

As Gabe pointed out in my post with compiled ffmpeg Linux binaries, there is a relatively simple method of adding libmp3lame.so.0 file to your shared hosting so that ffmpeg executable will see the library:

You can upload libmp4lame.so as well to the shared hosting site and when you call ffmpeg, call something to set an environment variable right before the call to ffmpeg i.e. in php I’d do exec(”export LD_LIBRARY_PATH=/path/to/lib/with/lame; /path/to/ffmpeg [ffmpegargs]”); That way you can use the uploaded lame. I hope that helps someone as I have been unable to find any info on how to use an uploaded lame. I’ve tried it and it works on godaddy.

Hope this helps.

Update: here’s libmp3lame.so.0.0.0 (from slackware 2.4.x, lame-3.97). I have no idea if it’ll work in your (shared hosting) environment; it is provided AS IS, use at your own risk etc. I can only state that the archived binary file at the moment of upload was indeed libmp3lame.so.0.0.0 from my elderly Slackware with 2.4.x kernel.

Get it here. If you haven’t used any other theme except for default, and if you’re Firefox user for a long time – it’s time to try something new! I suggest you try ColorGnome – it’s bright, clear, vivid, cheerful and even funny! I’m using it for several days already, on all but one of my computer workplaces – and find it good enough to write about.

If you want something more strict/official-looking, try maxfox II or maxfox II graphite – I enjoyed these two a lot, currently maxcfox II is on the only computer which doesn’t have ColorGnome

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,

int main () {
unsigned int i;

for (i = 0; i < 2 ; i++ ) { i = 0; } return 0; } [/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.