wiredfool

I got a little data off the iMac drive by copying while running OSX, but it turns out that it’s been far more reliable to just pull the drive and hook it up to Ubuntu with a sata->usb adapter. Large file copies in OSX would fail after a while, but I’ve been able to pull several > 100MB files (lightroom catalogs) from the drive without halts or apparent errors. I’ve been able to get all my email off, and a selection of other bits and pieces that will make restoring the machine that much easier. And, to top it off, I found a 5 month old backup from a earlier run of Time Machine.

But what’s even better is my old dev workstation, one that I was in the process of migrating off of onto more modern hardware, lost its root drive over the weekend. But, no data loss on that one.

The first rule of backups is to have one.

The second rule of backups is to never delete the most recent backup.

Rewind to this morning, I see this:

What this doesn’t say, in large red letters is “WARNING LARKS VOMIT THIS WILL DELETE YOUR BACKUP!”, it says that it will “remove your existing backup history”.

This is inherently a bad thing, though I didn’t realize it at the time, I really should have just copied that sparse bundle on the disk before letting Time Machine destroy 400 GB of backups. I’d like to point out that there was something like 1.3 TB of space on the drive, so there was no space pressure — it could have easily had an extra copy.

Because, first the delete failed. Apparently it takes a lot longer than expected to delete 400GB. Then, the new backups took forever. Like 1G/hr. On par with my net upload speed. And the computer was being narcoleptic for minutes at a time.

You know why you never want that little window when you don’t have a backup, even one that’s not with ‘improved reliability’?

(click to expand, or just guess)

“This disk has a hardware problem and can’t be repaired. Backup as much data as possible and replace the disk”

Thanks.

I could have used some of those 400 gigs of backups, because odds are, I’d probably be able to salvage more than I’m getting now, at a few hundred K per second.

Update: radar bug rdar://9215019

I’ve now got an arduino to start on the automation of the chicken’s door. It’s only been 6 months since I put in the sliding door, and 10 months since they’ve been in the outside coop, so it’s time to do a little hacking.

Day 1, the blink example works.

Day 2, I’ve got a basic light sensor running with a random sensor from American Science and Surplus, a pull up/current limiting resistor, and the analog in ports. Helpfully enough, there’s a pretty simple example to get it all running with very little programming.

Day 3, I’m looking at the sensor levels, and trying to distinguish between dusk and night. The sensor appears to allow between 10ma and 100ma through, at an apparent resistance from to the meter of between 5k and 100 ohms. The trouble is that most of the sensitivity is in the brighter ranges, and the range where I need the resolution is in the 4.5k to 5k range, or in the 10 ma end of current. (it’s not a simple resistor, so simple approaches aren’t goign to necessarily be correct)

Using a simple voltage divider isn’t going to give me a whole lot of resolution in this range, so I may need to look at some sort of amplifier circuit (either op amp or transistor) and clip or compress the bright end of the spectrum. With one 220 resistor as the limiter, I’m seeing about 3v over the sensor at indoor night light levels, and slightly more (.1v) when covered. If I lower the resistance to 110, I’m seeing more like 3.6v across the sensor.

The basic design I’m thinking of is that if we see ‘dark’ for 15 minutes or so, I’m going to close the chicken door, and if I see ‘light’ (or increasing light) for a similar time, I’ll let it open. Thresholds and delays are TBD, since it’s going to depend on bright moons, dark rainy days, and other weather related light level issues. Also chickens. I suspect that the microcontroller has a larger brain than most of the chickens.

Other observations — I’m probably going to want another one, and probably a mini instead of an uno, so I can just drop it into a breadboard instead of using the wire sockets. On the other hand, the motor shields and comm sheids work better with the original form factor. I’m probably going to want another one to play with for lego or r/c car robotics. Or two.

