Slashdot Mirror
FourHead: One PC, Four Users
LoganGD writes "A reseach group from UFPR university in Brazil, C3SL has managed to make one Linux box run four terminals at the same time. That means four mice, keyboards, displays and users with just one CPU. The way they managed to do that can be found at the FourHead project webpage. The fact that one computer science laboratory can suport up to 60 users whit only 15 PCs is really attractive for low-resource groups and countries."
This has been done a long time ago...i user/
http://cambuca.ldhs.cetuc.puc-rio.br/mult
But if one uses XGGI, its easy to get eight or more users on a single PC.
- A.C.
Ranging from:
'xterminals are cheaper' -- anyone care to back that up?
to:
'Windows terminal services can do this' -- don't know where to start on that one, suffice it to say: it can't.
to:
'This is just serial terminals' -- it isn't. RTFA.
I'm sure I missed a few...
"I assumed blithely that there were no elves out there in the darkness"
Mainframes used dumb terminals (that is, effectively a seperate machine connected to the mainframe via serial).
This is a standard computer handling several video outputs, keyboards and mice by itself. Just the same as any one person system, but handling multiple persons instead.
Or something.
And what if one person writes an important document and another wants to press reset?
;)
I suggest 4 CD-ROM drives and correct permissions set in fstab so everyone can use -their own- drive only
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Not exactly, they were designed for multiple users, but not multiple mouse/keyboard/screen. Actually, I'm not even sure UNIX/MULTICS were even designed to have a keyboard or a screen, let alone a mouse.
Opus: the Swiss army knife of audio codec
Just here to let you know, this 4-user setup defined in this forum's topic is using four nVidia TNT2 graphics accelerators! These are better than GeForce graphics accelerators for driver-related reasons. Way back in the maturation of XFree86, with version 3.3.6, it is possible then and a throughout the 3.x XFree86 branch to configure XFree86Config to "Load """ Utah-GLX's nvidia driver to attain hardware-accelerated openGL. This is a completly different driver approach than DRI's openGL SAL. Utah-GLX provides X Server modules rather than its various competitors providing a /usr/lib/libGL.so.* and any non-standard patch cludged into the X Server. DRI project's openGL acceleration architecture at the moment may also allow mutliple local X Servers, albeit that of the various non-XFree86 such as the capable technology at DirectFB project (which allows accelerated openGL without a X Server; directly using the DRI without an X Server).
Backtracking to Utah-GLX's driver (project page here, this will allow many complex openGL-phile programs to run at the same time given its architecture. I, however, doubt that older XFree86 3.3.6 will scale to this feat; I simply don't know. Yet, the Utah-GLX driver system has been ported to XFree86-4.x; it is a openGL GLX driver package in the form of dynamically loaded X Server modules/extensions and can be manipulated into and without the X Server without having to restart the X Server. It's somwhat parallel to the DRI driver, to provide an alternative, but it is not being maintaned anymore; Utah-GLX is dead and someone needs to commandeer!
I am using three Athlon Thunderbid 700MHz computers with a total 9 nVidia TNT2 adaptors total (three per computer), S-Video composite output to NTSC televisions, and quad-bonded 100BaseTX ZNYX LAN adaptors for verry low-latency threaded shared openGL rendering; I use as Chromium 3D videowalls, by using XFree86 4.3 and Utah-GLX's nVidia openGLX driver.
And yes, Quake3 looks hot!
If you go back some 30-35 years, you find some HUGE mainframe installations, supporting dozens or hundreds of online users simultaneously.
Do a bit more research, and you find that those mainframe installations had processors that ran at clock rates somewhere between 1 and 20 MHz, with typically a few megabytes (equivalent) of RAM, and a few hundred megabytes of hard disk. (And a few tape drives, but the tapes were not really used that much, by comparison.)
As a convenient example, consider the Control Data 6600 supercomputer at UT Austin in 1970. The CPU clock was 10 MHz, and it had just 131,072 words of main core memory, at 60 bits/word (which works out to about 1 Megabyte). It had two disk subsystems, one of which stored 168 million characters, the other storing 241 million characters.
Compare this with a 486/33, with 4 megabytes of RAM, a 200 Mb and a 340 Mb hard drive. 4 times as much RAM, probably comparable CPU throughput (the 6600 CPU was a master of parallel execution: it could be running as many as 10 instructions simultaneously).
The 6600 was heavily time-shared.
Late in the 1970s, things started getting interesting. The magic point was called "3M", which stood for "1 MIP, 1 Megabyte, 1 million pixels", and the price on that was JUST BARELY within reach of an individual.
Now look today. Our LOW END personal computers come with HUNDREDS of megabytes of RAM, hundreds of MIPS, tens or hundreds of gigabytes of disk storage, and several million pixels. (The limit on pixels is what you can get onto a display and refresh at a reasonable rate.)
What limited these guys to "only" four users per PC wasn't processing power or video bandwidth. It was the number of PCI video cards they could physically stuff into a PC motherboard.