McD's Musings

World Penguin Day

Wed, 25 Apr 2012 12:05:36 GMT

Pi Day, 2012

Wed, 14 Mar 2012 11:50:05 GMT

MPLAB-X Review

Fri, 17 Feb 2012 19:23:02 GMT

I first tinkered with MPLAB-X during beta. Although it was promising, it seemed flaky enough that I didn't want to move to it yet, plus, I wasn't doing a lot of PIC stuff anyway.

More recently I've been doing a bit more with the PIC. I had installed the release version but had quite a few problems so I put it on the back burner. I thought maybe it was time to go back and see whether it was going to be a good thing. All of this is based on MPLAB-X version 1.00 on Fedora 16.

For whatever reason, perhaps updated libraries, perhaps the last time I played with it I had got the configuration right, whatever, but it worked quite well for me. Mostly I used the C30 toolchain, although I did tinker with the C18 toolchain.

One of the first things you notice is that the buttons are all different. Nicer looking to be sure, but since they don't look like the old version, confusing.
One of the very nice features is that there is a build, program and run button. That is a departure from MPLAB 8 where they are all separate steps. Also, instead of having production and debug configurations and targets, you can simply click "Debug this project" and the project gets rebuilt for debugging, programmed and started. As in earlier versions, the debug buttons don't show up until you start the debugger.
Another big change is that the window is tiled. You could set MPLAB 8 up that way if you wished, but when debugging you need so many windows that it is pretty unwieldy. On MPLAB-X, though, everything is tabbed, so the tiled model is actually pretty nice. Once you get the idea of where things are, you aren't always hunting for hidden windows like in earlier versions.

The left hand area has a number of surprising choices. The most obvious, perhaps, is the dashboard. This seems to take a page from Piklab, but there are a couple of nice features, like bars showing memory used and a section showing the status of the programmer.

You can have multiple projects open at once, and the "Projects" tab shows all the open projects, and allows you to navigate for files in those projects. the "Files" tab is similar, but also allows navigating the various project subdirectories for object files, executables, etc. Yes, MPLAB-X makes a number of subdirectories so your main project directory doesn't get cluttered with all the odd MPLAB created files.

The services tab allows you to add team servers like java.net to your project, also issue trackers such as bugzilla. I tried adding a local instance of bugzilla with no joy. Not sure if it's broken or something lacking from my bugzilla instance. the only other issue tracker available is JIRA. Whether Trac or similar trackers could be added reasonably I have no idea.

But to a degree that fits. There is also a "Team" menu that allows connecting with CVS, Mercurial or Subversion. Where is git? Who knows. Seems odd to have all these old RCSs and not the most popular. But it appears that perhaps the Pony Express doesn't make it out to Arizona with news more than once a decade. Still a step up from the time when the only choice was SourceSafe.

On the bottom is a tabbed area very similar to the "Output" window in earlier versions, but with a lot more capability. Besides showing you the compiler output and the status of the programmer/debugger, it also has a very cool "variables" tab when debugging. If you halt in a function, this tab shows the values of all the automatic variables in the function, as well as any watches you have defined. This really cuts the need for the various debugging windows, and automatically shows you the exact things you probably want to see.

There is also a tab showing all the breakpoints you have defined, along with checkboxes allowing you to disable them without having to track down the source line. But wait, there's more. When debugging, hovering over a variable will show you its current value (if it is in scope, of course), and if it is a structure, will even show you the bits and pieces -- especially handy for special function registers.

For your static variables, it also shows the address of each element. Very, very handy.

MPLAB-X starts very slowly, being a huge Java app I suppose that isn't much of a surprise, but once started, it seems to be quite speedy. It seems especially quick for compiling and programming, odd, since it apparently uses the same compilers as MPLAB 8. The build, program and run button, one of the most common things to do during development, seems especially quick.

But there are some things that seem to take an inordinate amount of time. When a program is running, placing into reset seems to take forever. A simple task like that shouldn't take visible time, but it is at least 3 seconds on a very fast computer. Releasing from reset also seems slow, but nothing like holding the target in reset.

Probably the biggest win, though, is the editor. It seems to make a lot more sense than the old one, especially with tabs. It automatically puts in closing parentheses and braces, but unlike most other editors, if you habitually type that closing paren, yours simply writes over the provided one, unlike other editors where you may find yourself constantly erasing extra parens.

If you click on a variable or function, it highlights all other occurrences of that variable or function on screen, and places little tic marks to the right of anywhere else that function appears within the file, so you can even track down off screen occurrences easily.

The right-click menu lets you go straight to the declaration (or header or implementation in C++), find other occurrences, etc. It will even generate a call graph.

With all these features, though, I am still left with the feeling that there are important features from earlier versions of MPLAB missing. The more I use MPLAB-X, though, the less I feel that, and the more it does seem like a significant step up.

Now if I can just figure out how to make a git plugin ...

Happy Birthday Ken

Sat, 04 Feb 2012 13:57:42 GMT

Hacking on an IR Remote

Fri, 27 Jan 2012 01:36:15 GMT

This post, rather long and geeky, is more of an attempt to record a little project for myself, but I am copying it to the Planet, even though it has little Fedora content, because my fellow Fedorans deserve an occasional peek at just how weird I am!

For Christmas, Santa brought me a PIC24FJ256DA210 Development Board. This is quite a cool board, with an especially cool PIC. The board includes the obligatory buttons and LEDs, along with a PICtail socket, Host, Device and OTG USB ports, a serial port, parallel and SPI Flash, SRAM, mTouch pads, and a display connector. Plugged into the display connector is a 3.2" TFT display with a resistive touch panel.

The PIC24FJ256DA210 itself is quite interesting, including not only USB and PMP, and gobs and gobs of Flash and RAM (by PIC standards), but also a graphics controller. I had done some graphics a while back on a 24F on the Explorer 16 Development Board. I was interested in seeing how things changed with the controller on the PIC.

The demo app was pretty neat, one of the (many) things it did was to read JPGs off a thumb drive and display them. On a PIC this is kind of a big deal since few PICs even have a USB stack, let alone the capability to interpret the FAT filesystem and decode JPGs in finite time.

