I just had an amusing moment with FC4, and while I don't know if this is actually a bug in any component, it made for an unexpected experience. Take it or leave it.
I'm sitting a few feet away from the FC4 box. I'm logged into Gnome, and I'm playing an audio CD with the Gnome CD Player applet (2.10.2), a.k.a. the local session.
I'm also logged into the same FC4 box via NX, which is also running a separate Gnome (a.k.a. the remote session).
I eject the CD, and put in another.
Both the local and the remote sessions get their own CD Players, and both CD Players seem to be "playing" the CD (the song position dragger is moving in both), and both show the correct CDDB entry.
I stop and play the CD using the CD Player in the remote session. It stops, and starts as it should. The CD Player in the local session is now out of synch -- it detects the "stop", but not the "play".
There were two unexpected things in this tale: first, the "remote" Gnome session shouldn't have gotten a CD Player (if only because I didn't try to forward audio in my NX settings, for one, but there are also probably security considerations about console owners and such). Second, the "local" CD Player should've been in synch with what was going on with the CD (e.g., track changes were not reflected).
If any of these are actual bugs, please tell me the components and I'll file them.
Jack Tanner wrote:
I just had an amusing moment with FC4, and while I don't know if this is actually a bug in any component, it made for an unexpected experience. Take it or leave it.
This addendum I'm pretty sure actually is a bug: when I logged out of the "local" session, I couldn't use the CD Player to eject the CD any more.
On Tue, 2005-12-13 at 17:58 -0500, Jack Tanner wrote:
Jack Tanner wrote:
I just had an amusing moment with FC4, and while I don't know if this is actually a bug in any component, it made for an unexpected experience. Take it or leave it.
This addendum I'm pretty sure actually is a bug: when I logged out of the "local" session, I couldn't use the CD Player to eject the CD any more.
Well, it isn't. It is a feature of pam_console again. It tracks only local sessions and removes the rights on the device when you log out of it.
On 12/13/05, Jack Tanner ihok@hotmail.com wrote:
If any of these are actual bugs, please tell me the components and I'll file them.
I don't know if there is any technical mechanism to tell the first gnome session from the session exported over NX. Both sessions are really just 2 local gnome sessions being run by the same user. I imagine if you started a second session via gdmflexiserver and login as the same user or start up a vncserver with a gnome desktop it should behave similarly to the original session. Both your sessions are the same user and the "console" concept as used by pam tracks username so I'm not sure how you would restrict the first session as special unless there is some special commandline magic you can pass to gnome-session that I am unaware of.
If there is a bug here it probably has to do with the fact that the cd-player application itself gets out of sync across multiple invocations. Can you reproduce this by starting 2 gnome-cd instances in the same gnome session?
-jef
Jeff Spaleta wrote:
If there is a bug here it probably has to do with the fact that the cd-player application itself gets out of sync across multiple invocations. Can you reproduce this by starting 2 gnome-cd instances in the same gnome session?
Yes. 1. Starting 1 gnome-cd instance, play the CD. 2. Start another gnome-cd. It won't catch that the CD is playing.
Jack Tanner wrote:
If there is a bug here it probably has to do with the fact that the cd-player application itself gets out of sync across multiple invocations. Can you reproduce this by starting 2 gnome-cd instances in the same gnome session?
Yes.
- Starting 1 gnome-cd instance, play the CD.
- Start another gnome-cd. It won't catch that the CD is playing.
I was gonna file a bug about this, but could someone running Rawhide reproduce this first? FC4 is on 2.10.0, and that's probably too old to file about...
On Tue, 2005-12-13 at 17:42 -0500, Jack Tanner wrote:
There were two unexpected things in this tale: first, the "remote" Gnome session shouldn't have gotten a CD Player (if only because I didn't try to forward audio in my NX settings, for one, but there are also probably security considerations about console owners and such). Second, the "local" CD Player should've been in synch with what was going on with the CD (e.g., track changes were not reflected).
I've seen this kind of thing too on FC4--I've plugged in my digital camera via USB and both the console and an X terminal have been got the "Import Photos" pop-up.
Wil
Hi,
Just one question about this thread. Are local and remote the same user? If so, won't there be some reuse of the daemons etc that handle dbus interaction etc.
I know with kde that it is a bit scary running 2x sessions as the same user. Things don't always behave. Not sure about gnome
Just a though.
Darren Steven
On Tue, 2005-12-13 at 17:42 -0500, Jack Tanner wrote:
There were two unexpected things in this tale: first, the "remote" Gnome session shouldn't have gotten a CD Player (if only because I didn't try to forward audio in my NX settings, for one, but there are also probably security considerations about console owners and such). Second, the "local" CD Player should've been in synch with what was going on with the CD (e.g., track changes were not reflected).
I've seen this kind of thing too on FC4--I've plugged in my digital camera via USB and both the console and an X terminal have been got the "Import Photos" pop-up.
Wil
Wil Cooley wcooley@nakedape.cc Naked Ape Consulting, Ltd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, 2005-12-15 at 09:24 +1100, Darren Steven wrote:
Hi,
Just one question about this thread. Are local and remote the same user? If so, won't there be some reuse of the daemons etc that handle dbus interaction etc.
I know with kde that it is a bit scary running 2x sessions as the same user. Things don't always behave. Not sure about gnome
GNOME brings up a dialog warning you that you're already logged in if you try and log in twice. Its not very strongly worded, but the implication is "please don't do that".
One of the more annoying things is you can't run more than one copy of Galeon. Trying to launch a second copy only results in the original copy opening a new window in the original session. And the gnome panel tends to get a bit flaky. Etc...
IMHO this is really broken. You should be able to log in to GNOME more than once. After all, you can log in as many times as you want to a shell. Seems like a horrible regression of functionality as far as unix philosophy is concerned.
On Thu, 2005-12-15 at 01:47 -0600, Callum Lerwick wrote:
IMHO this is really broken. You should be able to log in to GNOME more than once. After all, you can log in as many times as you want to a shell. Seems like a horrible regression of functionality as far as unix philosophy is concerned.
It's probably done on purpose as a usability thing. They probably assume that if you have windows open on more than one machine, you're too stupid to remember which is which; so you have to be banned from doing it in the first place.
Some day soon, I expect the GNOME web browser du jour will actively filter out big words from the pages it's displaying, in case they confuse the user.
We're not far from that day already, in fact -- Evolution already refuses to display error messages it receives from the SMTP server, _even_ in an optional 'show details' section of the error dialog. Instead it makes up its own 'reasons' for the failure which are often completely incorrect. (Bug #165271)
On Thu, 2005-12-15 at 01:47 -0600, Callum Lerwick wrote:
On Thu, 2005-12-15 at 09:24 +1100, Darren Steven wrote:
Hi,
Just one question about this thread. Are local and remote the same user? If so, won't there be some reuse of the daemons etc that handle dbus interaction etc.
I know with kde that it is a bit scary running 2x sessions as the same user. Things don't always behave. Not sure about gnome
GNOME brings up a dialog warning you that you're already logged in if you try and log in twice. Its not very strongly worded, but the implication is "please don't do that".
One of the more annoying things is you can't run more than one copy of Galeon. Trying to launch a second copy only results in the original copy opening a new window in the original session. And the gnome panel tends to get a bit flaky. Etc...
IMHO this is really broken. You should be able to log in to GNOME more than once. After all, you can log in as many times as you want to a shell. Seems like a horrible regression of functionality as far as unix philosophy is concerned.
Hmm, what the heck for? That's what Desktop->Preferences->Remote Desktop is for, really. What's the case for logging in twice? Shell and desktop are so totally different that I'm not convinced that they should operate the same way here (not that my opinion matters, really). Should we expect all applications that provide GUI to put in a ton of work to account for a case that a fairly small number of people might actually use?
Dan
On Thu, 2005-12-15 at 08:07 -0500, Dan Williams wrote:
On Thu, 2005-12-15 at 01:47 -0600, Callum Lerwick wrote:
On Thu, 2005-12-15 at 09:24 +1100, Darren Steven wrote:
Hi,
Just one question about this thread. Are local and remote the same user? If so, won't there be some reuse of the daemons etc that handle dbus interaction etc.
I know with kde that it is a bit scary running 2x sessions as the same user. Things don't always behave. Not sure about gnome
GNOME brings up a dialog warning you that you're already logged in if you try and log in twice. Its not very strongly worded, but the implication is "please don't do that".
One of the more annoying things is you can't run more than one copy of Galeon. Trying to launch a second copy only results in the original copy opening a new window in the original session. And the gnome panel tends to get a bit flaky. Etc...
IMHO this is really broken. You should be able to log in to GNOME more than once. After all, you can log in as many times as you want to a shell. Seems like a horrible regression of functionality as far as unix philosophy is concerned.
Hmm, what the heck for?
Because Unix and Linux are OSes having been designed to work in a network.
That's what Desktop->Preferences->Remote Desktop is for, really. What's the case for logging in twice?
Because you work in a network ...
Standard situations: * You login into your personal "desktop" in your office, and leave for another room, on the same network and want to login there ... * Several monitors on your desktop physically connected to different machines, but with a common and shared (networked) /home underneath.
Shell and desktop are so totally different that I'm not convinced that they should operate the same way here (not that my opinion matters, really).
The problems underneath are the same. Saving a bash history isn't actually different from saving "Desktop"-setup.
Should we expect all applications that provide GUI to put in a ton of work to account for a case that a fairly small number of people might actually use?
Yes. That's what GUI-toolkits are for. It's not individual applications which should have to care about, it's the GUI-toolkit which should take care about transparently to the user and to the developer.
Ralf
On Thu, 2005-12-15 at 14:37 +0100, Ralf Corsepius wrote:
Standard situations:
- You login into your personal "desktop" in your office, and leave for
another room, on the same network and want to login there ...
- Several monitors on your desktop physically connected to different
machines, but with a common and shared (networked) /home underneath.
Actually that is very different from logging in several times on the same machine. (Unless you use LTSP I guess, but that's not what you said.) logging in multiple times on separate machines sharing a networked /home is supposed to be supported in Gnome; it has been problematic occasionally but that's because of bugs.
/Per
On Thu, 2005-12-15 at 08:20 -0800, Per Bjornsson wrote:
On Thu, 2005-12-15 at 14:37 +0100, Ralf Corsepius wrote:
Standard situations:
- You login into your personal "desktop" in your office, and leave for
another room, on the same network and want to login there ...
- Several monitors on your desktop physically connected to different
machines, but with a common and shared (networked) /home underneath.
Actually that is very different from logging in several times on the same machine. (Unless you use LTSP I guess, but that's not what you said.)
It's very similar to XDMCP from another box, which _is_ logging on to the machine twice.
On Thu, 2005-12-15 at 08:20 -0800, Per Bjornsson wrote:
On Thu, 2005-12-15 at 14:37 +0100, Ralf Corsepius wrote:
Standard situations:
- You login into your personal "desktop" in your office, and leave for
another room, on the same network and want to login there ...
- Several monitors on your desktop physically connected to different
machines, but with a common and shared (networked) /home underneath.
Actually that is very different from logging in several times on the same machine. (Unless you use LTSP I guess, but that's not what you said.)
I don't know what LTSP is ;)
Actually the situation I am talking about is quite simple: shared/networked /home on a file server, several desktop client machines.
logging in multiple times on separate machines sharing a networked /home is supposed to be supported in Gnome; it has been problematic occasionally but that's because of bugs.
Well, the situation isn't as problematic as it used to be, but it still is far from being perfect, IMO.
This starts with different machines having different screen resolutions/sizes and GNOME not being able to cope with this, over various tiny probs in sharing files and ends with running several instances of desktop applications in parallel on different machines, using the same /home underneath.
Questions such as * How do/do applications detect other instances are sharing their resources (e.g. preferences, caches, desktop setup)? * How are user-customized machine-specific setups handled (e.g. having added hard-ware specific desktop applets)?
as far as I can tell, to a large extend, these cases aren't handled "that well" at all in any GUI-toolkit/Desktop, but are left to be handled in applications and by the user ("don't run 2 instances of XXX").
Ralf
On Thu, 2005-12-15 at 08:07 -0500, Dan Williams wrote:
On Thu, 2005-12-15 at 01:47 -0600, Callum Lerwick wrote:
On Thu, 2005-12-15 at 09:24 +1100, Darren Steven wrote:
Hi,
Just one question about this thread. Are local and remote the same user? If so, won't there be some reuse of the daemons etc that handle dbus interaction etc.
I know with kde that it is a bit scary running 2x sessions as the same user. Things don't always behave. Not sure about gnome
GNOME brings up a dialog warning you that you're already logged in if you try and log in twice. Its not very strongly worded, but the implication is "please don't do that".
One of the more annoying things is you can't run more than one copy of Galeon. Trying to launch a second copy only results in the original copy opening a new window in the original session. And the gnome panel tends to get a bit flaky. Etc...
IMHO this is really broken. You should be able to log in to GNOME more than once. After all, you can log in as many times as you want to a shell. Seems like a horrible regression of functionality as far as unix philosophy is concerned.
Hmm, what the heck for?
We have set the following in /etc/profile.d/gconf.sh (and csh equiv): export GCONF_SHARED_LOCKS=1 export GCONF_GLOBAL_LOCKS=1
This allows our folks logged into GNOME on their desktop to also walk into a lab and log into hosts sharing $HOME. Without the above environment variables, GNOME always complained.
/Brian/
On Thu, 2005-12-15 at 08:54 -0500, Brian Long wrote:
On Thu, 2005-12-15 at 08:07 -0500, Dan Williams wrote:
Hmm, what the heck for?
We have set the following in /etc/profile.d/gconf.sh (and csh equiv): export GCONF_SHARED_LOCKS=1 export GCONF_GLOBAL_LOCKS=1
This allows our folks logged into GNOME on their desktop to also walk into a lab and log into hosts sharing $HOME. Without the above environment variables, GNOME always complained.
Right, fair enough. I think there's always been the expectation that you can at least share $HOME between two different logons on different machines. I was reading "log into gnome twice on the same machine" rather than sharing $HOME and logging into two different boxes.
Dan
On Thu, Dec 15, 2005 at 09:21:17AM -0500, Dan Williams wrote:
On Thu, 2005-12-15 at 08:54 -0500, Brian Long wrote:
On Thu, 2005-12-15 at 08:07 -0500, Dan Williams wrote:
Hmm, what the heck for?
We have set the following in /etc/profile.d/gconf.sh (and csh equiv): export GCONF_SHARED_LOCKS=1 export GCONF_GLOBAL_LOCKS=1
This allows our folks logged into GNOME on their desktop to also walk into a lab and log into hosts sharing $HOME. Without the above environment variables, GNOME always complained.
Right, fair enough. I think there's always been the expectation that you can at least share $HOME between two different logons on different machines. I was reading "log into gnome twice on the same machine" rather than sharing $HOME and logging into two different boxes.
Given the proliferation of session daemons, perhaps the right answer is for people who need this to use Linux-Vserver or OpenVZ to provide isolation similar to running on separate machines with a network share.
-Bill
Hi
Given the proliferation of session daemons, perhaps the right answer is for people who need this to use Linux-Vserver or OpenVZ to provide isolation similar to running on separate machines with a network share.
Unless these patches get upstream, they are not the right answer - atleast for Fedora.
regards Rahul
On Thu, Dec 15, 2005 at 10:19:53PM +0530, Rahul Sundaram wrote:
Given the proliferation of session daemons, perhaps the right answer is for people who need this to use Linux-Vserver or OpenVZ to provide isolation similar to running on separate machines with a network share.
Unless these patches get upstream, they are not the right answer - atleast for Fedora.
Oh, I certainly agree; my point is that for someone who *really* needs this capability, rather than just "oh that would be nice and clean...", there is a route available. Just as audio workstation users take Fedora Core and transform it into PlanetCCRMA by running adding a bunch of packages and running a custom Ingo-turbocharged RT kernel. In both case, the stuff might make it upstream one day, or might not.
Xen provides an interesting example too. Over the years there have been dozens of checkpoint/migrate/restart mechanisms developed at the process level, and they are complicated beasts. With Xen, the unit of encapsulation is the OS instance, and a non-local filesystem and gratuitous ARP are about all that's required.
-Bill
Dan Williams wrote:
Hmm, what the heck for? That's what Desktop->Preferences->Remote Desktop is for, really. What's the case for logging in twice? Shell and desktop are so totally different that I'm not convinced that they should operate the same way here (not that my opinion matters, really). Should we expect all applications that provide GUI to put in a ton of work to account for a case that a fairly small number of people might actually use?
Wow. I had no idea that this would be controversial.
Yes, sometimes I log into Gnome twice as the same user on the same machine. For example, my FC4 box has a CD burner; my Windows box doesn't. But, my Windows box has a nicer monitor than the FC4 box. So, I log into the FC4 box locally, and do the CD burning dance on that machine.
At the same time, I sit at my Windows box, log into the FC4 box via NX, and run other user apps (Thunderbird, etc.)
It seemed completely natural to me to use my desktop that way.
On 12/15/05, Jack Tanner ihok@hotmail.com wrote:
At the same time, I sit at my Windows box, log into the FC4 box via NX, and run other user apps (Thunderbird, etc.)
It seemed completely natural to me to use my desktop that way.
This is only happening because you choose to use NX instead of the available vnc technology exposed via Gnome's vino. Helping to get NX support coded into vino so Desktop->preferences->remote desktop acts a NX session would prevent what you are seeing. Feel free to convince the NX people to work more closely with the Gnome developers to get native NX support working, or convince them to produce something similar to vino so you can avoid the unnecessary second login and reuse your existing local desktop which is already running.
-jef