438. Very briefly: Freeing up RAM (sort of)

After having played around with two virtual machines simultaneous which at some point caused me to use/reserve all of my ram plus a small amount of swap (419 Mb), my desktop has been a bit slower. I don't see any real evidence that it's swapping to and from disk, but the system is much less responsive, e.g. when switching applications.

Note that when you RAM usage goes up, not all of the RAM is actually used in an active sense -- some may be reserved. Another factor to take into account is that you actually DO want to use as much RAM as possible as long as it improves performance, and this is done via caching. What's shown here is simply how to clean that cache. 

So is cleaning that cache a good thing? Well, sometimes. Empirically, it seems like dropping the caches can help if you've been doing something that caused a lot of ram to be used, but which is no longer running. Such as something heavily graphical (e.g. using VMD and rendering something) or a virtual machine.

See e.g. here for a discussion with comments: http://catalin-festila.blogspot.com.au/2011/06/myth-of-dropcaches.html

Anyway.

At the beginning this is how it looked (free -m):

            total       used       free     shared    buffers     cached
Mem:          7991       7488        503          0       1097        379
-/+ buffers/cache:       6011       1980
Swap:        15257        419      14838

To free up the ram cache, do

me@beryllium:~$ sudo su

[sudo] password for me:
root@beryllium:/home/me# sync
root@beryllium:/home/me# echo 3 > /proc/sys/vm/drop_caches

And when we're done it looks like this:

            total       used       free     shared    buffers     cached
Mem:          7991       3503       4488          0         47        147
-/+ buffers/cache:       3308       4683
Swap:        15257        419      14838

Our swap usage hasn't changed, but the apparent free RAM has increased significantly. And my computer feels snappier.

Often the need to free up RAM is precipitated by the presence of memory leaks though, since these are often manifested by the slow increase in the amount of RAM a program is using. Older versions of gnome-shell (including the one presently used in Wheezy) are known culprits, and ECCE has a tendency to eat up RAM like there's no tomorrow when running for too long (still working on getting hard numbers for it).

437. system-config-firewall on debian

Please, read this first:
system-config-firewall is a python based Red Hat tool.

The best way to manage your firewall is by configuring iptables by hand. It gives you minimal rule sets which are clear and easy to read.

If you absolutely need a GUI, then try included debian tools such as gufw, firestarter etc. but note that they can only configure a small subset of what iptables are capable of. They also often given rule sets that can be difficult to read.

If you are coming to debian from rhel/fedora+clones and are missing some of the redhat tools, note that you are probably better of adapting the recommended work flow of the distro you are using.

Having said that, e.g. system-config-samba works fine on debian so far (but again, configuring samba by hand is not that difficult).

The real work was done by the person who did the patching (can't find a specific name -- just Ubuntu Contributions)

This was done on Debian Jessie. I may have missed some of the pre-requisite dependencies. Post comments and I shall add.

Anyway, look at this as an exercise, nothing more.

sudo apt-get install checkinstall python-slip-dbus python-tksnack build-essential gfortran debhelper python-newt selinux-utils intltool python-support
mkdir ~/tmp
cd ~/tmp
mkdir sysfirewall
cd sysfirewall/
wget https://launchpad.net/~ubuntu-contribs/+archive/contrib/+files/system-config-firewall_1.2.29.orig.tar.gz
wget https://launchpad.net/~ubuntu-contribs/+archive/contrib/+files/system-config-firewall_1.2.29-2.diff.gz
tar xvf system-config-firewall_1.2.29.orig.tar.gz
gunzip system-config-firewall_1.2.29-2.diff.gz
sed -i 's/python2.6/python2.7/g' system-config-firewall_1.2.29-2.diff
patch -p0 < system-config-firewall_1.2.29-2.diff
cd system-config-firewall-1.2.29/
dpkg-buildpackage -uc -us
sudo dpkg -i ../*.deb
sudo apt-get -f install
system-config-firewall

You can see what your rules are and if they have taken effect by doing

sudo iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

You can also use your pre- and hand-configured rule set and put it in /etc/default/iptables and /etc/default/ip6tables, then edit with system-config-firewall (for whatever reason).

436. Miramath on debian

For no particular reason (well, because of this: http://forums.debian.net/viewtopic.php?f=10&t=104566) here's a very brief how-to to get miramath up and running. There may well be more packages required and which I had pre-installed. The pre-built miramath binaries don't work on debian jessie, but since this is python...well..Anyway:

First compile and install PyQwt-Polar. It takes quite a while. Note that there's a conflict between PyQwt-Polar and python-qwt5-qt4 which may potentially be serious. A side-effect of this is that you can't build a proper package, since dpkg would detect this conflict (hence the make install). What this means is that PyQwt-Polar will over-write files installed by the python-qwt5-qt4 files i.e. A potentially Bad Thing.  Consider setting it up in a chroot.

There's another reason why I wouldn't recommend miramath for serious work at the moment -- it is in pre-alpha and the degree to which is it maintained isn't entirely clear to me. For scientific work, use octave and maxima, which are well-maintained and have been around for ages.

The flip-side of this is obviously that there's no harm in checking out a new and interesting piece of software, and presumably no-one is preventing you from contributing. Anyway. The main reason for checking this out was the debian forum post referenced above.

I did this on Debian Jessie, but it should work on Wheezy as well.

sudo apt-get install python-sip-dev python-qt4-dev python-scipy python-qt4-gl python-sympy python-ply python-qwt5-qt4 python-qwt3d-qt4 python-guiqwt python-dev libqwt-dev libqwt5-qt4

mkdir ~/tmp/
cd ~/tmp
wget http://ufpr.dl.sourceforge.net/project/miramath/PyQwt-Polar/PyQwt-Polar-5.2.0.tar.bz2
tar xvf PyQwt-Polar-5.2.0.tar.bz2
cd PyQwt-Polar-5.2/
cd configure/
python configure.py -Q ../qwt-5.2
make
sudo make install

Then continue:

wget http://waix.dl.sourceforge.net/project/miramath/Release%20Tarballs/miramath0.020.tar.bz2
cd ~/miramath
sed -i 's/sympy.abs/sympy.Abs/g' symbolics_init.py
chmod +x main.py
./main.py