Control Yourself
If you read Mike’s last blog post about his trials and tribulations with FreeNAS, you know that he ultimately opted to use Windows 8.1 as his storage solution. That wasn’t because FreeNAS didn’t work (Mike admits it probably would be fine now that his RAM issues are resolved), but was because he was more comfortable with Windows – specifically, with his ability to understand exactly how to use Windows tools to exert control over his data and ensure continued access to that data. He didn’t want to be reliant on me, or other Unix and ZFS aware people, to maintain control over the destiny of his data. This idea – control over your own destiny – is a common thread among many Cirrascale employees, and by extension, guides how Cirrascale operates.
I touched on the idea of developing versus buying in one of my prior blog posts, and that is one aspect of controlling your own destiny. Buying an off-the-shelf component inherently puts you at the mercy of whomever you are buying it from, but is mitigated by only using components for which there is a second source. If one supplier closes it’s doors, or otherwise stops being a source for the component, business continuity isn’t compromised because the component is still available from another supplier. When developing, rather than buying, the idea changes a little, but is still present.
In my personal life, I like to make sure whatever hardware I buy is something I have reasonable faith can be kept up to date for its useful life – my important data lives on ZFS, now that there are Open Source ways to access it across multiple operating systems; my servers all run NetBSD or Gentoo Linux which I can (and do) build from source; my wife and I have phones and tablets that run ROMs with good community support rather than relying on the manufacturer to provide updates. Not that that is without its own pitfalls relating to control. Allow me to digress for a moment…
After getting annoyed at some of the bloat under the guise of features that Cyanogenmod has been taking on, I decided to give OmniROM a try on my phone, and liked what I saw. Unfortunately, my phone isn’t (yet) part of the OmniROM targets that are included by their build bots, so I can’t rely on the latest changes getting incorporated into nightly builds. There are a few other developers who have kindly made their device trees supporting OmniROM available on github, but once more the issue of control comes up: I don’t agree with some of the cherry-picks those developers are pulling into their trees, so don’t want to just point at their repositories as the source for my ROM. Although all is not perfect with the world, the use of open source software and tools means I at least have the ability to check out the source, re-build what I currently have, and make updates and modifications myself. Google, GitHub, XDA, and many other parts of the Internet act as my first, second, and more source supplier. I have control over what is going onto my phone, and any lack of updates is more-or-less a reflection of the effort I want to put forth, rather than being beholden to some other company that may or may not remain in business, and may or may not have interests aligned with mine.
On the business side of things, a short while back, one of our customers came across a feature of our BladeRack 2 Series Fan Trays that didn’t work like they expected. The Fan Tray is pretty simple, so adding the functionality that the customer expected didn’t seem like a big effort. (For readers not familiar with the BladeRack 2 architecture, each blade is sandwiched rows of fans that generate vertical airflow. These fans are housed in hot-swappable units containing two or more fans, and called a Fan Tray.) Perhaps because the Fan Tray is so simple, there had been no work on it for years (the SVN history leads me to believe that the last modifications were well before Cirrascale even existed in its current form), and Cirrascale didn’t have a development or test setup that could be used to make modifications to the PIC firmware. The original Fan Tray developer used the Microchip IDE version 8 and the CCS compiler version 4-something…both of which are now years past their sell-by date. Before making any modifications to the PIC firmware, I wanted to make sure that I could reliably recreate the existing firmware, and flash it to the Fan Tray. Fortunately Microchip makes available old versions of the IDE on their website, but CCS requires some hoop-jumping to get access to a specific compiler version. Neither company is under any obligation to continue to provide access to old versions of their tools, and it’s clear that CCS’ modus operandi is to encourage everyone to stay on the current release – the compiler updates itself online, and new installations always get the most recent version via the online installer that CCS distributes. Even though Cirrascale designed and built the Fan Tray hardware and firmware, our ability to make any changes to that firmware was contingent on two other companies being willing to provide us with older versions of their software.
There are a few routes this Fan Tray effort could go:
| 1. | Get a works-like-years-old development environment going, with the Microchip 8 IDE and the 4.something CCS compiler. |
| 2. | Stay with the same set of tools, but update everything to current versions, presumably buying some more time until the environment becomes obsolete again. |
| 3. | Switch to open-source tools, where realistically the environment and firmware could live in perpetuity. |
In the interest of time, I opted to go the 2nd route, and converted the firmware to use the Microchip MPLAB X environment, and the CCS 5 compiler. This allowed me to do minimal regression testing on the current firmware, and quickly get to adding and testing the new feature for the customer. With that out of the way, I have a back-burner task of getting us to option 3, where the firmware is built and flashed using free tools. I’ve already gotten the flashing changed to using the excellent piklab software, and have started to transition the compiler from CCS to SDCC, but don’t know what IDE to use just yet (I’m actually leaning toward simple makefiles and vi, but I fear whomever gets stuck with this code after me might be a GUI fanatic).
This whole Fan Tray exercise, and everything discussed in this post so far, probably comes off as overly paranoid about something unlikely to really be an issue. It may be. However, what if instead of being a feature request, the change to the firmware was for a security issue (I’m semi-grateful that I don’t have to deal with the fallout of Heartbleed related product updates that my prior employers are surely going through!)? What if CCS or Microchip were no longer in the software business, or the older products were outside of any support window? What if the older software only ran on old OS’ like Windows XP? Any of these situations could have left Cirrascale in the precarious position of being unable to ship new products, or support already fielded ones, without expending significant resources to re-develop its existing product.
That’s risk I don’t like having in my personal or business life, and why I much prefer to be in control of my own destiny.
Thank for the pingback on my blog post.