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"
That's not completely true. Since I'm not a Linux user, I'm not sure what kind of power a box would require to run something like this, but CRTs are only $100-150. Correct me if I am misspeaking, but I don't think you can buy a tower for anywhere near this price. The keyboard and mouse are pretty inexpensive. Would the video card have to push a lot of processing power? If so, maybe that's where the cost would even out, since there's so many video cards out that cost nearly as much as whole systems.
Thank you everyone.
And I did in fact miss the whole point of the article, my bad.
Yo Grark
Canadian Bred with American Buttering
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
Well, you can, but it's third party, very hardware specific and leaves you stuck with M$ XP. The Linux system demonstrated is a clear winner for schools, libraries, banks, casinos and other places where economical use of hardware is desired. While the Linux system might be difficult to maintain, it can be done. The Windoze solution leaves you dependent on the vendor. The people at Jetway have done an outstanding job but such is the world of proprietary software.
Anyone know of a better system? If you say citrix terminal services, I say, Linux Terminal Project and, cool as those things are, get thee back to 1975.
Friends don't help friends install M$ junk.
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
multiple comments that mention this was being done for years are all true - for Linux. Serial terminals, remote X access, VNC, network boot, diskless workstations, all that stuff depended on ancient (though still great) UNIX multi-user multi-session framework - multiple users work on the same machine at the same time.
And now Microsoft woke up.
After NEXT, GECOS and a couple others, PC has a GUI! Windows 1.0! Years after Amiga with real multitasking introduces Task Switching and later ('95) first Multitasking. Then the puny '98 "multi-user" (Amiga had that some 5 years earlier, UNIX machines way before that). And now, in 2004 we hear that after users of XP are tired of the pseudo-multisession of Switch User, SP2 is to include REAL MULTISESSIONING! Yeah, right! Two users can work on the same computer at the same time! Yay!
Noticed the catch? The keyword is "two". Yeah. Two sessions ought to be enough...
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Svetoslav Slavtchev has written a HOWTO that is part of the LDP. Link to the HOWTO.
These days you might as well use the 2.6 kernel for new setups, but if you really want to use 2.4 or are modifying an older system, the Backstreet Ruby patch is a backport for 2.4. Link to Aivil's Backstreet Ruby mirror
I have looked at this... the problem is the way Linux handles the keyboard... To Linux, all keyboards are the same. If there was some way to either tell X to ignore all KBs except some, or have the kernel map them (say /dev/input/kb0 /dev/input/kb1) similar to how mice are done, this would not be a problem at all.
Ah, young Jedi, but there is a way...
Ruby, or Backstreet Ruby.
Note that this was in the article, though the link for Backstreet Ruby here is down - probably Slashdotted.
Beauty of open source. Where there's a need, someone has found a way.
Are you talking about PCI Express cards (which is not PCI-X)? Do they make PCI-X graphics cards?
PCI-X is 4.3 GB/s (maximum!), and AGP 8X is 2.1 GB/s. Four graphics cards talking on a PCI-X bus would probably saturate it, especially given that it's shared-bus, so the number of bus arbitrations would be huge.
PCI-Express is point-to-point, so provided you could find a motherboard with 4 x16 links (good luck!) or at least had 4 x16 slots (again, good luck) you could do it.
But a 4 processor motherboard with 4 x16 slots doesn't exist right now (it'd be a *huge* motherboard!), so no, you can't do it.
My machine has been running for a few weeks and is not noticeably hot, however they are not the latest state of the art graphics cards, especially the PCI one which I found difficult to obtain. I would like to get a twinhead PCI to have 4 monitors, but they are rarer than hen's teeth in the UK.
BTW the graphics setup is OK in Linux or FreeBSD, once the Nvidia drivers are loaded, and with SuSE you must forget all about SAX and edit XF86Config by hand, as per the comprehensive info from Nvidia. The same file, with possibly minor tweaks can then be ported across to the FreeBSD partition, and the FreeBSD version of the Nvidia driver loaded, for those who want to dual-boot it with two decent OSs.
BTW I did this just to get lots of working space on my screens, 3 cheap LCDs at 1280*1024, great for programming and debug, and whatever else you need to do at the same time such as reading manuals, but takes less desktop than the two 1600*1200 CRTs I had contemplated. The Athlon is nothing special, 1600+ I think (not at that machine right now) but it has 2 HDDs, / on one, swap on the other, the usual speedup trick, not that it needs much swapping with 768MB RAM. Definitely not a top performer or games machine, but it works great, and most of the cost was the monitors.
This concept would be great for schools, it may be how Linux or BSD, or both, can make serious inroads into a big market, currently filled by the Criminal Monopoly. I think 6 screens might just about be viable with a top of the range Athlon, and some extra fans in the case, but I will not be building one of these for myself, it would be very OTT.
It is going back to the mainframe in a sense, but in areas where maintenance of the software is a major burden, this reduces that by a factor of 4, approximately. I would love to see this concept trialled in schools in the UK, it could free up money to be spent on other important things. If using a fairly basic PC, and cheap CRT monitors, it ought to be possible to get the cost to a very competitive level indeed, with no extortionate licence fees to you know who.
I t would also be good in offices where they do mainly word processing, hardly a heavy load, one PC for 4 secretaries.....
My 3-head monster has spare disk partitions, but I have not dared to try loading my redundant copy of Windoze 2000. It is rock-solid in Linux, FreeBSD is getting there (I am using 5.2.1 which is not a "stable" version, and have lots of apps loaded, so there is still a bit of tweaking needed, although the GUI etc are solid.)
Just had a thought, did Matrox not do a 4-head AGP card some time ago? Maybe that would do the job also, and leave slots free. I hope we are going to hear more of this sort of thing, on one front we have those who need, or want, performance goimng for multiple CPUs, all the way up to Beowulf clusters, and on the other hand the economy version has several users on one PC. Now whose OS is the scaleable one? Here is the proof!
That's the spirit. Why don't you submit your little tool to sourceforge.net or freashmeat.net so that people looking for it have a better chance of finding it? All you need to do is enter it as a 'project', make a little page with the text of your post here as a description, a link to that page, and in case your webserver ever goes offline, upload it to sf.net.
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!
Mandrake 10.0 allows you to run multiple X sessions out of the box. Maybe you should look at it. It is really cool.
Oh well, what the hell...
I have a multi-user setup at home (I'm using it right now) which is described here... it has 3 heads (video/keyboard/sound/mouse for each). I've found it to be an economical approach that involves far less administrative work than any other multi-user configuration -- separate systems with NFS file shares, X terminals, you name it.
There are several significant challenges involved in setting up a multi-head, multi-user system:
The 'normal' kernel USB setup merges multiple keyboards and mice into a single queue. This makes sense when you're using an external keyboard and mouse with a laptop, but it a pain in MHMU. Patches to the USB system are required.
The 'normal' console/virtual terminal system is not MHMU-aware. This has to be patched with the Backstreet-Ruby patches to work properly.
The 'normal' X server can handle a multi-head configuration, but expects all the heads to be used by one user. The prefbusid patch or similar must be applied to fix this.
Apps that use sound are a nightmare-- it's painful trying to get apps to send their sound to the right speakers. With three of us on the system, I regularly get blasted by sound from Flash websites that my kids are visiting. There is no standard for defining *where* sound should go -- yes, there are soundservers such as esd and artsd, but they are not used by all apps (and try finding current documentations for esd!).
If we made a concerted effort, the MHMU patches could be merged into the main source trees for X.org and the Linux kernel, and the distros could be set up to offer MHMU configurations at installation time.
However, the number of people using MHMU configurations is currently too small to really make a push for the integration of these features into the main source trees and distros.
So if you're using this type of system, or would find it beneficial, then let's work together to make this a mainstream option!
(I think that MHMU would be useful for: tellers in banks; kiosks such as library catalogs; computer labs and learning commons in colleges and universities; and family computing setups).
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.
My very first home computer was a Radio Shack TRS 16B+ in the mid 1980's.
It had a Z80 CPU to handle I/O housekeeping chores and an MC68000 main CPU running XENIX (a flavor of UNIX).
It supported four users at the same time - each at their own terminal - with no additional goodies needed at the 16B+.
Mine did have a full load of memory, a larger hard drive, and a few Hayes modems so the other users could be remote, but the modems hooked right into the existing multiple ports on the machine.
For several years it was a minor mail and news server on the web (named tijil).
In what major way it this "new" thing astonishingly different from what I had 20 years ago on my desktop at home?
Take care,
Tomas
There is a US mirror.
Brain is my second favorite organ.
Nevertheless, it should be noted that Ruby needs to be grabbed from CVS, some instructions here. Most of that is about the 2.4 backport, called backstreet ruby, but you'll get the 2.6 code along with it.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
admittedly this is nothing new, but you seem to overlook that this is also possible on those "free" machines
in college (back the 80's) we used to run comparable multi-head (usually twin or triple) 386/486 boxes
not so hot for rendering, but great when everybody needs to type a term paper at the same time
Even if you insist on running a pointy-clicky GUI, with X10 we used to run dozens of graphics terminals off of one VAX
Yes, but the X server was running on the terminals. The X apps running on the VAX only sent X primitives down the wire to the terminals, and the terminal bore the burdon of rendering stuff on the screen and processing kb/mouse input, turning them into events to send down the wire back to the app running on the VAX.
This article is about plugging the monitors/kbs/mices directly into the box with the X primitives processed on that box.
Think about the difference for a while before you reply to this.
You make the mistake of thinking you can educate the fundamental stupidity out of people. You can't.