From notting at redhat.com Tue Jun 1 04:08:02 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 Jun 2004 00:08:02 -0400 Subject: sound subsystem In-Reply-To: <1086030233.21727.132.camel@localhost.localdomain> References: <1085951610.21727.114.camel@localhost.localdomain> <20040531033627.GB26730@nostromo.devel.redhat.com> <1086030233.21727.132.camel@localhost.localdomain> Message-ID: <20040601040802.GE4309@nostromo.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > On Sun, 2004-05-30 at 23:36, Bill Nottingham wrote: > > Well.... ALSA by default only lets multiple apps output *up to the > > number of HW channels the card has*. > > I've been told that all interesting cards have at least 2 channels > (maybe more?) Not really. Cards are getting dumber, not smarter. Especially in the boring desktop audio space (think i810_audio.) > > Doing more requires configuration. > > Configuration we can do by default? Potentially. Bill From wcohen at redhat.com Tue Jun 1 15:19:51 2004 From: wcohen at redhat.com (Will Cohen) Date: Tue, 01 Jun 2004 11:19:51 -0400 Subject: Desktop application start up indicators In-Reply-To: <1085928357.29803.3.camel@localhost.localdomain> References: <40B7A382.6010809@redhat.com> <1085908878.8132.8.camel@localhost.localdomain> <1085928357.29803.3.camel@localhost.localdomain> Message-ID: <40BC9E97.8060503@redhat.com> Owen Taylor wrote: > On Sun, 2004-05-30 at 05:21, Mark McLoughlin wrote: > >> I'm not sure there is a reliable way to detect when an application has >>finished startup. Perhaps the first time the main loop goes idle would >>be a good indicator but I think you have difficulty distinguishing >>between that case and the case of the app blocking on the result of a >>CORBA call. > > > For nmany applications, a pretty good good (intrusive) way to figure out > when the app is up on the screen and painted is to put > a g_idle_add() into an expose handler; applications will typically > handle all exposes before going idle again. > > >> To give you an idea of where a GNOME application starting up spends its >>time see this: >> >>http://mail.gnome.org/archives/desktop-devel-list/2004-April/msg00360.html >> >> The only things really specific to the panel in this is the loading of >>main menu and applets/launchers. > > > I believe this is 'strace -tt' measurement? My experience is that that > can be quite distorting because it greatly magnifies the per-syscall > overhead. I took the examples that Havoc posted earlier and ran them to see what kind of difference the strace made on the runtimes. Run code on 2.4GHz pentium 4 machine with FC2 displaying on Pentium III RHEL3 machine. init1 is the really short example, init2 is the longer example. The volume of output from the strace does seem to affect the timing, particularly on the second example. /usr/bin/time ./init1 >& notrace1 0.00user 0.00system 0:00.08elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+738minor)pagefaults 0swaps /usr/bin/time strace -tt ./init1 >& trace 0.02user 0.03system 0:00.10elapsed 55%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+909minor)pagefaults 0swaps /usr/bin/time ./init2 >& notrace2 0.04user 0.01system 0:00.17elapsed 33%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1265minor)pagefaults 0swaps /usr/bin/time strace -tt ./init2 >& trace2 0.08user 0.08system 0:00.46elapsed 36%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1437minor)pagefaults 0swaps The amount of data generated by the strace is significant (>200Kb/s for the second example): $ wc trace1 543 3777 42811 trace1 $ wc trace2 1282 8312 103580 trace2 I have seen some performance tools that allow insertion of instrumentation into a program by the developer after the program is compiled. One could place points to measure events without overwhelming the system with a huge amount of data. However, this requires a programmer to have some knowledge of the workings of the program or else they won't get useful measurement. For compile time instrumentation we could use the -finstrument-functions option in gcc with support functions that record when each function is entered and left. Probably only want to compile a portion of the code with this option to get an overview of where time is spent otherwise the amount of output would exceed the strace. -Will From hp at redhat.com Tue Jun 1 16:05:52 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 01 Jun 2004 12:05:52 -0400 Subject: memory profiling Message-ID: <1086105952.30757.27.camel@localhost.localdomain> 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 From wcohen at redhat.com Tue Jun 1 16:13:09 2004 From: wcohen at redhat.com (Will Cohen) Date: Tue, 01 Jun 2004 12:13:09 -0400 Subject: memory profiling In-Reply-To: <1086105952.30757.27.camel@localhost.localdomain> References: <1086105952.30757.27.camel@localhost.localdomain> Message-ID: <40BCAB15.6070804@redhat.com> Havoc Pennington wrote: > 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 > > > You could use "pmap pid" to get a coarse view of memory used by libraries and per process basis, but this doesn't handle which functions allocated the space. You could combine the data from pmap of different applications to get an overall view of space usage. I have noticed that the "-x" option doe not seem to be working on version of pmap that FC2 uses, so it doesn't provide RSS, Anon, or Locked information. -Will From alexl at redhat.com Wed Jun 2 07:22:16 2004 From: alexl at redhat.com (Alexander Larsson) Date: 02 Jun 2004 09:22:16 +0200 Subject: memory profiling In-Reply-To: <1086105952.30757.27.camel@localhost.localdomain> References: <1086105952.30757.27.camel@localhost.localdomain> Message-ID: <1086160936.25112.7.camel@localhost.localdomain> On Tue, 2004-06-01 at 18:05, Havoc Pennington wrote: > 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. I was once thinking about something like this. If you could get allocations in each source file bundled in with the other allocations from that file we'd get a pretty decent approximation of the memory use for a certain class of objects (since each GObject is typically implemented in one source file). If we also count the number of live objects of each GType and match the GType to its implemented source file we'd have pretty good data about things like average memory use for each object type, total memory use for certain object types and number of live objects of each type. This should be implementable if you turn g_malloc into a macro that expands to something with __FILE__ in it, altought it would require us to rebuild the whole stack with this macro defined. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a globe-trotting guitar-strumming astronaut gone bad. She's a bloodthirsty paranoid pearl diver married to the Mob. They fight crime! From sandmann at redhat.com Wed Jun 2 13:27:25 2004 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: Wed, 02 Jun 2004 15:27:25 +0200 Subject: memory profiling In-Reply-To: <1086105952.30757.27.camel@localhost.localdomain> References: <1086105952.30757.27.camel@localhost.localdomain> Message-ID: <1086182845.4211.55.camel@localhost.localdomain> On Tue, 2004-06-01 at 18:05, Havoc Pennington wrote: > 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 don't think people agree with me, but in my opinion it is important to measure the working set. A program can malloc() 500 MB and then just sit in poll() never touching that memory. An approach that could give you something close to what you are after is to LD_PRELOAD a new malloc() for the entire desktop and have that new malloc() report a stack trace to another application that could then process the data: - Calculate the total amount of memory used by applications: sum of all mmap()ed pages in physical RAM + sum of all anonymous pages in physical RAM where "sum of all anonymous pages in physical RAM" is calculated by for each application subtracting the number of mapped pages in RAM from the RSS. - Report like memprof does now, the amount of memory allocated by a function and its children. Divide all numbers by the total amount of memory used. The amount of memory used by mmap()ed files is easy to measure: - scan /proc and build a list of mmap()ed files - mmap() of those files - use mincore() to find out how many pages of those files are actually in RAM. (I have a program that does this somewhere). > 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. The above might give you something like what you are after. It would be possible to report at a filename granularity instead of function granularity, which might be interesting as Alex suggested. Soeren From wcohen at redhat.com Thu Jun 3 14:27:58 2004 From: wcohen at redhat.com (Will Cohen) Date: Thu, 03 Jun 2004 10:27:58 -0400 Subject: replaying mouse and keyboard input for benchmarks Message-ID: <40BF356E.5090300@redhat.com> 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 From markmc at redhat.com Thu Jun 3 17:11:28 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 03 Jun 2004 18:11:28 +0100 Subject: terminal services prototype Message-ID: <1086282687.23702.44.camel@localhost.localdomain> 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 From skvidal at phy.duke.edu Thu Jun 3 17:33:36 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Jun 2004 13:33:36 -0400 Subject: terminal services prototype In-Reply-To: <1086282687.23702.44.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> Message-ID: <1086284016.3424.6.camel@opus> On Thu, 2004-06-03 at 13:11, Mark McLoughlin wrote: > 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. How are you handling device ownership for the hosting machine? I presume the vnc-connected hosts are not getting perms to cdroms and soundcards and what-not. Will any of this be functional to implement limited user-session switching a la XP or OSX? Thanks, -sv From markmc at redhat.com Thu Jun 3 17:49:05 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 03 Jun 2004 18:49:05 +0100 Subject: terminal services prototype In-Reply-To: <1086284016.3424.6.camel@opus> References: <1086282687.23702.44.camel@localhost.localdomain> <1086284016.3424.6.camel@opus> Message-ID: <1086284945.23702.72.camel@localhost.localdomain> Hey, On Thu, 2004-06-03 at 18:33, seth vidal wrote: > How are you handling device ownership for the hosting machine? I presume > the vnc-connected hosts are not getting perms to cdroms and soundcards > and what-not. I haven't even thought about it to be honest, but its all handled by pam_console, right? And with a VNC session, you're not on console, so no, you don't get those perms. > Will any of this be functional to implement limited > user-session switching a la XP or OSX? I really wouldn't recommend using this on a single host - VNC over a local socket just seems like a good way to waste memory, CPU and slow down your desktop to me ... There's already user-session switching in GDM. I don't know much about it, but that's the avenue I'd pursue for this feature. Cheers, Mark. From felipe_alfaro at linuxmail.org Thu Jun 3 21:59:39 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 03 Jun 2004 23:59:39 +0200 Subject: terminal services prototype In-Reply-To: <1086282687.23702.44.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> Message-ID: <1086299979.1677.3.camel@teapot.felipe-alfaro.com> On Thu, 2004-06-03 at 19:11, Mark McLoughlin wrote: > 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. Doesn't work properly. The first time I logon it works nicely. However, I can't get back to my session once I disconnect. When trying to log in back, GDM simply hangs indefinitely. No CPU cycles are wasted. Nothing seems to happen. I'm using Kerberos V authentication, IPv6 and IPSec. Please, feel free to contact me for additional information. Thanks! From hp at redhat.com Thu Jun 3 23:16:01 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 03 Jun 2004 19:16:01 -0400 Subject: terminal services prototype In-Reply-To: <1086282687.23702.44.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> Message-ID: <1086304561.4807.84.camel@localhost.localdomain> Hi, Cool! How much work to get this to work with gdm as the login prompt instead of vncviewer, so you auth via gdm which starts a fullscreen vncviewer on the client and connects it to the server without a second login? (Ignore any naive assumptions in the foregoing...) Havoc From jspaleta at gmail.com Fri Jun 4 00:45:54 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 3 Jun 2004 20:45:54 -0400 Subject: terminal services prototype In-Reply-To: <1086304561.4807.84.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> Message-ID: <604aa791040603174541571947@mail.gmail.com> A couple of things... 1) Where should we report bugs about the demo packs? I tried the fc2 versions.... got the same problem as reported in the thread already first vncviewer connection works fine second connection i get the gdm login...enter name and pass...looks like it hangs checking the server process list..it seems gdm created a second gnome session. 2) is there a potential here to create look but don't touch vnc connections as well as full access connections? Perhaps a secondary password for look-only vnc clients? so you enter username get prompted for a password if it matches the primary password you get the full access... if the password matches the secondary password you get a look only client. Or am I just smoking some very powerful crack? -jef From rdieter at math.unl.edu Fri Jun 4 00:57:50 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 03 Jun 2004 19:57:50 -0500 Subject: terminal services prototype In-Reply-To: <1086304561.4807.84.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> Message-ID: <40BFC90E.3050100@math.unl.edu> Havoc Pennington wrote: > Cool! How much work to get this to work with gdm as the login prompt > instead of vncviewer, so you auth via gdm which starts a fullscreen > vncviewer on the client and connects it to the server without a second > login? (Ignore any naive assumptions in the foregoing...) It's pretty trivial to do that. I've got that setup for many of our boxes already. I'll give more details tomorrow, if nobody beats me to the punch. -- Rex From caolanm at redhat.com Fri Jun 4 07:31:33 2004 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 4 Jun 2004 03:31:33 -0400 Subject: terminal services prototype In-Reply-To: <604aa791040603174541571947@mail.gmail.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> Message-ID: <20040604073133.GA23527@devserv.devel.redhat.com> On Thu, Jun 03, 2004 at 08:45:54PM -0400, Jeff Spaleta wrote: > A couple of things... > > 1) Where should we report bugs about the demo packs? > > I tried the fc2 versions.... got the same problem as reported in the thread > already first vncviewer connection works fine second connection i get the gdm > login...enter name and pass...looks like it hangs checking the server process > list..it seems gdm created a second gnome session. I see some occasional fuzziness with the second or third reconnection at the moment as well, I'm looking into it at the moment. C. From markmc at redhat.com Fri Jun 4 07:43:14 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 08:43:14 +0100 Subject: terminal services prototype In-Reply-To: <1086299979.1677.3.camel@teapot.felipe-alfaro.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086299979.1677.3.camel@teapot.felipe-alfaro.com> Message-ID: <1086334994.23702.92.camel@localhost.localdomain> Hey, On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote: > Doesn't work properly. > The first time I logon it works nicely. However, I can't get back to my > session once I disconnect. > > When trying to log in back, GDM simply hangs indefinitely. No CPU cycles > are wasted. Nothing seems to happen. I'm using Kerberos V > authentication, IPv6 and IPSec. Thanks for trying it out. Very helpful ... If you switch on GDM debugging in /etc/X11/gdm/gdm.con: [debug] Enable=true you'll get some horrendous spew in /var/log/messages that we may or may not be able to make sense of enough to figure out what the problem is :-) When the greeter has finished starting up on the primary display you'll see "gdm_slave_wait_for_login: In loop". We'll want everything after that which shows the VNC clients connecting. Cheers, Mark. From markmc at redhat.com Fri Jun 4 11:23:32 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 12:23:32 +0100 Subject: terminal services prototype In-Reply-To: <1086304561.4807.84.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> Message-ID: <1086348212.23702.315.camel@localhost.localdomain> On Fri, 2004-06-04 at 00:16, Havoc Pennington wrote: > Hi, > > Cool! How much work to get this to work with gdm as the login prompt > instead of vncviewer, so you auth via gdm which starts a fullscreen > vncviewer on the client and connects it to the server without a second > login? Basically, for the terminal/client our plan is to do something very similar to GDM's auto login thing, but it would log you in as a "vnc" user with very few local privs and just run a fullscreen vncviewer pointing at the server. The vncviewer might lock the display too ... Cheers, Mark. From markmc at redhat.com Fri Jun 4 11:29:49 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 12:29:49 +0100 Subject: terminal services prototype In-Reply-To: <604aa791040603174541571947@mail.gmail.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> Message-ID: <1086348589.23702.322.camel@localhost.localdomain> Hey, On Fri, 2004-06-04 at 01:45, Jeff Spaleta wrote: > 2) is there a potential here to create look but don't touch vnc > connections as well as full access connections? Yeah, we'll have something like that. Part of Vino's preferences dialog looks like: --- [ ] Allow other users to view your desktop [ ] Allow other users to control your desktop --- and I think that's all we might need - i.e. a preference to control whether other users connecting to your session are allowed to "touch". Its not really a consideration for the terminal services use case though, just the collaboration use case. Cheers, Mark. From tjb at unh.edu Fri Jun 4 13:48:07 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 04 Jun 2004 09:48:07 -0400 Subject: terminal services prototype In-Reply-To: <1086334994.23702.92.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086299979.1677.3.camel@teapot.felipe-alfaro.com> <1086334994.23702.92.camel@localhost.localdomain> Message-ID: <1086356887.644.5.camel@wintermute.sr.unh.edu> On Fri, 2004-06-04 at 08:43 +0100, Mark McLoughlin wrote: > Hey, > > On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote: > > > Doesn't work properly. > > The first time I logon it works nicely. However, I can't get back to my > > session once I disconnect. > > > > When trying to log in back, GDM simply hangs indefinitely. No CPU cycles > > are wasted. Nothing seems to happen. I'm using Kerberos V > > authentication, IPv6 and IPSec. > > Thanks for trying it out. Very helpful ... > > If you switch on GDM debugging in /etc/X11/gdm/gdm.con: > > [debug] > Enable=true > > you'll get some horrendous spew in /var/log/messages that we may or may > not be able to make sense of enough to figure out what the problem is > :-) > > When the greeter has finished starting up on the primary display you'll > see "gdm_slave_wait_for_login: In loop". We'll want everything after > that which shows the VNC clients connecting. > > Cheers, > Mark. > > I had similar results but mine came unstuck after a short time. I was able to create two concurrent sessions and detach and attach at will. I also had someone running on the real console. This is all pretty sweet. Coupled with vino, it seems the remote desktop is being taken care of quite nicely... tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From jlaska at redhat.com Fri Jun 4 13:52:53 2004 From: jlaska at redhat.com (James Laska) Date: Fri, 04 Jun 2004 09:52:53 -0400 Subject: terminal services prototype In-Reply-To: <1086282687.23702.44.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> Message-ID: <1086357173.10345.29.camel@flatline.devel.redhat.com> Nice work! I've been looking for something like this ever since I came across `screen`. A few quick questions: - How should physical console logins and logins over VNC for the same user at the same time be handled? Should both be accessing the same VNC session? I notice that if I login on VNC, and attempt to login on the physical console...the session is not shared. This results in gnome-session and gconf getting confused. One session seems to get the *locks* for gnome-settings-daemon and uses the configured theme? While the other session defaults to the stock GNOME icon set and theme. I believe this is already a known issue with running multiple gnome-sessions at the same time. - The VNC session will not be able to do hardware acceleration? - Launching desktop screensaver preferences shows: xscreensaver-demo is running as "root" on "myserver". But the xscreensaver managing display ":1.0" is running as user "nobody" on host "myserver". Since they are different users they won't be reading/writing the same ~/.xscreensaver file, so xscreensaver-demo isn't going to work right. - The window title for the VNC session is: "VNC: x11". Probably want something more descriptive like the user name, or the host? - Perhaps a way to list *active* VNC sessions? The modified gdm doesn't appear to add entries to utmp/wtmp. Once you login, perhaps you are prompted with a dialog like: "There is already an active desktop running for $USER from $HOST. Would you like to create a new desktop, or join one from the list below?" - Should the gdm xdmcp configuration settings hold true for the remote VNC gdm mode also? Meaning, if you set the gdm theme to be the "old-style" greeter for remote consoles... Great work! -jlaska On Thu, 2004-06-03 at 13:11, Mark McLoughlin wrote: > 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 > From tjb at unh.edu Fri Jun 4 13:55:46 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 04 Jun 2004 09:55:46 -0400 Subject: terminal services prototype In-Reply-To: <1086282687.23702.44.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> Message-ID: <1086357346.644.11.camel@wintermute.sr.unh.edu> On Thu, 2004-06-03 at 18:11 +0100, Mark McLoughlin wrote: > 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 > > Could you yummify your archive so we can just point at it and get updates whenever you make them? (I realize this will probably hit rawhide at some point but I'm taking a breather from rawhide for a while between betas!) Slightly OT: Do you plan to add vino? I've got it all built (it seems to work) but I'm not sure the rpms are complete. (I had to add vino-session as a startup item.) And along the lines of a bug report, everytime a coworker runs nessus against my system, vino-server goes off the deep end eating 100% of one CPU. Other than that, it works quite well. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From tdiehl at rogueind.com Fri Jun 4 14:00:53 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 4 Jun 2004 10:00:53 -0400 (EDT) Subject: terminal services prototype In-Reply-To: <1086348589.23702.322.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> <1086348589.23702.322.camel@localhost.localdomain> Message-ID: On Fri, 4 Jun 2004, Mark McLoughlin wrote: > Hey, > > On Fri, 2004-06-04 at 01:45, Jeff Spaleta wrote: > > > 2) is there a potential here to create look but don't touch vnc > > connections as well as full access connections? > > Yeah, we'll have something like that. > > Part of Vino's preferences dialog looks like: Can someone give me a pointer to vino. Google returns a bunch of info on different wines. While I like wine as much as the next guy I doube that is what you are referring to. :-) Tom From tjb at unh.edu Fri Jun 4 14:01:23 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 04 Jun 2004 10:01:23 -0400 Subject: terminal services prototype In-Reply-To: <1086334994.23702.92.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086299979.1677.3.camel@teapot.felipe-alfaro.com> <1086334994.23702.92.camel@localhost.localdomain> Message-ID: <1086357683.644.13.camel@wintermute.sr.unh.edu> On Fri, 2004-06-04 at 08:43 +0100, Mark McLoughlin wrote: > Hey, > > On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote: > > > Doesn't work properly. > > The first time I logon it works nicely. However, I can't get back to my > > session once I disconnect. > > > > When trying to log in back, GDM simply hangs indefinitely. No CPU cycles > > are wasted. Nothing seems to happen. I'm using Kerberos V > > authentication, IPv6 and IPSec. > > Thanks for trying it out. Very helpful ... > > If you switch on GDM debugging in /etc/X11/gdm/gdm.con: > > [debug] > Enable=true > > you'll get some horrendous spew in /var/log/messages that we may or may > not be able to make sense of enough to figure out what the problem is > :-) > > When the greeter has finished starting up on the primary display you'll > see "gdm_slave_wait_for_login: In loop". We'll want everything after > that which shows the VNC clients connecting. > > Cheers, > Mark. > > Also, any way to specify the size of the vnc-server session? I have my X display set to 1600x1200 and I want the vnc session to be the same. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From jspaleta at gmail.com Fri Jun 4 14:06:35 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 Jun 2004 10:06:35 -0400 Subject: terminal services prototype In-Reply-To: <20040604073133.GA23527@devserv.devel.redhat.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> <20040604073133.GA23527@devserv.devel.redhat.com> Message-ID: <604aa7910406040706673ad7d0@mail.gmail.com> On Fri, 4 Jun 2004 03:31:33 -0400, Caolan McNamara wrote: > I see some occasional fuzziness with the second or third reconnection at the > moment as well, I'm looking into it at the moment. should have known..... i go to play with this again today, and turn on debug in gdm this time to catch the log of the problem and.... things are working... repeated vncviewer client connections and they are dropping back into the running desktop. -jef"A watched pot never boils and a watched program never bugs out"spaleta From felipe_alfaro at linuxmail.org Fri Jun 4 14:34:41 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 04 Jun 2004 16:34:41 +0200 Subject: terminal services prototype In-Reply-To: <1086334994.23702.92.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086299979.1677.3.camel@teapot.felipe-alfaro.com> <1086334994.23702.92.camel@localhost.localdomain> Message-ID: <1086359681.1677.0.camel@teapot.felipe-alfaro.com> On Fri, 2004-06-04 at 09:43, Mark McLoughlin wrote: > Hey, > > On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote: > > > Doesn't work properly. > > The first time I logon it works nicely. However, I can't get back to my > > session once I disconnect. > > > > When trying to log in back, GDM simply hangs indefinitely. No CPU cycles > > are wasted. Nothing seems to happen. I'm using Kerberos V > > authentication, IPv6 and IPSec. > > Thanks for trying it out. Very helpful ... > > If you switch on GDM debugging in /etc/X11/gdm/gdm.con: > > [debug] > Enable=true > > you'll get some horrendous spew in /var/log/messages that we may or may > not be able to make sense of enough to figure out what the problem is > :-) > > When the greeter has finished starting up on the primary display you'll > see "gdm_slave_wait_for_login: In loop". We'll want everything after > that which shows the VNC clients connecting. Whops! I have enabled debugging, rebooted the machine and now everything is working fine. I can log back to my remote sessions with any delays or hangs. I'll keep playing with this to see if it breaks or misbehaves. Thanks! From felipe_alfaro at linuxmail.org Fri Jun 4 15:04:57 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 04 Jun 2004 17:04:57 +0200 Subject: terminal services prototype In-Reply-To: <1086334994.23702.92.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086299979.1677.3.camel@teapot.felipe-alfaro.com> <1086334994.23702.92.camel@localhost.localdomain> Message-ID: <1086361496.1715.2.camel@teapot.felipe-alfaro.com> On Fri, 2004-06-04 at 09:43, Mark McLoughlin wrote: > Hey, > > On Thu, 2004-06-03 at 22:59, Felipe Alfaro Solana wrote: > > > Doesn't work properly. > > The first time I logon it works nicely. However, I can't get back to my > > session once I disconnect. > > > > When trying to log in back, GDM simply hangs indefinitely. No CPU cycles > > are wasted. Nothing seems to happen. I'm using Kerberos V > > authentication, IPv6 and IPSec. > > Thanks for trying it out. Very helpful ... > > If you switch on GDM debugging in /etc/X11/gdm/gdm.con: > > [debug] > Enable=true I can confirm that when debug is disabled, I experience the hangs I just described. However, enabling debugging makes it work flawlessly. I checked this when installing the modified gdm* and vnc* packages on a clean FC2 system: while trying to log back onto a remote session, gdm hung. However, setting debug to true fixes the problem. Curious, isn't it? From felipe_alfaro at linuxmail.org Fri Jun 4 15:17:26 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 04 Jun 2004 17:17:26 +0200 Subject: terminal services prototype In-Reply-To: <604aa7910406040706673ad7d0@mail.gmail.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> <20040604073133.GA23527@devserv.devel.redhat.com> <604aa7910406040706673ad7d0@mail.gmail.com> Message-ID: <1086362246.1715.4.camel@teapot.felipe-alfaro.com> On Fri, 2004-06-04 at 16:06, Jeff Spaleta wrote: > On Fri, 4 Jun 2004 03:31:33 -0400, Caolan McNamara wrote: > > I see some occasional fuzziness with the second or third reconnection at the > > moment as well, I'm looking into it at the moment. > > should have known..... > i go to play with this again today, and turn on debug in gdm this time to catch > the log of the problem and.... > > things are working... repeated vncviewer client connections and they > are dropping back into the running desktop. It seems to me that enabling gdm debugging makes those "problems when logging back to a remote session" fade away. From markmc at redhat.com Fri Jun 4 16:55:23 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 17:55:23 +0100 Subject: terminal services prototype In-Reply-To: <1086357173.10345.29.camel@flatline.devel.redhat.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086357173.10345.29.camel@flatline.devel.redhat.com> Message-ID: <1086368122.23702.367.camel@localhost.localdomain> Hey, On Fri, 2004-06-04 at 14:52, James Laska wrote: > Nice work! > > I've been looking for something like this ever since I came across > `screen`. A few quick questions: > > - How should physical console logins and logins over VNC for the same > user at the same time be handled? Should both be accessing the same VNC > session? I notice that if I login on VNC, and attempt to login on the > physical console...the session is not shared. Okay, what I was thinking was that if you first log in on console and then log in using VNC, you'll get connected to the console login (requires work in Vino we haven't even looked at yet). But if you log in from console, you'll never get re-directed to an existing session - it will always start a new one. > This results in > gnome-session and gconf getting confused. One session seems to get the > *locks* for gnome-settings-daemon and uses the configured theme? While > the other session defaults to the stock GNOME icon set and theme. I > believe this is already a known issue with running multiple > gnome-sessions at the same time. Right, we need a gnome-settings-daemon for each display: http://bugzilla.gnome.org/show_bug.cgi?id=94049 Jody doesn't think the patch I had is viable for reasons I never really understood. And I've not yet succeeded in getting Jonathan interested in the problem. Jonathan ? :-) Sun have all these same problems with Sun Ray and up 'til now they were the only ones who cared about them. They're our problem too, now. Fun, huh ? :-) > - The VNC session will not be able to do hardware acceleration? > > - Launching desktop screensaver preferences shows: > > xscreensaver-demo is running as "root" on "myserver". But the > xscreensaver managing display ":1.0" is running as user "nobody" on host > "myserver". Since they are different users they won't be > reading/writing the same ~/.xscreensaver file, so xscreensaver-demo > isn't going to work right. Hmm, nice. No ideas off the top of my head on that one. > - The window title for the VNC session is: "VNC: x11". Probably want > something more descriptive like the user name, or the host? Yeah, probably. But mostly I expect the viewer to be running fullscreen. > - Perhaps a way to list *active* VNC sessions? The modified gdm doesn't > appear to add entries to utmp/wtmp. Once you login, perhaps you are > prompted with a dialog like: > > "There is already an active desktop running for $USER from $HOST. Would > you like to create a new desktop, or join one from the list below?" Yes, figuring out something like that is on our immediate TODO list. Not sure exactly what it'll be like yet. > - Should the gdm xdmcp configuration settings hold true for the remote > VNC gdm mode also? Meaning, if you set the gdm theme to be the > "old-style" greeter for remote consoles... Yeah, for no good reason at all we made the graphical greeter the default for the VNC login. Well, for one good reason - the standard greeter sucks. We also need to add the VNC configuration to gdmsetup. Lots to do :-) Cheers, Mark. From markmc at redhat.com Fri Jun 4 17:01:17 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 18:01:17 +0100 Subject: terminal services prototype In-Reply-To: <1086357346.644.11.camel@wintermute.sr.unh.edu> References: <1086282687.23702.44.camel@localhost.localdomain> <1086357346.644.11.camel@wintermute.sr.unh.edu> Message-ID: <1086368477.23702.374.camel@localhost.localdomain> Hey, On Fri, 2004-06-04 at 14:55, Thomas J. Baker wrote: > > > > + 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. You did see this, right ? :) > Could you yummify your archive so we can just point at it and get > updates whenever you make them? (I realize this will probably hit > rawhide at some point but I'm taking a breather from rawhide for a while > between betas!) I look into it .. > Slightly OT: > Do you plan to add vino? Yes, but I haven't decided when yet. I'm planning on changing Vino quite substantially to work under this model (i.e. you connect to Vino through GDM), I don't know when I'll get to that yet and I'm not sure if I should go and add Vino until that work is done. > I've got it all built (it seems to work) but > I'm not sure the rpms are complete. (I had to add vino-session as a > startup item.) Yeah, there's a patch in the tarball which we'd add to gnome-session rather than having people use vino-session. > And along the lines of a bug report, everytime a coworker > runs nessus against my system, vino-server goes off the deep end eating > 100% of one CPU. vino-server does some intense polling of the screen to keep its copy of the framebuffer up to date. As soon as the DAMAGE extension is in our Xserver, we'll be using that and this problem will go away. Cheers, Mark. From markmc at redhat.com Fri Jun 4 17:03:05 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 18:03:05 +0100 Subject: terminal services prototype In-Reply-To: References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> <1086348589.23702.322.camel@localhost.localdomain> Message-ID: <1086368585.23702.377.camel@localhost.localdomain> Hi, On Fri, 2004-06-04 at 15:00, Tom Diehl wrote: > On Fri, 4 Jun 2004, Mark McLoughlin wrote: > > > Hey, > > > > On Fri, 2004-06-04 at 01:45, Jeff Spaleta wrote: > > > > > 2) is there a potential here to create look but don't touch vnc > > > connections as well as full access connections? > > > > Yeah, we'll have something like that. > > > > Part of Vino's preferences dialog looks like: > > Can someone give me a pointer to vino. Google returns a bunch of info on > different wines. While I like wine as much as the next guy I doube that is > what you are referring to. :-) Footnote from the first mail is about as good as it gets: http://www.gnome.org/~markmc/blog/05022004 and the (out of date now) doc that's linked from there: http://www.gnome.org/~markmc/remote-desktop.txt Cheers, Mark. > Tom > From markmc at redhat.com Fri Jun 4 17:05:06 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 18:05:06 +0100 Subject: terminal services prototype In-Reply-To: <1086357683.644.13.camel@wintermute.sr.unh.edu> References: <1086282687.23702.44.camel@localhost.localdomain> <1086299979.1677.3.camel@teapot.felipe-alfaro.com> <1086334994.23702.92.camel@localhost.localdomain> <1086357683.644.13.camel@wintermute.sr.unh.edu> Message-ID: <1086368706.23702.380.camel@localhost.localdomain> Hi, On Fri, 2004-06-04 at 15:01, Thomas J. Baker wrote: > Also, any way to specify the size of the vnc-server session? I have my X > display set to 1600x1200 and I want the vnc session to be the same. We'll be making the Xvnc command line configurable in gdm.conf and you'll be able to change it there. In the far distant future, I'd like the VNC client to be able to request the screen size (i.e. different terminals will have different screen sizes) but that requires an addition to the RFB protocol. Hence the "far distant future" bit. Cheers, Mark. From markmc at redhat.com Fri Jun 4 17:07:42 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 18:07:42 +0100 Subject: terminal services prototype In-Reply-To: <1086362246.1715.4.camel@teapot.felipe-alfaro.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> <20040604073133.GA23527@devserv.devel.redhat.com> <604aa7910406040706673ad7d0@mail.gmail.com> <1086362246.1715.4.camel@teapot.felipe-alfaro.com> Message-ID: <1086368862.23702.384.camel@localhost.localdomain> Hey, On Fri, 2004-06-04 at 16:17, Felipe Alfaro Solana wrote: > On Fri, 2004-06-04 at 16:06, Jeff Spaleta wrote: > > On Fri, 4 Jun 2004 03:31:33 -0400, Caolan McNamara wrote: > > > I see some occasional fuzziness with the second or third reconnection at the > > > moment as well, I'm looking into it at the moment. > > > > should have known..... > > i go to play with this again today, and turn on debug in gdm this time to catch > > the log of the problem and.... > > > > things are working... repeated vncviewer client connections and they > > are dropping back into the running desktop. > > It seems to me that enabling gdm debugging makes those "problems when > logging back to a remote session" fade away. That's just what we need. Sob[1] :/ I think we both suspect some racey deadlock thing in the way the GDM daemon talks to the slave using signals. Maybe we can get George to save us on that one ... Cheers, Mark. [1] - That's Caolan's sob, not mine. He's the one dealing with it :-) From rdieter at math.unl.edu Fri Jun 4 17:15:37 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 4 Jun 2004 12:15:37 -0500 (CDT) Subject: terminal services prototype In-Reply-To: <40BFC90E.3050100@math.unl.edu> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <40BFC90E.3050100@math.unl.edu> Message-ID: On Thu, 3 Jun 2004, Rex Dieter wrote: > Havoc Pennington wrote: > > > Cool! How much work to get this to work with gdm as the login prompt > > instead of vncviewer, so you auth via gdm which starts a fullscreen > > vncviewer on the client and connects it to the server without a second > > login? (Ignore any naive assumptions in the foregoing...) > > It's pretty trivial to do that. I've got that setup for many of our > boxes already. I'll give more details tomorrow, if nobody beats me to > the punch. Attached is vncts.services and vncts.xinetd. Append vncts.services to /etc/services Drop vncts.xinetd into /etc/xinetd.d/ Add/append-to /etc/X11/xdm/Xaccess to add: localhost enable XDMCP in your loginmanager (gdm/xdm/kdm/whatever) restart X. -- Rex -------------- next part -------------- # default: off # To use this remote vnc method: # * Allow local accesss to Xserver/XDMCP, add to /etc/X11/xdm/Xaccess: # localhost # Then, this server is accessible at vncviewer :0-5 service vnc-1024x768x16 { disable = yes socket_type = stream wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -fp unix/:7100 -depth 16 -geometry 1024x768 } service vnc-800x600x16 { disable = yes socket_type = stream wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -fp unix/:7100 -depth 16 -geometry 800x600 } service vnc-640x480x16 { disable = yes socket_type = stream wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -fp unix/:7100 -depth 16 -geometry 640x480 } service vnc-1024x768x8 { disable = yes socket_type = stream wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -fp unix/:7100 -depth 8 -geometry 1024x768 } service vnc-800x600x8 { disable = yes socket_type = stream wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -fp unix/:7100 -depth 8 -geometry 800x600 } service vnc-640x480x8 { disable = yes socket_type = stream wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -fp unix/:7100 -depth 8 -geometry 640x480 } -------------- next part -------------- vnc-1024x768x16 5900/tcp vnc-800x600x16 5901/tcp vnc-640x480x16 5902/tcp vnc-1024x768x8 5903/tcp vnc-800x600x8 5904/tcp vnc-640x480x8 5905/tcp From markmc at redhat.com Fri Jun 4 17:27:33 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 04 Jun 2004 18:27:33 +0100 Subject: terminal services prototype In-Reply-To: References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <40BFC90E.3050100@math.unl.edu> Message-ID: <1086370053.23702.390.camel@localhost.localdomain> Hi, On Fri, 2004-06-04 at 18:15, Rex Dieter wrote: > On Thu, 3 Jun 2004, Rex Dieter wrote: > > > Havoc Pennington wrote: > > > > > Cool! How much work to get this to work with gdm as the login prompt > > > instead of vncviewer, so you auth via gdm which starts a fullscreen > > > vncviewer on the client and connects it to the server without a second > > > login? (Ignore any naive assumptions in the foregoing...) > > > > It's pretty trivial to do that. I've got that setup for many of our > > boxes already. I'll give more details tomorrow, if nobody beats me to > > the punch. > > Attached is vncts.services and vncts.xinetd. This is the well known hack to allow Xvnc with a GDM to be started by inetd which our work is completely replacing so that we can get the reconnection ability. I think you've missed what Havoc was asking about - he was asking about the *client* setup, not the server setup. Cheers, Mark. From rdieter at math.unl.edu Fri Jun 4 17:36:54 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 4 Jun 2004 12:36:54 -0500 (CDT) Subject: terminal services prototype In-Reply-To: <1086370053.23702.390.camel@localhost.localdomain> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <40BFC90E.3050100@math.unl.edu> <1086370053.23702.390.camel@localhost.localdomain> Message-ID: On Fri, 4 Jun 2004, Mark McLoughlin wrote: > I think you've missed what Havoc was asking about - he was asking about > the *client* setup, not the server setup. OK, my bad. -- Rex From jspaleta at gmail.com Sat Jun 5 03:20:55 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 Jun 2004 23:20:55 -0400 Subject: terminal services prototype In-Reply-To: <604aa7910406040706673ad7d0@mail.gmail.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> <20040604073133.GA23527@devserv.devel.redhat.com> <604aa7910406040706673ad7d0@mail.gmail.com> Message-ID: <604aa7910406042020775103c6@mail.gmail.com> another smallish thing.... dropping down to runlevel 3 keeps the gdm vnc session hanging around still. Not sure if thats a good thing or a bad thing...but its different from what i expect when dropping out of runlevel 5 down to 3, in terms of shutting down X completely. -jef From markmc at redhat.com Sat Jun 5 10:47:41 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Sat, 05 Jun 2004 11:47:41 +0100 Subject: terminal services prototype In-Reply-To: <604aa7910406042020775103c6@mail.gmail.com> References: <1086282687.23702.44.camel@localhost.localdomain> <1086304561.4807.84.camel@localhost.localdomain> <604aa791040603174541571947@mail.gmail.com> <20040604073133.GA23527@devserv.devel.redhat.com> <604aa7910406040706673ad7d0@mail.gmail.com> <604aa7910406042020775103c6@mail.gmail.com> Message-ID: <1086432461.4127.8.camel@localhost.localdomain> Hi, On Sat, 2004-06-05 at 04:20, Jeff Spaleta wrote: > another smallish thing.... > dropping down to runlevel 3 keeps the gdm vnc session hanging around still. > Not sure if thats a good thing or a bad thing...but its different from > what i expect when dropping out of runlevel 5 down to 3, in terms of > shutting down X completely. Yeah, that'd be another bug. Probably the same bug which stops the login Xvnc from being shutdown when you get re-connected to the original Xvnc. Cheers, Mark. From john at aneka-infokom.co.id Wed Jun 9 06:41:01 2004 From: john at aneka-infokom.co.id (John Alexander) Date: Wed, 9 Jun 2004 13:41:01 +0700 Subject: Terminal services (LTSP) Message-ID: Hello, I am already set up a server using Fedora Core 1. But there is some error, why the client hardware (vga and monitor) using the same driver with the server one? I have set the vga and monitor for the client configuration. Can anyone help me? J. Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at redhat.com Wed Jun 9 13:50:34 2004 From: alexl at redhat.com (Alexander Larsson) Date: 09 Jun 2004 15:50:34 +0200 Subject: Terminal services (LTSP) In-Reply-To: References: Message-ID: <1086789033.1991.57.camel@localhost.localdomain> On Wed, 2004-06-09 at 08:41, John Alexander wrote: > Hello, > > I am already set up a server using Fedora Core 1. > But there is some error, why the client hardware (vga and monitor) > using the same driver with the server one? I have set the vga and > monitor for the client configuration. > > Can anyone help me? This mailing list is about development of the fedora desktop. General help questions are better handled on fedora-list, or in your case the LTSP mailing lists at: http://www.ltsp.org/mailinglists.php =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a world-famous gay inventor on a search for his missing sister. She's a beautiful kleptomaniac lawyer from beyond the grave. They fight crime! From stevelist at silverorange.com Fri Jun 11 16:17:40 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Fri, 11 Jun 2004 13:17:40 -0300 Subject: Default Application for RPM files Message-ID: <40C9DB24.8000202@silverorange.com> I think that in FC1, the default application associated with RPMs was "Install Packages", but this doesn't seem to be the case in FC2. As a result, if you end up with an RPM opened from a web browser or double-clicked from a folder, you get an alert about no default application being associated with it. Is there a reason this changed? Is this true of FC2 in general, or have I accidentally changed something? I realize that running rpms might not be the best way to install things, but it did work very nicely. Thanks, Steven Garrity From mdraghi at prosud.com Fri Jun 11 16:24:42 2004 From: mdraghi at prosud.com (Mariano Draghi) Date: Fri, 11 Jun 2004 13:24:42 -0300 Subject: Default Application for RPM files In-Reply-To: <40C9DB24.8000202@silverorange.com> References: <40C9DB24.8000202@silverorange.com> Message-ID: Steven Garrity escribi?: > I think that in FC1, the default application associated with RPMs was > "Install Packages", but this doesn't seem to be the case in FC2. > > As a result, if you end up with an RPM opened from a web browser or > double-clicked from a folder, you get an alert about no default > application being associated with it. [...] I believe it has to do with the fact that the "official" or "standard" MIME/type for the RPM extension is "Real Media" something. So at some point it was decided to leave the .rpm files without asociation (an asociation with "Install Packages" would be non-standard, and an asociation with Real Media Player would be a mistake in a rpm-based distribution as FC2) Regards, -- Mariano From hp at redhat.com Fri Jun 11 21:27:29 2004 From: hp at redhat.com (Havoc Pennington) Date: Fri, 11 Jun 2004 17:27:29 -0400 Subject: Default Application for RPM files In-Reply-To: References: <40C9DB24.8000202@silverorange.com> Message-ID: <1086989249.3514.0.camel@localhost.localdomain> On Fri, 2004-06-11 at 12:24, Mariano Draghi wrote: > > I believe it has to do with the fact that the "official" or "standard" > MIME/type for the RPM extension is "Real Media" something. > So at some point it was decided to leave the .rpm files without > asociation (an asociation with "Install Packages" would be non-standard, > and an asociation with Real Media Player would be a mistake in a > rpm-based distribution as FC2) That can't be right - we should be able to use sniffing anyhow, or at least associate the ".arch.rpm" extension if not plain ".rpm" Havoc From shahms at shahms.com Fri Jun 11 22:22:25 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 11 Jun 2004 15:22:25 -0700 Subject: Default Application for RPM files In-Reply-To: <1086989249.3514.0.camel@localhost.localdomain> References: <40C9DB24.8000202@silverorange.com> <1086989249.3514.0.camel@localhost.localdomain> Message-ID: <1086992545.10499.90.camel@shahms.mesd.k12.or.us> On Fri, 2004-06-11 at 14:27, Havoc Pennington wrote: > On Fri, 2004-06-11 at 12:24, Mariano Draghi wrote: > > > > I believe it has to do with the fact that the "official" or "standard" > > MIME/type for the RPM extension is "Real Media" something. > > So at some point it was decided to leave the .rpm files without > > asociation (an asociation with "Install Packages" would be non-standard, > > and an asociation with Real Media Player would be a mistake in a > > rpm-based distribution as FC2) > > That can't be right - we should be able to use sniffing anyhow, or at > least associate the ".arch.rpm" extension if not plain ".rpm" > > Havoc The Real Player .rpm MIME Type (according to the RealPlayer mozilla plugin) is: audio/x-pn-realaudio-plugin which means it's not "official" or "standard", but is an extension. Additionally, I have *never* seen such a file in the wild, .ra and .ram, yes, but .rpm has always been an application. -- Shahms King From robla at real.com Fri Jun 11 22:59:15 2004 From: robla at real.com (Rob Lanphier) Date: Fri, 11 Jun 2004 15:59:15 -0700 Subject: Default Application for RPM files In-Reply-To: <1086992545.10499.90.camel@shahms.mesd.k12.or.us> References: <40C9DB24.8000202@silverorange.com> <1086989249.3514.0.camel@localhost.localdomain> <1086992545.10499.90.camel@shahms.mesd.k12.or.us> Message-ID: <1086994754.2849.67.camel@localhost.localdomain> Hi all, I'm cross-posting this to the player-dev at helixcommunity.org list so that we catch the Helix Player/RealPlayer dev team. On Fri, 2004-06-11 at 15:22, Shahms King wrote: > The Real Player .rpm MIME Type (according to the RealPlayer mozilla > plugin) is: audio/x-pn-realaudio-plugin which means it's not "official" > or "standard", but is an extension. Additionally, I have *never* seen > such a file in the wild, .ra and .ram, yes, but .rpm has always been an > application. .rpm associated with RealPlayer was designed to be used in HTML and tags. .rpm stood for "RealAudio Plugin Metafile" at the time of its design in 1995. I'm not sure if it's needed outside of that context to play all presentations out there designed for RealPlayer. The tricky part is that if we've ever had a player that generally claimed the MIME type (probably), that means that at least one misguided author has authored a presentation that relies on that broader support (for example, putting my dog spot eating dirt) . So, removing that support may make some presentations break. Rob -- Rob Lanphier, Development Support Manager - RealNetworks Helix Community: http://helixcommunity.org Development Support: http://www.realnetworks.com/products/support/devsupport From markmc at redhat.com Sun Jun 13 12:54:22 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Sun, 13 Jun 2004 13:54:22 +0100 Subject: desktop security questions Message-ID: <1087131261.3815.139.camel@localhost.localdomain> Hi, So, I was just looking over George Lebl's desktop security paper for GUADEC[1] and I realised that when talking about desktop security we make a lot of assumptions about what we mean by security. Given that designing secure applications/systems is all about trade offs between the risks to the application and the cost of the possible countermeasures, you need some sort of basic framework for making those tradeoffs. Here's the kind of thing I'm thinking of: * What can go wrong/what are we trying to prevent/risks? * Loss of data * Disclosure of private data/loss of privacy * Denial of service * Interruption of work/reduced productivity * ... * What may cause the above to come about/threats? * Escalation of privileges to an attacker * Execution of arbitrary commands specified by an attacker * Ability for an attacker to force the program into monopolising system resources (cpu, memory, file descriptors, ports, hard disk space) * Ability for an attacker to cause a program to abort in an unrecoverable way * Ability for an attacker to snoop a user's actions * ... * What are our assumptions? * The attacker can not have root access (i.e. any countermeasures to this threat would be futile) * Our user is not technical and does not need to understand the threats to the system (although they do implicitly understand the risks) * (Deployment environment assumptions) * ... * What are our goals? * Provide a system whereby the user can easily and safely get their work done * Ensure the privacy and integrity of a user's data * ... Any thoughts? Useful or not? Feel free to expand[2] the "..." bits. Cheers, Mark. [1] - See http://2004.guadec.org/schedule/profiles.html [2] - Red Hat people edit the SecureDesktopQuestions wiki page, everyone else just reply to the list (yes, that sucks and, yes, we'd really like to have an external wiki) From stevelist at silverorange.com Sun Jun 13 15:08:05 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Sun, 13 Jun 2004 12:08:05 -0300 Subject: Default Application for RPM files In-Reply-To: <1086989249.3514.0.camel@localhost.localdomain> References: <40C9DB24.8000202@silverorange.com> <1086989249.3514.0.camel@localhost.localdomain> Message-ID: <40CC6DD5.5010904@silverorange.com> Havoc Pennington wrote: > On Fri, 2004-06-11 at 12:24, Mariano Draghi wrote: > >>I believe it has to do with the fact that the "official" or "standard" >>MIME/type for the RPM extension is "Real Media" something. >>So at some point it was decided to leave the .rpm files without >>asociation (an asociation with "Install Packages" would be non-standard, >>and an asociation with Real Media Player would be a mistake in a >>rpm-based distribution as FC2) > > That can't be right - we should be able to use sniffing anyhow, or at > least associate the ".arch.rpm" extension if not plain ".rpm" Should I file a bug on this? Steven Garrity From hp at redhat.com Sun Jun 13 21:46:55 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 13 Jun 2004 17:46:55 -0400 Subject: Default Application for RPM files In-Reply-To: <40CC6DD5.5010904@silverorange.com> References: <40C9DB24.8000202@silverorange.com> <1086989249.3514.0.camel@localhost.localdomain> <40CC6DD5.5010904@silverorange.com> Message-ID: <1087163215.3514.64.camel@localhost.localdomain> On Sun, 2004-06-13 at 11:08, Steven Garrity wrote: > Havoc Pennington wrote: > > On Fri, 2004-06-11 at 12:24, Mariano Draghi wrote: > > > >>I believe it has to do with the fact that the "official" or "standard" > >>MIME/type for the RPM extension is "Real Media" something. > >>So at some point it was decided to leave the .rpm files without > >>asociation (an asociation with "Install Packages" would be non-standard, > >>and an asociation with Real Media Player would be a mistake in a > >>rpm-based distribution as FC2) > > > > That can't be right - we should be able to use sniffing anyhow, or at > > least associate the ".arch.rpm" extension if not plain ".rpm" > > Should I file a bug on this? > Yeah, presumably vs. system-config-packages Havoc From stevelist at silverorange.com Sun Jun 13 22:52:33 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Sun, 13 Jun 2004 19:52:33 -0300 Subject: Default Application for RPM files In-Reply-To: <1087163215.3514.64.camel@localhost.localdomain> References: <40C9DB24.8000202@silverorange.com> <1086989249.3514.0.camel@localhost.localdomain> <40CC6DD5.5010904@silverorange.com> <1087163215.3514.64.camel@localhost.localdomain> Message-ID: <40CCDAB1.8000307@silverorange.com> Havoc Pennington wrote: > On Sun, 2004-06-13 at 11:08, Steven Garrity wrote: >>Should I file a bug on this? >> > > Yeah, presumably vs. system-config-packages Two bugs already filed (maybe dups?): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120276 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123242 Steven Garrity From hp at redhat.com Mon Jun 14 14:01:07 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 14 Jun 2004 10:01:07 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] Message-ID: <1087221660.21952.14.camel@localhost.localdomain> We do need to fix this HIG vs. desktop entry spec issue. Historically what we've done for Red Hat is just put what we want in Name and ignore GenericName. Havoc -------------- next part -------------- An embedded message was scrubbed... From: Ivan Gyurdiev Subject: Re: Gnome Icons, Gnome/KDE Menus need improvement Date: Sun, 13 Jun 2004 13:58:02 -0600 Size: 5046 URL: From mdraghi at prosud.com Mon Jun 14 14:44:18 2004 From: mdraghi at prosud.com (Mariano Draghi) Date: Mon, 14 Jun 2004 11:44:18 -0300 Subject: Default Application for RPM files In-Reply-To: <40CCDAB1.8000307@silverorange.com> References: <40C9DB24.8000202@silverorange.com> <1086989249.3514.0.camel@localhost.localdomain> <40CC6DD5.5010904@silverorange.com> <1087163215.3514.64.camel@localhost.localdomain> <40CCDAB1.8000307@silverorange.com> Message-ID: Steven Garrity escribi?: > Havoc Pennington wrote: > >> On Sun, 2004-06-13 at 11:08, Steven Garrity wrote: >> >>> Should I file a bug on this? >>> >> >> Yeah, presumably vs. system-config-packages > > > Two bugs already filed (maybe dups?): > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120276 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123242 > The program asociation was ok under FC1. Is it possible that it was broken because of some Freedesktop.org and/or Gnome upstream issue as regards MIME types, and KDE/Gnome integration? If I remember correctly, FC1 (at least the Gnome version shiped with it...) didn't use the Freedesktop.org mime types. If that is the case, this should be fixed upstream, shouldn't it? -- Mariano From bclark at redhat.com Mon Jun 14 15:15:59 2004 From: bclark at redhat.com (Bryan Clark) Date: Mon, 14 Jun 2004 11:15:59 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087221660.21952.14.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> Message-ID: <1087226159.3112.8.camel@localhost.localdomain> I made a bug over the weekend to remind myself to fix the HIG on this. http://bugzilla.gnome.org/show_bug.cgi?id=144284 The F.D.O spec seems to suggest that Name is purely the proper name of the application without the description of functionality included. We should align on this issue. My recommendation is to format the Name as "[Proper Name] [Description of Functionality]" and GenericName as "[Description of Functionality]". When two applications exist with the same "[Description of Functionality]" then the Name is used instead. I can see the possibility of expecting the "[Proper Name] [Description of Functionality]" format to be generated automatically via the way the F.D.O. spec is now, however the code isn't there to support this and I suspect issues (especially in regards to translation) will arise if we try to generate the names automatically. ~ Bryan On Mon, 2004-06-14 at 10:01 -0400, Havoc Pennington wrote: > We do need to fix this HIG vs. desktop entry spec issue. Historically > what we've done for Red Hat is just put what we want in Name and ignore > GenericName. > > Havoc > > > Email message/mailbox attachment, "Forwarded message - Re: Gnome > Icons, Gnome/KDE Menus need improvement" > On Mon, 2004-06-14 at 10:01 -0400, Havoc Pennington wrote: > > > What are your thoughts on this > > (response to bugzilla re: changing menu entries) > > > > Kaffeine Maintainer (Livna.org): > > > > ------- Additional Comment #1 From Ville Skytt? 2004-06-13 21:12 -- > > > > > I am not quite comfortable changing the menu entry because it is implementation > > specific how the actual shown label is constructed. Moreover, we use > > freedesktop.org .desktop files to provide the menu entries, and so the > > canonical > > specification to follow is the desktop entry specification, which says > > Name is > > the app_name, and I'd say GenericName would correspond to app_function. > > http://freedesktop.org/Standards/desktop-entry-spec/0.9.4/ar01s04.html > > > > Until the ambiguities (and AFAICS even small conflicts) between the > > GNOME HIG > > and desktop entry specifications are clarified, and there is a clear > > documented > > way how to represent this information in .desktop files in Fedora stuff, > > I do > > not want to go into the business of changing things. What would make > > sense to > > me would be to construct the menu entry label like "Name GenericName" > > from the > > .desktop entry fields. That would result in a mess if Name already > > contained > > app_function. > > > > =============================================================================== > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Mon Jun 14 15:23:02 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 14 Jun 2004 10:23:02 -0500 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087226159.3112.8.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> Message-ID: <40CDC2D6.30207@math.unl.edu> Bryan Clark wrote: > I made a bug over the weekend to remind myself to fix the HIG on this. > > http://bugzilla.gnome.org/show_bug.cgi?id=144284 > > The F.D.O spec seems to suggest that Name is purely the proper name of > the application without the description of functionality included. We > should align on this issue. My recommendation is to format the Name as > "[Proper Name] [Description of Functionality]" and GenericName as > "[Description of Functionality]". When two applications exist with the > same "[Description of Functionality]" then the Name is used instead. I'm glad someone (esp @redhat) has seen the light. I suggested doing *exactly* this on the fedora-devel list a few weeks ago, and it was dismissed. > I can see the possibility of expecting the "[Proper Name] [Description > of Functionality]" format to be generated automatically via the way the > F.D.O. spec is now, however the code isn't there to support this and I > suspect issues (especially in regards to translation) will arise if we > try to generate the names automatically. In KDE, at least, the display/handling of [Name] [GenericName] is user-configurable. -- Rex From bclark at redhat.com Tue Jun 15 00:41:23 2004 From: bclark at redhat.com (Bryan Clark) Date: Mon, 14 Jun 2004 20:41:23 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087226159.3112.8.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> Message-ID: <1087260083.7600.8.camel@localhost.localdomain> I've added the entry to the GNOME HIG and closed the bug related, however now the f.d.o. spec needs to be updated. In the Desktop Entry Spec: http://freedesktop.org/Standards/desktop-entry-spec/0.9.4/ar01s04.html Below: Table 2. Standard Keys Reads: Name | Specific name of the application, for example "Mozilla". If you agree that the translation of the generated names is a bad thing, which I'm certain it is. I believe this should read something like: Name | Specific and generic name of the application, for example "Mozilla Web Browser". That might need to be elaborated on a bit though. Cheers, ~ Bryan On Mon, 2004-06-14 at 11:15 -0400, Bryan Clark wrote: > I made a bug over the weekend to remind myself to fix the HIG on > this. > > http://bugzilla.gnome.org/show_bug.cgi?id=144284 > > The F.D.O spec seems to suggest that Name is purely the proper name of > the application without the description of functionality included. We > should align on this issue. My recommendation is to format the Name > as "[Proper Name] [Description of Functionality]" and GenericName as > "[Description of Functionality]". When two applications exist with > the same "[Description of Functionality]" then the Name is used > instead. > > I can see the possibility of expecting the "[Proper Name] [Description > of Functionality]" format to be generated automatically via the way > the F.D.O. spec is now, however the code isn't there to support this > and I suspect issues (especially in regards to translation) will arise > if we try to generate the names automatically. > > ~ Bryan > > On Mon, 2004-06-14 at 10:01 -0400, Havoc Pennington wrote: > > We do need to fix this HIG vs. desktop entry spec issue. Historically > > what we've done for Red Hat is just put what we want in Name and ignore > > GenericName. > > > > Havoc > > > > Email message/mailbox attachment, "Forwarded message - Re: Gnome > > Icons, Gnome/KDE Menus need improvement" > > On Mon, 2004-06-14 at 10:01 -0400, Havoc Pennington wrote: > > > What are your thoughts on this > > > (response to bugzilla re: changing menu entries) > > > > > > Kaffeine Maintainer (Livna.org): > > > > > > ------- Additional Comment #1 From Ville Skytt? 2004-06-13 21:12 -- > > > > > > > I am not quite comfortable changing the menu entry because it is implementation > > > specific how the actual shown label is constructed. Moreover, we use > > > freedesktop.org .desktop files to provide the menu entries, and so the > > > canonical > > > specification to follow is the desktop entry specification, which says > > > Name is > > > the app_name, and I'd say GenericName would correspond to app_function. > > > http://freedesktop.org/Standards/desktop-entry-spec/0.9.4/ar01s04.html > > > > > > Until the ambiguities (and AFAICS even small conflicts) between the > > > GNOME HIG > > > and desktop entry specifications are clarified, and there is a clear > > > documented > > > way how to represent this information in .desktop files in Fedora stuff, > > > I do > > > not want to go into the business of changing things. What would make > > > sense to > > > me would be to construct the menu entry label like "Name GenericName" > > > from the > > > .desktop entry fields. That would result in a mess if Name already > > > contained > > > app_function. > > > > > > =============================================================================== > > > From jrb at redhat.com Tue Jun 15 04:58:46 2004 From: jrb at redhat.com (Jonathan Blandford) Date: 15 Jun 2004 00:58:46 -0400 Subject: desktop security questions References: <1087131261.3815.139.camel@localhost.localdomain> Message-ID: Mark McLoughlin writes: > Hi, > So, I was just looking over George Lebl's desktop security paper for > GUADEC[1] and I realised that when talking about desktop security we > make a lot of assumptions about what we mean by security. Good mail. I'm not 100% sure what the goal here is, but I'll try to follow up. > Given that designing secure applications/systems is all about trade > offs between the risks to the application and the cost of the possible > countermeasures, you need some sort of basic framework for making those > tradeoffs. > > Here's the kind of thing I'm thinking of: > > * What can go wrong/what are we trying to prevent/risks? > * Loss of data > * Disclosure of private data/loss of privacy > * Denial of service > * Interruption of work/reduced productivity Another possible risk is identity masquerading (eg. sending a bomb threat from another persons email account.) There's also a ranking of the severity of these. They're all bad, but the last two are less bad, as they diminish your experience and don't necessarily cause irreversible harm. We should also add that we are trying to protect the whole ecosystem as much as possible. That is, it's bad if an attacker gains the ability to run a process as an unprivileged user on a box even if it takes negligible resources from that box. > * What may cause the above to come about/threats? > * Escalation of privileges to an attacker > * Execution of arbitrary commands specified by an attacker > * Ability for an attacker to force the program into > monopolising system resources (cpu, memory, file > descriptors, ports, hard disk space) > * Ability for an attacker to cause a program to abort in > an unrecoverable way > * Ability for an attacker to snoop a user's actions * Ability for the attacker to trick the user into doing something. > * What are our assumptions? > * The attacker can not have root access (i.e. any > countermeasures to this threat would be futile) > * Our user is not technical and does not need to > understand the threats to the system (although they do > implicitly understand the risks) > * (Deployment environment assumptions) * Any solution that puts the burden of determining risk on the user is a non-solution? > * What are our goals? > * Provide a system whereby the user can easily and safely > get their work done > * Ensure the privacy and integrity of a user's data No discussion of a process to reach these goals. Is that an exercise for the reader? (-: Thanks, -Jonathan From snickell at redhat.com Wed Jun 16 19:08:10 2004 From: snickell at redhat.com (Seth Nickell) Date: Wed, 16 Jun 2004 15:08:10 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <40CDC2D6.30207@math.unl.edu> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> Message-ID: <1087412890.2567.15.camel@localhost.localdomain> On Mon, 2004-06-14 at 10:23 -0500, Rex Dieter wrote: > Bryan Clark wrote: > > I made a bug over the weekend to remind myself to fix the HIG on this. > > > > http://bugzilla.gnome.org/show_bug.cgi?id=144284 > > > > The F.D.O spec seems to suggest that Name is purely the proper name of > > the application without the description of functionality included. We > > should align on this issue. My recommendation is to format the Name as > > "[Proper Name] [Description of Functionality]" and GenericName as > > "[Description of Functionality]". When two applications exist with the > > same "[Description of Functionality]" then the Name is used instead. > > I'm glad someone (esp @redhat) has seen the light. I suggested doing > *exactly* this on the fedora-devel list a few weeks ago, and it was > dismissed. Bryan and I have discussed this and we're not doing it. From an end desktop-user (not one of the active community folks, but Abby) the name of the item *is* what we put in the menu. When you or I see "Web Browser" in the menus we think "that item is epiphany". But to Abby, that item is "Web Browser": it has no other name. A good example is the calculator, because "Calculator" is the name of the program to us. Wouldn't it be weird if, upon installing "Pro+ Calculator" calculator, suddenly the default calculator was called "SimpleMath Calculator" (or whatever)? Its like some magic new name appeared for it! "Web Browser" is the *real name* of the item to Abby, not Epiphany. Calling it "Epiphany Web Browser" all of the sudden because I installed "Firefox Web Browser" is going to be weird, and it doesn't really help anything. "Epiphany" is just as foreign to Abby as "SimpleMath Calculator" is to us. The only two valid options I see are always including the branding name, or never including it. But, for example, Epiphany and Gaim are just as core to the desktop as a Calculator (perhaps more core at this point). I don't see a particular reason to brand them and not Calculator (except that we happen to be used to the branded names, which is why everyone gets all excited about generic names). Upstream GNOME and KDE should include both Name and GenericName tags, but the reason is so they are translated so upstream distributors can easily choose whether to use the Branded Name[TM] or the GenericName for a particular item. -Seth From rdieter at math.unl.edu Wed Jun 16 19:20:24 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 16 Jun 2004 14:20:24 -0500 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087412890.2567.15.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> Message-ID: <40D09D78.1030209@math.unl.edu> Seth Nickell wrote: > On Mon, 2004-06-14 at 10:23 -0500, Rex Dieter wrote: > >>Bryan Clark wrote: >> >>> I made a bug over the weekend to remind myself to fix the HIG on this. >>> >>>http://bugzilla.gnome.org/show_bug.cgi?id=144284 >>> >>>The F.D.O spec seems to suggest that Name is purely the proper name of >>>the application without the description of functionality included. We >>>should align on this issue. My recommendation is to format the Name as >>>"[Proper Name] [Description of Functionality]" and GenericName as >>>"[Description of Functionality]". When two applications exist with the >>>same "[Description of Functionality]" then the Name is used instead. >> >>I'm glad someone (esp @redhat) has seen the light. I suggested doing >>*exactly* this on the fedora-devel list a few weeks ago, and it was >>dismissed. > > > Bryan and I have discussed this and we're not doing it. I respectfully disagree, and by not doing it, you're not following freedesktop.org .desktop guidelines/standards. Please, *please* reconsider. Besides, in KDE, at least, the display of [Name] and [GenericName] is configurable, so users can have any of [Name] [Name] ([GenericName]) [GenericName] ([Name]) and redhat is free to use the latter as the default. -- Rex From jspaleta at gmail.com Wed Jun 16 19:22:02 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 Jun 2004 15:22:02 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087412890.2567.15.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> Message-ID: <604aa7910406161222f4aff43@mail.gmail.com> On Wed, 16 Jun 2004 15:08:10 -0400, Seth Nickell wrote: > "Web Browser" is the *real name* of the item to Abby, not Epiphany. > Calling it "Epiphany Web Browser" all of the sudden because I installed > "Firefox Web Browser" is going to be weird, and it doesn't really help > anything. "Epiphany" is just as foreign to Abby as "SimpleMath > Calculator" is to us. I'm confused about the assumptions being made in this use case: 1)Is Abby installing Firefox or are you installing Firefox for Abby? 2)Do we expect Abby to install any extra applications with overlapping functionality? 2a)How is Abby suppose to know how to install overlap functionality without understanding the difference between choices at the brand name level? 2b)Once Abby is aware of the brandname choices and is informed enough to make a choice for overlap applications to install, does it really mean that adding the brandname back into the menu entry for the default application for that functionality mean more confusion? Once a user is aware of brandname choice...brandname becomes a distiquishing factor. 2c)Do we expect Abby to have access to someone like you to install the overlapping applications? -jef From djr at redhat.com Wed Jun 16 19:29:35 2004 From: djr at redhat.com (Daniel Reed) Date: Wed, 16 Jun 2004 15:29:35 -0400 (EDT) Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087412890.2567.15.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> Message-ID: On 2004-06-16T15:08-0400, Seth Nickell wrote: ) "Web Browser" is the *real name* of the item to Abby, not Epiphany. ) Calling it "Epiphany Web Browser" all of the sudden because I installed ) "Firefox Web Browser" is going to be weird, and it doesn't really help ) anything. "Epiphany" is just as foreign to Abby as "SimpleMath ) Calculator" is to us. When I think about refrigerators, I do not think of brands. "Refrigerator" is label enough for me. When I think about cars, the make and style can be very important to me. Different makers and models can have very different features, presentation, etc. The differences from one calculator (or refrigerator) to another are usually not enough to warrant distinguishment. Cars (and possibly web browsers), on the other hand, might warrant some kind of differentiation in a selector. Car rental agencies usually do not present a choice in makes and specific models, but allow you to choose style (sub compact, full size, van, etc.). What differentiates the various web browsers we support? Can we use that information in the menu? -- Daniel Reed http://people.redhat.com/djr/ Desktop and Cygwin From jspaleta at gmail.com Wed Jun 16 19:38:20 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 Jun 2004 15:38:20 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> Message-ID: <604aa791040616123856aa9a30@mail.gmail.com> On Wed, 16 Jun 2004 15:29:35 -0400 (EDT), Daniel Reed wrote: > Car rental agencies usually do not present a choice in makes and specific > models, but allow you to choose style (sub compact, full size, van, etc.). > What differentiates the various web browsers we support? Can we use that > information in the menu? Beyond the menu...can you use that sort of information at package selection time in the add/remove software process? Whatever is used to be the distiquishing characteristic would be great to see as a pervasive characteristic defining how home desktop users interact with their machines to add and remove software as well as using it. -jef From christopher.blizzard at gmail.com Wed Jun 16 19:42:23 2004 From: christopher.blizzard at gmail.com (Chris Blizzard) Date: Wed, 16 Jun 2004 15:42:23 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087412890.2567.15.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> Message-ID: > Bryan and I have discussed this and we're not doing it. From an end > desktop-user (not one of the active community folks, but Abby) the name > of the item *is* what we put in the menu. When you or I see "Web > Browser" in the menus we think "that item is epiphany". But to Abby, > that item is "Web Browser": it has no other name. A good example is the > calculator, because "Calculator" is the name of the program to us. > Wouldn't it be weird if, upon installing "Pro+ Calculator" calculator, > suddenly the default calculator was called "SimpleMath Calculator" (or > whatever)? Its like some magic new name appeared for it! > > "Web Browser" is the *real name* of the item to Abby, not Epiphany. > Calling it "Epiphany Web Browser" all of the sudden because I installed > "Firefox Web Browser" is going to be weird, and it doesn't really help > anything. "Epiphany" is just as foreign to Abby as "SimpleMath > Calculator" is to us. It depends on how strong the branding is. Firefox, for example, is starting to develop a brand of its own. It would be worth it in that case to include "Mozilla Firefox" as the launcher instead of "Web Browser." There's also the issue of whether or not you want to consider it part of the overall brand or operating system or whether or not you're co-branding. A great example of this was many years ago when the browser wars were in full swing. I remember having conversations with people about how they were "finding things on Netscape" even though they didn't even have Netscape installed anwhere on their computers. They were using IE, but that's how strong the brand was. --Chris From richardl at redhat.com Wed Jun 16 20:33:09 2004 From: richardl at redhat.com (Richard Li) Date: Wed, 16 Jun 2004 16:33:09 -0400 Subject: desktop security questions In-Reply-To: References: <1087131261.3815.139.camel@localhost.localdomain> Message-ID: <20040616203309.GA24619@conundrum.boston.redhat.com> On Tue, Jun 15, 2004 at 12:58:46AM -0400, Jonathan Blandford wrote: > Mark McLoughlin writes: > > > > Given that designing secure applications/systems is all about trade > > offs between the risks to the application and the cost of the possible > > countermeasures, you need some sort of basic framework for making those > > tradeoffs. > > > > Here's the kind of thing I'm thinking of: > > > > * What can go wrong/what are we trying to prevent/risks? > > * Loss of data > > * Disclosure of private data/loss of privacy > > * Denial of service > > * Interruption of work/reduced productivity > > Another possible risk is identity masquerading (eg. sending a bomb > threat from another persons email account.) There's also a ranking of > the severity of these. They're all bad, but the last two are less bad, > as they diminish your experience and don't necessarily cause > irreversible harm. > > We should also add that we are trying to protect the whole ecosystem as > much as possible. That is, it's bad if an attacker gains the ability to > run a process as an unprivileged user on a box even if it takes negligible > resources from that box. On a different but related note, protecting the whole ecosystem entails different types of defenses. Bruce Schneier lists three types: prevention, detection, and response. So, in Jonathan's example above, there are three kinds of questions that the ultimate solution can choose to provide: 1. What does the desktop do to prevent identity masquerading? 2. Once someone has stolen by identity, what does the desktop do to let me know this has happened? 3. Once I figure out it's happened (via my own intuition or by some notification mechanism), how does the desktop help me recover? Another example: I've read that a lot of spam is sent by unwitting Windows users. Microsoft is trying to improve security with efforts such as the firewall in SP2. Something that could also be useful could be something that sensed a lot of SMTP traffic and reported it: "Your desktop is sending a very large quantity of email. This could indicate that your machine has been infected with a malicious program. Go to this URL for more information." > > * What are our goals? > > * Provide a system whereby the user can easily and safely > > get their work done > > * Ensure the privacy and integrity of a user's data Also: Detect any violation of my data integrity/privacy. Recover from violations of my data integrity/privacy. Richard From hp at redhat.com Wed Jun 16 20:51:59 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 16 Jun 2004 16:51:59 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087412890.2567.15.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> Message-ID: <1087419119.9717.124.camel@localhost.localdomain> On Wed, 2004-06-16 at 15:08, Seth Nickell wrote: > Upstream GNOME and KDE should include both Name and GenericName tags, > but the reason is so they are translated so upstream distributors can > easily choose whether to use the Branded Name[TM] or the GenericName for > a particular item. Keep in mind, we don't have a way at the moment to toggle whether to use Name or GenericName on a per-.desktop-file basis. We'll need to engineer a way to do this. The simplest hack of course is to just munge GenericName over the top of Name using desktop-file-install. Also, as an aside, I don't think the HIG is very clear on when to use "Web Browser" and when to use "Foo Web Browser" ... your mail implies this is a "desktop core" vs. "not core" kind of line, the HIG with Bryan's revisions implies it's "whether there are multiple alternatives," etc. The HIG should document unambiguously what 3rd party, upstream, and ISV app developers should put in the .desktop file... Another issue we need to address is getting this name consistent across the package manager, the .desktop file, and what's displayed in the app itself (titlebar, about dialog), currently these are not consistent. Some kind of automated relationship between .desktop file and package manager / installer display would be good. We could potentially have the libraries automatically g_set_application_name() from the .desktop file, also. Havoc From snickell at redhat.com Wed Jun 16 21:19:49 2004 From: snickell at redhat.com (Seth Nickell) Date: Wed, 16 Jun 2004 17:19:49 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> Message-ID: <1087420789.7932.28.camel@localhost.localdomain> > It depends on how strong the branding is. Firefox, for example, is > starting to develop a brand of its own. It would be worth it in that > case to include "Mozilla Firefox" as the launcher instead of "Web > Browser." Yeah, I agree. In cases where heavy branding has already been done, it will be easiest for people to recognize the brand. E.g. if we're offering Coke in our menus (and our menus have plenty of, ahem "coke"), I'd call it Coke, not "Cola Beverage". Our goal should be to use the lowest noise / most identifiable name. The apache brand is strong enough in sysadmin circles that I would definitely label an apache menu item (if we were to have such a thing for some wacky reason *grin*) "Apache Web Server". I caution, however, that while the Firefox (or OpenOffice.org) brand could in theory be strong in 2 years, its basically non-existant in the general office worker population today. >From a usability perspective: In cases where the brand does not already exist (the norm for practically all of our apps relative to, say, Abby), we should use generic names. Branding is usually a process of educating people about things they don't need to know, but we want them to know. It is not typically helpful from a usability perspective (there are cases where it is, but on the whole, not so much). We should not be reducing usability to help establish brands, though where a brand is established we can leverage it ). >From a branding perspective: Prolific brands lead to brand dillution and reduces the ability to have *any* distinct brands. In the marketplace you can't control this, because everyone will try to establish a brand. In this case we can. We can effect how many brands show up in the interface. Sometimes having two or three brands can help, because you associate different things with each brand, but you want to do this strategically. Typically you'll have multiple products under a single brand, not a brand per "product": and I even think its questionable to treat each menu item as a "product". We want to treat the core desktop as a single product, not 50 different products. Put another way, if we add names to menu entries we have multiple brands per product. If anything, we want multiple products per brand. > There's also the issue of whether or not you want to > consider it part of the overall brand or operating system or whether > or not you're co-branding. Yes. Sometimes it will be strategic (and mutually beneficial) to associate with existing strong brands by co-branding... but that's not the norm. I have no problem with a couple things that deviate from the norm on the basis of exceptional arguments. -Seth From snickell at redhat.com Wed Jun 16 21:24:51 2004 From: snickell at redhat.com (Seth Nickell) Date: Wed, 16 Jun 2004 17:24:51 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087419119.9717.124.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> <1087419119.9717.124.camel@localhost.localdomain> Message-ID: <1087421091.7932.33.camel@localhost.localdomain> On Wed, 2004-06-16 at 16:51 -0400, Havoc Pennington wrote: > On Wed, 2004-06-16 at 15:08, Seth Nickell wrote: > > Upstream GNOME and KDE should include both Name and GenericName tags, > > but the reason is so they are translated so upstream distributors can > > easily choose whether to use the Branded Name[TM] or the GenericName for > > a particular item. > > Keep in mind, we don't have a way at the moment to toggle whether to use > Name or GenericName on a per-.desktop-file basis. We'll need to engineer > a way to do this. > > The simplest hack of course is to just munge GenericName over the top of > Name using desktop-file-install. I was sort of assuming that as the status quo. If the translation is in the desktop file, we can figure out something to do with it.... at least it gives us options if upstream includes both. > Also, as an aside, I don't think the HIG is very clear on when to use > "Web Browser" and when to use "Foo Web Browser" ... your mail implies > this is a "desktop core" vs. "not core" kind of line, the HIG with > Bryan's revisions implies it's "whether there are multiple > alternatives," etc. > > The HIG should document unambiguously what 3rd party, upstream, and ISV > app developers should put in the .desktop file... Bryan & I will work on this... but it can't be unambiguous. As with most design issues, we can give guidelines and factors to consider, but a lot of it comes down to common sense. Unfortunately common sense is somethings ISVs don't display when you give them an opportunity to add more branding :-P Still, it would be hard for me to write a guideline on why we should put "Coca Cola" in the menus, but not "Safeway Select" (make up some market saturation point at which you flip to using a branded name?!?). > Another issue we need to address is getting this name consistent across > the package manager, the .desktop file, and what's displayed in the app > itself (titlebar, about dialog), currently these are not consistent. > Some kind of automated relationship between .desktop file and package > manager / installer display would be good. We could potentially have the > libraries automatically g_set_application_name() from the .desktop file, > also. That's a concern I share. -Seth From rstrode at redhat.com Wed Jun 16 21:35:03 2004 From: rstrode at redhat.com (Ray Strode) Date: Wed, 16 Jun 2004 17:35:03 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087419119.9717.124.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> <1087419119.9717.124.camel@localhost.localdomain> Message-ID: <1087421703.14515.26.camel@dyn-238.desktop.boston.redhat.com> On Wed, 2004-06-16 at 16:51, Havoc Pennington wrote: > We could potentially have the > libraries automatically g_set_application_name() from the .desktop file, > also. I wrote a g_set_desktop_file () function that does that. http://bugzilla.gnome.org/show_bug.cgi?id=139974 --Ray From hp at redhat.com Wed Jun 16 22:55:05 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 16 Jun 2004 18:55:05 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087421091.7932.33.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> <1087419119.9717.124.camel@localhost.localdomain> <1087421091.7932.33.camel@localhost.localdomain> Message-ID: <1087426505.9717.156.camel@localhost.localdomain> On Wed, 2004-06-16 at 17:24, Seth Nickell wrote: > > The HIG should document unambiguously what 3rd party, upstream, and ISV > > app developers should put in the .desktop file... > > Bryan & I will work on this... but it can't be unambiguous. As with most > design issues, we can give guidelines and factors to consider, but a lot > of it comes down to common sense. Unfortunately common sense is > somethings ISVs don't display when you give them an opportunity to add > more branding :-P Still, it would be hard for me to write a guideline on > why we should put "Coca Cola" in the menus, but not "Safeway > Select" (make up some market saturation point at which you flip to using > a branded name?!?). Maybe some kind of flow chart? If you have a diamond in the flow chart labeled "judgment call" that's basically going to mean "ask Seth and Bryan" for Fedora Core, but for all third parties it's going to mean "make up something that we will have to fix on the Fedora level" Maybe an "if in doubt, foo" kind of phrasing based on which answer is statistically more probable would minimize our work ;-) I'm less worried about ISVs (who will inevitably name it "Our Trademark Here(tm)" no matter what we say) than I am about upstream projects and Fedora Extras. Havoc From hp at redhat.com Thu Jun 17 02:52:11 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 16 Jun 2004 22:52:11 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087426505.9717.156.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> <1087419119.9717.124.camel@localhost.localdomain> <1087421091.7932.33.camel@localhost.localdomain> <1087426505.9717.156.camel@localhost.localdomain> Message-ID: <1087440730.9717.177.camel@localhost.localdomain> Hi, I was noticing on Windows XP the other day that the toplevel 4-5 "most frequently used" apps show two names: Email Outlook Express Havoc From stevelist at silverorange.com Thu Jun 17 03:22:01 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Thu, 17 Jun 2004 00:22:01 -0300 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087440730.9717.177.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> <1087419119.9717.124.camel@localhost.localdomain> <1087421091.7932.33.camel@localhost.localdomain> <1087426505.9717.156.camel@localhost.localdomain> <1087440730.9717.177.camel@localhost.localdomain> Message-ID: <40D10E59.1080908@silverorange.com> Havoc Pennington wrote: > Hi, > I was noticing on Windows XP the other day that the toplevel 4-5 "most > frequently used" apps show two names: > > Email > Outlook Express Windows XP does this for the default email client and web browser, but I don't think any other applications. Here's a screenshot: http://www.microsoft.com/presspass/newsroom/winxp/images/img009.jpg The terms "Internet" and "Email" are permanent. The app names update to reflect the current default apps. Steven From bclark at redhat.com Thu Jun 17 04:57:33 2004 From: bclark at redhat.com (Bryan Clark) Date: Thu, 17 Jun 2004 00:57:33 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087426505.9717.156.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> <1087419119.9717.124.camel@localhost.localdomain> <1087421091.7932.33.camel@localhost.localdomain> <1087426505.9717.156.camel@localhost.localdomain> Message-ID: <1087448253.3391.39.camel@localhost.localdomain> On Wed, 2004-06-16 at 18:55 -0400, Havoc Pennington wrote: > Maybe some kind of flow chart? > > If you have a diamond in the flow chart labeled "judgment call" that's > basically going to mean "ask Seth and Bryan" for Fedora Core, but for > all third parties it's going to mean "make up something that we will > have to fix on the Fedora level" > > Maybe an "if in doubt, foo" kind of phrasing based on which answer is > statistically more probable would minimize our work ;-) > > I'm less worried about ISVs (who will inevitably name it "Our Trademark > Here(tm)" no matter what we say) than I am about upstream projects and > Fedora Extras. Upstream projects and Fedora Extras should be right on track with the Name and GenericName spec as it stands, however I think it could be clarified even more to give better "if in doubt" statements. :-) Seth and I will get this up soon. As for Fedora Core, unless there is some change in the spec or behavior of the menu code we'll end up munging the GenericName into the Name for most of the upstream code that is correct according to the spec. The current system and spec work fine except for the case of keeping the standard names intact after 3rd party apps are installed. By copying the GenericName to the Name we fix this on an app by app basis. However if we can change the behavior of the code that displays the names it's better for the GNOME Desktop and Fedora can get this behavior for free too. GNOME protects the name of the standard applications that it considers to makeup the desktop with this new behavior, the same would be true for Fedora. Seth made a good point (although this is not the best one, but one off the top of my head) about this with the Calculator in MS Windows. If for instance you installed a 3rd party calculator called "Sci-Soft Calculator" because you needed a really great scientific calculator on your PC. Should the original Calculator change it's name to be "Microsoft Calculator" now that there's a new kid on the block? Probably not, the calculator that ships with the desktop is already branded by the entire desktop and doesn't need the added branding. It is simply _the_ "Calculator" of the desktop. Especially true if the calculator happened to come from a company that was bought by MS, all of a sudden it would show it's true colors and be the "SCO Calculator" (hypothetical situation of course). ~ Bryan From jspaleta at gmail.com Thu Jun 17 12:09:18 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 17 Jun 2004 08:09:18 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087448253.3391.39.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> <1087419119.9717.124.camel@localhost.localdomain> <1087421091.7932.33.camel@localhost.localdomain> <1087426505.9717.156.camel@localhost.localdomain> <1087448253.3391.39.camel@localhost.localdomain> Message-ID: <604aa79104061705096e200920@mail.gmail.com> On Thu, 17 Jun 2004 00:57:33 -0400, Bryan Clark wrote: > Should the original Calculator change it's name to be > "Microsoft Calculator" now that there's a new kid on the block? > Probably not, the calculator that ships with the desktop is already > branded by the entire desktop and doesn't need the added branding. It > is simply _the_ "Calculator" of the desktop. Especially true if the > calculator happened to come from a company that was bought by MS, all of > a sudden it would show it's true colors and be the "SCO > Calculator" (hypothetical situation of course). Can you add/remove the MS calculator? And if so do you do it by just selecting "calculator" In the case of Epiphany in Fedora, when a home desktop user goes to add/remove "Web Browser" (Epiphany) after they have discovered Firefox and no longer care to use Epiphany, they have to know the brandname to be be able to uninstall it or reinstall it. Is there a plan in the works to make the concept of generic name for the default applications map over as useful concepts for the software install/removal operations? As much as seeing the name change will confuse people who install a second web browser. It will be much more confusing if they decided they don't need the default browser anymore and the add/remove software tools don't understand the concept of generic name as seen in the menus. -jef From christopher.blizzard at gmail.com Thu Jun 17 15:16:42 2004 From: christopher.blizzard at gmail.com (Chris Blizzard) Date: Thu, 17 Jun 2004 11:16:42 -0400 Subject: [Fwd: Re: Gnome Icons, Gnome/KDE Menus need improvement] In-Reply-To: <1087420789.7932.28.camel@localhost.localdomain> References: <1087221660.21952.14.camel@localhost.localdomain> <1087226159.3112.8.camel@localhost.localdomain> <40CDC2D6.30207@math.unl.edu> <1087412890.2567.15.camel@localhost.localdomain> <1087420789.7932.28.camel@localhost.localdomain> Message-ID: On Wed, 16 Jun 2004 17:19:49 -0400, Seth Nickell wrote: > Yeah, I agree. In cases where heavy branding has already been done, it > will be easiest for people to recognize the brand. E.g. if we're > offering Coke in our menus (and our menus have plenty of, ahem "coke"), > I'd call it Coke, not "Cola Beverage". Our goal should be to use the > lowest noise / most identifiable name. The apache brand is strong enough > in sysadmin circles that I would definitely label an apache menu item > (if we were to have such a thing for some wacky reason *grin*) "Apache > Web Server". I caution, however, that while the Firefox (or > OpenOffice.org) brand could in theory be strong in 2 years, its > basically non-existant in the general office worker population today. Even so, is it in our best interest to promote the Firefox brand because it promotes our goals, even outside of the distribution of our operating system? If people are exposed to it one place, they might be willing to use it in other places as well (think home vs. office.) The more people using something other than IE, the better. Promoting the Firefox brand does this. > >From a usability perspective: > In cases where the brand does not already exist (the norm for > practically all of our apps relative to, say, Abby), we should use > generic names. Branding is usually a process of educating people about > things they don't need to know, but we want them to know. It is not > typically helpful from a usability perspective (there are cases where it > is, but on the whole, not so much). We should not be reducing usability > to help establish brands, though where a brand is established we can > leverage it ). There's also uneducating people as well. That is, if someone has had a bad experience in the past with brand Y and those problems have been fixed, rebrand as brand Z and you have the chance to re-educate under the new brand. (Netscape 6 was terrible. Firefox is, by comparison, not.) > > >From a branding perspective: > Prolific brands lead to brand dillution and reduces the ability to have > *any* distinct brands. In the marketplace you can't control this, > because everyone will try to establish a brand. In this case we can. We > can effect how many brands show up in the interface. Yep. You need to pick and choose. --Chris From yusufg at outblaze.com Fri Jun 18 00:31:41 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Fri, 18 Jun 2004 08:31:41 +0800 Subject: Mozilla slowdown due to default IPv6 enabling in FC2 Message-ID: <20040618003141.GA8602@outblaze.com> Mozilla hacker Darin Fisher provides more insight on the side effect of enabling IPv6 by default in FC2 http://weblogs.mozillazine.org/darin/archives/005753.html -- Yusuf Goolamabbas yusufg at outblaze.com From hp at redhat.com Fri Jun 18 01:26:38 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 17 Jun 2004 21:26:38 -0400 Subject: Internet data synchronization Message-ID: <1087521998.9717.331.camel@localhost.localdomain> Hi, http://www.idealog.us/2004/06/my_article_micr.html We could start really simple: a global setting with a gnome-vfs URI where your data should be stored. Each app could then store stuff there. Havoc From alexl at redhat.com Fri Jun 18 06:32:54 2004 From: alexl at redhat.com (Alexander Larsson) Date: 18 Jun 2004 08:32:54 +0200 Subject: Internet data synchronization In-Reply-To: <1087521998.9717.331.camel@localhost.localdomain> References: <1087521998.9717.331.camel@localhost.localdomain> Message-ID: <1087540374.1952.167.camel@localhost.localdomain> On Fri, 2004-06-18 at 03:26, Havoc Pennington wrote: > Hi, > > http://www.idealog.us/2004/06/my_article_micr.html > > We could start really simple: a global setting with a gnome-vfs URI > where your data should be stored. Each app could then store stuff there. A cool thing would be to store stuff to a webdav uri that is backed by subversion. That way you'd also get automatic version history. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a notorious gay rock star with a secret. She's a wealthy tomboy lawyer operating on the wrong side of the law. They fight crime! From bartk at clara.co.uk Fri Jun 18 21:23:50 2004 From: bartk at clara.co.uk (Bart Kalita) Date: Fri, 18 Jun 2004 22:23:50 +0100 Subject: access to fedora logos and images Message-ID: <1087593830.5899.18.camel@nemesis.astradine.net> Can anybody point me in a direction of Fedora Core 2 logos? I've managed to find few in rpms on a DVD and found few more in previous posts in this group. What I am mainly looking for are good quality fedora core logos form gnome desktop ( the ones with "2" in the background ) I was thinking about making some high resolution wallpapers. -- __________________________________________________________ Bart Kalita MCP Registered Linux user #347493 Fedora Core 2 www.bart-domain.com www.astradine.no-ip.org From stevelist at silverorange.com Fri Jun 18 21:50:45 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Fri, 18 Jun 2004 18:50:45 -0300 Subject: access to fedora logos and images In-Reply-To: <1087593830.5899.18.camel@nemesis.astradine.net> References: <1087593830.5899.18.camel@nemesis.astradine.net> Message-ID: <40D363B5.6020900@silverorange.com> Bart Kalita wrote: > Can anybody point me in a direction of Fedora Core 2 logos? I think you'll find what you're looking for here: http://people.redhat.com/glesage/artwork/ Note to RedHat people: I understand Garrett isn't at RedHat anymore, but can you make sure this stays up anyhow? Thanks, Steven Garrity From bartk at clara.co.uk Fri Jun 18 22:59:33 2004 From: bartk at clara.co.uk (Bart Kalita) Date: Fri, 18 Jun 2004 23:59:33 +0100 Subject: access to fedora logos and images In-Reply-To: <40D363B5.6020900@silverorange.com> References: <1087593830.5899.18.camel@nemesis.astradine.net> <40D363B5.6020900@silverorange.com> Message-ID: <1087599573.5899.21.camel@nemesis.astradine.net> On Fri, 2004-06-18 at 22:50, Steven Garrity wrote: > Bart Kalita wrote: > > Can anybody point me in a direction of Fedora Core 2 logos? > > I think you'll find what you're looking for here: > http://people.redhat.com/glesage/artwork/ > > Note to RedHat people: I understand Garrett isn't at RedHat anymore, but > can you make sure this stays up anyhow? > > Thanks, > Steven Garrity > > Thanks. but.... I've already got them, I am still in search of that elusive logo though :) -- __________________________________________________________ Bart Kalita MCP Registered Linux user #347493 Fedora Core 2 www.bart-domain.com www.astradine.no-ip.org From nigelnye at comcast.net Fri Jun 18 22:44:12 2004 From: nigelnye at comcast.net (nigel) Date: Fri, 18 Jun 2004 18:44:12 -0400 Subject: smc usb problems Message-ID: Greetings I seem to be having trouble installing my usb wireless adapter (smc 2662 v4). How do I know that Linux can see the device? Also, the file type of the driver was *.o and not *.ko like the other wireless drivers--is that a problem? From matt at matthansen.net Sat Jun 19 00:52:20 2004 From: matt at matthansen.net (Matt Hansen) Date: Sat, 19 Jun 2004 10:52:20 +1000 Subject: access to fedora logos and images In-Reply-To: <1087599573.5899.21.camel@nemesis.astradine.net> References: <1087593830.5899.18.camel@nemesis.astradine.net> <40D363B5.6020900@silverorange.com> <1087599573.5899.21.camel@nemesis.astradine.net> Message-ID: <1087606340.2912.9.camel@topaz.homenet.lan> On Sat, 2004-06-19 at 08:59, Bart Kalita wrote: > On Fri, 2004-06-18 at 22:50, Steven Garrity wrote: > > Bart Kalita wrote: > > > Can anybody point me in a direction of Fedora Core 2 logos? > > > > I think you'll find what you're looking for here: > > http://people.redhat.com/glesage/artwork/ > > > > Note to RedHat people: I understand Garrett isn't at RedHat anymore, but > > can you make sure this stays up anyhow? > > > > Thanks, > > Steven Garrity > > > > > > Thanks. > > but.... I've already got them, I am still in search of that elusive logo > though :) Bart, I believe you're after file:///usr/share/pixmaps/splash/gnome-splash.png from the fedora-logos package? However, according to the COPYING file, I don't think you're allowed to modify the image in any way as stated in condition number 2: "2. You do not modify the appearance of any or all of the Logos in any manner; and" But IANAL, so I could be wrong. :D Regards, Matt -- Registered Linux User #348963 / counter.li.org GnuPG KeyID: 0xCE9F8922 / gnupg.org mhelios -- www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bartk at clara.co.uk Sat Jun 19 11:15:41 2004 From: bartk at clara.co.uk (Bart Kalita) Date: Sat, 19 Jun 2004 12:15:41 +0100 Subject: access to fedora logos and images In-Reply-To: <1087604312.2912.7.camel@topaz.homenet.lan> References: <1087593830.5899.18.camel@nemesis.astradine.net> <40D363B5.6020900@silverorange.com> <1087599573.5899.21.camel@nemesis.astradine.net> <1087604312.2912.7.camel@topaz.homenet.lan> Message-ID: <1087643740.2414.7.camel@nemesis.astradine.net> On Sat, 2004-06-19 at 01:18, Matt Hansen wrote: > On Sat, 2004-06-19 at 08:59, Bart Kalita wrote: > > On Fri, 2004-06-18 at 22:50, Steven Garrity wrote: > > > Bart Kalita wrote: > > > > Can anybody point me in a direction of Fedora Core 2 logos? > > > > > > I think you'll find what you're looking for here: > > > http://people.redhat.com/glesage/artwork/ > > > > > > Note to RedHat people: I understand Garrett isn't at RedHat anymore, but > > > can you make sure this stays up anyhow? > > > > > > Thanks, > > > Steven Garrity > > > > > > > > > > Thanks. > > > > but.... I've already got them, I am still in search of that elusive logo > > though :) > > Bart, I believe you're after > file:///usr/share/pixmaps/splash/gnome-splash.png from the fedora-logos > package? However, according to the COPYING file, I don't think you're > allowed to modify the image in any way as stated in condition number 2: > "2. You do not modify the appearance of any or all of > the Logos in any manner; and" > But IANAL, so I could be wrong. :D > > Regards, > Matt Is there anybody who could clarify that point for me?? I've made few wallpapers incorporating Fedora Core Logo http://astradine.bart-domain.com/Linux_wallpaper.rar they are horrid at best since I have no access to good quality logos and making them from scratch seems a bit silly. Now I do not know if I'm supposed to be looking for a good layer or continue digging through RPMS in search of more images. At the end of the day all I want is to "advertise" Fedora Core with no financial gain and since there are no official wallpapers I thought that my little "hobby" won't bother anyone. Hope I was not wrong and that there is a place or a person who has those images and is willing to share. -- __________________________________________________________ Bart Kalita MCP Registered Linux user #347493 Fedora Core 2 www.bart-domain.com www.astradine.no-ip.org From programing at mbss.org Sat Jun 19 12:45:00 2004 From: programing at mbss.org (Damir Dezeljin) Date: Sat, 19 Jun 2004 13:45:00 +0100 (GMT-1) Subject: Locking down Fedora Core 2 desktop Message-ID: Hi. I installed Fedora Core 2 on a new PC. This PC will be a dedicated to guests of a hotel. For this reason it should provide some functionality on one side and on other side it should prevent users to do other stuff. The functionality needed: 1. User friendly; 2. Browsing the Internet; 3. Sending / receiving mails (from web browser ... so same as first); 4. Multi lingual; 5. Open-Office (it should be allowed for a guest to write a short document and to print it); 6. Copying files from memory cards (e.g. Compact-Flash) to CD (CD burner). 7. Remote locking (or at least loging off) of local loged user desktop. I'm planing of using GNOME desktop. Functionality from 1. to 6. is provided by default by Fedora Linux. So I still have to solve some problems: 1. Is it possible to remotely (from SSH session) lock the desktop (screen saver lock ?) of the local loged user? How can I achieve this? 2. Is it possible to remotely (from SSH session) log out a local loged in user without restarting the X server (init 3 && init 5)? How can I achieve this? 3. Is there any easy way or a compressible (easy) doc file how to costumize GNOME menses and desktop? I want to leave only few icons in the menu / desktop? Can I make this settings writable only by root (read only for user) so that after logout / login the predefined settings will be loaded? 4. Is it posible to prevent a user from running not allowed applications? I want to avoid changing 'x' bit of N binaries. I would like to costumize a file browser to allow only browsing memory cards and copy the content to CDs ... I also want to disallow creating shortcuts on the desktop (so that the user will not be able to run e.g. xterm). How can I do this? 5. Which 'easy to use' program should I use for burning CDs? Any additional hint / suggestion? Regards, Dezo From pavels at capital.lv Sat Jun 19 12:51:40 2004 From: pavels at capital.lv (Pavels Nikolajevs) Date: Sat, 19 Jun 2004 15:51:40 +0300 Subject: Locking down Fedora Core 2 desktop In-Reply-To: References: Message-ID: <40D436DC.3050105@capital.lv> Greetings >1. User friendly; > > check >2. Browsing the Internet; > > firefox 0.9+flash plugin, disable xpiinstall, remove nullplugin >3. Sending / receiving mails (from web browser ... so same as first); > > thunderbird? >4. Multi lingual; > > check all languages at install >5. Open-Office (it should be allowed for a guest to write a short document > and to print it); > > check >6. Copying files from memory cards (e.g. Compact-Flash) to CD (CD burner). > > mkdir /mnt/flash and add entry to /etc/fstab >7. Remote locking (or at least loging off) of local loged user desktop. > > hmm.... never tried to do that, but I think it's possible >3. Is there any easy way or a compressible (easy) doc file how to > costumize GNOME menses and desktop? I want to leave only few icons in > the menu / desktop? > Can I make this settings writable only by root (read only for user) so > that after logout / login the predefined settings will be loaded? > > painful, but possible. gnome docs contain very little of it, but you should read gnome sysadmin's guide >4. Is it posible to prevent a user from running not allowed applications? > I want to avoid changing 'x' bit of N binaries. I would like to costumize > a file browser to allow only browsing memory cards and copy the content > to CDs ... I also want to disallow creating shortcuts on the desktop (so > that the user will not be able to run e.g. xterm). How can I do this? > > don't allow them run from root. everything else can be achieved setting correct permissions on Desktop directory >5. Which 'easy to use' program should I use for burning CDs? > > Default nautilus CD burner From robdumas at optonline.net Sat Jun 19 18:21:38 2004 From: robdumas at optonline.net (Robert Dumas) Date: Sat, 19 Jun 2004 14:21:38 -0400 Subject: access to fedora logos and images In-Reply-To: <40D363B5.6020900@silverorange.com> References: <1087593830.5899.18.camel@nemesis.astradine.net> <40D363B5.6020900@silverorange.com> Message-ID: <40D48432.1030104@optonline.net> Seems like a close enough topic to ask: is the word "Fedora" in the logo Myriad Pro Italic? It looks an awful lot like it. -- Robert D. Steven Garrity wrote: > Bart Kalita wrote: > > Can anybody point me in a direction of Fedora Core 2 logos? > > I think you'll find what you're looking for here: > http://people.redhat.com/glesage/artwork/ > > Note to RedHat people: I understand Garrett isn't at RedHat anymore, but > can you make sure this stays up anyhow? > > Thanks, > Steven Garrity > > -- -------------------------------------------------------------- Robert Dumas // robdumas at optonline.net http://obnoxio.us/ // AIM: ThisMessIAmIn From wtogami at redhat.com Thu Jun 24 05:44:44 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 23 Jun 2004 19:44:44 -1000 Subject: Help Needed: Firefox 0.9 & Thunderbird 0.7 Message-ID: <40DA6A4C.7000803@redhat.com> https://bugzilla.fedora.us/show_bug.cgi?id=1617 Firefox 0.9 https://bugzilla.fedora.us/show_bug.cgi?id=1765 Thunderbird 0.7 Your help is needed to fix the Firefox 0.9 and Thunderbird 0.7 packages for Fedora Extras updates. Both have problems that may require upstream help in order to solve. Even if you are unable to program, your assistance in communicating with upstream developers would be greatly appreciated. Warren Togami wtogami at redhat.com