Programming language

James Robertson jwrober at linuxfromscratch.org
Tue Feb 1 10:33:08 PST 2005


Gerard Beekmans wrote:
> On Tue, 2005-02-01 at 08:30, James Robertson wrote:
> 
>>new tool is programmed in.  I just want it to work.  Here are my
>>thoughts on the matter to start discussion.
> 
> <snip>
> 
> I would choose plain old C for the server too. It doesn't do anything
> fancy: listen on a port for a TCP connection, authenticate, validate,
> run whatever it's given without question.

That was my thought exactly.  The daemon on the server is the grunt 
worker, so speed/stability is of the essence.

> The client is where we need the GUI the most. Taking my own dozen system
> scenario as an example again, an overview of the status of each system's
> installation would be beneficial. Now I don't really care myself how
> it's done. Ncurses works for me. A nice QT application would provide
> additional eye candy. But aside from eye candy a GUI interface that QT
> can provide might be nicer to work with than a console only version.
> This is like discussing vim vs emacs so I won't go down that path.

That is what I was alluding to in my first post.  The SRS does not 
specify exactly what the client is programmed in or how eye-candy-rich 
it is.  ncurses is ok for me as well for console stuff.  I do like nice 
X GUI's, so if one is written, then QT is probably the way to go.

> But we want the server process to be fast and responsive. Not every
> system will be a 3 GHz system out there. Python and Perl speeds might be
> circumspect on the slower machines. Then again..if it takes a minute to
> start a server process...compared to a build that would take 20 hours,
> would anybody care?

That would be me.  My lab is really old PII's (running at 233MHz). 
Currently a build takes right at 12/13 hours - not too bad considering. 
  I do want the server process to be speedy however and minimize the 
overhead it adds to the system when I really want as much horsepower 
reserved for compiling. not for daemon stuff.

James



More information about the alfs-discuss mailing list