[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Booting older thin clients



Be sure, be sure you get TeacherTool (fl_teachertool) completely working before you do your demo; it mostly works out of the box but there are some additional steps you have to do manually to allow the teacher to monitor, control, broadcast to, and spotlight the students' client machines. It's a great WOW! piece for demos that really grabs people's attention. Teachers love it and so do admins.

The extra steps for TeacherTool aren't hard, they just can't be done automatically by the installer. You can find them on Robert's FL_TeacherTool page at http://www3.telus.net/public/robark/Fl_TeacherTool/

Petre

Kemp, Levi wrote:
Your right Petre, one step at a time. I'm actually on the Server right now and rather liking it. I can see this system supporting multiple requests for the same program, considering that what students usually do. The same assignments mean doing research, writing, etc at the same time. Ok, thanks again for the help on this. I'm going to get this small demo setup and hopefully present it by next week.

Levi

-----Original Message-----
From: k12osn-bounces redhat com on behalf of Petre Scheie
Sent: Thu 3/1/2007 4:27 PM
To: Support list for open source software in schools.
Subject: Re: [K12OSN] Booting older thin clients
Depends on what you mean by 'other systems'. If you use two NICs in the server, one for the clients, one to connect to the school network, then no, you won't have any trouble, since the server's DHCP server only hands out addresses on the NIC for the clients. But if you'll be putting your clients and server(s) all onto the schools main network, you will have problems with multiple DHCP servers handing out addresses. This is still manageable, but you have modify the ranges of addresses that each server gives out, and you might have clients connecting to different servers at each boot. Since you're new to this, I suggest keeping each room's client computers on a private network, and connect only the LTSP server to the school's existing network, just for simplicity. All the client machines will be hidden from the school network, and the server will handle all the internet-bound traffic via NAT.

Petre

Kemp, Levi wrote:
Thats what I wanted to here. Another quick question, does the location of the K12LTSP server in the network matter? I'm asking because for the demo I'm wanting to spread some out. One in the library, and one both labs. I swore I read recently here that the other systems would just ignore the boot info being put out right?
Levi

________________________________

From: k12osn-bounces redhat com on behalf of "Terrell Prudé Jr."
Sent: Thu 3/1/2007 11:38 AM
To: Support list for open source software in schools.
Subject: Re: [K12OSN] Booting older thin clients


James P. Kinney III wrote:
	On Thu, 2007-03-01 at 10:51 -0600, Kemp, Levi wrote:
		Ok I have to ask at the risk of sounding ignorent. I asumed that Linux
		was going to be running a great deal faster on some of my older
		systems than it is. Maybe its the hardware, or it could be the setup.
		I havn't set them up as diskless yet because we need to familiarize
		ourselves with everything first. Aside from that we have a lot of
		Compaq iPaqs 450Mhz with Ram ranging from 128 to 256. They are PXE
		capable but right now I'm running it off the local HD, varying amounts
		20GB 40GB and 80GB, all Western Digital 7200RPM drives. They don't
		appear to be doing much better then XP is and if I can't show that it
		will be worth it I won't be able to get the Admin to move on the
		project. Any suggestions? Should I just set up a diskless and see for
		myself?
Levi
		
	There are many factors that determine the felt speed of the system. The
	greatest factor is RAM. If the system has minimal RAM (128MB is
	considered minimal) then heavy environments like gnome and KDE will feel
	sluggish.
	
	Now add that these are older IDE drives that have slow IO and very slow
	CPU speeds.
	
	So as far as running these old boxes as desktops, they will be slow
	since they are underpowered.
	
	But using them as thin clients eliminates most of these issues. All of
	the computational work gets done on the _server_ and the load on the
client is minimal. 128MB RAM is just fine as well as the 450MHz CPU.
	The key there is the server has some CPU horsepower and RAM. All the
	client has to do is spit bits on the screen.
	

And that's why my Pentium-166 thin client feels like a dual-Athlon machine.  My K12LTSP server is the dual-Athlon.  Everything (Firefox, OpenOffice.org, KDE/GNOME, etc.) runs on the dual Athlon, not on the Pentium-166.  It's basically a graphical dumb-terminal, like back in the mainframe "green screen" days.

I agree with James; don't try running those old boxes as standalone "fat clients" like you used to do with Windows 98.  The only way that would feasibly work is if you use a "micro" GNU/Linux distribution like Damn Small Linux (yes, that's its official name), which fits on a 50MB mini-CD.  But that probably isn't what you're looking for.

Go ahead and set up diskless.  That's the way you run LTSP/K12LTSP anyway, so that's the proper demo to have.  Whenever I demo K12LTSP, I *always* go diskless + server.

--TP



------------------------------------------------------------------------

_______________________________________________
K12OSN mailing list
K12OSN redhat com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

_______________________________________________
K12OSN mailing list
K12OSN redhat com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>


------------------------------------------------------------------------

_______________________________________________
K12OSN mailing list
K12OSN redhat com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]