In looking for a project to get my head around this thing, it turned out that a friend (N8ERO) was working on decoding the output from a TV remote. He was trying to draw the output graphically on a little black and white LCD. It occurred to me that this was a sort of interesting project and would exercise the PIC.

I began by coming up with a scrolling graph on the Explorer 16 since I was already familiar with the older version of the Microchip Graphics Library, and I thought a speed comparison would be interesting. Since I didn't need the touch screen for this application, but did need speed, I stuck to the graphics primitives portion of the library and avoided the Graphics Object Layer (GOL). Although the scrolling wasn't terribly fast, handled by redrawing rather than memory copying, it was still pretty tolerable on the PIC24FJ128GA010, so now off to the the PIC24FJ256DA210 to see what the graphics controller could do with a pretty simple case.

(For the pathologically curious, the code for all these little exercises is on gitorious at https://gitorious.org/pic16/graphtest/trees - there's actually nothing in the master branch; each of these experiments is in its own branch. The GA010 display is in graphAD branch.)

Microchip has some pretty slick hardware, but their software has never been anything to write home about. The older Graphics Library had a mess of directories and files that made little sense. I was hopeful that the new library would be an improvement.

Well, it was worse. "Back in the day", you could download the Graphics Library. Now, you need to download the "Microchip Application Library", which includes not just the Graphics Library, but all sorts of other things. It isn't that the download is so burdensome, or the disk space is unmanageable, but the addition of all the other features, even if they are pretty neat, gives Microchip the opportunity to make it even more of a mess than it was before.

And it gets worse. over the past few years Microchip has added a number of experimenter boards to their stable, including quite a collection of displays and a few graphics controllers. When you dig down into the source, every line of code is preceded by about a half page of #ifdefs to select the appropriate PIC, board, controller, display panel and touch controller combination. In some cases there are choices between serial and USB interfaces and SPI or parallel external flash. It is totally unreadable.

There are no actual "libraries" in the Graphics Library, something I thought a little odd. Their sample projects include lots of source files into the project. Well, of course, you need to set all those various #defines before compiling the code. In many cases it isn't at all clear how you get some symbol or another defined without editing the Microchip code, but with a lot of digging you can get around it with our old friend -D. (Would have been nice if the documentation provided a clue, tho.)

Speaking of documentation, there is quite a bit. Most of it .chm files. Now, .chm files in general tend to be trash. The templates that Visual Studio provides lead the developer down the path of useless help files. But to Microchip's credit, the MPLAB help files are among the best I've seen.

Unfortunately, the files provided with the application library are a newer version than can be handled by anything I could find in Fedora, newer even than could be read on the XP image I have on a VM. Fortunately, the critical (to me) stuff was also available as .pdf. There's a lot of stuff there I would like to explore that is only in .chm files, tho.

Sadly, the documentation is mostly disjointed. They do have a pretty nice function reference for the Graphics Library, but it doesn't give you any help as to what the dependencies are, what symbols need to be defined for what purposes, etc. There are other documents that help you figure out how to set the two dozen jumpers on the board, but those documents are scattered. The best bet seems to be reading the schematics. Those are annoying because they are spread out over umpteen pages. I would rather deal with a humongous fold-out like Icom does. A bit unweildy but at least you can trace lines with some degree of confidence.

After a bit of a struggle I managed to get my GA010 code working on the DA210, and the speed improvement was startling. Even without using features of the controller the display was almost 20 times faster, although it felt faster than that. (graphAD-DA branch).

Earl provided me with an IR sensor he had ripped out of an old VCR or something. I tacked it onto a PICtail prototyping board I had been using for various experiments, and when supplied with 5 volts, it seemed to be able to see my remote. Unfortunately, it was totally blind when powered with 3.3 volts. This is a problem. The PIC24's are 3.3 volt parts. Although the DA210 isn't a horribly expensive part, it is a TQFP100. I've been able to deal with parts like that before, and although possible, it isn't any fun at all. I really wanted to avoid damaging the PIC. But I'm also a big fan of simple, so rather than some elaborate voltage conversion scheme, I simply put a 10K between the sensor and the PIC on the theory that the sensor wouldn't be able to drive damaging current into the PIC through the 10K.

So, now we have the IR sensor connected to the PIC, but the PIC didn't seem to be able to detct anything. Most of the PIC lines are used for the graphics controller. Even tho the DA210 has 100 pins, the board has enough different functions that every pin has multiple uses. The pins connected to the buttons, which are shared by mTouch pads and LEDs, seemed to be the best bet, and I could convince myself that I had the right pin by putting my meter on the PICtail and pushing the button, but still the PIC couldn't see anything.

After spending way too much time, I realized that the pull ups for the pushbuttons couldn't be overpowered through the 10K by the sensor. But another blatantly obvious thing I should have seen; the pushbutton was enabled by a jumper! Simply removing the jumper allowed the PIC to see the sensor.

Up to this point the slugging had been pretty slow. Every step became a battle. But from here on, once I had my head around the graphics so-called library and the board, things went surprisingly well. From here on the vast majority of time was spent, well, tinkering. I can really get wrapped up in making this or that look just right. Foolish, really, since I have absolutely no eye for making things look right!

As I looked at the data from the sensor it became obvious that a scrolling display wasn't going to be much help. Ultimately, the point is to be able to decode the pulses from the remote. There were a LOT of pulses going by very fast. If the data were scrolling by there would be no opportunity to examine it to look for patterns.

So, the scrolling display went out the window, in preference to a static graph. (readIR). The approach I used, since I didn't know the speed, was to sample the data and put it in an array, then plot the data after the fact. The PIC24FJ256DA210 has a lot of RAM, so a fairly large array wasn't out of the question. I could then adjust the sampling time without messing with the graphing code until I could see the relative length of the pulses.

But, it turns out there are a LOT of pulses. Given the 320x240 resolution of the little display I couldn't display even a significant fraction on them, and even if I could, the display wouldn't make much sense.

So, the next optimization was to make the array very large, and display the data a page at a time. This was effective, and made for a nice display, but still it was difficult to make sense out of what I was seeing.

At this point I started digging around on the web to see if I could come up with the codes for my remote. Unfortunately, not only did I not find my particular remote, but different sites seemed to have entirely different opinions of how to interpret the data stream.

It seemed to me that a less pretty approach might be more enlightening. So the next approach was to display a string of characters, green for a low and white for high. This evolved to displaying underbars for low and a digit, increasing as the pulse persisted, for high. This made it quickly obvious that, other than the start pulse, there were only two pulse lengths. Short pulses were either 1 or 2 samples, long 7 or 8 (after adjusting the sampling time to optimize the display). (listIR commit 58bfdd2)

Once it became evident I only had two states, it seemed obvious to convert the pulse train into a number, using 0 for a short pulse and 1 for a long pulse. Now I could easily see whether I had the timing right and understood the signal; if the same button resulted in the same number, and a different button gave a different number, I was close to having it decoded.

So initially I was pretty timid; get the number, look for one of a few hits in a case statement. Of course, the case statement became immediately annoying as I added codes, so it went out the window in favor of a table lookup, which was not only shorter, but much easier for adding codes. I also quickly dispensed with the string display, and pretty soon my fancy graphics display was pretty boring. All I really needed was the hex code (for adding new buttons) and the result.

So at this point, I'm kind of at the end of this experiment. I did notice that, although there are all sorts of claims of standards, the pulse lengths vary widely between different remotes. But honestly, I don't have a burning application for this capability anyway, so I doubt I'll be motivated to expand to other remotes.

FUDcon Day 3

Sun, 15 Jan 2012 20:48:50 GMT

Another good day, in a surprising way.

Last night the roads were pretty poor, but this morning, in spite of a little more snow last night, were good. Apparently they have salt in Virginia.

The main event planned today was the Docs hackfest. We never did find the agenda, but we did get one thing done; all the Beats are ready to start on F17. This isn't a huge job, but it is really tedious and annoying. With multiple hands it was done in no time. So now everything is in place to get started on the Fedora 17 Release Notes.

After lunch they wanted to move us to another floor, and lots of folks were headed back home, so I headed back to my hotel room. It had warmed up considerably; so much so that I decided to seize the top-down opportunity for the short drive back to the hotel, interrupted by a quick stop at Starbuck's. (I may not have mentioned, there was NO COFFEE at FUDcon.)

I needed to get out my monthly report for my day job(?). I was missing two reports, sent out a request for one and got it back almost immediately. The second one might not make it; only about an hour now before I have to just send the report.

I plan to meet my godson later today. He is on the way back to VT as I write this. He is in Civil Engineering at VT, so it will be nice to have a chance to see him.

Tomorrow we will try to get out as early as possible and head back north. I don't much like the way the weather reports look back in Michigan, so we want to get as many miles behind us as possible before we hit the weather.

I don't know how it went for others, but for me, this was a very productive trip.

FUDcon Day 2

Sun, 15 Jan 2012 13:34:21 GMT

Day 2 is the main deal at FUDcon. Most of the presentations and such are on Saturday. After the FPL's State of Fedora address and voting on the BarCamps, I had back to back Docs things. First, I needed to be in the Introduction to Docs so I could harass Sparks. Then, after lunch, I was on the hot seat for the XML/Publican presentation, with Jared doing the harassing. Both went well. There were only a handful of attendees, but they were well engaged.

Probably one of the high points was a presentation from suehle's daughter explaining how Princess P's power was spelling, something us Docs folks could use.

I also picked up the Raspberry Pi presentation. There wasn't a lot there that was really new to me as I had followed the product for a while, but I hadn't really "internalized" just how serious they are about producing millions of these things. I did also manage to get a cupon from Red Hat for a Raspberry Pi and power supply as soon as they become available.

Saturday is also FUDpub. This time held at the "Break Zone" in the student center. I was a bit surprised at how elaborate the facilities are these days at school. Perhaps because of a misspent youth dozens of pool tables seemed out of place at an engineering school. Don't know why, saw the same thing at Annapolis decades ago. Perhaps the bowling alleys felt a bit over the top. The food was good, the talk was good. I left a bit early when Jared and Mark started having a snowball fight; I was pretty concerned about how southerners would react to snow on the road.

So yet another good day. Sunday should be a bit more laid back, with a Docs hackfest all that is on deck.

FUDcon Day 1

Sat, 14 Jan 2012 13:44:15 GMT

Got over to the school early to find a parking place - that turned out to be much harder than I expected. In the end I lucked out, but although I expected it to be a problem, the pickings were a lot slimmer than I expected.

Day 1 started out as they always seem to - disorganized. The first thing I did was to take in the first of the ARM sessions. There was another session planned for Saturday that looked as it might be better (for me), but it conflicted with stuff I really needed to be at. Well, this one turned out to be perfect.

And there was no coffee!

It was a surprise to me that ARM intended to be a primary arch, but once I thought about it, it makes sense. And that alone answered lots of questions I had. I was also surprised to learn that putting SSDs on some of the servers significantly improved performance, but also that the life was so short, and predictable. I guess I was aware of the limitations of FLASH, but hadn't considered what that means in heavy use applications.

Did I mention there was NO COFFEE?

So, we walked over to Jimmie John's for lunch, and it was FREEZING.

After lunch on to mw-render. Ian Weller discovered that upstream had released a new version of mw-render just a day ago. He downloaded it and it seemingly no time had it running. But once we tried it out, it complained about a "writer". A little exploration revealed that in an earlier release they had removed exactly the part we need.

So Ian, Eric and myself noodled on what we might do, and I think we have a good strategy.

I also managed to drop in on a session Tatica was leading on dealing with people needing help, especially the very demanding users. Good session with a lot of good thoughts passed around.

So all in all, a very productive day.

FUDcon Day 0

Fri, 13 Jan 2012 13:28:56 GMT

Well, I'm here, and it is good.

I left Michigan Tuesday afternoon. I wanted to leave plenty of time in case of snow. Tuesday was beautiful, corner to corner blue sky, made it to Columbus where we stayed in one of our favorite places. Unfortunately, we didn't get to Columbus in time to enjoy the Turkish restaurant, but you can't have everything.

Wednesday wasn't so nice. The weather deteriorated as the day went on, and by the time we hit West Virginia, we had very heavy rain, lots of standing water on the Interstate, and very dense fog. Still, we made it to Blacksburg fairly early. The Predicted snow kept getting later, and it didn't show until Thursday night, and even then, not more than a dusting.

Thursday late morning I called Jared, went over to the Inn to chat a bit. Didn't seem like a lot was getting organized yet, so I went back to the hotel (I'm staying in a different place) and started tickling the keys.