According to the lightroom docs, if you are using a config like this:

  fastcgi.server = ( ".php" =>
      (( "socket" => "/tmp/php-fastcgi.socket",
          "bin-path" => "/usr/bin/php-cgi",
          "max-procs" => 10,
          "bin-environment" => (
              "PHP\_FCGI\_CHILDREN" => "16",
              "PHP\_FCGI\_MAX\_REQUESTS" => "1000" 
          ),
          "broken-scriptfilename" => "enable" 
      ))
  )

you will have (following the famous formula):

num-procs = max-procs * ( 1 + PHP\_FCGI\_CHILDREN ) 
10 * (16 + 1) = 170 procs

This is perhaps not what you want, especially since the php instances will slowly increase their memory high water marks and not release memory until they will generally all have processed your most memory intensive script, at which point you will have probably run out of memory in a manner similar to what apache will usually do for you out of the box.

If you’re using an opcode cache, you want one process, to allow one cache to be shared amongst all the child processes. (apparently, according to the google. I’m checking now). If you do have php children set, you don’t want 1, as that will have one controlling process and one child process, for a nice waste of space. My impression is that you want either max processes = 1 or max children = 1, and let the other float such that processes * max memory is less than your ram.

So, Ben is in a Lego robotics class at his school where they’re using the Lego WeDo kits to do a little exploration of robotics at an early elementary level. I’ve been helping in the class a bit, since I’m the ‘person most likely to know how to program these things’ of the people who could help out.

The kits are much smaller than the NXT/mindstorm ones, they’re just about 150 pieces of technic and ordinary legos plus a USB hub, motor, IR distance sensor, and tilt sensor. Also unlike the NXT systems, it only works when connected to the computer. The good part is that you’ve got all the programming capability of a computer to use, the bad part is that it’s a really strange environment. (and there’s a pesky usb cable, which amazingly enough, tends to trigger the distance sensor). There’s a kids instruction book in the kit, which is essentially similar to any other lego instruction book, it tells you how to build the kit, but not what to do with it at the end. There’s a good chunk of stuff in the teacher’s guide, some of it having to do with the programming, and some with other activities with less direct connections to the robotics theme.

The programming environment is described as ‘iconic’, fitting in with the general tone of lego instructions. It’s strange, and a little unclear as to what all the functions really are. It gets a little better if you can read the docs, and see the explanation of what the icons mean in the teacher’s guide, but that’s not in the kids’ books. It’s also not internally consistent. The ‘run motor for x time’ block takes a number, and that number is apparently in 1/10 of a second. It’s not clear from the context, I found that online somewhere in a discussion of how some of the items work. The delay block also takes a number, but it delays in full seconds.

Finally, and most importantly, it’s not clear how to branch. The programs are linear, with loops and delays, but nothing that looks like an if statement. There is no obvious conditional or branch. In a way, that makes sense if you can have a bunch of event based triggers that are easily tied to the sensor readings, but that’s also a bit tricky. (It can be done, and there are at least two ways of doing it. One way is to send a message, and receive it multiple times, the other would be to have the same keypress event start all the threads, then in each case have an infinite loop with a delay on the sensor condition as the first item in the thread. I say thread because they’re lines of blocks that look like threads, not that they’re actual threads). The actual projects in the class don’t really explore any sort of conditional behavior, they’re more in line with triggering some action on a sensor response. That may have something to do with the limitations on the programming environment.

Thankfully, there’s a solution: Scratch. Scratch has built in support for the motor and sensors in the 1.4 version. And Ben started playing with it a bit over Christmas break, so he’s already somewhat familiar with it. It’s got conditionals, words that explain the functions, and units on the numbers. When the motor block says run for x seconds, you know what you’re getting. Though, the directions “this way” and “that way” are a bit… relative.

I’m interested in pushing this a bit beyond what’s in the class, which seems to focus way more on the building part and less on the possibilities for interesting behavior. So, I’ve borrowed a hub, motor, and sensors to see what can be done at home. The criteria are tight, as you can really only run one motor and one sensor at a time. You can hook two sensors and a motor up, but one of the sensors gets very erratic and noisy when that happens. Additional USB hubs could be used, but there are still issues running more than one motor at a time. So, there are tight constraints.

