September 2013 Archives

September 23, 2013 @ 16:20 EDT

Tactical Assault Bunny

206394:294659


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos

September 23, 2013 @ 09:18 EDT

A friendly English reminder

206381:294627

In other news, I'm in Cambridge (UK) for a work trip. After a detour to Amesbury I'll spend a day or two in Havant before heading back across the pond.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos

September 23, 2013 @ 08:49 EDT

310/365: Truth in Stereotyping

206377:294622

And in other news, that's all I'm doing on this 365 thing. It never recovered after my move, but it was what I needed at the time.

I'll be trying to post more often.


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

September 11, 2013 @ 23:03 EDT

309/365: Coming Through

206249:294433


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

September 11, 2013 @ 22:56 EDT

Okay, Freescale, I give up.

The Freescale "Freedom" FRDM-KL25Z boards have a lot going for them. They're cheap ($13), and sport an ARM Cortex M0+ core in an Arduino-ish form factor, with a fancy "OpenSDA" USB-based flash/debug thingey bolted onto the side for user-friendlieness.

Unfortunately.. they botched the execution in many ways; some subtle, some less so.

Let's start with the first impression. In order to get anything more useful than marketing materials from Freescale's web site, you have to register. They then hand this info off to a distributor who proceeds to email and call you before you have a chance to meaningfully evaluate anything.

The actual datasheets and programmer manuals were okay; not the worst I've seen by any means, but not all that great either.

But the software side of things is another story. The only thing they offer is a ginormous plugin for an obsolete version of Eclipse that supports all of their microcontrollers... via a code generator. Theoretically, once you generate that skeleton codebase it's usable outside of Eclipse.

At least you can extract the not-quite-CMSIS-compliant processor headers from that morass. But those files say "all rights reserved" which makes them technically unredistributable. Sigh.

But the best part, the part I spent the last day and a half fighting, was their "OpenSDA" programming/debugging mechanism.

In theory, it's a smart design -- It presents as a composite USB device consisting of a serial port and a virtual mass storage device. The serial port gives you the console, and to program the controller's flash, you just copy a new firmware image over to the filesystem.

It turns out there's nothing open about it.

OpenSDA is about as proprietary as it gets. To actually use it as a debugger under Linux you'll need a proprietary 32-bit-only binary drivers+libraries. That's right, they don't even supply an application to use it -- even a GDB server will cost you extra.

So it's useless as a debugger. What about as a flasher/programmer? It fails even more spectacularly there, thanks to it simply not working under Linux (or even OSX), due to gross violations of the USB mass storage spec.

In all fairness, they did eventually fix these problems (both in their bootloader and their flasher "application").. but you'll still need a native Windows system (not a VM, because their USB enumeration is just that badly broken) to do the update. Once you have the new application running, it works well enough, though it doesn't complain if you try to write something too large.

The one saving grace is that Keil released a firmware file that replaces the anything-but-OpenSDA "flasher+debugger" with ARM CMSIS-DAP compliant interface that JustWorks(tm). Unfortunately, it's only usable as a debugger with the tools I have, so to actually flash an image, you have switch back to the OpenSDA "applications" -- which, since they pulled their fixed-for-Linux bootloader, requires a Windows box.

All I want to do is write a "Hello World" program on this thing, and I've wasted the better part of two days on things that should JustWork(tm).

So much to "Open" or "Freedom" -- Grand ideals ruined by horrible execution. Unfortunately, this is the sort of thing I've come to expect out of Freescale. Every encounter leaves me wanting to bash my head againt the wall.

A month or so ago I compared Freescale to someone shooting themselves in both left feet. Maybe I should add "while running backwards" to that analogy.

In comparison, STMicro's STM32F4DISCOVERY board ($15 with a Cortex-M4!) isn't without its flaws, but it took less than half an hour to assemble everything I needed to flash and debug the board, and their documentation and software samples are comprehensive and excellent.

...It's not much of a race.


Posted by Solomon Peachy | Permanent link & Comments | File under: Free Software

September 08, 2013 @ 22:51 EDT

One Closet, Clean

My closet has always been a bellweather for my mental state. A perfectly tidy closet is usually an indication that there's something weighing on my mind -- Folding and/or hanging up clothes is one of those mindless tasks I can just zone out doing. Similarly, letting the clean clothes pile up on the floor of my closet is a procrastinative task, a sign that I'm avoiding something deeper.

Tonight, I'm not sure what's on my mind, but the net result is that instead of the better part of five (admittedly tiny) loads of laundry, the sole sign of disarray is a solitary white plastic hanger left as a token protest against order for order's sake.

...now that I've taken care of what needs doing, what wants doing? As always, I seem to lack sufficient imagination to answer that question in any longer-term sense. I only know that I can do more; that I can amount to more -- whatever that actually means.

Fortunately, these days I'm able to channel this drive professionally, and my cats are more than happy to remind me that they are the higher purpose of my life.

Hmm, a drive for selfeless individuality. What's one more paradox?


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

September 08, 2013 @ 15:45 EDT

308/365: Lunch is served

206150:294234


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365

September 05, 2013 @ 22:56 EDT

Logarithmic Losses

Tonight I found out that one of my former Tai Chi instructors, Tony Dahab, passed away in his sleep after a long battle with cancer. Services were held on my birthday.

The day after my birthday, my tenant's cat suffered a sudden pulmonary edema, and had to be put to sleep in an act of mercy. This is the same cat whose life I'd saved a year ago, almost to the day.

Yesterday, the seven-legged banana spider guarding the light over the front door to the office fell from her precarious web to her death on hard concrete.. before she was able to lay her eggs.

Three days, three deaths.

