Daniel's spot

My Ubuntu installation was accusing low space at /usr. It was a 15GB partition and nevertheless it had about 600MB free.

As I had overestimated the size of /var, I decided to reduce it (using gparted) and create another partition for /usr/share, which would give me about 6GB of free space at /usr.

Everything worked as a charm. I went about my normal day and, after a few hours of normal work, I moved to a different task. I am teaching a class and had not uploaded the slides for the students. So, I opened the presentation on Impress (Libre-Office's "Powerpoint") and most of the text was gone. I still had pictures, the titles were there, but the actual content was gone.

I pulled back some backups, nothing. Then, after a cup of coffee to clear my mind, I realized that it could be related to the changes I had done in my file system. Trying to understand better what happened, I looked at the slides again. I noticed that the missing text were using specific fonts. For example, I used courier for code snippets, and in the one single case I forgot, the code was there. Now, guess where the fonts are stored? yes: /usr/share/fonts. Everything started to make sense.

So, after poking around, I found that there is a cache of fonts and I concluded that moving /usr/shareto another partition, I messed with the cache. So, I rebuilt it and.. voi-la! It works.

If you come across a similar problem, the command to rebuild that cache is as follows:

For the first time in a long time, I decided to go out of my "comfort zone". I would try a distro that wasn't based on Ubuntu or even Debian. I needed to change my installation anyway, from 32 to 64 bits, so I used it as an excuse for my adventure.

I decided to try Mageia, a distro which is derived from Mandriva (from the company created by the fusion between the French Mandrake and the Brazilian Conectiva), just like Fedora derived from RedHat.

Unfortunately, my experience was not really pleasing. The DVD installation didn't work. When I booted my computer, the graphical driver wouldn't work. I ended up successfully installing from the Live CD. But, with my lack of familiarity with the environment (e.g., "Where is the "apt-get" equivalent?"), I found the system quite unstable.

I even tried Enlightenment (E17)... Honestly, it was pretty but not really good. I found E17 to be too slow and with too much animation. I think that a more efficient configuration tool that allows fine-tuning might make E17 a more interesting alternative.

As Sheldon said once: "There is a reason for why it's called 'comfort zone'". So, at least for now, I am going back "home". This afternoon/night, I'd be reinstalling Linux Mint 13, (now the 64 bit variation) running LXDE. When time permits, I might do another adventure in another "foreign distro".

Some Linux users (including myself) have been unsuccessfully trying to execute a command via SSH, for example:

ssh user@host mycommand

The problem seems to be that "mycommand" is in a directory that is not in the PATH. However, when they connect normally, they can see the directory in the PATH environment variable.

It seems that most of these users (again, including myself) update the PATH variable in the .bashrc file and, apparently, the .bashrc file is not executed when connected "non-interactively" via ssh.

After looking for a good while, many people suggested to check if the .bashrc was called by .profile or .bash_profile or something like that. Well... that did not solve my problem.

What, in fact, happened was that .bashrc was being called (or "sourced") by SSH, but the guys from the distro decided to add the following lines in it:

# If not running interactively, don't do anything

[ -z "$PS1" ] && return

Basically, the test above only allows the execution of the rest of .bashrc if it is an interactive shell, thus it does not work for my needs. Why is it there? I have no idea... anyway... I just commented the test and it worked perfectly.