terminal services prototype
by Mark McLoughlin
Hey,
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
session.
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
server.
We've reached a stage where we can demo the basic idea, so here's the
results:
1) On a test machine which will act as the terminal server, install
the "gdm" and "vnc-server" packages from:
http://people.redhat.com/markmc/terminal-services-demo
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
original session.
Caveats:
+ You don't want install these packages on a machine which you need to
stay working. We're making no stability/security guarantees
whatsoever yet.
+ 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[1].
+ 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
soon too.
Cheers,
Mark.
[1] - http://www.gnome.org/~markmc/blog/05022004
19 years, 10 months
replaying mouse and keyboard input for benchmarks
by William Cohen
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.
-Will
19 years, 10 months
memory profiling
by Havoc Pennington
Hi,
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)?
Something like:
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.
Havoc
19 years, 10 months
Desktop application start up indicators
by William Cohen
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:
start profiling
note time
command-line invocation of application
<bunch of application initialization>
<call library function that indicates application is running>
<key function notes time, shutdown profiling>
-Will
19 years, 10 months
sound subsystem
by Havoc Pennington
Hi,
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.
Havoc
19 years, 10 months