I'm the guy Dave Barry described when he talked about spending days building tools to help a five minute project. Every release I take Robyn's schedule and put the release notes part on the wiki with a little more description. The descriptions in the schedule are often misleading, and some tasks require a lot more prose than is reasonable in the schedule.

Also, I'm a visual sort of a guy, so I also make calendars with the schedule on them. I got it in my head that I needed a program (my knee-jerk is still C instead of bash) that would take Robyn's schedule and make the calendar pictures directly.

It turns out that the Taskjuggler csv's are hideous, with an obnoxious date format. So I need to convert those dates into something useful if I am going to calculate where they are on the picture. I had some ideas about how I would organize the schedule in memory so I could make calendar images a little nicer than the ones I have now. I thought I would import the taskjuggler csv's into a spreadsheet, and sort out dependencies so when the schedule inevitably changes, I could change one or two tasks and the rest would fall into place, instead of changing dozens of dates.

Of course, oocalc can't make sense of the taskjuggler dates, so the first step was to write a program to convert the dates. That took more than I thought because oocalc seemed to want everything to be text. After a lot of diddling around I discovered all I actually had to do was to tell oocalc what columns were dates when I imported the csv. Oh well.

Once the schedule was in oocalc I realized that if I put the comments and extended descriptions into the spreadsheet, I could then write a program that would output the ugly wiki table, and I could also easily then mark external milestones etc. So a second C program. That one went very quickly.

