Devin Reade |
|
GNO Consortium | Home | GNO/ME |
|
Public Projects | System Administration | General Computing | Parallel Computing | Compilers | Linux Links |
This page is a collection of information regarding getting rid of
what I consider to be annoyances in the standard
RedHat
and derivitive (such as CentOS
and Fedora)
distributions. If you happen to like the specified "features"
as RedHat ships them, then more power to you. However don't bother
to drop me mail saying,
"
Submissions for additions and corrections to this page are welcome; see the address at the bottom of this page. If I happen to agree with you (this list was created mainly for my benefit and that of a few friends), I'll include it.
This page refers to
"Locales" affect the way a computer displays its data. It is a customization that permits an internationalization of the system by affecting character sets, what words a program displays, and other things.
The traditional locale (the one used before the concept of locales was introduced into computing) is known as the "C" locale, since it has its origins in the C programming language.
Red Hat is good for its support of locales. It has selected en_US as its default locale which, while being self-centered, can be excused. After all, if someone prefers a different locale they can always select it during the installation process or change it later.
My complaint with Red Hat in this matter is that there is no way to select the C locale during the installation process; it is just not an option. (I would also contend that the C locale should be the "default" default locale ...)
How to fix it:
LANG="C"You may want to keep a copy of the old LANG line, commented out by preceeding it with a # character, so that you can at some point in the future determine what locale was used during installation. (This can be useful in certain pathological cases.)
Edit the two files /etc/DIR_COLORS and /etc/DIR_COLORS.xterm and change the lines
COLOR tty
to
COLOR none
This won't effect any existing shell sessions, but you should see the
difference in any new ones.
In your $HOME/.emacs file, you probably have something like the following:
; Turn on font-lock mode for Emacs
(cond ((not running-xemacs)
(global-font-lock-mode t)
))
Comment it out using semicolons.
This is actually caused by the files /etc/profile.d/vim.* setting an alias for the command vi to point at vim. Just comment the alias lines in those files.
Commenting them out is better than deleting the files because the next time you do an update, you should wind up with either an .rpmnew or .rpmsave file. If you're smart, you've got a cron job looking for the existence of such files, and thus will be notified when the upgrade decides to reenable your vim aliases.
(Rant: If people want to run vim, let them run vim, but don't foist it on the rest of us.)
For tcsh and csh, this is controlled by the shell rc files. In a suitable spot, add in the line
set nobeep
For bash, this is controlled by the readline routines, and therefore by the files /etc/inputrc (globally) and $HOME/.inputrc (on a user-by-user basis). You want to add the following line:
set bell-style none
If you're running Konsole in KDE, go into "Settings" --> "Bell" and set it to "None". You will probably want to save your settings for other Konsole instances via "Save as Default". Note that this only affects the current and new Konsole instances; ones that are already running will not be affected.
Note that this doesn't necessarily get rid of the bell in all circumstances, but it's a start (especially with the Konsole change, above). For example, vim will sometimes beep at you, overriding (or ignoring) your default settings. In such cases, you should consult the documentation for the problematic application.
This (I believe) is primarily a csh/tcsh problem. In the shell rc files, look for a line of the form:
set ignoreeof
change this to the following, adding it if necessary:
unset ignoreeof
Klipper is that annoying clipboard tool that, ever time you click on a URL, will bring up a dialog asking which asks you what browser you want to run it in. Which means that you cannot cut and paste URLs. (Or if you can, it is certainly nonintuitive.)
Another web page on the Internet mentioned that you can turn this off globally by renaming the autostart klipper.desktop file (found, on RH systems, in /usr/share/autostart). However, when I did this I found that something in KDE would lock up the machine when KDE first starts up. This is definitely rude behavior, and not something that a non-privaleged user should be able to do (*grumble*). This was true even if the klipper.desktop file was moved to another directory. (Afterthought: Was this because I had klipper-related config files left over in my $HOME/.kde directory hierarchy? I don't know.)
Therefore, the mechanism that I used to disable this mis-feature was to edit $HOME/.kde/share/config/klipperrc and set the following line thus:
URLGrabberEnabled=false
Note that this is effective only for the current user.
You can also disable it globally by setting the same value in the /usr/share/config/klipperrc file. Note, though, that this won't affect users who already have an overriding value in their personal klipperrc file.
That's the graphical screen that comes up on the initial boot. I find it annoying (obviously :) and worse, it is a problem if you've got a serial console.
If the file /etc/grub.conf or /boot/grub/grub.conf exists, you're probably using the grub boot loader. In this case, edit the respective grub.conf file and:
GRAPHICAL=yes
to
GRAPHICAL=no
Note that at least with older versions (circa RH8, if I remember correctly) it was sometimes necessary to redo this procedure after performing a major system upgrade; Red Hat seemed to like to add this "feature" back in. I wouldn't be surprised if this is still the case.
(Thanks to Magnus Naeslund for providing part of this information, back before I started using grub.)
If you use the LILO boot loader, you can disable it by editing the file /etc/lilo.conf and commenting out the line:
message=/boot/messageAfter you edit that file, you must run the command lilo for it to take effect.
By default (after about RH8 or so) autorun(1) is active on the system. It causes the autorun file on data CDs to be executed automatically upon load, and permits kscd to immediately run audio CDs.
This autorun mechanism can be disabled (in KDE) by deleting the file $HOME/.kde/Autostart/Autorun.desktop. If you wish to later reenable this feature, you can copy the Autorun.desktop file from the /etc/skel hierarchy.
I don't know if this problem exists under GNOME nor, if it does, how to fix it.
I first noticed this problem with FC3. It also exists in FC4, FC6, (and probably FC5), CentOS 5.0, CentOS 5.1, CentOS 5.2, and probably all newer distributions.
If your applications' alt or meta key shortcuts no longer work, it's probably the case that the key mappings are wrong.
Solution 1 (recommended): Create the file $HOME/.Xmodmap containing the following:
keysym Alt_L = Meta_L Alt_L
Mode 644 is sufficient.
You need to log out and log back in again for this to take effect.
You do not need to reboot.
Solution 2: Create the file $HOME/.xmodmaprc with the same line in it as shown above. Then create the file $HOME/.xinput.d/default (which may also be mode 644) and in that default file add the following line:
xmodmap $HOME/.xmodmaprc
The above works for KDE. I make no gaurantees for GNOME, but it's probably fine there, too.
You might want to also check out http://cweiske.de/howto/xmodmap/allinone.html
First off, if you've used switchdesk or a similar mechanism to explicitly set the desktop for a particular user, the following procedure has no effect.
However, if you would like the default desktop for new users to be something other than the usual Gnome, then you need to edit (or create) the file /etc/sysconfig/desktop and (assuming you want the default to be KDE), ensure that it has the following line:
DESKTOP="KDE"
|
Last Updated: 19 Dec 2008 |
|