X and fonts

dep dep
Mon May 17 11:46:51 PDT 2004


begin  Ian Stephen's  quote:

| I learned that direct rendering doesn't work with xinerama, that
| config files seem to be picky even about whitespace, /var/log is my
| friend, /etc/X11/xkb/compiled is a symlink to /var/lib/xkb and that
| Lynx is a wonderful thing when one wants to find and download old
| rpms with no X.

to which i'd add midnight commander for keeping track of experimental 
versions of configuration files, editing those files, and ftping 
things as needed. it really is the one essential linux utility in my 
estimation.

| Questions I am left with now are whether the up2date I did last
| night caused this or is that just a coincidence?  What would have
| made /var/lib/xkb disappear?  What did reinstalling base-fonts do? 
| Looking at /etc/X11/fs/config and the font paths contained in that
| file's catalogue section provides no clues (at least not that I
| see).

the newest trick undertaken by distributions -- i've been screaming 
bloody murder years about the move in this direction -- is to screw 
around with xfree86 such that anything you know about it is no longer 
true. the pinnacle (thusfar) that i've seen is that for unspecified 
security reasons, the xfree 4.30 shipped with suse 8.2 is *not* 
replaceable by xfree that you compile yourself; the latter won't 
work. in that the chief issue in the discussion of that involved xdm, 
i suspect that red hat is doing something similar. at minimum they've 
made it all a lot more complicated than it ought to be, and they have 
not bothered to tell anyone what they've done.

it sounds as if red hat is up to similar monkeyshines, such that they 
have now achieved a degree of incompatibility with themselves.

| I learned some time back not to play willy-nilly with things like
| glibc.  Should I not even assume that up2date will update them
| safely? Is it better not to update those without a specific reason
| to do so?

i have successfully updated glibc and i have had updating glibc break 
everything on the machine. i utterly destroyed my caldera 2.4 install 
a couple years ago by such an update. it depends on the degree of 
backward compatibility in the new version. one of the greatest 
weaknesses in things linux is the view that backward compatibility is 
an insignificant luxury. ask anyone who bought the corel applications 
suite.

the idea, seems to me, is to tie users to binaries from one's 
distribution, so that ultimately one will have to subscribe to an 
update service. now you report that red hat has taken this a step 
beyond what works.

linux was a lot easier back when it was too difficult to use.
-- 
dep

http://www.linuxandmain.com -- outside the box, barely within
the envelope, and no animated paperclip anywhere.


More information about the Linux-users mailing list