The Internet, while a really wonderful medium for the gathering of information, also presents a challenge in validating the sources of information as being reliable and accurate. Here, the developers make our best attempt at debunking some common rumors about TinyMUSH.
I hear that TinyMUSH 3 is unstable. Is this true?
It's not true. To the best of our knowledge, TinyMUSH 3.0 is very stable, and we believe, now that TinyMUSH 3.1 is out of beta, that it, too, is very stable.
We have not received any crash reports for TinyMUSH 3.0p2 and later 3.0 patchlevels -- i.e., no fatal errors for code released since January 2001. We do not have any open bug reports for 3.0; there are no known issues with the latest release (3.0p4).
If someone tells you that they can crash a TinyMUSH 3-based server, we encourage you to ask them for specifics, and report the issue to us so we can make sure that it's fixed. We hear people tell us that "a friend of a friend" told them about a problem, but the problems seem to be urban legend at best. While we're certain that no MUD server is ever entirely bug-free, we do believe that TinyMUSH 3 is extremely stable; you should not be experiencing any crashes with the current patchlevel.
If you do experience problems with TinyMUSH 3 crashes, please let us know, and we'll do our best to immediately fix the problem, and issue you a patch.
I hear that TinyMUSH 3 has database corruption problems. Is this true?
It's not true.
To our knowledge, there are no database corruption problems in TinyMUSH 3.0, and we don't believe there are any in TinyMUSH 3.1, either.
We have not received any reports of database corruption from users, since 3.0 beta 22 (November 2001). Note that 3.0 beta 21 had known database corruption problems that did impact a number of MUSHes, and is probably the source of prior worries about stability; that problem, however, is completely fixed.
If you do encounter database corruption issues, the development team would be very interested in hearing about them, and working with you to track down the source of the problem.
I hear there's a security problem with GDBM. Is this true?
It's not true.
The rumor comes from an exploit for GDM (xdmcp) that was catalogued in several security-tracking sites as a GDBM exploit, thanks to a typo of a 'B'. You can confirm this for yourself by doing a search for GDBM on whatever exploit-archive site you like; you'll either find no exploits, or an exploit that, when clicked, brings you to a GDM exploit. (Note that the exploit is also labeled as being a vulnerability in 'GDBM 2.0'. GDBM 2.0 does not exist.)
Furthermore, even if a security vulnerability existed, a MUSH runs as a non-privileged user, not as root, it has only the privileges to execute what that user could execute; any exploit, if it existed, would compromise the user and not root -- still an undesirable problem, if a security vulnerability existed, but not a root vulnerability. However, such a vulnerability does not exist.
You can confirm that there are no known security problems with GDBM from the SourceForge information on GDBM, which states there are no known security vulnerabilities.
GDBM is a GNU package in extremely widespread use. If there were known security vulnerabilities in it, they would have been patched very quickly, in a very public manner. There haven't been any.
I hear that GDBM can't handle lots of attributes on an object. Is this true?
There's a rumor that states that if you write several thousand attributes to an object, the database will overwrite itself and cause continuing corruption.
The developers have yet to see convincing evidence that this bug exists. We have tried numerous tests involving creating thousands of attributes on objects, and have not been able to cause any kind of database problem. No one else has been able to demonstrate a problem, either.
If you do indeed manage to demonstrate this problem, we would be very interested in hearing about it. Make sure you examine other factors as well, though: shell-imposed process size limits, available disk space, and so forth. You should provide as much information about your operating system and configuration as possible.
Prior to 3.0 beta 22, there was a bug caused by the introduction of @logrotate, which could cause database corruption in special circumstances, related to the handling of stderr. This bug was fixed in 3.0 beta 22. It is possible that database corruption due to this bug was misattributed.
Some technical details:
The attribute that tracks the list of attributes on an object (A_LIST) is stored in a malloc()'d buffer that is reallocated as it grows. There is no limit on its size.
GDBM does little more than seek to an offset in a file and write whatever data it is given. There is no limit to the size of the data, and GDBM handles its free space effectively; if there is no available free space large enough to hold the data, it will write to the end of the file. GDBM is in widespread use, so it is unlikely a major problem with it would go unreported.
An OS-specific problem with the stdio calls, or with the underlying filesystem, is possible. However, these problems would be well-known with any OS in widespread use. Note that physical drive failure, partial write due to a system crash, and other system catastrophic failures can indeed cause database corruption, but it would be unrelated to the number of attributes (though of course, very large databases and objects would have a higher chance of being affected by such system failures).
Do you make any money from this?
The developers are not compensated in any way for time that they spend on working on TinyMUSH 3. There are no plans to ever make TinyMUSH 3 (or any derivatives, spin-offs, etc.) into a commercial product. This is open-source freeware, and it will remain that way. (It is not GPL'd, because the terms of the original TinyMUD license, which covers derivative works such as TinyMUSH 3, prevent bringing TinyMUSH 3 under the GPL. We use the Artistic License, which is OGL compatible.)
Some of our developers may take contributions. You may reward them for their work, if you see fit.