Client/Server - please straighten out the terms

Jeremy Huntwork jhuntwork at
Wed Feb 2 11:45:07 PST 2005

Jeremy Utley wrote:

> Randy, what he's talking about is one machine, connecting out to a bunch 
> of daemons simultaneously, and directing them, instead of having 
> multiple clients connecting in to a central server, grabbing the profile 
> from the central server, and acting on their own.  It's backwards, if 
> you ask me.  The machine you're building LFS on, you know you must have 
> physical access to it (otherwise, how would you get the ALFS program 
> going in the first place?).  In the model these guys are describing, you 
> have to have physical access to the server as well.

J, what you've described is basically just a file server for profiles. 
We've already got that. What we're after is a way to administrate remote 
LFS builds or as Gerard brought up, updates of remote machines.

Really, the model we're after is just a separation of the ui from the 
parser/validator/builder. They are linked via a communication protocol. 
Doing it this way, you can now open up a 'client' or ui for alfs and 
connect it to a daemon - it doesn't matter if that alfs daemon is 
running locally or remotely.

In a network environment like what Gerard describes, this becomes useful 
because an adminstrator can install the alfs daemon as a service on each 
of his machines and remotely monitor installations or upgrades on all of 

Jeremy H.

More information about the alfs-discuss mailing list