[sf-lug] Diskless Workstation/Fat Client

Tom Haddon tom at greenleaftech.net
Tue Oct 2 16:24:57 PDT 2007

On Tue, 2007-10-02 at 15:57 -0700, Christian Einfeldt wrote:
> hi 
> On 10/2/07, Tom Haddon <tom at greenleaftech.net> wrote:
>         On Tue, 2007-10-02 at 15:31 -0700, Christian Einfeldt wrote:
>         > hi
>         >
>         >
>         > We have a mix.  All of our clients have hard drives, but
>         some of them
>         > have Windows 98 installed on the HDs, simply because we have
>         not been 
>         > able to get any Linux live CDs to boot on those systems for
>         the
>         > purpose on installing to get a swap partition.  But I would
>         definitely
>         > recommend that you have HDs and that you install Linux
>         natively on 
>         > each HD so that you can get a swap partition in the event
>         you exceed
>         > the memory capacity on individual systems' RAM.
>         Hi Christian,
>         By "Fat Client/Diskless Workstation" I don't mean a fully
>         operational OS 
>         installed on the local disk. I mean the OS is installed on the
>         server,
>         you boot from the network and then mount the root filesystem
>         from the
>         server - effectively your hard disk is on the server but all
>         other
>         resources (RAM, CPU, display, etc.) are being run from the
>         local
>         machine.
> Right.  That is actually the same thing here.  All of our machines PXE
> boot from the server.  But the server knows that it can use the swap
> from the local HDs if necessary.  And, of course, each client runs
> enough of a basic kernel to use the local resources, but otherwise all
> of the work of individual apps, such as OOo and Firefox are run
> centrally on the server, with only X and a few other basic things
> running locally on the clients.  At least that is how I understand
> it. 

I don't think we're quite on the same page. I still think from what
you're saying that you're using a standard Thin Client (albeit
supplemented with local swap) installation. We're not talking about Thin
Client, we're talking about Fat Client (also know as Diskless
Workstation, which is a little misleading, because Thin Client is also
diskless workstation). The main difference is that Thin Clients are
using the hardware resources (CPU, RAM, Disk, etc.) of the server. Fat
Clients are only using disks off the server but are using their own
local RAM/CPU for all application/OS processing. Of course, Thin Clients
are using *some* local resources to be able to connect to the Server at
all (very minimal), but the key difference is with a Fat Client when you
open a browser (for instance) it's loading into the RAM on the local
workstation and using the local workstation's CPU to do so. In a Thin
Client Setting the RAM and CPU used to do this is all on the server.

Thanks, Tom

>         I think from what you've said here, you're using Edubuntu in a
>         Thin
>         Client setting (and then some machines non-Edubuntu for the
>         reasons
>         outlined above). 
> No, about 17 or our 23 main clients are running Ubuntu locally on the
> individual client HDs.  The server (running Edubuntu) can use the
> Ubuntu swap partition on those client boxes. The remaining 6 or so
> boxes are effectively just dumb PXE terminals, because those HDs have
> Windows OSes, and hence no Linux swap. 
> My only point here is that, if possible, it is a good idea to get
> small HDs and install Linux on them so that the server can use local
> swap on the clients if need be. 
>         We're not trying to go that route because our server
>         doesn't have sufficient resources and our clients have much
>         better
>         resources (relatively speaking).
> Right, so you would probably want to be able to install Linux on those
> clients, and then the server will use the local swap, in the event
> that the RAM is exceeded. 
> I know that Steve Hargadon of TechnologyRescue.com swears by diskless
> clients, but we have experienced some lag in OOo's performance with
> that set up.  Some of that lag was solved by simply rebooting the
> server (which had run continuously for some 500 + days at the time the
> lag appeared !!), but not all of it.  

Tom Haddon
mailto:tom at greenleaftech.net
m +1.415.871.4180

More information about the sf-lug mailing list