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.
> 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.
More information about the alfs-discuss