The axe may well have been the first tool humans ever developed. Examples have been found that were made by Homo Habilis in the lower Paleolithic era, meaning that axes have been around longer than modern humans.
Various religious orders throughout history have used axes as symbols.. They have also been used as symbols of military power and authority (see the Roman fasces). These factors have lead to axes having a place in a lot of folklore, as well as other more modern forms of mass media.
I had a couple of axes that were in pretty sorry shape. I'm not really sure where I got one of them, and I got the other (the double bladed one) at a garage sale for the princely sum of $2.
You can see that the handles were in pretty sad shape, and that the heads were rusted. The double bladed axe had probably been used to chop something other than wood as well. I removed the handles by placing the axe heads in a vise and driving them out with a hammer and a metal rod used as an ersatz punch. The single bladed axe took a while, but the handle for the double bladed one came out after two hits. Some moron had tried to simply glue the handle in.
I soaked the heads in old motor oil (I'd just changed the oil in my car) overnight to soften up the rust. After that I used a drill-mounted wire brush and orbital sander to clear the rust off.
I then sharpened the heads with an angle grinder and belt sander, and applied a few coats of paint.
After this, I began the rehafting process. First the handle is inserted into he head.
The next step in the process is to drive the wedge into the notch in the end of the axe handle
After the wedge is driven into place, it is secured with a metal clip. I had issues with the clip the handle came with bending, so I just used a fence staple.
After repeating the process on the double bladed axe, I now have two perfectly good axes.
It could be argued that I may have been better off just buying a couple of new axes and calling it a day. It certainly would've saved me a bit of time. None the less, I'm glad I did this. I get tired of how disposable things are. It felt good to take "worthless junk" and make it into a good, useful tool.
Sunday, May 27, 2012
Wednesday, March 28, 2012
Reusing Threads in Perl
For all its warts, Perl is a powerful programming language that will continue to be used for some time. If programming languages were people, Perl would be your crazy uncle with a very cluttered but very well stocked workshop. One of its more powerful features is the threads api.
I have noticed that programs which create and join a lot of threads seem to consume more and more memory. I'm not sure why this happens, but I think it is because the memory allocated when the threads are created isn't deallocated when they are joined. (This is speculation).
The solution to this is to create a batch of threads which will run for the entire life of your program. Instead of being joined and returning, they instead communicate via queues created using Perl's thread-safe Thread::Queue library.
In the name of full disclosure I need to state that I could not have done this without the pool_reuse.pl example found here. The aim of this article is to supplement the provided example by providing a more verbose explanation, as well as an example where data is received from the threads.
Several queues are created. First we make a queue which holds the ids of threads which aren't currently busy. After this is done, we run through a loop where we create an input queue, an output queue, and a thread. In our example, the threads are for functions which add a random number to the input. The input and output queues are passed as arguments. The queues are assigned to values in hashes, keyed by the thread ids.
When we want to do actual work, we dequeue an available thread from the thread queue. We'll then store which thread we are using in a data structure of some kind, and then dequeue that thread's output queue later. It is important to keep track of which queues we are using, because dequeue is a blocking operation. If you try to dequeue an empty queue, it will simply sit there until something has been enqueued. Depending upon how you've written things, that could be never.
Please see the example below:
#!/usr/bin/perl
use threads;
use threads::shared;
use Thread::Queue;
use strict;
#sentinal variable for threads
my $finished :shared = 0;
#number of threads
my $numThreads = 10;
my %inputQueues;
my %outputQueues;
my $threadQueue = Thread::Queue->new();
for (my $i = 0; $i < $numThreads; $i ++) {
#create input queue for the thread
my $inputQueue = Thread::Queue->new();
#create output queue for the thread
my $outputQueue = Thread::Queue->new();
my $thread = threads->new(\&randomAdd,$inputQueue,$outputQueue);
my $tid = $thread->tid();
$inputQueues{$tid} = $inputQueue;
$outputQueues{$tid} = $outputQueue;
}
#signal handler for clean exit
$SIG{'SIGINT'} = $SIG{'SIGTERM'} =
sub {
$finished = 1;
$threadQueue->enqueue(0,-1);
};
my @initialValues;
#fill up the array with random numbers
for (my $i = 0; $i < 10; $i ++) {
push @initialValues, int(rand(100));
}
for (my $i = 0; $i < 10; $i ++) {
print "$i\n";
my @output;
my @tids;
foreach my $value (@initialValues) {
#dequeue a thread
my $tid = $threadQueue->dequeue();
push @tids, $tid;
$inputQueues{$tid}->enqueue($value);
}
foreach my $tid (@tids) {
push @output, $outputQueues{$tid}->dequeue();
}
print "old value new value\n";
for (my $j = 0; $j < 10; $j++) {
print "$initialValues[$j] $output[$j]\n";
$initialValues[$j] += $output[$j];
}
print "\n";
sleep 1;
}
$finished = 1;
foreach my $thread (threads->list()) {
$inputQueues{$thread->tid()}->enqueue(-1);
$thread->join();
}
exit(0);
sub randomAdd {
#add a random number to the data input from the queue.
#put the results in the output queue
my ($inputQueue,$outputQueue) = @_;
my $tid = threads->tid();
while (! $finished) {
#put ourselves in the queue so we are avilable
$threadQueue->enqueue($tid);
#pull input from queue
my $inVal = $inputQueue->dequeue();
if ($inVal >= 0) {
my $outVal = $inVal + int(rand(100));
#enqueue data in output queue
$outputQueue->enqueue($outVal);
} else {
return;
}
}
return;
}
I have noticed that programs which create and join a lot of threads seem to consume more and more memory. I'm not sure why this happens, but I think it is because the memory allocated when the threads are created isn't deallocated when they are joined. (This is speculation).
The solution to this is to create a batch of threads which will run for the entire life of your program. Instead of being joined and returning, they instead communicate via queues created using Perl's thread-safe Thread::Queue library.
In the name of full disclosure I need to state that I could not have done this without the pool_reuse.pl example found here. The aim of this article is to supplement the provided example by providing a more verbose explanation, as well as an example where data is received from the threads.
Several queues are created. First we make a queue which holds the ids of threads which aren't currently busy. After this is done, we run through a loop where we create an input queue, an output queue, and a thread. In our example, the threads are for functions which add a random number to the input. The input and output queues are passed as arguments. The queues are assigned to values in hashes, keyed by the thread ids.
When we want to do actual work, we dequeue an available thread from the thread queue. We'll then store which thread we are using in a data structure of some kind, and then dequeue that thread's output queue later. It is important to keep track of which queues we are using, because dequeue is a blocking operation. If you try to dequeue an empty queue, it will simply sit there until something has been enqueued. Depending upon how you've written things, that could be never.
Please see the example below:
#!/usr/bin/perl
use threads;
use threads::shared;
use Thread::Queue;
use strict;
#sentinal variable for threads
my $finished :shared = 0;
#number of threads
my $numThreads = 10;
my %inputQueues;
my %outputQueues;
my $threadQueue = Thread::Queue->new();
for (my $i = 0; $i < $numThreads; $i ++) {
#create input queue for the thread
my $inputQueue = Thread::Queue->new();
#create output queue for the thread
my $outputQueue = Thread::Queue->new();
my $thread = threads->new(\&randomAdd,$inputQueue,$outputQueue);
my $tid = $thread->tid();
$inputQueues{$tid} = $inputQueue;
$outputQueues{$tid} = $outputQueue;
}
#signal handler for clean exit
$SIG{'SIGINT'} = $SIG{'SIGTERM'} =
sub {
$finished = 1;
$threadQueue->enqueue(0,-1);
};
my @initialValues;
#fill up the array with random numbers
for (my $i = 0; $i < 10; $i ++) {
push @initialValues, int(rand(100));
}
for (my $i = 0; $i < 10; $i ++) {
print "$i\n";
my @output;
my @tids;
foreach my $value (@initialValues) {
#dequeue a thread
my $tid = $threadQueue->dequeue();
push @tids, $tid;
$inputQueues{$tid}->enqueue($value);
}
foreach my $tid (@tids) {
push @output, $outputQueues{$tid}->dequeue();
}
print "old value new value\n";
for (my $j = 0; $j < 10; $j++) {
print "$initialValues[$j] $output[$j]\n";
$initialValues[$j] += $output[$j];
}
print "\n";
sleep 1;
}
$finished = 1;
foreach my $thread (threads->list()) {
$inputQueues{$thread->tid()}->enqueue(-1);
$thread->join();
}
exit(0);
sub randomAdd {
#add a random number to the data input from the queue.
#put the results in the output queue
my ($inputQueue,$outputQueue) = @_;
my $tid = threads->tid();
while (! $finished) {
#put ourselves in the queue so we are avilable
$threadQueue->enqueue($tid);
#pull input from queue
my $inVal = $inputQueue->dequeue();
if ($inVal >= 0) {
my $outVal = $inVal + int(rand(100));
#enqueue data in output queue
$outputQueue->enqueue($outVal);
} else {
return;
}
}
return;
}
Sunday, January 8, 2012
DIY Wort Chiller
One of the more annoying parts of the brewing process is waiting for your wort (flavored grain tea, beer to be) to cool off enough to pitch your yeast. A device called a wort chiller allows you to greatly reduce the time spent doing this.
I'm going to do a little show and tell for the one I just built (entirely from hardware store components), but we're going to need to talk a little bit about thermodynamics first.
All materials have a property called specific heat. This is how much energy (in Joules) which must be added or removed from a gram of the material in order to change its temperature by one degree Celsius. For water (which even the heaviest beer consists mainly of) this is 4.186 Joules, which is a lot higher than most things. A standard five gallon batch of beer will weigh just shy of 19 kilograms. In order to get it down to yeast pitching temperature you will be trying to lower it from just below 100 Celsius to around 24 Celsius. Simple arithmetic dictates that we need to remove about 6 million Joules from your wort.
The other thing about thermodynamics is how heat behaves. It flows from the areas with the most heat to those with the least until it is evenly distributed throughout the material. This is why putting ice in your drink cools it off, and why the ice melts. We're going to build a device to insert into our wort that will absorb heat from it, and carry that heat away. This will be done by running water through tubing which has been submerged in the wort.
This is a 20' section of 3/8 copper tubing, purchased at a nationwide hardware store that rhymes with Gnome Repo. My girlfriend and I wrapped it around our kitchen fire extinguisher (it was a two person job). Enough tubing was left out to allow it to hang over the edge of the fermenter bucket. We probably could've made it more uniform, but considering that neither of us had ever worked with copper tubing before I think we did a pretty good job.
Now that I had a really cool copper coil, I had to set it up so I could run some water through it.
Here we have a 3/8" Ander-Lign compression fitting attached to the end of the tubing. A 1/2" pipe nipple then connects the connector for a garden hose. The Ander-Lign fitting does not require a compression sleeve, you simply fit it to the tubing and apply torque.
Another Ander-Lign fitting is attached to the opposite end of the tubing. It has a 1/2" to 3/4" adapter installed, so a garden hose can be attached to the output of the wort chiller. This will allow the water to be used for other purposes (waste not, want not) or simply carry it away from the area.
While testing the chiller for leaks, I found it to be very cold to the touch. I sincerely hope that it will significantly reduce the time spent waiting for my wort to cool.
I'm going to do a little show and tell for the one I just built (entirely from hardware store components), but we're going to need to talk a little bit about thermodynamics first.
All materials have a property called specific heat. This is how much energy (in Joules) which must be added or removed from a gram of the material in order to change its temperature by one degree Celsius. For water (which even the heaviest beer consists mainly of) this is 4.186 Joules, which is a lot higher than most things. A standard five gallon batch of beer will weigh just shy of 19 kilograms. In order to get it down to yeast pitching temperature you will be trying to lower it from just below 100 Celsius to around 24 Celsius. Simple arithmetic dictates that we need to remove about 6 million Joules from your wort.
The other thing about thermodynamics is how heat behaves. It flows from the areas with the most heat to those with the least until it is evenly distributed throughout the material. This is why putting ice in your drink cools it off, and why the ice melts. We're going to build a device to insert into our wort that will absorb heat from it, and carry that heat away. This will be done by running water through tubing which has been submerged in the wort.
This is a 20' section of 3/8 copper tubing, purchased at a nationwide hardware store that rhymes with Gnome Repo. My girlfriend and I wrapped it around our kitchen fire extinguisher (it was a two person job). Enough tubing was left out to allow it to hang over the edge of the fermenter bucket. We probably could've made it more uniform, but considering that neither of us had ever worked with copper tubing before I think we did a pretty good job.
Now that I had a really cool copper coil, I had to set it up so I could run some water through it.
Here we have a 3/8" Ander-Lign compression fitting attached to the end of the tubing. A 1/2" pipe nipple then connects the connector for a garden hose. The Ander-Lign fitting does not require a compression sleeve, you simply fit it to the tubing and apply torque.
Another Ander-Lign fitting is attached to the opposite end of the tubing. It has a 1/2" to 3/4" adapter installed, so a garden hose can be attached to the output of the wort chiller. This will allow the water to be used for other purposes (waste not, want not) or simply carry it away from the area.
While testing the chiller for leaks, I found it to be very cold to the touch. I sincerely hope that it will significantly reduce the time spent waiting for my wort to cool.
Thursday, December 15, 2011
Slinging yourself around the internet
Sometimes your need to use the Internet, but you have a connection you can't exactly trust (coffee shop and hotel wifi come to mind). In other situations you may feel a need to hide your real IP address, possibly for security reasons.
There are more than a few tools which you can use to do these sort of things. This post will focus on some of the more popular tools. I am assuming that you are both running Unix of some kind or other, and know how to use it. There probably are equivalent tools for Windows, but I am not familiar with them.
I am not going to tell you exactly how to install each and every one of these tools, because it varies from system to system, but I will provide basic information about how to use them. I also suggest verifying that things are actually working before moving any sensitive information.
Additionally, these tools only work for TCP connections. UDP will not work.
SSH Tunnels
If you have a Unix system, you probably have SSH installed. People usually use it to connect to other machines (pretty much as as an encrypted replacement for telnet) or to copy files from one machine to another.
SSH has a feature that even extremely skilled people are not always familiar with. You can open a tunnel across the SSH session to another host. When you start up the tunnel, it opens a port on your local machine. If you connect to this port, the connection runs across the ssh connection and out the machine you connected to, to a host and port combination you specified when you created the tunnel.
Picture this scenario: you're out of town, and you want to take a look at your bank's web site. Your only internet connection is an open wifi network, and having played with a sniffer or two in your day, you not want to send your banking information across such a network. Back at home the router connected to your cable modem is configured to forward SSH to one of your computers (and a dynamic dns entry to go along with it), and a computer running a SOCKS proxy on 192.168.1.7.
You fire up a terminal window and type:
ssh myhomecomputer.dyndns.org -L1081:192.168.1.7:1080 , and then log in as normal. After that, you configure your web browser to connect to a SOCKS proxy running on port 1081 on your local machine, then browse away.
Everything your browser does now runs across your strongly encrypted SSH connection.
It is important to note that you can use tunnels for a lot of things other than SOCKS proxies. If you want to lock down access to a web based application, you can make a white list consisting of a single host and then open tunnels through that machine.
Proxychains
You now know how to run your applications which allow you to specify a proxy across a tunnel, but not all applications allow you to do that. This is where a handy tool called proxychains comes into play.
Proxychains is a pretty powerful tool, it actually allows you to run your connection through a series of different proxy servers. However, this complexity is outside the scope of this post. If you simply specify a single proxy server (in this case localhost and the port you've opened) in the [ProxyList] section of the config file. This is enough for basic functionality.
Once this is done, simply type: proxychains [command]. Your application will now seamlessly run across the proxy.
TOR
TOR, or The Onion Router is an anonymity tool originally developed by the US Navy, later the EFF, and currently by the TOR project. While the technical details of how TOR works should be read about by the user, all that will be mentioned in this post is that TOR encrypts traffic and conceals its source. When TOR is up and running on a system, it starts a SOCKS proxy that listens on port 9050. If you point a SOCKS aware application at that port, it should go across the TOR network.
There is a tool similar to Proxychains called torsocks. It is also used in a very similar manner (torsocks command).
Conclusion
You now have a basic idea of how to securely tunnel through part of the Internet to another part. Please be aware that a good number of these tools are under constant development, so they may not behave exactly as specified. The important things to grasp are the concepts of tunnels and proxies. If those are understood, you should be able to correct for any minor differences encountered.
There are more than a few tools which you can use to do these sort of things. This post will focus on some of the more popular tools. I am assuming that you are both running Unix of some kind or other, and know how to use it. There probably are equivalent tools for Windows, but I am not familiar with them.
I am not going to tell you exactly how to install each and every one of these tools, because it varies from system to system, but I will provide basic information about how to use them. I also suggest verifying that things are actually working before moving any sensitive information.
Additionally, these tools only work for TCP connections. UDP will not work.
SSH Tunnels
If you have a Unix system, you probably have SSH installed. People usually use it to connect to other machines (pretty much as as an encrypted replacement for telnet) or to copy files from one machine to another.
SSH has a feature that even extremely skilled people are not always familiar with. You can open a tunnel across the SSH session to another host. When you start up the tunnel, it opens a port on your local machine. If you connect to this port, the connection runs across the ssh connection and out the machine you connected to, to a host and port combination you specified when you created the tunnel.
Picture this scenario: you're out of town, and you want to take a look at your bank's web site. Your only internet connection is an open wifi network, and having played with a sniffer or two in your day, you not want to send your banking information across such a network. Back at home the router connected to your cable modem is configured to forward SSH to one of your computers (and a dynamic dns entry to go along with it), and a computer running a SOCKS proxy on 192.168.1.7.
You fire up a terminal window and type:
ssh myhomecomputer.dyndns.org -L1081:192.168.1.7:1080 , and then log in as normal. After that, you configure your web browser to connect to a SOCKS proxy running on port 1081 on your local machine, then browse away.
Everything your browser does now runs across your strongly encrypted SSH connection.
It is important to note that you can use tunnels for a lot of things other than SOCKS proxies. If you want to lock down access to a web based application, you can make a white list consisting of a single host and then open tunnels through that machine.
Proxychains
You now know how to run your applications which allow you to specify a proxy across a tunnel, but not all applications allow you to do that. This is where a handy tool called proxychains comes into play.
Proxychains is a pretty powerful tool, it actually allows you to run your connection through a series of different proxy servers. However, this complexity is outside the scope of this post. If you simply specify a single proxy server (in this case localhost and the port you've opened) in the [ProxyList] section of the config file. This is enough for basic functionality.
Once this is done, simply type: proxychains [command]. Your application will now seamlessly run across the proxy.
TOR
TOR, or The Onion Router is an anonymity tool originally developed by the US Navy, later the EFF, and currently by the TOR project. While the technical details of how TOR works should be read about by the user, all that will be mentioned in this post is that TOR encrypts traffic and conceals its source. When TOR is up and running on a system, it starts a SOCKS proxy that listens on port 9050. If you point a SOCKS aware application at that port, it should go across the TOR network.
There is a tool similar to Proxychains called torsocks. It is also used in a very similar manner (torsocks command).
Conclusion
You now have a basic idea of how to securely tunnel through part of the Internet to another part. Please be aware that a good number of these tools are under constant development, so they may not behave exactly as specified. The important things to grasp are the concepts of tunnels and proxies. If those are understood, you should be able to correct for any minor differences encountered.
Wednesday, December 14, 2011
Why root access matters
I have long held the belief that a person should have complete and total control of his digital devices. While this is largely because I think if a person shells out for a high tech toy, she should be able to run whatever software she likes, tweak any and all settings, and so on. Some insufficiently suspicious folks called me paranoid when I would mention that without full control of the device, you can't be sure that all the software running on it is benign.
About two weeks ago, it was learned that several cell phone carriers have been shipping Android phones with a hidden application called CarrierIQ installed. This application can do things like monitor the phone's location via GPS, and check signal quality as well. In addition to this, it can monitor text messages for specific strings and what URLs have been visited.
Yesterday, the FBI declined a Freedom of Information Act request about the software on the grounds that the information was related to "a pending or prospective law enforcement proceeding". Today, the EFF reported that they believe keystroke data is being inadvertently transmitted to third parties.
It is important to note that at least some (if not all) of the information CarrierIQ gathers does serve legitimate diagnostic purposes. In my line of work we occasionally need to perform packet inspection to resolve various network issues. There is a very large and very real potential for privacy abuse here, but it doesn't happen. While it is true that there are a variety of policies and procedures to make sure that our customers' privacy is respected, we simply don't have the time to dig through other people's packets.
Carrier IQ probably is not slinging your text messages and browsing history off to the CIA (that'd be much easier to do on the carrier's network anyway). None the less, if people had full control of their phones in the first place, this application would not have been hidden, and not gone unnoticed for an undetermined period of time.
Anyone who hides things from you on devices you own or tries to keep you in a walled garden is not your friend.
About two weeks ago, it was learned that several cell phone carriers have been shipping Android phones with a hidden application called CarrierIQ installed. This application can do things like monitor the phone's location via GPS, and check signal quality as well. In addition to this, it can monitor text messages for specific strings and what URLs have been visited.
Yesterday, the FBI declined a Freedom of Information Act request about the software on the grounds that the information was related to "a pending or prospective law enforcement proceeding". Today, the EFF reported that they believe keystroke data is being inadvertently transmitted to third parties.
It is important to note that at least some (if not all) of the information CarrierIQ gathers does serve legitimate diagnostic purposes. In my line of work we occasionally need to perform packet inspection to resolve various network issues. There is a very large and very real potential for privacy abuse here, but it doesn't happen. While it is true that there are a variety of policies and procedures to make sure that our customers' privacy is respected, we simply don't have the time to dig through other people's packets.
Carrier IQ probably is not slinging your text messages and browsing history off to the CIA (that'd be much easier to do on the carrier's network anyway). None the less, if people had full control of their phones in the first place, this application would not have been hidden, and not gone unnoticed for an undetermined period of time.
Anyone who hides things from you on devices you own or tries to keep you in a walled garden is not your friend.
Wednesday, November 23, 2011
SOPA and the Casio keyboard of mystery
You may have heard of a new law called SOPA that our esteemed rulers leaders currently have in development.
SOPA stands for Stop Online Piracy Act, which it will not do. What it will do is require ISPs to block access to content which allegedly infringes upon copyrights when requested to do so by the holder of said copyright. It will also require Visa, MasterCard, PayPal, et al to block fund transfers to individuals or groups trading in content which they allegedly do not own.
The real non-technical problem here is that these blockages won't require a court order or a warrant. The copyright holder simply has to make a claim of infringement.
Also, if this wasn't bad enough, it'd make streaming copyrighted material a felony.
There are a lot of technical problems with this too. The ISP will probably just poison their DNS servers to prevent the site in question from resolving. There isn't a lot to keep someone from just using a DNS server located outside the United States, or just turning up their own resolver for the matter. If actual routes were blocked, proxy servers aren't exactly hard to find.
As far as blocking financial access, this is yet another reason why I like Bitcoin.
There is no third party intermediary, you just send money and be done with it.
In conclusion, SOPA is a bad law that will make it hard for ISPs to do business. Lamar Smith (the bill's sponsor) should go fuck himself with a garden rake, and I do not mean with the handle.
On a more pleasant note, despite my better judgment I decided to dig around on the CB band (27 mhz) tonight. Someone is playing a little Casio keyboard tune on CB channel 17.
SOPA stands for Stop Online Piracy Act, which it will not do. What it will do is require ISPs to block access to content which allegedly infringes upon copyrights when requested to do so by the holder of said copyright. It will also require Visa, MasterCard, PayPal, et al to block fund transfers to individuals or groups trading in content which they allegedly do not own.
The real non-technical problem here is that these blockages won't require a court order or a warrant. The copyright holder simply has to make a claim of infringement.
Also, if this wasn't bad enough, it'd make streaming copyrighted material a felony.
There are a lot of technical problems with this too. The ISP will probably just poison their DNS servers to prevent the site in question from resolving. There isn't a lot to keep someone from just using a DNS server located outside the United States, or just turning up their own resolver for the matter. If actual routes were blocked, proxy servers aren't exactly hard to find.
As far as blocking financial access, this is yet another reason why I like Bitcoin.
There is no third party intermediary, you just send money and be done with it.
In conclusion, SOPA is a bad law that will make it hard for ISPs to do business. Lamar Smith (the bill's sponsor) should go fuck himself with a garden rake, and I do not mean with the handle.
On a more pleasant note, despite my better judgment I decided to dig around on the CB band (27 mhz) tonight. Someone is playing a little Casio keyboard tune on CB channel 17.
Monday, November 14, 2011
Optical theremin
Another subject I've always meant to learn more about is electronics. When I was a kid I remember some of my father's friends building various interesting contraptions in their garages and basements, hunched over circuit boards with a soldering iron in one hand and a stubby bottle of Lucky Lager in the other.
When I was old enough to learn what actually went on with electronic components (instead of just blindly connecting things to other things) I downloaded the floppy disk images for Slackware from a BBS and immediately lost interest.
Every now and then I have thought about trying to get back into the hobby. When the new issue of Make showed up at the house early last week there were plans for a light-controlled theremin. It looked easy enough, so I sat down and gave it a try.
It was indeed easy enough. I have now built my own electronic annoyance device.
I'm going to try and hunt down a case for it in the next few days. If I stick with this I will need to get the supplies needed to drill and etch circuit boards as well.
When I was old enough to learn what actually went on with electronic components (instead of just blindly connecting things to other things) I downloaded the floppy disk images for Slackware from a BBS and immediately lost interest.
Every now and then I have thought about trying to get back into the hobby. When the new issue of Make showed up at the house early last week there were plans for a light-controlled theremin. It looked easy enough, so I sat down and gave it a try.
It was indeed easy enough. I have now built my own electronic annoyance device.
I'm going to try and hunt down a case for it in the next few days. If I stick with this I will need to get the supplies needed to drill and etch circuit boards as well.
Subscribe to:
Posts (Atom)