My Reprap Mendel

by Craig Mayhew on Wed 09th Apr 2014 under General/Techie


It all started with a cat and some plastic...
Felix helping with reprap assembly

Basic Mendel frame

In 2010 when Beth and I started building the reprap, we anticipated it would take us a month or two. We we're wrong. We had almost no tools, no work space and limited engineering knowledge. Sometimes because work was just too busy, we wouldn't touch the reprap for months at a time. The frame was completed by mid 2010. The x axis and x carriage were completed by the end of 2010 and by 2013 the reprap was working aside from some incredibly poor printing accuracy. It wasn't until this weekend just passed that I finally tweaked the reprap into having a good enough accuracy to print replacement and upgraded parts for itself. Now of course, the mendel reprap is outdated and many parts have been improved or are completely replaced in the latest available designs. It will take several months of spare time to bring the printer up to date. I've already got a list of improvements to add including;

  1. - Moving both z axis motors up on top of the rep rap to improve print height and reduce problems with the two z axis worm gears getting out of sync.
  2. - A small fan to cool the extruded plastic much quicker. This will also improve printing of bridges.
  3. - Using a ribbon cable to replace all wires to the x carriage.
I can't wait to see where 3D home printing is in another 4 years.

Reprap mendel with gear

Reprap mendel with gear



RepRap Mendel 3D printer

0 Comments


Economics of SETI on AWS spot instance

by Craig Mayhew on Mon 25th Nov 2013 under General/Techie


I needed an excuse to use spot instances on AWS to test them for some upcoming projects. I chose SETI and I have to say it was a nice simple experience. It took about 30 minutes to build the linux VM, set it up with SETI and turn it into an AMI. This instance was one of the new c3.large high CPU instances. These were the financial results:

$0.45 / 14 Hrs = $0.032 per instance hour
2 Cores per instance so $0.032 / 2 = $0.016 for one core hour
SETI creates 100 points every ~12000 seconds ish - and we run 2 of these, one per core
So 3 1/3 hours * 0.016 = 0.053 cents per 100 points

So about 3p per 100 points.


AWS SETI

0 Comments


NX Server on CentOS 6

by Craig Mayhew on Sun 10th Nov 2013 under Linux/Ubuntu


Install nxserver

yum install nx freenx
cd /etc/nxserver
cp node.conf.sample node.conf
vi node.conf
Ensure that this line is not commented out:
ENABLE_PASSDB_AUTHENTICATION="1"

Setup NX Server

vi /etc/ssh/sshd_config

nxserver --adduser craig
nxserver --passwd craig

touch /var/lib/nxserver/home/.ssh/known_hosts
cd /var/lib/nxserver/home/.ssh/
chown nx:root known_hosts

vi /etc/nxserver/node.conf

Install NX client

Depends on your operating system, in my case it was windows https://www.nomachine.com/download

Setup Client

Grab DSA key from here that you will need for the client
vi /etc/nxserver/client.id_dsa.key

Sources: http://wiki.centos.org/HowTos/FreeNX



centos nomachine gnome kde

0 Comments


Script Hash

by Craig Mayhew on Tue 20th Aug 2013 under Guides/Fixes


Developers have a responsibility to protect their users as much and as often as they can. I would like to live in a world where everyone leaves school with the know-how to protect their passwords with something such as lastpass for each site they use. However we aren't quite there yet.

Let's look at the various levels of hashing and security you can put in place to protect your users.

Level 0: Passwords are stored in plain text on the server file system or in a database. This is just terrible and the worst possible situation. Ideally your website/application will limit login attempts and enforce a minimum password length policy of at least 15 characters.

Level 1: Passwords are stored in a hashed form within the database using MD5 or similar. Slightly better but GPU speed now means passwords up to 9 characters can be found from their hash by brute forcing in less than a day.

Level 2: A password SALT is used. This helps make the passwords much more difficult, if not impossible to compute (depending on SALT length and how many years computers take to reach speeds needed to brute force it). However - anyone with access to the SALT can take this back to level 1 and do you really believe someone can get a copy of your database but not manage to get the SALT too?

Level 3: A password SALT that us unique to each user is used. Same as the above but you have some function that you try to keep secret too. If the function is known, it is still slower to brute force the entire database.

Level 4: You use all of the above and a hashing algorithm like Script. Script is designed to be slower to compute and require much more memory than say MD5 to compute a hash. The high volume of RAM required means you can't run many hashes in parallel on say a GPU.

Level 5: Your code is ready to change to another hashing algorithm (e.g. as users log in) so you can upgrade them in future to even more secure hashes.

Script hashing passwords security

0 Comments


New blog - using tiny php framework and mongodb

by Craig Mayhew on Sat 10th Aug 2013 under General/Techie


I have replaced my ancient wordpress blog with a lean custom php framework. The blog entries, tags, categories and comments are now stored in mongodb rather than mysql. This has speed advantages in the case of a high read / low write blog as all the data for a page load is stored as a single database "document".

This is in contrast to the relational way of storing the data that needs at least 3 JOINS to retrieve the same information. Page load times dropped from ~2 seconds to 40 milliseconds (mostly due to the lean php).

mongodb

0 Comments