dev-libs/memcache-api-php is gone

When this package was added it was intended as a stopgap measure, really. There was no good PHP API for the memcached daemon. The only good one was the Perl one, (now Cache::Memcache) written by the memcached author.

There was later a PHP API written in C, part of the PECL, which would inherently be faster. It’s now the recommended API (SO USE IT, AND DISTCC! </subtle).

So now the slow, buggy, unsupported API is gone. Rejoice!

The UO Addiction has Gentoo implications

Cos I’m about two seconds away from comitting UOAMhub, an unofficial Linux port of the Win32 only UOAMsvr.

UOAM is a program designed to act as a kind of GPS within the UO world. Various guilds and groups of friends use UOAM to keep track of everyone’s position, which, coupled with voice communication (such as TeamSpeak) helps in coordination of events.

Belxan’s UOAM protocol is proprietary and the uoamhub daemon has reverse engineered it.

I’ll be testing the daemon today and stress testing it this week with my own guild.

sys-libs/memcached-api-php removal!

I posted on the -dev mail list late last month about removing this API. It’s buggy, and the source files aren’t even on SRC_URI. There was 0 response to my -dev post and 0 favourable response to my post to memcached mail list.

So if you’re going to use Memcached with PHP please use the PECL version. dev-php5/pecl-memcache or something. 😉

Google Error? What the hell?

Google Error
We’re sorry…

… but we can’t process your request right now. A computer virus or spyware application is sending us automated requests, and it appears that your computer or network has been infected.

We’ll restore your access as quickly as possible, so try again soon. In the meantime, you might want to run a virus checker or spyware remover to make sure that your computer is free of viruses and other spurious software.

We apologize for the inconvenience, and hope we’ll see you again on Google.


What rubbish!!

Things I’ve learned by using Gentoo…

In my years using Gentoo I’ve learned a lot. I’m going to share it with everyone (whether you like it or not):

In no particular order…

  1. It isn’t necessary to completely wipe clean your disk to fix a perceived problem in your installation (even if you allocate only 4gb instead of 40 for /).
  2. Never downgrade glibc.
  3. Always use Google when you’ve got a problem.
  4. ALWAYS use Bugzilla
  5. Join Gentoo🙂
  6. Ignore flamewars
  7. Don’t ignore -core mail or you’ll miss out on important data, like, Gentoo is a foundation? And it’s got a council? *g*
  8. Disable root logins, ssh version 1, and password logins in sshd_config; force ssh key access
  9. Backup your data
  10. ADMIT NOTHING!!!!!!!
  11. Don’t take things too seriously
  12. Take the serious things seriously

There’s so much more, but it would take far too long to list.

More on Distcc and SLP

As much as I’d love to see SLP integrated with Distcc I’ve come to the realisation that Gentoo isn’t the place for the patch to be implmented and tested. Rather, it should be applied to the source tree UPSTREAM for the entire user base to test, likewise with all other patch enhancements.

Obiously it’s different if the package has no maintainer and hasn’t seen the loving hand of a programmer in years or if the patch is to fix a serious Gentoo-specific bug, like the TMPDIR issues in distcc from a year or two ago.

How do you know when you’re really bored?

You write a shite CMS in Bash and PHP!

It’s called CMS580 cos all told it is 580 lines in length. lol

It’s buggy, has barely any ‘CMS’ features, but it uses mod_rewrite, which was kind of the goal.

What did I learn about mod_rewrite? Save yourself the trouble and just send everything to a prg: map.

Anyways, if you’re morbidly curious feel free to laugh, at the code in cvs. The mod_dir bits are commented in .htaccess because of bug 11843.