One of your biggest headaches will probably be CD-ROMs and CD-R/Ws. In theory, they belong on the mock mainframe like everything else, but this creates lots of problems. Your users need to be able to physically get to the machine to put the CDs in, which might not be a good idea from the security point of view. Once the CD is in the drive, you can get various people trying to mount, unmount or eject it, and getting upset if they can't. Reading a CD (for example with cdparanoia) can interfere with multimedia programs and cause sound tracks to skip. Writing CDs is even worse because it requires the system to pay attention for a certain uninterrupted amount of time. If you only have one processor on the machine and other users decide to do something intensive while the burn is going on, the write might fail, and somebody is going to be really upset, because he just lost a blank CD.

One thing you can do is to move the CD-R/W onto a dedicated support machine (the Burner) that does nothing else. Such a machine can be set up with Jörg P. M. Haeger's http://joerghaeger.de/webCDwriter webCDwriter. It has a graphical interface written in Java and runs under any operating system with a Java Virtual Machine. This preserves the principle of encapsulation. Make sure there is nothing else on the Burner that you can't afford to use if the system is compromised. There are of course other, more primitive ways: You could export the user's home directory by NFS, which is, however, exactly the sort of thing we are trying to avoid. Or have the user create an image of the CD as an ISO file, and then let him send it to the support machine via sftp or scp. Then the user can walk over to the machine and burn it by hand.

In a family setting, none of this might be a problem. For a larger configuration, with untrusted users, it could be a big problem. You might end up telling everybody that they can't burn CDs on this system, period.

Other resources are less of a problem. Traditionally, you used a quota setting to limit the amount of disk space any single user could use. With hard disks becoming less expensive by the month, this is not much of a problem anymore, but depending on your user base, you might consider installing very large quotas just to be safe. Users, however, are easily upset by the very idea of quotas, especially if they hit their limit while most of the harddisk is still free.

The original aim of screen savers was to keep whatever was being displayed on the screen from burning itself into the monitor's phosphorous coating while you were off to the water cooler. Soon, however, clever, cute, and intricate screen savers became an end in themselves. Today's screen savers have become so resource-hungry that some actually require you to have certain types of hardware (like OpenGL support) before they will run.

If you have a mock mainframe with X Windows, you can be sure that every single one of your users will have a screen saver setup that will test the system to its limits (just for fun, log into every terminal attached to the mainframe once you have set everything up, and let each one run a different screen saver. Watch the system load while you do this. Try not to whimper too loudly). To make matters worse, some desktops like KDE let the user set the screen saver's priority. The idea is that the user can set a low priority, but in reality, they increase the priority until their jumping OpenGL balls don't jerk anymore.

Users consider playing around with their screen savers one of their basic computer rights, so just blocking everything except the "blank screen" mode can lead to people showing up in your office with pitchforks and torches. One way around this is to put a wrapper around the screen saver that makes sure the priority is set low. For example, if your setup uses the xlock command as a screen saver, you can move it to xlock.real and then create a shell script named xlock:

        #!/bin/bash
        nice -19 xlock.real "$@"

This is a very crude script, but you get the point. This lets your users keep their beloved screen savers but makes sure that the performance hit won't be deadly to the whole system.

Another annoying habit users have is to walk away from their terminals while they are still logged in. KDE and Gnome have a "Lock Screen" button right next to their "Logout" button, but you might have problems getting your users to use it, at least until the first person finds that somebody has had fun with his email account.

One way to deal with this is to have the system shut down abandoned terminals with the idle daemon, which should be included in your distribution. Use this with care: If you force a user off the system when he still has some half-written letter on his screen, he isn't going to like it. The program xautolock can be set up to invoke a screen saver or a different program after an X session has been idle for a configured amount of time.