Is it a requirement that you use XDMCP? Most organizations have
switched to using ssh to connect to a remote machine, and then
launching applications through the ssh tunnel.
Look, the whole reason for X11 on Macs is to be compatible with
applications and business processes which have not yet drunk the
kool-aid and ported themselves to Quartz and the Apple Way. The
compatibility is the key here, not the improvements.
Messages like this are the reason that many of my colleagues place a
low priority on participating in these discussions. And when I say
"messages like this", I specifically mean "general rants about
dissatisfaction with changes in Leopard that are responses to
specific, targeted help I am trying to give a user to overcome a
specific problem they are seeing in the software that I spent the last
year working on.
If compatibility is a concern, you should stick with a configuration
that you know works. Why upgrade?
This is why, for example, you want the part of the DISPLAY value in
front of the colon to be blank or a hostname, not something else.
Irrelevant. I've seen a very small number where our special $DISPLAY
value broke things. When it has, generally it's been due to poor
assumptions on the part of the author of the code that broke, and it
has been trivially fixable. The ds9 situation is a special case, and
I covered it in depth in another message; in any case, there's a
trivial workaround.
This is why you want XDMCP to work.
I want *everything* to work. I really do. I only work as hard on
this software as I do because I believe in its importance.
I know people use XDMCP -- we used it in all our labs in college
(mostly on SparcStations).
However, we received no reports of XDMCP not working during Leopard's
entire development cycle. Not from participants in the Developer seed
program, nor from Customer Seeding. We don't have a setup made to
test out XDMCP -- I could have probably thrown one together if I'd
known there was a need to, but I did not know.
Although we're still investigating, I'm beginning to believe that
XDMCP is broken due to changes at a lower level of OS X than X11.
Has anyone had any luck getting it to work using Tiger's X11.app on
Leopard?
This is why you want people's ~/.xinitrc files, including their
settings of the DISPLAY environment variable, to work.
This is also irrelevant to XDMCP, but I'll still respond. When Apple
had issues like this a few releases ago with the early versions of
X11.app, they put in a warning that popped up the first time you ran
X11 that advised you that certain xinitrc setups might cause
undesirable behavior in X11.app. In retrospect, it would have been
nice to do this if we detected that $DISPLAY was being overridden, but
it didn't occur to me at the time, no testers suggested it, and I was
busy fixing other bugs, anyway.
This is why you test with applications like OpenOffice and the GIMP,
major X11-based Mac applications, before putting a brand-new way of
doing X11 in a major operating system release.
There are more X11 applications than OS X applications, but only one
of me. Our seedings program help make up for that; I see at least
three instances during Leopard's dev cycle where X11 changes broke
OpenOffice, developers filed bug reports, and I fixed it. I'm not
aware of any outstanding OpenOffice issues, with the exception of some
font issues that I haven't been able to reproduce and that nobody else
on this list has been able to help me identify.
Gimp.app testing was hampered by their hacky inclusion of X11
libraries in their .app bundle. I'm glad that they were able to make
the bundle work in Tiger; a lot of people found it very useful. I
spent a day trying to figure out if there was a way to prevent it from
breaking on Leopard, but decided it was technically infeasible; that
approach is unavoidably dependent on the specific versions of the
libraries it's trying to override.
It should be easy for them to release a new, Leopard-compatible
version; they haven't, yet, presumably because it's a project
maintained by unpaid volunteers.
Again, this has nothing to do with "a brand new way of doing X11".
And why, if they don't work, you ship that OS release with the old
way of doing things,
rather than the new not-yet-working version.
Apple doesn't have the cash to blow on paying developers to work on
software that we don't then plan to release -- on the contrary, they
would have saved a whole year's worth of my salary (at least) by
staying with the old X11.app. We'd then have people complaining that
we were neglecting X11.app -- which we had been. Unfortunately,
there's no magic way to upgrade software while preventing any
breakage. All we can do is architect our software carefully (check),
ask a few thousand people to test it (check) and then fix the bugs
that they find (done, as best we could), and then address the issues
that arise upon release.
--
Ben Byer
CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/x11-users/email@hidden
