wiredfool

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.