On 6/6/2013 5:15 PM, Michael Haberler wrote:
> very interesting writeup! very much in line with my observations
>
> I have so far run with a remote X display directly (i.e. without ssh
> tunneling) by setting DISPLAY on the bb and enabling connect on the X server,
> so no sshd overhead but more involved startup
Because X11 Forwarding works so reliably, is so easy to set up, and is
so "the right thing to do" for people who worry* about network security,
I just use it automatically. This is my first situation where its
performance became an issue.
For those who want to run in what I called "naked" X11 mode, there's a
bit of magic needed if you are running your XServer on Ubuntu. Not only
do you need to allow it to accept X connections, typically by invoking
'xhost <XClient hostname/IP>' or 'xhost +' if you are lazy, but you also
have to set it to allow connection via TCP. Ubuntu (well, actually
Gnome) makes this unaccountably hard in its attempt to do everything for
you. The traditional setting in /etc/X11/xinit/xserverrc is overruled by
a setting in gdm.schemas.
You can prove this by changing xserverrc to allow TCP (eg., delete
'-nolisten tcp' from the invocation) and restart gdm. Run 'ps ax' and
note that X started with the 'nolisten tcp' option despite you just told
it not to.
In Ubuntu 10.04LTS, at least, this tweak works:
In /etc/gdm/gdm.schemas, change 'true' to 'false' in the following stanza
<schema>
<key>security/DisallowTCP</key>
<signature>b</signature>
<default>false</default> <--- here I've already changed
'true' to 'false'
</schema>
Save and restart gdm using, for example, 'sudo service gdm restart'.
>
> also interesting to note - the core parts (milltask and the interpreter
> embedded therein, plus rtapi_app and usercomps) use negligable CPU compared
> to GUIs
For all my runs with the AXIS GUI, milltask was number two on the hit
parade, consuming roughly 28 percent of CPU time and 3.1 percent of
memory. With the other GUIs it was always less than 5 percent of CPU,
more typically 2-3 percent, as were hal_manualtoolc and halui across the
board. I looked at every task down to 'top' which always consumed about
1 percent of CPU and 0.3 percent of memory. I was tired and only took
the time in this first cut to report on the two that most concerned me.
Details later, maybe.
Regards,
Kent
* you can't work with computers at NIST for three decades and not be
such. We wore belts and suspenders, so to speak. Public perception was a
huge issue. By act of Congress, NIST plays a major role in computer
security research, testing, and standards in the US, culminating in the
Federal Information Processing Standards (FIPS). It just would not do
for any of us to be caught with our own pants down...and don't think the
Internet blackhats don't try. Our firewalls were/are under constant
assault and we were constantly lecturing our staff about social
engineering practices. Sometimes dumb luck carries the day. We were one
of the few major sites to sidestep the infamous Morris worm back in 1988
but only because our principal mail server was running on VAX/VMS and
not Unix. Sometimes not everyone gets the memo. Sometime in the 90s, we
got hit right between the eyes by a vulnerability in Sun Solaris because
we had Suns running on an experimental ATM (asynchronous transfer mode,
not a cash machine) network connecting us by optical fiber to several
universities. The ATM network bypassed the firewall. The Suns involved
were all supposed to be in a DMZ, but dualhoming with the regular
network was not unheard of. Naturally, security audits got more
draconian. Designing, building, and maintaining an electronic condom is
tough business.
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
