#!/bin/bash

# Get the code for the k10 temperature module
wget http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20080718/d51be536/attachment.bin

# Create a directory for the module to be built in
mkdir k10temp && mv attachment.bin k10temp/k10temp.c
cd k10temp

# Create the make file
echo ‘obj-m := k10temp.o’ > Makefile
echo ‘KDIR := /lib/modules/$(shell uname -r)/build’ >> Makefile
echo ‘PWD := $(shell pwd)’ >> Makefile
echo ‘default:’ >> Makefile
echo ‘$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules’ >> Makefile

# Compile the module
make -C /lib/modules/$(uname -r)/build M=$(pwd) modules

# Insert the module and store it with the rest of the modules
sudo insmod k10temp.ko
sudo cp k10temp.ko /lib/modules/$(uname -r)/kernel/drivers/hwmon
sudo depmod

# Add k10temp to /etc/modules if not there so it will start at boot
if grep -q k10temp /etc/modules
then
echo ‘k10temp already in /etc/modules’
else
sudo echo ‘k10temp’ >> /etc/modules
echo ‘k10temp added to /etc/modules’
fi

# Remove the temporary files
cd ..
rm -r k10temp

Though I digress, the point of this post is that I have seen a number of discussions that Linux on the Macbook appears to be more responsive. The Macbook is a great platform and is extremely fast when completing regular tasks under OS X or Ubuntu so I didn’t want to just speculate on performance. Instead, I wanted to actually measure the difference in performance. For me, the vast majority of my processor intensive computing is done via MATLAB and therefore this is where I looked for a performance comparison.

For reference I have a 2.0 Ghz Intel Core Duo Macbook with 2 GB of RAM. I started up each operating system and right off of the back ran MATLAB 7.4 R2007a and the following benchmark code:

x = bench(10); mean(x)

Output under OS X:

ans =

0.3091 0.4460 0.3285 1.4133 1.0258 0.4507

Output under Ubuntu 7.10

ans =

0.3037 0.4127 0.2488 0.5628 0.4634 0.4018

As may be clearly seen, MATLAB under Ubuntu on the Macbook outperformed the MATLAB instillation on OS X. I have yet to fully test out the performance when running some of my current research but these benchmarks provide some hope that I may spend less time waiting.

1.) Install the pre-built binaries for octave from HPC Mac OS X

2.) Install aqua term

3.) The pre-built binaries for gnuplot do not seem to work adequatley with aqua term and octave at the current time, so download the source for the newest version of gnuplot

4.) Untar the source files and open a terminal shell in the new directory and excute the following commands*

export CFLAGS='-arch i386'
export LDFLAGS='-arch i386'
./configure --with-readline=builtin
make
sudo make install

Afterwords, every thing should be working fine, test it out in octave with:

plot((-10:10).^2)

* Thanks to Nick Vox for this information.

gedit ~/.gnome2/nautilus-scripts/latex\ to\ pdf

Next paste in the following script.

#!/bin/bash

# Runs the file through pdflatex and opens it in evince if the pdf file exists

if echo $1 | grep -i “.tex”; then
pdflatex $1
PF=${1/tex/pdf}
if [ -f $PF ]; then
evince $PF
else
zenity –info –title=”latex to pdf” –text=”Failed to create the PDF file.”
fi
else
zenity –warning –title=”latex to pdf” –text=”File must be a latex file with the extension .tex”
fi

Then make the script executable.

chmod +x ~/.gnome2/nautilus-scripts/latex\ to\ pdf

Now you are able to right click on a latex file and select the “latex to pdf” script to convert it to a pdf file and open it up in evince.

For software I decided to run m0n0wall. I would have prefered a linux based solution over a FreeBSD based product but it appeared to be the best solution for my situation. The setup was a breeze and it turns out my 64MB flash card was overkill as the entire image is under 8MB. After working with m0n0wall’s web gui to setup the system I couldn’t stop thinking this is a fantastic product! m0n0wall’s features are enough for almost any home or office network and the configuration is a breeze. Most interesting is that the entire boot-time configuration is written in PHP. Smoothwall and my dumpster pc served me well for a long time but m0n0wall and my WRAP box provide a more feature rich firewall in a much sleeker and cooler running package.

]]> http://stochasticflux.com/blog/?feed=rss2&p=9 http://stochasticflux.com/blog/?p=6 http://stochasticflux.com/blog/?p=6#comments Wed, 05 Jul 2006 23:03:02 +0000 marten Ubuntu http://stochasticflux.com/blog/?p=6 Waiting for me today when I got home was a nice surprise, the new Dapper CDs from Canonical. It appears as if the ShipIt service has gotten better along with the distribution. This is the first time I got the correct order fully intact, it was also the quickest I have recieved an order yet. They were also kind enough to throw in some sweet Ubuntu stickers!

