RTAI, Realtime Linux
Okay. (But you don't mention just what "low resources" means, leaving anyone who responds to make buttumptions that are almost certain to be wrong.) Then don't run X...
It has been around for several years now. It is fairly popular for embedded control applications (robotics, data acquisition, things like that). There's another one called RTLinux that provides roughly the same features.
RTAI and RTLinux provide a small kernel that sits "below" Linux. The main Linux system essentially runs as the idle task of this kernel. The small kernel provides things like guaranteed worst-case interrupt latency and low-jitter timing.
You can run an xterm without a window manager, but when you call an X app from it...
It depends on how X is started. If you're using xinit, then it starts X, reads shell commands from .xinitrc...
Linux typically makes no guarantee about worst-case timing, only average throughput. The RT kernel does make such guarantees. This is not necessarily a good thing for general purpose use. For instance, a high-priority app that wants to hog the CPU can prevent anything else from running, but for some applications it is a requirement.
Real-time tasks run under the control of this kernel rather than the normal Linux kernel. Methods (shared memory, fifo's, etc) are provided to communicate between real-time tasks and normal Linux processes.
The use of it is for applications that specify hard deadlines (specs like "the servo loop must run every X +-- Y microseconds and must complete within Z microseconds") but also have a substantial non real-time component (user interface, data logging, web server, whatever). The realtime stuff runs directly under the control of the real-time layer, while the user interface and so forth are normal Linux programs.
This stuff is only of use for programs that are written to take advantage of it, which tend to be rather specialized. It is not going to make Quake run any better.
-- - Bob Hauck - A proud member of the reality-based community.