Re: Font sources

[Tim X]

"Dave Pawson" <dave.pawson@gmail.com> writes:

> On 15/09/2007, Tim X <timx@nospam.dev.null> wrote:
>
>> > xfs dead but pid file exists
>> > [dpawson@marge ~]$ service xfs start
>> > Starting xfs: rm: cannot remove directory `/tmp/.font-unix': Operation
>> > not permitted
>
> No Tim. Yet again it was my lack of knowledge. This time it was selinux.
> I'd messed with the contexts in /tmp and selinux was blocking all
> writes to there.
> Another lesson I guess, but it totally stopped xfs running.
> Now I can run the font commands as you say, except that FC7 seems not
> to have a .Xresources in my home directory. I've a feeling this is another
> one that uses /tmp again.

I've not yet got around to using selinux, so know nothing about it
really. IMO people get a bit too paranoid about security. My rule of thumb
is that security needs to match the assets your protecting. For my personal
Linux desktop, I actually have very little that is worth anything from a
security perspective. I do just the standard things (disable
unwanted/uneeded services, basic firewall that prevents incomming
connections that are not associated with an outgoing session, what I
thought were reasonably strong passwords (until I read about rainbow tables
and fast cracking!), using ssh with reasonably long passphrases, ssh/vpn
connections to remote sites only  and a couple of files which are encrypted
that contain possibly sensitive information  and thats about it. My system
is backed up regularly, so if it gets hacked, I can just wipe it away and
start with a frresh install. 

Note that not all distros will create a .Xresources. sometimes it is called
.Xdefaults (there is/was a distinction between the two once upon a time,
but I don't think it matters anymore). Try just creating one and see if it
makes a difference. It is very nlikely it would be stored in /tmp. Note
also that some window managers (such as KDE) will ignore/override some
things, like geometry and colours). 

> Further one, using xfontsel, I was unable to copy the eventual string over
> the the shell window. Possibly another X messup due to selinux.

Seems odd. All I need to do to 'copy' it across is to hit the 'select'
button in xfontsel and then switch to the window I want to paste it into
and hit the middle mouse button.

> A further install necessary to clean up. The selinux documentation is two
> versions out of date.
>
> Seemed no matter what I did xfs wouldn't run.
> On the new running system all the fonts are there as you say.
>
>
>
>>
>
>> > Seems like xfs is going out of fashion on Fedora.
>> > Wonder if other OS's will follow this direction.
>> >
>>
>> It is possible font servers will decline in use. Actually, I didn't run a
>> font server until it became a sort of default configuration (which I think
>> was back when I was running Red Hat). Before then, I hust had font paths
>> hard coded into my X config file. At some levels a font server is overkill
>> for a stand alone Linux box.
>
> The comments indicate that emacs is a last big user of xfs?
> I wondered if emacs is considering moving to another method of obtaining them.
> As was said on this thread, it's tidy for a multi-user system, to have a 
> single
> suite of fonts for all users. Less so for single users such as myself. It 
> would
> appear that Fedora/Redhat jump more when the big buyers say, so perhaps
> it will remain.
>  Also noted that emacs isn't installed by default any more.

Just a minor conceptual correction.

Emacs doesn't know anything about font servers. All the font server stuff
happens in the background at the X server level. X applications get fonts
from the X server and don't caere/know where the X server gets them from - they 
may be
hard coded font paths from the config file (i.e. xorg.conf) or they may be
defaults built into the server at compile time or they may come from a font
server (or a mixture of all 3). 

A common setup is to have the font server specified first in the font path
setting within the X config file and then also include some font paths for
common/basic fonts. With this setup, if the font server fails, your not
totally stuffed - you will be able to get some fonts, but possibly not the
ones you are use to/want. 

On my old Debian box, I have fontpath settings in xorg.conf and there is a
font server as the first line. However, on my more recent Debian box
installed from etch, there are no fontpath entries at all in the xorg.conf
file. 

You can find out what your current font path is by useing the xset
utilitye.g. xset q

>
>> I think many of the issues
>> here relate to historical and legacy concerns combined with portability and
>> cross platform objectives.
>
> snip.
>
>> Given the fact Emacs has now adopted the GTK+ widget set and given
>> the fact that the latest developments have been improving font support so
>> that Emacs supports antialiased, multibyte etc fonts, I think the quoted
>> comment just shows ignorance of what is going on.
>
> Not sure it's ignorance, but maybe a biassed perspective.
>
>
>  The printing integration
>> has never been an issue for me (though I would have to say I don't feel
>> CUPS has made it that much easier than 'lpr' and in fact hate the way it
>> tries to 'guess' what I want and usually gets it wrong. The comments also
>> totally overlook all the other spects of Emacs and fails to suggest
>> anything else that covers the same level of functionality we already have
>> an which does fit with his criteria (re fonts, desktop widgets, printing
>> and i18n).
>
> Yes. I did note the sarcasm. I don't want to install another operating system.
> Clearly non emacs users.
>

Yes, this is the 'standard' emacs criticism. 

>>
>> I'm not at all interested in religious wars over editors, but would argue
>> emacs is no closer to going the way of the Dodo than VI (and all its
>> clones) and that while things like GNOME have certainly created desktop
>> environments closer to what Windows uses are familiar with, I've not seen
>> any GNOME based editor that has any more functionality than 'notepad'. When
>> there is an editor that has all the flashy desktop widgets, full
>> integration with font services, full integration with the printing
>> infrastructure etc and has the extensibility of emacs and support for all
>> the programming modes Emacs already has, I'll reconsider the argument, but
>> until then.....
>
> Trouble is, its not a free ride Tim.
> I know my children are impatient, far more than I.
> Perhaps the time investment is simply too much for todays generation?
>

Possibly. However, I've seen quotes about the younger generation being
impatient going back to the romans and Greeks. It is probably just the way
of things. Younger users have grown up in an era where computers are seen
as a tool that should do what they want 'out of the box'. I don't think GNU
Linux is quite at that point yet. People who don't want to work at getting
the environment they want, but rather just want to use it are unlikely to
find GNU Linux much good. On the other hand, those who want to put in the
time and effort usually end up with an environment which is far better at
meeting their specific needs than an out of the box solution. 

to some extent, saying that Emacs is going the way of the Dodo because it
doesn't have the flash of newer editors, is too large and cumbersome etc is
a bit like arguing that manual shift cars would go the way of the Dodo once
automatic transmissions were introduced. While there are lots of people who
wold only buy an automatic (and can only drive one), there are still plenty
who like the control and additional power of a manual. 

BTW, I don't think emacs has been installed 'by default' under Red Hat for
a long time. Few distros install it by default. I wold guess that for
programmers, emacs and vi clones are the most popular editors under GNU
Linux. Not sure what percentage are moving to eclipse, but I suspect its
mainly the java developer crowd. Friends who have tried eclipse have
mentioned there are aspects they like, but they find it a bit
slow. Personally, I couldn't imagine working in any other editor unless it
had the power of something like elisp in the background that allowed me to
do some of those uncommon but time consuming tasks which don't have a
pre-built solution/feature. 

Tim


-- 
tcross (at) rapttech dot com dot au