For this example I will assume that Ubuntu is installed on both computers and that the server may be denoted by the hostname xdmcpserever.

To start off first enable XDMCP on the host computer by editing the gdm.conf-custom file

sudo vim /etc/gdm/gdm.conf-custom

Make sure that it contains the following section.

[xdmcp]
Enable=true

If you want the remote login screen to be the same as the graphical greeter that is the default in the Ubuntu install make sure that the following is present.

[daemon]
RemoteGreeter=/usr/lib/gdm/gdmgreeter

Now one is able to log in via the default gdm greeter on the client systems if so desired, but in my case I wanted the client to automatically boot to the login screen for the server. The process is actually quite simply. First a script to launch the daemon for the new XDMCP login must be created.

sudo vim /etc/init.d/xdmcp

In this file place the following script [download here].

#! /bin/sh
# Launchs XDMCP

set -e

PATH=/sbin:/bin:/usr/sbin:/usr/bin
PIDFILE=/var/run/xdmcp.pid
XDMCPSERVER=xdmcpserver

. /lib/lsb/init-functions

case “$1″ in
start)
if pidof usplash > /dev/null; then
/etc/init.d/usplash start
fi
log_begin_msg “Starting XDMCP…”
start-stop-daemon –start –quiet –pidfile $PIDFILE –name xdmcp –exec /usr/bin/X — -query $XDMCPSERVER > /dev/null || log_end_msg 1
log_end_msg 0
;;
stop)
log_begin_msg “Stopping XDMCP…”
start-stop-daemon –stop –quiet –pidfile $PIDFILE –name xdmcp /usr/bin/X — query $XDMCPSERVER –retry 30
log_end_msg 0
;;
restart)
$0 stop || true
$0 start
;;
*)
log_success_msg “Usage: /etc/init.d/xdmcp {start|stop|restart}”
exit 1
;;
esac

exit 0

The next step is to set the executable bit on this script with

sudo chmod +x /etc/init.d/xdmcp

The way I chose to have the system run the script on startup is by simply replacing the gdm startup script in the default runlevel with our new xdmcp startup script.

sudo rm /etc/rc2.d/S13gdm

sudo ln -s /etc/init.d/xdmcp /etc/rc.2/S99xdmcp

Now when we restart the client we will be presented with a login screen being served from our xdmcp server.

]]> http://stochasticflux.com/blog/?feed=rss2&p=4 http://stochasticflux.com/blog/?p=3 http://stochasticflux.com/blog/?p=3#comments Fri, 30 Jun 2006 04:22:38 +0000 marten Ubuntu http://stochasticflux.com/blog/?p=3 A great adition to Linux has been the filesystem in user-space project FUSE which brings us SSHFS. One now has the ability to mount remote filesystems through ssh. Installing sshfs is easy with a simple sudo apt-get install sshfs.

First one must add their user name to the fuse group either via the gui or the command line tool adduser. (As pointed out by Casey you need to logout-login for the group changes to take effect.) Next one needs to insert the fuse module into the kernel with a

sudo modprobe fuse

This module should be appended to the end of /etc/modules inorder for it to load when the system boots.  Then it is possible to mount filesytems over ssh with a simple

sshfs username@sshserver: /media/directory

and then enter your password when prompted. This will automatically mount the users home directory. To mount a specific directory use

sshfs username@sshserver:/directory /media/directory.

Though most of us don’t want to open up a command line and go through this hassle everytime we want to mount our remote filesystem. For this I purpose the following solution. First we create a password-less login by setting up a trust realtionship with public keys. On the local computer in your home directory run

ssh-keygen -t rsa

When prompted for the location to save the file and a passphrase simply hit enter. The keys will be stored in $HOME/.ssh/id_rsa. The next step is to copy the public keys over to the remote server which has already been mounted in /mount/directory.

cat ~/.ssh/id_rsa.pub >> /media/directory/.ssh/authorized_keys
chmod 600 /media/directory/.ssh/authorized_keys

Now we can ssh into our remote box without the need for a password. The other problem one runs into with implementing a clean graphical sshfs experience is the fact that if one wants to unomunt the filesystem they can not simple right click unmount the system from the Gnome desktop icon. This is because umount requires root privlages, however fuse has a solution for this which is fusermount -u /media/directory. The following bash script can be attached to a menu or panel icon to do the simple mounting of the system and the unmounting if it is already mounted.

#!/bin/bash
if grep -q sshserver /proc/mounts
then fusermount -u /media/directory
else sshfs username@sshserver: /media/directory
fi

Don’t forget to replace sshserver, username, and directory with the appropriate values for your situation.

]]> http://stochasticflux.com/blog/?feed=rss2&p=3