you just did a CVS update and now the program does not compile, or crashes, or changes didn't go through.

did you forget the "make install" step?
header (.h) file changed
you must do a "make clean" because all jMax makefiles are broken regarding .h files.
new source file (.c) added
you must rerun "configure". i recommend to do "make clean" after that.
maybe matju forgot to checkin an important change.

you should know where the FTS executable file is. Its filename looks like "/usr/lib/jmax/fts/bin/i686-linux/opt/fts". we'll call it $FTS now.
if you want to prevent a complete machine crash, you should not run fts as "root" user, and you should do chmod -s on the $FTS file. i recommend that you work that way until the fts crash problem is fixed, and only run it again as root when the only problem left is lack of smoothness.
by running the command "ulimit -c unlimited" before starting jmax (from the same shell) will cause a crash to write the program's RAM into a file named "core" in the current directory.
you can read this file in a semi-friendly way by doing "gdb $FTS core" right after that. what you need to do with that is usually just to type "backtrace" and then "quit". the first command will print a list of functions active during the crash. the bug is usually in one close to the top of the list.

FTP transfer in ASCII mode
- this mode assumes you are passing plain-text files. it filters out windows-style end-of-lines. the jMax format (".jmax") is not plain-text, and so, important bytes get removed from the file.
- solution: use binary mode.
CVS update
CVS assumes text files in which it makes sense to merge file differences together. this normally results in update-conflict and corruption on jMax files.
Your previously working file is renamed as hidden file with a ".#" prefix. The new working file is available by removing the corrupted one and doing cvs update again.
The worst thing you can do is actually check-in a damaged file, in which case you'll have to peek an older version and check-in that file.

put often-used files on fast drives. this means don't use NFS (networked file system) for that. the file->ram cache can compensate for that up to a certain amount, but the larger the file is, and the most used the file is, the most important it is to put it on a local drive.