desktop June 2004

desktop@lists.stg.fedoraproject.org

33 participants
15 discussions

terminal services prototype
by Mark McLoughlin 05 Jun '04

05 Jun '04

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

10 29

replaying mouse and keyboard input for benchmarks
by William Cohen 03 Jun '04

03 Jun '04

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

1 0

memory profiling
by Havoc Pennington 02 Jun '04

02 Jun '04

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

4 3

Desktop application start up indicators
by William Cohen 01 Jun '04

01 Jun '04

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

4 5

sound subsystem
by Havoc Pennington 31 May '04

31 May '04

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

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop June 2004