todays rawhide - feedback

[Mike A. Harris]

n0dalus wrote:
> On 2/20/06, Mike A. Harris <mharris at mharris.ca> wrote:
> 
>>xfs is started by default always, to ensure that it is running *if* you
>>run X, be that via gdm/xdm/kdm, or via "startx", as the X server will
>>not start if xfs is not running, unless you manually reconfigure the
>>X server to serve fonts directly.  While some users prefer to have the
>>X server serve fonts directly in this manner, this type of configuration
>>is not integrated well with the system the way our infrastructure is
>>set up currently.
> 
> This question seems a bit obvious, but why can't X just start xfs when
> it's run, or at least give a useful warning message when xfs is not
> available?

Solutions of that nature that try to be "too smart", tend to miss
various corner cases in the way people use things.  What if the
X server has been configured to connect to a remote font server
instead of one running on the local host?  What about multiple
font servers?  What would doing this really gain?

It would not really gain anything /really/ useful, and would only
increase the chances of bugs being introduced or hitting unexpected
usage corner cases that then have to also be worked around.  All that
work being done more or less as a wasted effort that does not buy
any really terribly useful functionality.

The system has worked fine the way it is for 6-8 years or so now, and
will probably continue to be shipped as-is until legacy core font
usage dies off and is completely replaced by fontconfig hopefully in
the future.

Any time spent enhancing, xfs, or anything related to core fonts in
general, is time invested in dead technology that continues to lose
more and more relevance each OS release.  It makes no sense to expend
any effort in this area, as doing so would be engineering time taken
directly away from interesting and useful projects that lay in the
direction where the X Window System is going - rather than where it
has been.

If we were just starting to implement core font system integration
at this point in time, what I would do, is avoid using xfs entirely,
and have chkfontpath or whatever utilities set to configure the
X server directly instead of using a separate font server.  The tables
would be turned, and our font installation scripts would then cause
the X server's configuration to be updated instead, and people who
desired the benefits (which are mostly debateable nowadays) of using
a font server would then be opting into setting xfs up themselves, for
local or networked operation.

In a perfect world, it would be theoretically nice if all of the
components in the puzzle supported either and/or both methods, and
it all just worked in every scenario a user might want to use core
fonts in, including with networked servers.

Unfortunately though, in the real world, the permutations of how all
of this stuff can be configured is quite a mess, and the majority of
users out there simply do not need such complexity.  As such the
system level integration of core fonts support is specifically
intended to handle the "default case", which it generally does fairly
well, despite some rough edges.  While it is of course definitely
possible to round those rough edges off, it the benefits to the
average user out there are essentially zero.

The core fonts system is ancient, very few applications really use
it nowadays, however there are enough apps that do still use it that
we can't kill it off unless we want hundreds of bug reports from
angry users griping about xterm not working, or their favourite motif
apps, etc.  (although some apps can optionally use fontconfig/Xft, but
most don't by default).  As long as we have to ship it, we certainly
don't want to rock the boat and destabilize what "works" more or less
now.

Please just let xfs rot in peace until we can just kill it completely.
An extra daemon running at boot time isn't really hurting anything, and
those who care that much can disable it easily.

If you're truly serious about your suggestion however, X.Org mailing
lists is the right place to suggest it, as I'm pretty sure we wouldn't
waste precious engineering cycles on such a low-gain feature.  ;o)




-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.