I’ve been busy with a ton of projects and a slump at work so I’ve been all over spectrum on wanting to do anything related to computers. I’ve moved my blog to a Raspberry Pi 2 and felt that I needed something that was static but yet functional. So I’m trying out Frog.
In the coming months a few States (IA, DE) will be releasing the first ever “Digitial Driver’s License”. As with most things, being able to keep a digital copy in your pocket is quite convenient. Surprisingly, with everyone becoming more security concious both the government officials requesting the Digital ID’s and the companies creating them are both putting our safety in the forefront of the project. There is only one flaw in their design: You have to give the police your phone!
The other day I was reading through /r/scheme and found an interesting post about continuations. The post did a pretty good job of showing some examples of how to use continuations, but seemed to miss the mark explaining how they work and how to add them into your design. So I thought why not take a crack at it.
“A Continuation is an abstract representation of the control state of a computer program.” Thats how Wikipedia explains it. So it is a snapshot of the current state of your application at some given point in time. But how can that be useful?
History: Another high traffic page from my previous site being transitioned here.
If you’ve ever worked with embedded systems or built code for a system other than your build machine you’ve probably found that running code on native hardware can sometimes generate different results than on your Beige Box. Being able to run and debug your code on your target hardware can be very useful but sometimes quite difficult to do. Using GNU’s Debugger gdb can be extremely cumbersome on its own and I typically prefer to use the GUI client ddd. With most of my projects, the target hardware does not have X support and most of my interactions are through Serial or Ethernet. If you are in the same situation you might find gdbserver, which comes with gdb, of use.
For a while now I’ve been using building applications using a Cross Compiler Jail (see blog post) on my development system to make the use of cross compilers much simpler. I can compile inside a system that looks and feels like I’m on the target’s OS having gcc, arch, and a bunch of other attributes all pointing to a ARM CPU even though I’m compiling on an x86_64. No need for calling
gcc-arm-unknown-linux-gnueabi-gcc when the jail macros it to
A bit of history: I had written a wiki article a few years back about how to setup a cross compiler and a build environment for working with ARM CPUs and Debian based distributions. I’m in the process of getting rid of the site so I thought it was a good time to retry this setup and put it on my new site.
This tutorial will cover setting up a build environment for cross compiling. This tutorial assumes you are building on a Debian based system for a Debian based target. If your systems are slightly different follow the spirit of the tutorial rather than the letter.
I’m a big proponent of taking personal security measures when interacting on the internet. I sign all my emails using my PGP key so you know it is from me and not a virus, spammer, or a stolen account. I encrypt my netbook’s hard drive and keep a pretty tight firewall. For the most part I like to keep everything under lock and key because you just never know who might get your info and what they might do with it.
What if you don’t want to go through all this work. Without a Public/Private Key you can still use Symmetric Encryption to send files and emails and store data on your computer with an increased level of security. All possible with a few utilities found on most *nix systems.