One remark and one proposal I'd like.

The remark
The term "rank" is a bit of a misnomer. A guild could associate no permissions with rank 8 and all permissions with rank 1, making rank 1 the highest rank in the guild, and it would all work okay.  (Unless I overlooked something, like, PS automatically adding all permissions of a low-numbered rank to all higher-numbered ranks. But I don't think it does that, and I don't think it should do that.)
A better term would be "title", I think.

The proposal
I'd like to have composable guild ranks, i.e. allow people to have multiple ranks.
So a character could be, say, a "Lord Protector" and also an "Ambassador". Guilds would be free to assign titles as they see fit, designating some as ranks and some as honorary or temporary titles.
There would be rather little game mechanics involved. In particular, the game need not differentiate between a "rank" and a "title", the difference is just in the minds of the players.
(There would be a schema change involved to allow multiple titles per character, and the GUI would need to support editing the list of titles, the permissions, and the list of titles that a player has - not a trivial change I have to admit, but I kinda like the RP possibilities that that offers.)

Thoughts?

Just in case anybody is reading here: the guild website has just moved to http://thewarriorsguild.org .
The contents are unchanged.

Setting the option didn't change anything.
It's still falling back to default device (ALSA, it seems):

Sat Aug 21 17:23:39 2010, <src/common/sound/system.cpp:36 Initialize SEVERE>
Sat Aug 21 17:23:39 2010, Failed to locate Sound renderer!
DEBUG: Initializing OpenAL sound system
DEBUG: Retrieving available devices.
DEBUG: Available OpenAL device: ALSA Default
DEBUG: Available OpenAL device: OSS Default
DEBUG: Available OpenAL device: Null Output
DEBUG: Default OpenAL device: ALSA Default
DEBUG: No device specified
DEBUG: Falling back on default device
Segmentation fault

I'm on current Ubuntu.

Core2 Duo here, but on 64 bits - the poll didn't offer an option for that specific combination.

You may be running into issues with sound in pslaunch, which hopefully will be fixed with the next minor release.

pslaunch seems to always run into sound issues, psclient should work if sound is disabled.
Note that pslaunch is just a convenience feature; doing pslaunch --repair will do updates, and editing the various configuration files will allow you to do all the configuration that pslaunch does. Just keep original versions of the configuration files around in case you broke something.

I don't know off the top of my head what's in which configuration file, so you may want to google "site:hydlaaplaza.com" for the configuration file names, explanations for configuration file changes have been posted in the past. Start using the newest instructions first, configuration has changed over the years, so experimenting is unavoidable.

Enemies should be generally consistent, but as Neko pointed out, it need not be a perfect symmetry.

To prevent misunderstandings like this, it might be a good idea to rephrase the faction relationships in terms of "A hates B" to "A loves B".

I.e. BF hates everybody, but nobody hates or loves them.

Oh, and I think there should be a secret organization that knows about BF. Otherwise, BF will simply win, hands down.

Yes it is.
I'm playing on a 3-years-old laptop here. If PS ups the hardware requirements, then that's it for me until I have another reason to cough up the 1000 Euros for a new laptop.

I see two areas where Erlang can help PS:

1) Make the code base more robust against crashes (the keyword is "fault-tolerant"). E.g. this could prevent the server from crashing due to faulty database field contents.
This is more a programming-culture than hard-language-property thing; similar things could be done inside the current C++ codebase.
A comparative study of using Erlang's processes vs. C++'s exceptions could be interesting.

2) Use Erlang to distribute the server software across multiple machines. Erlang would scale far better than C++ with RPCs or something could, if only because moving an Erlang process to another machine is easier than moving a C++ object.

Note that Erlang is not at all suitable for sending data between server and client, that would open security holes. (Erlang is built for environments where all Erlang software runs on trusted machines, and where only trusted machines can open Erlang connections to each other. A PS client cannot be trusted.)