Caolán and I have been working on prototyping a VNC based terminal
services system which also allows hot-desking.
The idea is that we allow GDM to accept VNC connections, spawn a VNC
server for each new connection and display a login screen. The user then
authenticates through the login screen as normal and GDM starts a new
session on the VNC server. However, if you then close your VNC client,
the session doesn't go away. GDM continues to manage that session.
You may then go to a different terminal, the server will spawn off a
new VNC server with a login screen through which you log in. However,
once you log in, GDM detects that you already have a session running and
switches you to your original session rather than starting a new
You could imagine terminals which are very similar to LTSP terminals,
but instead of starting an X server which queries the server for a login
using XDMCP, it starts a fullscreen vncviewer which connects to the
We've reached a stage where we can demo the basic idea, so here's the
1) On a test machine which will act as the terminal server, install
the "gdm" and "vnc-server" packages from:
Note: there are packages built against both FC2 and rawhide.
2) Punch port 5900 through the firewall on the server - i.e.
system-config-securitylevel, Other ports, "5900:tcp"
3) Reboot for good luck.
4) From another machine, vncviewer -FullScreen -FullColor myserver
5) Log in as normal, play around, start a few apps.
6) Close vncviewer (F8, Exit viewer)
7) Start vncviewer as in (4)
8) Log in as normal, you should be immediately switched back to your
+ You don't want install these packages on a machine which you need to
stay working. We're making no stability/security guarantees
+ The VNC protocol stream is unencrypted. When you type in your
password to the login screen its going across the network in plain
text. Don't test this on an untrusted network. We'll be making all
this work using the SSL extension used in Vino.
+ Right now, the client will be encoding the pixels using the "raw"
encoding. No compression, so it'll be slow. We'll be fixing that
 - http://www.gnome.org/~markmc/blog/05022004
Someone mentioned Gtk+ Event Recorder (gerd),
http://www.gtk.org/~timj/gerd/, as means of recording keyboard and mouse
input into a desktop application, so the benchmarks are run under the
same conditions. Has anyone else looked at gerd recently? Anyone know of
a version that will work on FC2?
I have played around with it a little and got it to work on RHL9 and
RHEL3, but it has problems on FC2. On FC 2 the version of gtk is newer
that what gerd can use.
I was able to record and replay events for gimp with gerd. gerd uses a
LD_PRELOAD to force a wrapper library to be loaded and record events.
Programs like ooffice and mozilla which use a shell script to start up
the program don't get events recorded. I also noticed that gerd also
records the delays of moving the mouse. For benchmarks it would be
desirable to have things selected as quickly as possible rather than at
the rate the user selects them.
Another suggestion is to make use of the accessiblity layer to allow a
benchmarking program to know when a menu is available. Is there an
ordering of between screen and accessibility layer events? Screeen is
always updated before information is sent to accessibility layer?
Information always sent to accessibility layer before screen update? Or
a race coding and no ordering is guaranteed. For the benchmarking it is
rather important to know what order they occur. If the information is
sent to the accessibility layer before the screen update, then the work
for the screen update will not be counted.
How hard would it be to assign sub-application-granularity "blame" for
all the memory used by a full desktop (GNOME+Evolution+Mozilla+OO.org)?
5M sum of per-app icon theme caching
5M sum of per-app base gtk_init() overhead
10M sum of per-email data in Evolution
7M base evo overhead with no mail loaded
30M sum of all executable pages (libraries and binaries)
i.e. try to get an idea of where focused optimization could have the
most impact on the desktop overall - what percentage of TOTAL memory
usage for the whole desktop can be blamed on each optimizable item, with
sufficient granularity to be useful.
I am thinking about ways to measure the startup time for various desktop
applications. Obviously, a common one used is how soon after a menu item
is selected can I do something in the application. However, this does
not lend itself to being automated.
I assume that most of the applications can be launched from a command
line. Are there applications or applets that are started from the menu
and do not have corresponding command line invocations?
How similar are the gnome applications in startup? Do they use the same
set of libraries? Would it be possible to have instrument a function in
a common shared library that generally indicates that the application
has initialized everything and is just waiting for the user to do
something? If there is a common function could do something like:
command-line invocation of application
<bunch of application initialization>
<call library function that indicates application is running>
<key function notes time, shutdown profiling>
Arjan asks that we move everything to use libasound rather than esound
or OSS. Because ALSA lets multiple apps output sound at once, esound
isn't really needed; the only functionality we lose is that remote apps
can't play sound on the local system, but that functionality was pretty
hosed with esound anyway.
I don't have a sense of how many things are accessing OSS/esound
directly, or how much work is involved here.