Thursday, October 11, 2012

The table saw would never be invented today

Foreward: I'm not advocating a ban on table saws. That would be silly, not unlike banning pencils because they could be used to put one's eye out.

The other day I was building a frame for a mirror in my house. As part of the process, I had to make some grooves in some dimensional lumber in order to hold the glass in place. To achieve this, I installed a dado blade in my table saw and passed the lumber over. This got me thinking of all the different ways that a table saw could horribly maim someone, and why, if it were invented today, the table saw would never be allowed to be sold.

I mean, it's basically just a blade sticking up out of a table, staring you in the face. Most tools have you placing your hands on the tool to operate it (freehand tools like a chainsaw or circular saw require two hands to keep the tool steady, and a stationary mitre saw is equipped with a deadman's switch so you have to keep one hand on the saw at all times,) but in the case of a table saw, you actually put your hands on the material you're passing through that blade. And unlike tools with a spring-loaded trigger, if you reflexively jump back, the saw just keeps going; the very nature of the way a table saw is used requires the motor to keep running without operator intervention.

So you've got this blade sticking out of a table, whirring away, happy to tear through anything that comes in contact with it. Modern saws have a couple safety devices, but these don't make the saw safe, only safer, and often these safety devices must be deliberately disabled in order to use the table saw to its fullest potential.

Splitter

As the table saw operates, the saw blade spins toward the operator. The front edge of the blade is moving into the table, which means as the blade chews through the material, it also pulls the material down onto the table. However, if the material catches the backside of the blade, it will be lifted up off the table. The splitter is attached at the back of the saw table. Its purpose is to hold the cut material apart so that it doesn't catch on the backside of the blade and get thrown into the operator's face. Unfortunately, if you're not cutting all the way through the material, it can't pass by the splitter. This means the splitter must be removed when making grooves.

Blade guard

In my case, the blade guard is a piece of clear plastic that is attached to the splitter. It sits over the saw blade and stops flying debris from being ejected up and away from the table. Since the blade spins toward the operator, most of the sawdust created by the saw blade ripping through material will be directed down into the body of the saw. However, sometimes material can be shot up off the backside of the blade; it will normally run into the blade guard instead of flying into the operator's face. The guard may also prevent someone from accidentally sticking their hand into the saw blade directly. However, this blade guard is attached to the splitter, so when the splitter has to be removed for ripping dado grooves, the blade guard goes with it.

Anti-kickback teeth

As the blade spins, it exerts a force on the material being cut. This force is mostly down into the table, but part of the force is also directed back toward the operator. This backward force increases as the top of the material approaches the top of the blade (for example, when cutting thick stock or cutting with a lowered blade height.) The reason this device is called "anti-kickback" and not "anti-pushback" is that a table saw's running blade can impart enough force to send the material back toward the operator quite vigorously. The teeth are spring-loaded and press down on the material as it passes by the splitter. They work to allow the material to pass only in one direction; if the material tries to run in the wrong direction, the teeth dig in. This, in theory, will resist the saw's attempt to punch the operator in the stomach with a chunk of wood. However, since the teeth are attached to the splitter, they, like the blade guard, disappear when the splitter does. This means the teeth are absent at their time of greatest need: when ripping grooves, as the saw blade's force is entirely toward the operator during this operation.

So yeah, I'd have to say that my table saw is the most dangerous tool I own. It's more dangerous even than my chainsaw, because at least the business end of my chainsaw is pointed away from me while I'm using it. If the table saw were invented today, there's no doubt in my mind that there would be overwhelming resistance to the sale of such a thing in retail stores, and you wouldn't find one outside of a licensed woodworking shop. To that I can only thank the powers-that-be that table saws hit the market in a different age, and now carry enough inertia to stay on the market. I mean after all, they (and far more dangerous tools) have existed for centuries, and the human race is still here.

It comes down to this: respect the table saw. The table saw giveth, and the table saw taketh away. It can be used in creative ways to do awesome things quickly, but it also packs a nasty bite which it uses to punish the careless and the ignorant.

Mediatomb handles my music collection with Mysql

Recently I've started streaming audio and video from my music collection to my ASUS Transformer tablet. For the most part this works really well, except that my music collection is rather huge (7355 tracks so far).

In particular, I'm using MediaTomb to index and stream the media over the network. What's really nice about MediaTomb is that there's no client configuration needed to find the server; the client discovers the server using uPNP. A close second is that MediaTomb uses the inotify facility on the system to detect and index files as they're added to the filesystem. This means that resource-intensive periodic scans of the filesystem are not necessary.

MediaTomb worked really well for streaming videos, but my video collection is rather small. When I tried to index and stream my music collection, it would choke. As it turns out, the default installation of MediaTomb on Debian uses SQLite3 to store the backend database. SQLite, put simply, doesn't scale. I've seen this in other applications as well; I seem to recall trying to deploy Bacula with a SQLite3 backend, with similar catastrophic results.

Anyway, because MediaTomb was trying to use SQLite, the database would get corrupted when trying to add more than a few hundred audio tracks. I tried adding them piecemeal, but it was to no avail; tracks would be missing, or would be in the list, but wouldn't play. Finally I decided it was time to get my hands dirty; MediaTomb will use MySQL, if you tell it to, and I already had a MySQL backend running on my server for other things.

So here's what I did (Thanks to Socrateos for the instructions):

  • Start by stopping mediatomb on the server. Then delete the old SQLite3 database, which by default is stored at /var/lib/mediatomb/mediatomb.db
  • Edit /etc/mediatomb/config.xml
    • Find the <storage> section
    • Change "sqlite3 enabled" to "no"
    • Change "mysql enabled" to "yes"
    • Set the "host", "username" and "password" fields in the mysql section. On my installation, the password attribute was missing, so I created it.
  • Save the file and exit
  • Next, create a database user:

    • $ mysql -u root -p 
    • mysql> create user 'mediatomb'@'localhost' identified by 'secret';
    • mysql> grant all on mediatomb.* to 'mediatomb'@'localhost';
    • mysql> quit
  • Now create the mysql database...:
    • $ mysql -u mediatomb -p 
    • mysql> create database mediatomb;
    • mysql> quit
  • ...and populate it
    • $ mysql mediatomb -u mediatomb -p < /usr/share/mediatomb/mysql.sql
  • Lastly, start the server
    • $ sudo /etc/init.d/mediatomb start
After this, I was able to connect to my MediaTomb server and scan my entire music library in at once. After MySQL hammered on my CPU for a few minutes doing thousands upon thousands of INSERTs, the database was complete and functioning.