[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: XDMCP Core 3



On Thu, 2005-01-20 at 17:27, Kyrre Ness Sjobak wrote:
> tor, 20.01.2005 kl. 12.20 skrev Jonathan Andrews:
> > On Thu, 2005-01-20 at 08:14, Mark McLoughlin wrote: 
> > > Hi,
> > > 
> > > On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote:
> > > > Is XDMCP, remote X bust in core 3 ?
> > > 
> > > 	I was using it not so long ago and it was working fine.
> > > 
> > > > I've tried the gui configuration for tool gdm. The machine has no
> > > > firewall enabled - all I get the "gdm_child_action: Aborting display
> > > > jonspc:1" in the log ?
> > > 
> > > 	I'm suprised that's the only message you get - a glance at the code
> > > suggests if you're getting this error message (which is from the master)
> > > you should be getting another message from the slave.
> > If found my problem, its a name resolver issue (thank you Mr Cox :-D )
> > I think email is on a go-slow, please look back if you have time.
> > 
> > Some comments on this and a few other things
> > 
> > 1) gdm doesn't have a process itself, it runs from init - but when gdm
> > is started it seems to undergo a name change to "gdm-binary" without
> > being owned by gdm or anything called gdm. As a result its not possible
> > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing
> > something here or this a bit naff ? 
> > 
> 
> it is. But you have the tools gdm-restart etc. (just type gdm*tabtab*
> and you'l find 'em

Thanks, i've found it - yet another small shell script.  In a way you
are making my point nicely.  Gnome broke the way xdm works when they
ported it into gnome, then they keep bodging on another shell script for
the functionality thats missing. I know in the global scheme of things
its a minor point, but breaking the sensible way process control works
just to add a few lines of logic before and after the process seems to
be a bit ... well ... you get the idea !

I have to admit gdm is pretty though (after xdm anything looks better)
:-)  - but to many bodges ... 

*** warning - nasty idea for Unix purists ***
Linux is general seems a bit confused about process control, init,
xinetd and rc all overlap slightly in functionality. Couldn't the entire
machine come up with just a slightly better xinetd and config files ? 
xinetd treats socket connects as an event - but isn't starting, stopping
or changing runlevel just another event ? 

Jon




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]