Looking for ideas that would be interesting to build and play with, we settled on a robotic car. The motor will drive the rear wheels, and in a nod to the cheapest sorts of radio control cars, we’re going to try to make the front wheels turn the car in reverse, so that it can theoretically avoid obstacles in its path. So far though, it can drive forward and backward (in a straight line) when the arrow keys are pressed, and if something gets in the way of the sensor, it backs up for 2 seconds. Ben added code to make it go faster when the up arrow is pressed, and stop on the down arrow. He has plans to work with it for the next couple of days.

(I also saw the 2 wheel balancing robot on the MIT Scratch/WeDo page. That would be fun to try to, but perhaps when we have a better handle on the drivetrain)

This makes me want to get an arduino and interface it to a real radio control car. It wouldn’t be _that_ hard. Tim’s uses 4 wires for driving two motors, but I’d probably want something a bit more robust than that one.

Last weekend, before the hog arrived, we pulled out a bunch of beef short ribs from the freezer to make a little room. I knew that I wanted to try a braise again, but the last time that we did it, the flavor was a little vinegary. (That was the recipe from Tom Calliuchio’s Think Like a Chef, with sherry vinegar and cherry peppers in it.)

So, taking inspiration from a few recipies in various meat cook books, I wound up with something that could hardly go wrong.

– 7 lbs of short ribs. (It’s what I had, and was more than I needed, but not by that much)
– 1 qt + 1 cup chicken stock — Quantities here were also what I had on hand from making stock a few weeks back. We froze it in quart jars, and there was a cup left over from something a night earlier, and a quart from the freezer.
– 1/2 bottle cheap red wine.
– 2 smallish heads of garlic, with the cloves split out.
– Couple of Carrots, Celery Stalks, and an onion, in big chunks.

Browned the ribs for a cew minutes on each side, then assembled the stock, wine, and veggies and heated that to a boil. Added the ribs back in, and at this point, I needed to have a 12″ fry pan and a 6 qt stockpot to hold everything. Added a little water to nearly cover the ribs, then put in a 350 oven till everything was at a bare simmer. Turned it down to 325 and let it go for a few hours. After a couple, I turned the ribs, after a couple more, I took everything out, separated the ribs from the veggies, strained the liquid, and reduced it by about half. Reheat the ribs in the liquid, and serve.

The liquid was a thick beef stock, with intense beef flavor and only a hint of wine, and no vinegaryiness. The meat was fall apart tender, and very flavorful.

I want to try this Cider Braised Ham Roast, or something similar. I was a little unhappy that we got 4 extra fresh (frozen) ham roasts (not cured) with the half hog, instead of putting it in sausage. We _know_ we eat sausage. But then again, we also know that we really like pulled pork. So, hearing that the fresh ham roasts can be used like butt, and knowing that braises are goooood, I think this is going to be a winner.

Only 2 short years ago, we were vegetarians. Now there’s 40 lbs of pork in the outside fridge curing into bacon and ham.

We’ve got one ham going, roughly 20 lbs on the bone, which was half of the back leg of the half pig that we got. It’s big. It’s a huge chunk of meat. And it’s curing in the Cider Cure from Hugh Fernley Whittingsworth’s Meat book. It’s likely go go something like 30-40 days in the cider and brine, then it will be hung to dry for a while.

We’re doing 2 different styles of bacon, one is the basic dry cure from Hugh’s book, with mostly salt, a little sugar, and some spice. It needs to be re-rubbed every day or so, so it’s a bit more work. The other one is a wetter, maple, sugar and salt cure Basic fresh Bacon from the Charcouterie book. These will go a week to 10 days — the dry cure one is already looking firmer, the wet one is going a little slower.

The cats were terribly interested in what was going on in the kitchen while this was in progress. Thankfully, no bacon was lost to cats, nor was any bacon taped to them.