By now it was afternoon and other trouble makers and ne'er do wells had started to arrive so I ran back over to the Inn, hung out with Robyn, Eric, Ian, etc. etc. etc.

After dinner I decided to turn to the calendar, my initial intent, and by then concluded with with everything else in place, that was going to be quicker just doing it manually.

As I was finishing that up, Ian asked on IRC whether it was OK to move the mw-render session, which was fine with me. In fact, a positive since it would allow me to at least catch the first part of the ARM sessions. Those ARM things showed up late, and were pretty much all scheduled in conflict with some Docs thing, in spite of the calendar being mostly empty at this point.

OK, so now it is cold outside, getting time to head over the the campus and see what's up at McBryde.

A Christmas Doodle

Sat, 24 Dec 2011 14:37:38 GMT

A little Christmas doodle for my PIC buddies (628A so PIC-EL II or III)

https://github.com/jjmcd/Elmer160/tree/16F628A/ChristmasDoodle

Click on doodleAll.zip then right-click on "raw" and select SaveAs... to get the entire project in a zip, or if you just want to look at the code, click on doodle.asm instead.

Can you figure out what it does? (It is deliberately sparse on comments.)

Even after you run it can you figure out what it's doing?

Happy Birthday Fortran

Sat, 15 Oct 2011 13:34:37 GMT

Fifty-five years ago, Fortran was introduced to the world.

Fortran was the first modern computer language, and for many years was the predominant language for scientific computing.

Back in the late 60's, after spending weeks converting a small Cal (a predecessor to FOCAL) program to FORTRAN (back then it was all caps), I promised myself I would never write a program in anything but the FORTRAN-60 dialect of FORTRAN because all computers understood that and I wouldn't have to waste time on conversions.

How much the world has changed!

Every so often I will write some little thing in Fortran "just because", but now I feel like C is my native language, although I probably do a lot more bash and PHP.

But for a great many years, Fortran was the bread and butter language for anything outside accounting, where COBOL held sway.

I have to share a little story ... The original FORTRAN had nothing resembling an if-then-else construct. Programs tended to be a mass of GOTO statements, and the language encouraged "spaghetti code". FORTRAN programs of any size at all could be very difficult to follow. (In contrast, Cal had not only an if, then, else but also an unless, otherwise and but, which made conversion to anything maddening.)

At the time structured, or "go to-less" programming was being talked about, I was learning PL/I. Since PL/I had all sorts of arcane constructs, I decided to attempt to write my next app in a go to-less fashion to see if there was anything to this structured programming nonsense.

But the whole concept of structure was pretty alien to this FORTRAN programmer, so the best analog I could find for a GOTO was the PL/I "on condition". This was a bizarre statement that would cause transfer of control based on some condition occurring. For example, you could say something like "if X ever equals 17 go to some particular statement". Of course, the on condition and the target statement could be quite removed from the place where X reached 17, so the result could be surprisingly opaque.

The result was a relatively small program that was virtually impossible to follow.

But still, I have a warm spot in my heart for FORTRAN.

Sunday, October 2, 2011

Sun, 02 Oct 2011 08:18:18 GMT

Mourning the loss of mw-render

Thu, 22 Sep 2011 19:33:15 GMT

An unhappy thing happened this time on the Release Notes. In preparing the Publican XML, I discovered that I couldn't do it on my Fedora 15 laptop. Fortunately, I was able to ssh into a machine at home that still had Fedora 13. I was at OLF at the time, so going over a network shared with many, many other weirdos was a little slow, but it worked.

The problem on F15? python-mwlib, which provides mw-render, is gone missing from the Fedora 15 repos. I tried the obvious ... could I install it from the F14 image? Not in finite time; hundreds of missing dependencies. Could I perhaps rip the bits out of the SRPM that provide the functionality I need? No, a quick look into the SRPM made it pretty obvious why Ian complains about this thing.

It's sad because over the years the process of converting the wiki to XML has gotten pretty straightforward. Back in the F10-F11 timeframe, the output of mw-render required so much hand editing that it was almost easier to just cut and paste from the wiki. But over time, mw-render has gotten better, and we have learned how to make most of the edits with a sed script. So now, what used to take hours takes about five minutes. I run mw-render, run a short sed script, and do perhaps a minute's worth of hand editing. If I was a little more of a sed maestro I probably could eliminate the hand editing step. Indeed, even working over a slow connection the process of converting the wiki (on a Fedora 13 box) went way quicker than I remembered.

So what to do? I see a few possibilities:

Stickster suggests that there is some sort of mediawiki API that might work. Certianly that would end up involving other issues, but I think it is something that has to be explored.
Suffer through getting python-mwlib installed on F15. That looks pretty painful, but probably not un-doable. I'm not entirely sure I want to be responsible for maintaining that monstrosity, tho.
Spend the time to fish out the bits I need from the SRPM. That looks like a major effort, too. But the end result would likely be a lot simpler than trying to hunt down all of the RPMs tentacles, which I am sure includes all sorts of functionality that I find uninteresting. Since I haven't heard others screaming about the loss of this library, I suspect there isn't a lot of demand for the other bits anyway.
Start over from scratch. This would certainly involve a lot less uncertainty than the other approaches, and probably quicker, too. But if I were to do this I would probably choose a more traditional language like C (yeah, I'm a dinosaur), leaving me with something even more unmaintainable.
Go back to cut and paste. I really hate how tedious that is, and it would move the translation from the wiki back to a week's project rather than a few hours, but it does have the advantage of being easily understandable.

Are there any options out there that I'm not aware of?

Labor Day 2011

Mon, 05 Sep 2011 12:32:03 GMT

Mysterious Empty Posts

Tue, 23 Aug 2011 17:46:41 GMT

Until some folks on IRC started commenting on it, I didn't realize that these empty posts were showing up.

Here's the deal (I think). I do most of my online chatting/blogging on Multiply. I generally leave LJ for my Fedora stuff, and on Multiply I can go on and rant while not offending my fellow Fedorans with my lunatic-fringe ravings.

Multiply has groups for a variety of interests, and one group of which I am a member is a small group of folks who just get on there to chat. Whoever gets there first starts a post for the day, and often tries to include some interesting tidbit. I like to include a picture or two as well. Today's post, by the way, recognized the birthday of Edgar Codd, the father of the relational database, and the 79AD eruption of Mount Vesuvius, which happened on Vulcanalia, the feast of Vulcan, the god of Fire.

For some reason it appears that when I start the post, the title only gets reposted to LJ. I have no clue why the single line from Assyrian Martyrs Day made it to LJ, indeed, that Assyrian Martyrs line is from the middle of that day's post; the headline recognized Margaretha Geertruida "Grietje" Zelle, the Dutch spy better known as Mata Hari. The next time I start a new post on Multiply, I'll check to see if there isn't some checkbox or another that enables cross posting.

August 7, 2011 - A Sunday

Sun, 07 Aug 2011 11:50:39 GMT

Happy Assyrian Martyrs Day

Sputnik

Fri, 05 Aug 2011 13:31:51 GMT

Last night I had a long drive home from the lower right corner of the state, beautiful evening, started with a pretty sunset, ended with stars overhead. I got to thinking about technology. My father loved maps, but he never got to see a world where many of us have maps of the entire country automatically called up by the onboard computer in the car.

I can still remember that night in 1957 when my father took me out in the front yard to watch Sputnik go over. It was an amazing thing, that humans had put something into orbit - into space! Disappointing that it was the Russians, although in hindsight, that was probably a good thing.

That first Sputnik was pretty lame. It had a transmitter on board, but all it did was beep. Amateur radio operators found that pretty cool, one radio observatory tracked it, but by today's standards, pretty lame.

I got to thinking about it listening to the sat radio. Hundreds of "stations", carried over a single digital stream, much better quality than terrestrial radio, and lots more choices because the market is the entire country instead of some metro area.

When I left the Detroit area for the last leg of my trip, the lady in the dashboard announced that she was recalculating my route because of traffic.

In the 70's I remember trying to use an amateur radio satellite, and because of battery problems, it was only turned on every other pass. I was annoyed that this amazing device wasn't always available for my selfish use all the time.

Now where are we? The computer in the car, by making arcane calculations from a bunch of satellites, is able to know exactly where I am. It has maps of everywhere, and can calculate the best way to get me where I am going. The computer gets traffic information from another satellite, and can save me the annoyance of the Detroit traffic. All the while I am listening to my choice of music from that same satellite that brings the traffic information to the dashboard lady, and I don't need to worry about driving out of range of the station.

All because the Russians put a lame aluminum basketball in the sky.

New Madrid Aftermath

Thu, 19 May 2011 01:25:25 GMT

I don't usually write about my "other life" in this blog. I try to stick mostly to Fedora related things, and to save my other comments for other forums. In particular, my ham radio life is pretty unusual, and lots of what I do requires a lot of explanation. Well, this is one case I think it is worthwhile. I apologize in advance for the length.

Back when we were preparing the schedule for Fedora 15 I tried pretty hard to get someone else to take point on the Release Notes. I knew that this time of year is generally very busy for me, and that this year in particular was going to be horrible. I wasn't able to find anyone dumb enough to stand in for me, and I wasn't disappointed in how frantic it was going to get, either.

Tuesday was the peak of the madness, and it was wonderful. To understand how wonderful, though, requires quite a bit of background.

In my non-Fedora life, I am the Section Emergency Coordinator for the State of Michigan. That means that I organize about 2200 volunteers to provide backup communications in the event of an emergency. In that role I spend a lot of time with the State Police in Lansing. In Michigan, the State Police have responsibility for emergency management and homeland security. Not all states are organized this way.

When an emergency occurs, the affected jurisdiction activates an "Emergency Operations Center" or EOC. The point of the EOC is to collect representatives from all the important agencies in the jurisdiction so that the responders at the incident can get any resources they need.

When an incident exceeds the capabilities of an individual county, the State Emergency Operations Center or SEOC is activated. Every agency in Michigan government has a representative at the SEOC when it is activated. In addition to the twenty-odd government agencies, two volunteer agencies are there; the Red Cross and amateur radio (me).

Michigan is fortunate in that we don't face many of the hazards that other states have to deal with. Sure, we have tornadoes, but they tend to be localized. And we have winter storms, but they are slow moving and relatively easy to deal with. But we don't do earthquakes, tsunamis, hurricanes, lots of the things that other states deal with we simply don't face.

We do, however, have three nuclear power plants in the state, and even though the likelihood of an issue at these plants is quite low, they do represent the highest perceived threat. As a result, this is what we exercise. And we exercise nuclear power plant incidents frequently.

This really isn't all bad. A nuclear incident is one of the few incidents I can think of that requires every state agency to be involved. The complexity of this sort of incident is surprising, but every few months on average I am down in Lansing practising for a serious event at one of these plants. All of us that work in the SEOC have taken radiological training, and most of us have had to be take tests on what the plant operators would do in specific circumstances, so that we understand what is happening "in the field". (The NRC is pretty detailed about what plants have to do when certain things happen).

Many of you may have heard that this week, FEMA is conducting a "National Level Exercise" in which several states are practising for an earthquake in the central U.S. Because the geology of the area is so different, the effects of an earthquake in the New Madrid - Wabash fault area are quite a bit more devastating than west coast earthquakes. Fortunately, severe quakes in that area don't happen very often, but it turns out we are overdue. [1]

An earthquake of the size that hit the area in 1812 would probably not cause a lot of direct damage in Michigan, but the effects would still be devastating. You see, most of our power and petroleum runs through that area. Many major communications lines also go through the fault. An 1812 size event would knock out most of the bridges across the Mississippi, disrupting deliveries from the west coast. Many air deliveries are routed through Memphis, whose airport would be disabled for months. Huge numbers of evacuees would likely come to Michigan. All in all, the aftermath would be a big problem.

Michigan, like a number of other states, opted out of the National Level exercise, choosing instead to conduct a separate exercise around some of the impacts to our state. I was part of the team designing that exercise, which is what has chewed up a lot of my time over the past few months.

There is a lot to designing an exercise like this. FEMA has a lot of guidance on designing exercises, so the first thing on the agenda for me was a raft of FEMA courses around exercise design and evaluation.[2] Amateurs recognized that this raised issues we hadn't considered before, so we partnered with our counterparts in Indiana, and the Indiana Department of Homeland Security to engage in some testing with that state around this sort of scenario.

The heavy lifting, though, was really done by a number of other agencies. The Public Service Commission did modelling to help understand the likely impact on electrical, gasoline and natural gas supplies. The Red Cross did a lot of work understanding how they would shelter thousands of evacuees. The Department of Agriculture went to work understanding how to deal with all the pets those evacuees would bring with them. And it goes on and on and on. The level of complexity is truly astonishing.

The way these exercises are developed is, once you have the general scenario (an 8.1 near Memphis, followed by a 6.6 aftershock in southern Indiana) you then lay out a general timeline of events. From the timeline, you then develop "injects". These are typically messages coming into the SEOC. They often are directed at the wrong agency, as they would be in a real event. As the detailed event list develops, you also need to identify how you expect the players to respond. Ultimately, you will evaluate how the players reacted compared to your expectations and plans.

We probably ended up with far too many injects. We weren't able to get them all in and even so, the players were at a dead run for the entire exercise.

As I said, we exercise nuclear power plant incidents regularly, but we haven't exercised other incidents all that often. In addition, many of the normal representatives at the SEOC were involved in the design, and thus couldn't play. Many others were needed in the "SimCell", the place the messages come from, as subject matter experts. As a result, many of the players were inexperienced in the SEOC. Even those that had worked there before were faced with issues they had never dealt with.

Although the stress level was high, it was quite impressive to see how the players reacted. There were many, many creative decisions made, and incredible cooperation between the agencies. During the exercise I was serving as an evaluator, which gave me a chance to observe much more of what was going on than I usually can.

So now that the exercise is behind us, we still have to get together and collect our evaluations, write the after-action report, and then the hardest part, the improvement plan. My counterpart in Indiana and myself have already identified a huge amount of work we need to do going forward, and we need to document that as well. But the frantic, high-stress part is largely behind us.

All in all it has been quite an experience. I can't help but feel that the citizens of Michigan are just a little bit safer than they were before, and that I made a real contribution. it was discouraging to be less engaged in this release than I would have liked, but I feel like I made a worthwhile investment of my time, and to be honest, to be quite privileged to have had the opportunity.

[1] There is a short video on this fault at: http://www.history.com/videos/mega-disasters-earthquake-in-the-heartland

[2] FEMA has a large number of emergency preparedness courses available online. Some are pretty specific, but there are a few that would be helpful to anyone: http://training.fema.gov/is/crslist.asp

The incident at Fukushima Daiichi

Mon, 14 Mar 2011 00:51:41 GMT

If for some unfathomable reason you happen to see my blog, and didn't see Henrik Heigl's, check out this link he posted:

Why I am not worried about Japan's nuclear reactors.

This article is fairly long, but a very worthwhile read.

This whole nuclear plant business in Japan has been horribly frustrating for me. I know a lot more about nuclear power plants, and especially what can go wrong at nuclear power plants, than I ever wanted or expected to. You see, I participate in nuclear power plant exercises several times a year for a number of years now, and have had considerable training on what can go wrong at these plants and what to do about it.

What I have seen reported on the Japanese incident has clearly contained a lot of misinformation and just plain errors, and what little is true is often presented in an overly alarmist way.

The TV reporters all get "experts" who turn out to be anti-nuclear activists, and the print media seems to use these same experts but won't even admit who they are. So much for serious journalism.

Thank you so much Henrik for digging up this excellent piece.

How come virtlib gets no respect?

Mon, 31 Jan 2011 01:09:27 GMT

Back in September, I reported that I was disappointed that the virtualization presentation failed to mention Fedora. It was annoying, especially since the various virtualization products that were mentioned seemed so complex. But after all, it was one guy, and apparently Fedora just wasn't on his radar.

But today I was sitting in Barnes & Noble flipping through an issue of Linux User and they had a comparison of several virtualization products. I was surprised to see that Fedora's implementation scored poorly. Why? Because it is too complicated to install! I read the section on libvirt and they really didn't say why, just in the scoring it got knocked down for being too hard to install.

HUH? OK, I'm a command line sort of a guy, perhaps typing

yum groupinstall Virtualization

is too tough for the folks at Linux User.

So, as much as I dislike the GUI for this sort of thing, let's see what it takes. I can't see selecting "Add/Remove Software" too cryptic for someone who wants to install some software. There's only one place to type, so I type in "virtualization", sure enough, all it takes is to tick the box next to "Virtualization". Maybe it's the typing. Do other distros have precognition so they know in advance what you want? Or do they just have so few packages that it makes sense to browse a list?

OK, I'll admit, there are some goodies you might want besides the stuff in the Virtualization group, but to do the stuff they talked about in the article, everything you need seems to be there. I can't imagine that would be a "complex" installation.

What about installing a new VM? Well, until you have a VM selected (and if you have none created yet, you can't have any selected), there's only one toolbar button activated. If you hover over that button, it says "Create a new virtual machine". OK, if you weren't trying to create a VM perhaps that would be a mysterious message, but since that's the whole point....

Now, I'm no expert; I don't run a server farm, and I don't have hundreds of giant VMs to manage. I just find it handy to be able to have the previous and next versions of Fedora handy for testing, to be able to cleanly test on all the various desktops, and yes, to run Windows for that one web site I need to use that insists on Internet Explorer. But even to me, this doesn't seem all that tough.

So why does virtlib seem to be the black sheep?

QEMU and Beagleboard

Mon, 06 Dec 2010 16:45:52 GMT

Lately I've been eyeing the BeagleBoard. I do a certain amount of embedded playing around, and this thing is a whole new level. It's been around a while. I first saw it at FUDcon Berlin but I didn't pay all that much attention. I should have.

Basically, it's a laptop motherboard in a 3x3 inch form factor. Their latest version uses an ARM Cortex-A8. The board has ethernet, DVI-D, 4 USB ports, half a gig of RAM and a Micro-SD slot for HD emulation. It comes with an embedded Linux distro on SD.

Oh, and if you don't load up too many peripherals, it can be powered from a USB port. Lots of desktops take hundreds of watts - this thing, less than half a watt. The portable possibilities just boggle the mind.

This looks like it could be great fun. For me, the upgrade from the PIC16 to the dsPIC was a game changer, this thing looks to ratchet up what "embedded" means by another order of magnitude.

It does get me wondering whether qemu-system-arm will adequately emulate the A8. The "embedded" distro includes GNOME ... causes me to ponder a Fedora port.

Wheeeeee

Tue, 16 Nov 2010 15:34:58 GMT

What a wild ride this month has been.

Right at the beginning of the month I got the zero day Release Notes RPM out the door - without a hiccup. What's up with that? There's always something. Not this time.

Then up to Traverse City for the Statewide Interoperable Communications Conference where I was speaking of all things. Went well, good conference, got to see a lot of folks I don't see very often. And then, surpise, surprise, the State Police picked up my hotel bill. Feeling great. Then I hit the road to go home and it starts snowing, yuck. 130 miles of mostly country roads through the snow - no fun at all.

I'm barely back here in river city and I learn that Hank Kohl, K8DD, became a silent key. Hank was a giant in amateur radio, an avid DXer, contester, DXpeditioner, and a member of the QRP Hall of Fame. A really great guy and barely older than me. Hardly get that digested and I find out that Ray (Abe) Abraczinskas, W8HVG, also became a silent key. Abe built the western Michigan linked repeater system almost single-handedly. Another huge loss.

Monday I get my monthly report together that I send to the League and the State Police, and I find that my nets passed a record amount of traffic in October. And the reports went together smoothly, too, thanks to help from Ryan Lughermo, KB8RCR. Send out big attaboys to all the net managers.

Today I marked my first actual application for Fedora for stable. I've been maintaining the Release Notes for a while, but this is my first actual code. I have another package we use for packaging the Release Notes that I need to get working on now.

Tomorrow I head for Lansing to meet with the Emergency Coordinators of all the State agencies to begin planning for a big exercise next year. I'm expecting that to be a lot of fun, but pretty challenging, too.

What a roller coaster, and only halfway through the month. I wonder what the rest of the month will bring.

My buddy git

Mon, 25 Oct 2010 13:06:08 GMT

It's been a while since I've written anything. RL has really been intruding, and for a long time I was totally netless - boy was that unhandy. But, things are slowly returning to their normal levels of chaos.

A while back I wrote on git and especially gitweb. Git is getting more and more to be my friend. A lot of Fedorans use git because, well, that is what Fedora uses. It becomes one of those little annoyances before and after they want to do some work on Fedora. But I used RCS for me, so of course I am using git for me. The small repo thing I mentioned earlier is a key, but still it takes a level of discipline.

What do I get out of git? Well, thinking about it, there are a few things.

Probably the biggest win for me is neatness. You see, I'm a bit of a packrat. I tend to hang on to every little test and trial I make on anything. Pretty soon my directories are a mess, mostly full of stuff I'll never use. But knowing that everything is in git means that I can recklessly delete stuff I don't need at the moment, secure in the knowledge that if I do need it sometime in the future, it's right there in the repo. And neater working directories mean I spend less time fishing around for stuff.

Another biggie is documentation. I often find myself going back to something I did years ago. With git, and especially gitweb, I can just look that the history and the diffs to remind myself where I've been. Again, it takes a bit of discipline to make consistent, meaningful commit messages, but knowing my own history I sometimes tend toward descriptive, occasionally long, messages.

Another nice feature is that I can work anywhere. I have a bunch of boxes for different purposes, and sometimes it might be handy to develop on my laptop, other times directly on this server or that. With git and small repos, making the development tree on another box takes just a few seconds. Instead of ending up with multiple, different copies, I can blow away temporary or work copies after they've been pushed to the remote repo, so the price for working on a different box because it happens to be handy at the time is quite small.

A surprise to me is backup. It turns out that bare repos are pretty darned compact. With all the important stuff in git, it is a simple matter to make a DVD of the git tree. And because it is quick and simple, I do it more. Sure, I've got a bunch of automatic backup strategies, but it is comforting to know that the important stuff is offline, and even offsite.

I wrote before about some of the features of RCS that git lacks. But in some ways, the lack of those features is a feature, rather than a delta, because it makes using the tool easier. I will admit to occasionally using git gui. Usually a gui just gets in the way, but once in a while it simplifies things. Being able to do it both ways is handy.

So I've become a bit of a git geek. You might think about what it can do for you. Setting up a "remote" repo on your LAN is a piece of cake, but what it can do for you is quite wonderful.

OLF Day 2

Mon, 13 Sep 2010 13:12:12 GMT

Day 2 is kind of the main event, and it was a pretty full day.

Before the keynote, the organizers indicated that last year they had 800 attendees preregistered, and 500 walk-ins. This year they had 1200 registered, and it being first thing Saturday morning, no feel yet for the number of walk-ins. So looks like from an attendance standpoint, a successful conference.

The morning keynote was delivered by Stormy Peters, executive director of the GNOME foundation. Her main story was that, while we are all sensitive to software freedom, the rise in web services has made us somewhat less sensitive to the risks to our data. Her presentation was excellent, and well received. Her point about us not always recognizing the freedoms we give up when we hand our data over to a web service is one that certainly deserves a wider audience.

One interesting takeaway from Stormy's presentation is that there are a number of places where the GNOME Foundation sees a need for free web services, and they are taking it on themselves to provide some of those. They need some experience to determine whether this will be affordable.

For the next time slot I took some time to look through the booths, although I probably did not spend as much time talking to people as I should have. The expo area was well attended, and it did surprise me to see many folks just there for the expo when there were so many good presentations going on.

The next session I attended was Perl and Arduino, and that was a little disappointing. The presentation was actually excellent, but it focused more on the Arduino and less on Perl, and my interest was the reverse. It did, however, make me want to see Catherine Devlin's talk on automation later, but she was up against Jim Campbell, and I felt like I needed to see Jim's talk.

The next talk on virtualization really was disappointing. I got the impression the presenter had no clue, and he certainly made it sound more complicated than it actually is, or at least more complicated than it is on Fedora. Perhaps if you are using VirtualBox it really is spooky, I just don't know. But it was disappointing. Maybe more so because in listing systems that support virtualization he failed to mention Fedora, and I am of the impression we are out in front on that technology.

Lunch was kind of interesting, too. There was a Greek place in the food court, and they had pastitio on the menu, one of my favorites. There was quite a line, all people ordering gyros and fries. Unfortunately, they didn't have the pastitio, so instead I ordered spinakopita and a couple of dolmates. Whether it was because she liked me breaking up the constant stream of gyros or because she didn't have the pastitio, she gave me an extra dolmates and an order of fries on the house.

The food was a bit of a surprise. The dolmates were not what I was used to and I didn't care for them, but the spinakopita, although the shape was odd, was really outstanding. A surprise from a fast food place, and way better than a burger. The fries were really good, too, but way overshadowed by the spinakopita.

After lunch it was Paul's talk on PyGTK. I was actually a bit surprised that it was as on-target for me as it was. I had hoped to pick up an overview of this model with probably half of the talk being outside what I was interested in. (I am, after all, pretty weird). But it was more like three-quarters good stuff, with a little "what is an object" redundant (for me) thrown in. Quite worthwhile.

Jim Campbell's talk on choosing a documentation syntax was also better than expected. I don't know why, but I had kind of expected a sales pitch on Mallard. Instead, he compared a half-dozen different ways to source documentation, some of which I had never heard of. He even put in a pitch for the Fedora Release Notes. I had met Jim at the GNOME Desktop Help Summit earlier in the year and it was nice to see him again. I was a little disappointed I didn't run into any of the other perps from that session.

Next up was Carol Smith with "7 Habits of Highly Ineffective Project Managers". Her talk was quite good, but some bits of it, and the discussion that followed, were kind of disappointing. You see, I spent a good part of my career working on the software process in an organization that was quite good at delivering software. I saw first hand just how valuable the whole CMM/CMMI philosophy is to development. To see a company as large as Google (and obviously a number of others), who 8 years later still don't get it is a little disheartening.

By now I was really tired, and looking forward to a two hour drive up to Findlay. I did want to see Monty's keynote, and although I was sure to enjoy Maddog's presentation, I didn't expect it to be "valuable". So I decided to head north at that time, rather than risk being two hours more tired for driving. At least I got to spend a few minutes chatting with David and Robyn before heading out.

It started raining as soon as I left, and I had spoken with folks who indicated they hadn't had any rain in quite a long time, so I expected the roads to be quite slippery. I didn't feel the effects (my car is reasonably sure-footed even in the wet), but I did have one scary moment when I was stopped at a light and a pickup pulling a huge trailer went through the light with all four wheels locked. I was sure I was going to get smacked by that trailer, but he did manage to keep it between the lines. But I did pass a couple of other folks who weren't so lucky. At one point I was stopped waiting for a driver to be placed in an ambulance, so I was glad I had chosen caution.

The drive to Findlay did seem to go pretty quickly, though, but when I hit the sheets I was one whipped puppy.

Great event. Great to see so many Fedorans, some I had met before, some only on the net before this weekend. And a significant amount of valuable technical content, too.

Ohio Linux Fest - Day 1

Sun, 12 Sep 2010 01:27:52 GMT

I guess the "real" part of OLF is Saturday, but Friday there are some tracks, including an "Early Penguins" track at which both Mel and Robyn were speaking. An ulterior motive I had was to get pictures of them presenting; that didn't work out.

I met David and Mel and Robyn for breakfast at the hotel. We walked over to the conference (a long walk inside the conference center) to get registered, but they weren't ready for speakers so I was the only one that actually got registered initially. The actual talks didn't get started until 11.

One unfortunate feature is that the rooms were simply rows of chairs; there were no tables to set laptops, so for the most part I took my notes old-school (after harrassing Mel for taking notes on dried slabs of ground-up wood).

The first presentation was Mark Krenz on command line tricks. He is the face behind @climagic and his talk was excellent. A lot of little things I didn't know, and pointers to more goodies.

After lunch Brian Proffitt talked about the difference between free and open. Interesting points from the guy who wrote the most recent book on Fedora.

Then the Fedorans, and to tell the truth, I was a little surprised. Both Mel and Robyn had topics that I thought were perhaps a little arcane to this sort of forum, but both drew really interesting Q&A sessions from a lot of engaged folks.

Unfortunately, almost as soon as Mel started her talk the battery in my camera died. So, I grabbed my backup battery and it died almost immediately, too. Falling back to my cell phone, guess what, it's battery went, too.

At that point I was pretty discouraged, and tired, so I went back to the room to kick back for a bit and recharge the batteries; mine and the electronics.

Later on a bunch of folks were hanging out in the hotel. Spot and Paul had arrived, but almost all the Fedorans there were speakers and had a speaker's dinner to go to. Spot (who wasn't speaking) organized an expedition to a sushi restaurant, which was really outstanding, both the fish and the talk.

There was a party which pretty much everyone went to. I decided to pass since not only was I tired, but I needed to check out in the morning so I needed to get a head start on packing if I wasn't going to be too rushed in the morning.

All in all, quite a good day.