Three deaths, three euphamisms.

Three euphamisms, three losses.

I will miss them all; The spider who protected me from blood sucking parasites and squeamish individuals; The cat whose youthful exuberance was tempered only by a lack of brain cells; The great man who passed down much wisdom to his many students.

Requiescat in pace.


Posted by Solomon Peachy | Permanent link & Comments | File under: Life and other BS

September 05, 2013 @ 11:07 EDT

The great hard drive switcheraoo of 2013

Last night I finally finished the last of the hard drive swaps. From start to finish, this took about six days from start to finish, mainly because I wanted to rejigger, well, everything.

Shaftnet started out with:

  • 4x1.0TB (RAID5) Bulk storage (xfs)
  • 4x1.5TB (RAID5) Bulk storage (ext4)
  • 2x0.5TB (RAID1) Operating System and user homedirs (ext4)
  • 1x0.5TB (eSATA) Backups (xfs)

All of these ware hanging off a 3Ware 9650SE-16ML controller. To further complicate things, neither of the RAID5 arrays had their partitions/filesystems aligned properly to the RAID stripe size, resulting in sub-optimal write performance.

The plan, as originally envisioned:

  • Add a new 4x2TB array (properly aligned, xfs)
  • Copy contents of 4x1TB array to 4x2TB
  • Copy contents of 4x1.5Tb array to 4x2TB
  • Blow away 4x1TB array
  • Blow away 4x1.5TB array
  • Re-create 4x1.5TB array (properly algined, xfs)
  • Move old content back to 4x1.5TB array (mainly my photos)
  • Upgrade the 2x0.5TB arry to 2x1TB (in-place)
  • Repartition "new" 2x1TB array to utilize the extra space
  • Power down system, physically swap around drives, power back up
  • Grow 2x1TB filesystem to use the extra space
  • Dump backup drive's contents to 1TB drive
  • Grow "new" backup drive filesystem to full 1TB
  • Swap workstation 0.5TB drive with 1TB drive
  • Throw out the two failing 0.5TB drives
  • Utilize remaining two (good) 0.5TB drives for other purposes

Needless to say, I hit a few snags.

The RAID controller failed one of the 1.5TB drives after I'd already moved the data back over, with errors leading me to believe there would likely be data loss. The "data" in this case was my photo repository, fully checksummed with backups on optical media in case of problems. It was simple enough to verify everything, though with that extra load it took a couple of days for the arrays to finish re-initializing.

Then came the real hiccup -- The RAID controller only supports growing the size of a RAID volume by adding disks, rather than by replacing the existing drives with larger ones. This meant my strategy of growing the 2x0.5TB array to 2x1TB didn't work.

I generally love the 3Ware RAID controllers; they JustWork(tm) and have rock-solid Linux support. But this is a serious omission; every other hardware RAID controller I've used will automatically grow an array when the drives are all replaced with larger ones.

In the end, I had to create a new 2x1TB array, take the system offline and dump (via dd) the old array contents to the new one. Then I discovered I'd not partitioned the system particularly intelligently when I set it up five or so years ago, forcing a lengthy partition reshuffling so I could grow / and /var proprortionally. Four hours of needless downtime.

Fortunately, after all of that, the backup drive migration was straightforward and seamless.

Then it was onto my workstation, with its failing 0.5TB drive formatted mostly as NTFS (until I recently retired my old laptop, it was only ever used for games and printer driver reverse engineering) I'll spare the details of that migration, except to say that NTFS doesn't handle bad sectors particularly well...

That system now has a 1TB drive dedicated to Linux (xfs) and one of the two remaining good 0.5TB drives for the old WinXP install that I only boot into once every few months. I'm giving the final 0.5GB drive to my ex-wife.

Now, I need to figure out what to do with the pair of dying drives. I wonder if I can find a local gun range willing to let me use them as a target?


Posted by Solomon Peachy | Permanent link & Comments

September 05, 2013 @ 10:02 EDT

Webcrawlers and bandwidth

Every now and then I carefully go over shaftnet's aggregate logs to see where the traffic is coming from. Every now and then something stands out, such as the time two different IPs in China were downloading a set of large hockey videos 4-5 times a day.

Lately I've noticed a few more discrepancies -- Towards the end of August I discovered there wasn't an appropriate robots.txt file on some of shaftnet's sub-sites, most crucially the portal to the git repositories. Consequently, crawlers kept hitting the diff and snapshot links on every commit, driving up the CPU and bandwidth usage considerably. I fixed that, and saw a noticable dive in utilization almost overnight.

Now that September has started, I took a look at the first four five days' worth of server logs, and one more things stands out -- Baidu (the Chinese search engine giant) is single-handedly responsible for about 2/3rds of all hits -- On average, I'm seeing a request every three seconds from their bots.

Fortunately since I capped gitweb/cgit's snapshots, the bandwidth load has noticably dropped, so despite Baidu being 66% of the hits, it's only responsible for about 12% of the bandwidth usage.

Still, I see zero referrals from baidu in the logs. That's a lot of server/bandwidth load and log pollution for no discernable benefit.

(In comparison, googlebot's only responsible for 4% of the hits so far)


Posted by Solomon Peachy | Permanent link & Comments

September 01, 2013 @ 20:37 EDT

Software Development

99 little bugs in the code; 99 little bugs in the code; Take one down, patch it around, 117 little bugs in the code...


Posted by Solomon Peachy | Permanent link & Comments

September 01, 2013 @ 19:07 EDT

307/365: Dress Blues

206097:294133

Finally Set up the studio equipment in the extra room. I think it turned out pretty well!


Posted by Solomon Peachy | Permanent link & Comments | File under: Photos, Project_365