The UID variables control the user used to run Roxen under Unix. Usually services such as web servers are run as the root user, with unlimited privileges. However since Roxen might be running a lot of scripts and modules it is not always appropriate to run it as root.
There are three ways to run Roxen as another user. The simplest is just to start Roxen as that user. A problem is that only root may open privileged ports on many unixes. Therefore it might be necessary for Roxen to run as root to open the ports.
Then it becomes possible to use the Settings / Change uid and gid to variable. In that case Roxen will change to this user unless it has to do something that requires it to be root, for example opening a port. Since Roxen still retains the ability to change user to root this might not be safe enough. Therefore you can use the Settings / Change uid and gid permanently variable to force Roxen to permanently change user just after it has opened its ports. This is safer but has the side effect that you may have to restart the server to be able to change the URL settings of a site.
It must however be stressed that none of the methods of changing user id is as safe as starting Roxen with that user id. Paranoid persons solve the privileged port problem in another way, for example by putting a relay or load balancer in front of the web server or by using ACLs to give the Roxen user permission to open privileged ports.
On most operating system Roxen can run as a threaded server. This has the advantage of making it possible for Roxen to serve requests while it is doing something CPU intensive, such as creating a large business graphics diagram. Or serve other requests while it is waiting for the operating system to fetch a file from a slow disk.
It is however not necessary that threading makes Roxen perform better overall. There is always an overhead when running with threads. Roxen doesn't need threads to send data to several browsers at the same time, it only needs threads to be able to calculate what to send concurrently.
Threading will not make it possible for Roxen itself to make effective use of more than one CPU on a multi-CPU system.
A big disadvantage is that running Roxen threaded will make it vulnerable to all bugs in the operating systems thread implementation. This may make Roxen perform badly, hang Roxen or even hang the computer itself.
To enable threads Roxen must be started with start --DENABLE_THREADS, something that is done automatically on Solaris. It is possible to configure the number of request handling threads with the Settings / Number of threads to run variable. Note that modules and scripts may start more threads.
The Settings / Module directories variable controls where Roxen will search for modules, by default in roxen/server/modules/ and in roxen/local/modules. The second location is intended for the user's own modules or third-party modules. It is not recommended to install any modules under roxen/server/modules, since they will be replaced when Roxen is updated.
Roxen will check any .pike, .class (Java modules) file found in the module directories or its sub directories to se if they are a module. A file is a module if it can be loaded and conforms to the Roxen module API.
Note that module uniqueness is determined by the file name and only the file name. Roxen cannot handle two modules with the same file name, regardless of which directories they reside in. The upside to this is that you can move a module between directories without affecting Roxen.
Roxen searches for fonts in the directories specified by Settings / Font directories, by default in roxen/server/nfonts and roxen/local/nfonts. The second location is intended for the user's own fonts or third party fonts. It is not recommended to install any fonts under roxen/server/nfonts since they will be replaced when Roxen is updated.