<snip>
> Do we go on maintaining a set of patches
> for this project as the main development progresses? Or do
> we submit our patches to the author with an explanatory
> email and get them accepted into the main source?
</snip>
*** Submit to the author would be more favorable :) The patches are quite
simple and the author could have put them in in less than 30 minutes but
as Jim suggested the code was a little hard to follow. I spent most of my
time trying to follow program flow (The fact that it is an event-driven
C++ program didn't help much either!)
> Obviously, the latter option is preferable as it requires
> (almost?) no ongoing effort to maintain the desired
> functionality. Hopefully the author will accept these
> patches. Has anyone contacted him yet?
*** I haven't but anyone is most definitely welcome to do so.
>
> This didn't exist in the original version? Maybe I'm
> confusing two projects, but I thought it looked for a
> global config file in <prefix>/etc/ (default
> /usr/local/etc/). But whatever program I'm thinking of
> also allowed user-specific .x0rfbserver files to override
> the global config file, the opposite of what your patch
> accomplishes.
*** Exactly, the norm is the ~/ takes priority over global in most
programs but in this case I didn't want that.
> Anyhow, my take on this is that the file does not belong in
> LTSP's root directory. It either belongs in
> <ltsproot>/etc/ or in <ltsproot>/usr/X11R6/etc/ (if this
> dir exists).
*** Yeah I figured people would want to move/rename that file. Easy to
do. In x0rfbserver.cc the very first line:
#define GLOBAL_RFB_CONFIG "/.x0rfbserver"
can be changed to whatever. ie:
#define GLOBAL_RFB_CONFIG "/etc/x0rfbserver.config"
Remember the path is relative to the root of the client. So in my case the
above file would be stored
in: /tftpboot/lts/ltsroot/etc/x0rfbserver.config
> Or perhaps Jim's new system under 3.1 will provide a better
> way. I believe he specifically implied that it would.
*** It definitely would be better.
> So, can you please look into memory usage by x0rfbserver?
> This is great news about the light CPU-usage aspect, but
> that isn't my primary concern. If it likewise has a small
> memory footprint, however, then this thing is a godsend!!
*** Tests show while waiting for a connection:
cpu usage: 0.0 %
RSS: < 2K
while 'shadowing':
cpu usage: varies depending on screen update complexity
RSS: < 10k
So it appears light weight. I've installed this -stealth version in one of
our LTSP schools which has a very heavy usage. I'll hear from them if
there is any adverse affects but my preliminary tests shows they won't
know that it's there.
> Thanks for spending a Saturday on this! I hope you didn't
> miss too nice of a day outside... :-)
*** It rained :( but it's a beautiful day today :)
> Jason
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
>http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help, try #ltsp channel on irc.openprojects.net
>
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.openprojects.net
