Jeff Duntemann's Contrapositive Diary Rotating Header Image

Reviews

Evaluations of products and services

Henley’s Grimoire

Forty three-ish years ago, Uncle Louie gave me a Geiger-Muller tube. I tried to build a Geiger counter with it and failed, and I had this notion that if I could find the tube, I would try again. I haven’t seen the tube for quite a few years, but I don’t recall giving it away or breaking it, so the damned thing may still be down in the pile somewhere. I dug around yesterday, digging through some boxes I haven’t looked through in awhile, including a few that have been sitting in the closet unopened for all the six years since we left Arizona.

I didn’t find the Geiger tube. But I found something else that I thought I’d lost: My 1928 copy of Henley’s Formulas, which I bought at some used bookstore or another in the ’80s and had used as padding (!) in a box containing sweep tubes, 807s, 811As, 829Bs, and other peculiar and outsized specimens. This was a helluva coincidence, as I recommended the book to a friend of mine a few days ago as a handbook of “barn technology” as it was understood and practiced circa WWI.

Henley’s reminds me of nothing so much as John Markus’ 1968 Sourcebook of Electronic Circuits, which Markus apparently assembled by photocopying every schematic he could grab and slapping it between two covers. Gardner Hiscox did very much the same thing with Henley’s, which consists of thousands of short and very short items much like the following:

A Grease for Locomotive Axles. Saponify a mixture of 50 parts tallow, 28 parts palm oil, 2 parts sperm oil. Mix in soda lye made by dissolving 12 parts of soda in 137 parts water.

That was under Lubricants, where there are literally dozens of recipes like the above, for greases and oils of every conceivable use. Not every entry is a recipe; some relay a sort of lost wisdom that was mostly lost (at least to cityfolk) even a hundred years ago. E.g.:

Bear Fat. Fresh bears’ fat is white and very similar to lard in appearance. The flank fat is softer and more transparent than the kidney fat, and its odor recalls that of fresh bacon. Bears’ fat differs from the fats of the dog, fox, and cat in having a lower specific gravity, a very low melting point, and a fairly high iodine value.

There is a recipe for “Dog Soap” calling for 5 parts petroleum, 4 parts wax, 5 parts alcohol, and 15 parts “good laundry soap.” This doesn’t sound like a good scrub for white dogs. (QBit just dove under the bed.)

What we have here, as with Markus’ book, is a grimoire: A magician’s memory jogger set out by categories, containing enough of the details to get you back in the groove without providing enough context to do much with them if you’d never done them before. There was a day when certain people did things like this all the time, out in the barn or the shed, and mainly this book was parked up above the buckets and barrels in case we couldn’t recall how many parts of caoutchouc went into that great rubber cement we whipped up a batch of last spring. If you needed a step-by-step, it was ask gramps or sit by Nellie.

Life used to be messy, and this is definitely a very dangerous book for boys. The Explosives section runs several pages, and explains at length how to make gunpowder, guncotton, dynamite, explosive chlorates, and smokeless powder. Some of the recipes are nonetheless exaspiratingly brief:

Fulminating Bismuth. Take bismuth, 120 parts; carbureted cream of tartar, 60 parts, and niter, 1 part.

Take it, sure–at least when I figure out how to carburate my cream of tartar. What one does with it after one takes it; now, that’s the trick. I’m not sure you just grind it all up in the mortar. I guess people knew how to make their own fulminates back then. Today, you’d just sink a pipe into the blogosphere and stand back.

A lot of the recipes are for personal care products, including cosmetics, perfumes, many kinds of soaps, treatments for rashes and lice, and even odder things, like one short entry entitled “Skin Bleach for Negroes.” The largest single section in the book, as best I can tell, explains the details of making alcohol of many kinds, including calculations of yield per bushel of corn, sugar, or potatoes, and even fruits like bananas. There are pages and pages on dyes, paints, and inks, and a surprisingly large section on metal plating.

Much of the trouble with Henley’s is the endangered terminology. I’m sure people used to know what “saponify” and “carburate” meant, and I had a vague idea in both cases. But I thought a “lute” was a medieval guitar; in fact, it’s also a kind of putty. I had heard of caoutchouc but had the spelling wrong. I had not heard of iodoform, though I bet I used to smell it down at Dr. Pierce’s office in the 1950s. Kefir used to be called “matzoon.” “Menstruum” isn’t what it looks like; it’s actually an archaic term for “solvent.” I haven’t looked up “red bole” yet, and I thought there was more than one color of vitriol. I’ve heard the word “tragacanth” but it’s been a long time. Ditto “putz pomade,” though it sounds like the nickname of a third-string hockey player.

And that was just my first hour of flipping pages and reading random snatches. This is a fascinating book, not so much for whipping up your own matzoon as getting a sense for what people were willing to do in the days before Wal-Mart and Home Depot, before safety became a religion and milkfat became radioactive waste. Back then, skimmed milk was considered dross, suitable only for the making of casein. (It is an “article of slight value, and cannot even be employed in feeding hogs.” Bravo! What he said!) Back then, I guess, we made it do or did without, and we were willing to go to a lot more trouble to make it do, assuming we had enough tragacanth powder out in the shed.

Henley’s has long been in the public domain (its copyright was never renewed, even for the post-1923 editions) and there are plenty of recent reprint editions for sale on Amazon. (You can also get a free PDF facsimile on the Internet Archive.) Mine is an original, and I like that. I stuck my nose in the gutter and caught the scent of…something old and mostly forgotten. But no! Of course! On page 509: Take 1 ounce orris root, 60 grains terpinol, 4 drams tonka…

Iron Filings

I’m a little disappointed in the new Chromium-based browser SRWare Iron (see my entry for April 18, 2009) or perhaps I should say a little disappointed in SRWare itself. The browser has worked extremely well the last couple of days here on my quad-core XP machine. After only a little sleuthing I made the ad blocker work: All you have to do is download a text list of ad sites into the Iron directory, and the browser runs with it. (The browser is shipped with an empty adblock.ini file.) However, Pete Albrecht alerted me to the fact that Iron won’t run at all on his Windows 2000 machine–even though SRWare hints that it might.

Google is quite firm about it: Chrome won’t even install under Win2K. XP and Vista are all you get. However, down in the German-language portion of the SRWare Web site, Pete (who is fluent in German and in fact translates engineering texts for a living) found this:

There is something new for users of Windows 2000 as well; for cost reasons, there are still many users of this system, for example, in business. While Chrome can’t even be installed on Windows 2000 systems, Iron has also removed the warning message that appears whenever it is started on a Windows 2000 system. However, installations under Windows 2000 remain unsupported, as there may be isolated problems.

(Pete’s translation; the item is not present in English.) Well, if the problems are isolated, they’re isolated in a peculiarly concentrated fashion. I loaded Iron Portable on a Cruzer Mini and woke up every operational Win2K machine I still have in the house. (This took some waking; my poor 2001 ThinkPad doesn’t work very well anymore.) Iron failed on all four machines, with variations on the following error message:

The procedure entry point <whatever> could not be located in the dynamic link library KERNEL32.DLL.

KERNEL32.DLL is one of several places where the fundamental Windows API lives. The API call that failed was not always the same, but in every single case, Iron failed to start.

0 for 5 on Win2K, sigh. Iron won’t run on Linux or Mac either. (Nor will Chrome.) What bothers Pete and me is that SRWare suggests that the software should run under Win2K, with only “isolated problems.” Why not just be honest? If people get their hopes up that your software will run on their systems and then find out the hard way that it won’t, it only makes your software (and you) look bad. This is not the way to make a very promising software product catch on.

The Iron Sandbox

I’ve been pretty focused the last three or four months, so I mostly missed the whole discussion about Google Chrome and its pros and cons. Parts of Chrome are very impressive, particularly the “sandbox” security model–and parts are about what you’d expect from a monster company that makes its money on Web ads. I caught snatches of the debate here and there, but it wasn’t until I found myself at 3 PM today with 5,100 words’ worth of progress made since 7:30 AM that I decided, enough of this. (I’m now 133,000 words in and pretty much on schedule again, having lost some ground in March.) So I kicked back and started reading up on Chrome. In doing so, I found something I hadn’t expected, or heard about at all: SRWare Iron.

What Iron looks like to me is Chrome with Google’s business model stripped out. Chrome itself was based on a number of different technologies, most of them open-source, including Google Code’s Chromium browser framework and the WebKit rendering engine. Google built a number of tracking mechanisms into Chrome, including a unique user ID and a few other mechanisms for sending search statistics back to Google. These seemed relatively benign to me (perhaps I’ve seen too much of the really bad stuff, heh) but a lot of people got very upset over the Chrome privacy model.

Enter SRWare, a German software security firm. They took the open-source codebase for Chrome and stripped out whatever they considered dicey from a privacy standpoint. They updated the WebKit rendering engine, did a few other miscellaneous security tweaks, and re-released the product as Iron. This sounds presumptuous to some people, but that’s how open source works. (There’s nothing preventing Google from re-absorbing SRWare’s changes, but as the changes are mostly features removed, that wouldn’t be especially useful.) Basically, we have a Chrome variant that doesn’t track your searches and phone home.

That’s good, and as browsers both Chrome and Iron have reviewed well. Chrome (and therefore Iron) do well on Web standards, passing Acid1 completely and Acid2 with only minor glitches. But what I find best about Chrome/Iron is the security model. Each tab is a separate process, and each tab process has its system rights severely restricted. Even if the browser itself is running in an admin account, the tabs run as restricted users, with a few further restrictions. Malware may well run in a tab, but there is very little that the malware can do except run in the tab. It can’t install software, sniff other processes, write files, or survive the closing of the tab. It’s not a per-tab virtual machine (which is where I think malware will eventually force Web browsers to go) but it’s a giant step in the right direction. (InfoWorld has a nice discussion of the Chrome security model.) I’m still having a little trouble getting a technical grip on the merits and flaws of Chrome’s V8 javascript virtual machine, but I’ll keep sniffing around and will eventually figure it out.

The security model prevents many plug-ins from working correctly, and this may bother some people more than others. Not me: Plug-ins are the 900-square-foot hole in browser security generally, and for basic Web research, I can do without, well, all of them.

I’ve only had a couple of hours to fool with Iron, and I’ll tell you right now that I like it a lot. I installed the portable version, which confines all of its files to a single directory and does not touch the Windows Registry. The rendering is very snappy, snappier than Firefox 3. (I haven’t touched IE in so long I didn’t even bother making a comparison.) It imported all my bookmarks without a burp, though it did not automatically place my Firefox toolbar bookmarks in its own toolbar. (I did that from Iron’s bookmark manager with one drag and drop.) I read somewhere that Iron had a built-in ad blocker, but I don’t see any controls for it, and I’m still seeing lots of ads.

Still, what attracted me to Iron is its approach to Web security…and over and above everything in the code, what may make Iron safest of all browsers is that it’s rare. Security exploits are often (if not always) app-specific or at least library-specific. Malware depends heavily on the density of the installed base to succeed, which is why so many exploits target IE, and more recently Firefox. As long as the software works well for me, I don’t care how few copies are out there–in truth, the fewer the better. SRWare has kept up with patches on both the Chrome code base and the WebKit code base (which Chrome itself hasn’t kept up with) and assuming they continue to do so, we may have us a breakthrough in the malware wars. It’s still early, but I’m already very impressed. (I’ll come back with “highly recommended” if I still think so in a few weeks. Stay tuned.)

Debuggery

In parallel with editing and (increasingly) writing chapters, I’ve been interviewing tools to feature in later parts of the third edition of Assembly Language Step By Step. Kate has the gig for editor, but the debugger slot has been annoyingly open for a long time. Since the beginning of the year I’ve been interviewing debuggers and GUI debugger front-ends for gdb, which is more an engine than a debugger and may well be the single most painful piece of software I’ve ever had to use. (Don’t get me started on that. Whoops. Too late.)

It’s been frustration cubed. Here are some notes on the fray thus far:

  • Nemiver does not work correctly with assembly language executables.
  • Insight would be a good choice, but it is one of the ugliest things I’ve ever seen running on Linux, and I mean ugly in the sense of, well, ugly: Badly rendered Motif/Lesstif screens that seem scruffier than they should be, with hard-to-read tiny fonts. I know why they used that widget set (it’s very lightweight) but I also think that’s no longer anything like an issue in the Linux world.
  • DDD is uglier than Insight, and doesn’t work as well.
  • KDbg was my favorite for a long time, because it’s not ugly and fairly straightforward to use, but its help system is broke and I never figured out how to dump memory or display named data items from assembly. Like Nemiver, it was really created with C and C++ in mind. Like people tell me endlessly (and shut up, already!) “Nobody uses assembly anymore.” Heh.

As I race past 65,000 words and close in on the end of Chapter 6, I was forced yesterday to make an executive decision and call Insight the winner. Insight is interesting in a number of ways: It’s not a GUI front-end for gdb; it is gdb, and has knowledge of gdb’s deep internals in a way that a separate app simply can’t match. The GUI was written in Tcl/Tk, a language I learned and enjoyed almost fifteen years ago when I got Ousterhout’s book in for review at PC Techniques. One would think it would be no big deal to rewrite Insight for Gtk or Qt, but I don’t see the dust from any stampede.

So I got me an ugly debugger. That is (given my deadlines and the significant amount of money riding on the project) better than no debugger at all.

The Yard’s All Out of 3 X 4s…

I’ve gotten far enough into the revision of Assembly language Step By Step that I need to have a Linux machine running up here in my office all the time. I often spend hours in Ubuntu on this dual-boot machine, but there are still some things I need to do in Windows, and booting in and out to bounce from one to the other is time wasted, and pointless when I have old PCs stacked like cordwood in the basement.

SX270AndBracketOnDesk2.jpg

I have one of the very cool SX270 stainless-steel all-in-one brackets that combines a 10cm VESA monitor mount with a couple of tangs to hold an SX270 mini-PC behind the monitor. It makes for a very compact system, and in fact it was the integration of the SX270 and the monitor on the bracket that first brought the SX270 to my attention some years back, when I saw a couple of them at our optometrist’s office. So I took my spare SX270, parked it on the bracket, dug a Dell keyboard and a mouse out of the odd lots box, and realized that I did not have a VESA monitor to hang on it. So off we went to Best Buy, where I learned from the earnest young woman in the computer department that they had not sold 4:3 monitors for almost a year now. Every single one in the long line on display was 16:9.

I know why this is the case (home theater) and whereas it wouldn’t be my first choice, I’m willing to use that form factor, and really needed a monitor. I was apprehensive for a simple reason: The SX270 was made in 2003, and I don’t recall the machine supporting the 1600 X 900 resolution of the smaller 16:9 LCDs. I took a chance, figuring (or at least hoping) that I could rummage around online and come up with a newer driver for the Intel 82865G graphics chipset.

What I bought was a Samsung SyncMaster 2033SW. It’s VESA-compliant, and I bolted it to the stainless steel bracket without difficulty. It was on sale for $179. The machine itself cost me less than that; I think $150 on eBay some time last summer. 2.8 GHz, 1 GB RAM, with XP Pro–used and used hard, and ugly up close, but completely functional. I went up to Dell’s site to see if newer video drivers were available, but what they had was what I had. The closest that Windows could come to 1600 X 900 was 1280 X 768. The monitor centered the smaller raster in the middle of its screen, with the surrounding pixels dark. There was a “stretch” option that spread the raster out to the full extent of the screen, but it looked hideous.

Fortunately, Windows wasn’t the goal here. I booted the Ubuntu Intrepid installer CD in LiveCD mode to see what the OS would detect and how it would respond, considering that the machine dates back to 2003. Without a grunt of complaint, it detected the graphics hardware and loaded a 1600 X 900 driver. I tried a few things, pronounced it good, and told the OS to go install itself in earnest. Twenty minutes later, I was downloading NASM, Kdbg, the Bless Hex Editor, Nemiver, ddd, and a few other things through the Synaptic Package Manager. Not once did I have to face a command line. Everything Just Worked. The age of the machine (apparent from its collection of dents and inventory-tag stickum) didn’t seem to matter at all.

The display is gorgeous; it’s easily the brightest LCD I’ve ever seen. The whole gadget takes up about as little space as anything with a 20″ monitor possibly could. And after spending an afternoon with it, I realize that a long horizontal aspect can be handy: Editor on the right, Kdbg on the left, and just enough of a terminal peeking out under the editor to run make as needed.

I’ve been fooling with Linux intermittently for well over ten years, and the craziness of today’s events still boggles me: It installed much faster and way more easily than Windows generally does, and on old hardware to boot. This was not the case in 1999, let me tell you. If MS isn’t in trouble by now, it’s nobody’s fault but our own.

Cruzer Micro Skin

I’ve been using removable storage for a long time, and five years ago I moved from Iomega ZIP 250 MB disk cartridges to Cruzer Mini 256 MB thumb drives. I chose the Cruzer Mini line for a slightly weird reason: They fit comfortably in the pencil groove of my Northgate keyboards. Not all thumb drives do, and I’ve found it very convenient to have all of my active removable storage devices sitting there right where I can grab them.

Five years on, and not a single one of the Cruzer Minis has ever given me a lick of trouble, though I destroyed one once by working too fast. SanDisk no longer makes Cruzer Minis, and the ones I have are fairly small, some only 128 MB. This makes for lots of thumb drives lying around; for example, I had to put each one of the five Carl & Jerry books on its own Cruzer. It was time to scout out something else that would fit in my pencil groove, and with considerable delight I discovered the SanDisk Cruzer Micro Skin. They’re shorter than the Cruzer Minis, and a little narrower. No problems keeping them in the groove.

I bought them for their size, and didn’t understand the line’s gimmick until I had one in my hand: The Cruzer Skins are inside a flexible, tough plastic sleeve with an end cap of the same material. The skin and cap fit the metal body of the device very closely, enough so that if you dropped one in the sink the works wouldn’t even get wet if you pulled it out within a few seconds. (I’m guessing that they float, in fact, though I’ll let somebody else do the experiment.) You can remove the sleeve and apply a Brother-style label to the drive body, and then wiggle the sleeve back over it. This protects the label, especially if you drop it in your pocket with your car keys, as I’ve done a time or two. (Brother labels mar very easily.)

They’re yawning huge compared to my five-year-old Cruzer Minis. I recently bought several 4 GB units for $12 each, and an 8 GB (for $20!) to hold all five Carl & Jerry books, including high-res raw scans of all the 300+ illustrations. I’ve been able to consolidate several ongoing book projects from separate 256 MB cartridges onto a single 4 GB unit. The caps don’t fall off; you have to yank them. They don’t come with lanyards, but you know, I have yet to see anybody keep a thumb drive on a lanyard. (A lanyard loop is there at the end of the unit if you want to make your own, like we did at summer camp in 1965.) We’ll see how they hold up over time, but right now, I say highly recommended.

An Embarrassment of Riches

I’m hard at the rewrite of my assembly book, and in going over the chapters closely I realize that I have a lot to do, significantly more than I thought going in. Parts of this book date back to 1988, and the work as a whole was not organized back then the way I would organize it today. So I’m doing more to it than I thought I would, and although that will make for a better book, it’s also eating more of my time. (Expect a few fewer Contra posts over coming months, and perhaps shorter ones.)

I’ve also been using Ubuntu a lot more than I ordinarily do, since the rewrite finally exiles DOS from the discussion except as a historical footnote. I find myself surfacing for a breath now and then, and realizing, I haven’t been in Windows for almost six hours! Crossover Linux has made this possible, since I have Office 2000 and Visio 2000 installed under Ubuntu now, and don’t have to be bouncing between two machines or two partitions to write code and then write about the code.

In the process, I’ve been using Ubuntu more and at more depth than I ever have before. One thing I’m beginning to appreciate is just how easy it is to get software and keep it current, and just how good the software that’s out there really is. That’s changed in ten years. Back in 1999, in order to run NASM under Red Hat I had to download a tar file full of source, unzip it somewhere, and then recompile the whole damned thing. I had no intention of changing the assembler and would have been more than happy with binaries.

It’s different now. With Ubuntu (and I assume most modern distros) you go up to a software repository through a package manager utility, cruise an enormous list of free packages that are available, and check off the stuff you want. Then you click Apply and stand back: The package manager downloads the package and anything that the package depends on, checking first to see if you’ve got any of the prerequisites installed already. Only the stuff you need comes down, and when the smoke clears you have new apps on your app menu, or new libraries tucked in where they’re supposed to go. (Or both.) Wow.

Ubuntu periodically checks to see if updates are available for anything you have installed, and a couple of clicks brings them down and installs them.

I’m sure that not everything that exists is up there, but what’s up there is extremely impressive. If I allowed myself to get distracted, I’d be playing with Gambas and Boa Constructor rather than writing. The Nemiver debugger front end didn’t exist ten years ago, and it will star in the new edition of Assembly Language Step By Step. Most of all, I want to play with Lazarus (the GUI IDE for Free Pascal) and have to slap my hands periodically, or I’d get nothing else done.

The primary barrier to the adoption of the Linux Desktop is unlearning old habits, followed as a distant second by conversion of existing Windows-centric files. There may have been a third barrier somewhere, but I’ve forgotten what it was. There is certainly no shortage of software to get the jobs done.

Gretchen’s Patent Pasta Ponchos

jeffinpastaponcho

I got a couple of really nice things for Christmas. Carol gave me a Canon G10 camera, a device that probably contains more intelligence than NASA had at its disposal in 1965. In fact, I’m still getting used to some of that intelligence, but…more on that later.

The other thing worth noting is a hand-made item from my sister Gretchen, before whom all things in the textile kingdom bow. Months back, when Gretchen asked me what I wanted for Christmas, I told her, Make me a pasta poncho. I told her what I meant. And she did.

You see the results above. She took an ordinary 48″ X 26″ bath towel in appropriate tomato red, and somehow (this is a black art to me) inserted a turtleneck dead center. So whenever we have pasta now, I just pull it over my head, and I’m set. Nothing to tuck, tie, or button. And when I invariably dump some of the sauce on myself, well, it’s machine-washable. (I always seem to wear white shirts the nights I make our trademark Front Range buffalo spaghetti sauce.)

The photo was taken yesterday evening, just before I lit into a pile of whole wheat spaghetti. I had a minor problem; I’m alone in the house. So I took the new Canon G10, put it on my tripod, and placed it across the kitchen table where Carol’s chair usually is. While digging through the manual looking for how to use the self-timer, I discovered that the G10 has something new (to me): a face-recognition self-timer. It works like this: You set up the shot, select the face timer, and then trip the shutter. The camera waits until it sees a new face in the field of view, and then kicks off the self-timer. So all I had to do was amble (not run) over to my chair, grab my utensils, and look the camera in the, er, eye. Bang! Timer starts running. Five seconds later, photo happens.

It doesn’t have to be a solo portrait. Get the family together in one frame, trip the shutter, and the G10 will wait until it sees you (or at least one more face) in the frame before it starts the timer. Sheesh. For a guy who began in photography with 120 Tri-X Pan film and a motheaten folding bellows camera (patched at a bellows crack with a small piece of Curad Battle Ribbon) this treads on the thin edge of spooky. I can see myself the day after Christmas 2019, arguing with my brand-new Canon G256:

ME: “Hey, lensface, this time take the glint off my skull, ok?”

G256: “Sure thing, boss. I can render CGI hair if you want.”

ME: “Don’t be a wiseass. You know what I mean.”

G256: “That would be an image closer to your genetic reality.”

ME: “A genetic reality that hasn’t been fully expressed since 1982 or so.”

G256: “But that’s the Canon slogan for 2019: Reality never looked this good!”

ME: “Take the best picture you can. Don’t screw with reality. Just. Take. The. Picture.”

And I’d get the CGI hair. Just what the world needs: A WYGIWITRSB camera. (“What You Get Is What I Think Reality Should Be.” )

Not that I’m complaining; the G10 is a pretty spectacular camera, and it doesn’t talk yet. It can take macro shots that are almost like what you’d see through an inspection microscope. The thumbnail at left is a 1N23 microwave diode, slightly larger than life size. (The real thing is 5/8″ long.) Click on it. Dare ya. Count the dust grains. Wow.

Anyway. Gretchen made a pair of ponchos and gave one to each of us. We hung them on hangers in the laundry room just off the kitchen so they’re handy, and as soon as Carol comes home again I’m going to throw her a spaghetti feast like she’s never seen before–and if I miss, well, she’ll be wearing the poncho.

Remote Lecturing with Skype and Mikogo

First on my do-it list this morning was to deliver a lecture at Miami University at Middletown, Ohio. I’m still here in Colorado (though, alas, Carol is in Chicago again and I’m batching it until the 26th) but it worked out well, and the lecture was my first “production” use of Skype and the Mikogo plug-in for Skype for remote presentation.

Jay Slough K4ZLE of the Southwest Ohio Digital and Technical Symposium asked me to do an hour-long presentation on Carl & Jerry well over a year ago, but our schedules didn’t mesh in January 2008, and we had to wait a year for another chance. In a way that was good, because in my view, Mikogo plows NetMeeting (which we had intended to use last year) right into the soil.

Mikogo adds presentation capability to any participant in a Skype conference call running the plug-in. Whatever is displayed on the screen of the chat participant deemed the presenter is echoed on all other participant screens. The presenter can change at any point, so people can take turns presenting to the group. Mikogo defaults to screen echo only, but it has an option for remote control, a la VNC. Mikogo also allows the presenter to draw nondestructively on the echoed screen, whiteboard-style, though I didn’t need this feature for today’s session.

I’m a seasoned lecturer and have done presentations to groups as large as a thousand people, but there was a critical difference this time: I couldn’t see the audience, and could hear them only faintly. The other end of the Skype/Mikogo connection was Jay’s laptop driving a big-screen VGA projector in a university classroom, with Jay at the controls wearing a headset. I sat here in my chair in front of the screen in my office, talking into my headset between Powerpoint slide changes and trying to remember not to wave my hands. I missed not being able to play off the audience, and couldn’t tell if they were laughing at my jokes. During the Q&A in the last five minutes, Jay had to relay all questions to me, which was awkward even if necessary.

Technologically it went well, though it took a couple of minutes longer than we planned to get the two systems talking to each other. During the presentation, Thunderbird popped up an email notifier box in the lower right corner of the screen, and until I could shoot the box it became part of the screen echo. The symposium gang out in Ohio apparently loved it, and it was a great opportunity to popularize Carl & Jerry to people I would probably never have connected with otherwise.

I’d do it again in a heartbeat, but I’d like to add some refinements, which I think Skype could support:

  • I want a cam aimed at the audience, with a mic that will pick up general sound from the same direction. Video from the cam would have to go on a second display, but displays are cheap. Audience feedback is important, whether you’re a stand-up geek comedian like me or not.
  • Less necessary, but it might help the general tenor of the presentation: Somehow display a borderless video window in the lower left corner of the presentation screen, so that the audience can see me. (I’d leave a hole in my slides sized to match the video window.) How well this would work is obscure but readily testable. My webcam is four years old and I probably should get a new one. Logitech sells high-res units that automatically integrate with Skype.

Other applications of this system suggest themselves: Real-time manuscript workshopping, with workshop participants taking turns echoing their screens while displaying their manuscripts. Tech support. And (as Pete Albrecht and I intend to try in the next few days) remote control of his big Meade telescope and imager.

Skype is a fine thing. Pete is in a Skype window right now, telling me about the new Skype competitor, Oovoo, which adds session recording to videoconferencing. Skype lacks that feature, and it would be handy for people (like me!) who couldn’t make it all the way to Ohio for the Symposium. More when (or if) I try it.

Mikogo Over Skype

Yesterday I discovered Mikogo, a Net meeting/remote desktop technology that would be a lot like VNC and the others I’ve played with, except that it can be configured to piggyback on Skype. There is a Mikogo Skype “extra” (what Skype calls its plug-ins) and I will be using it to give a remote lecture on Carl & Jerry to the Southwest Ohio Digital and Technical Symposium on January 10, with the help of Jay Slough K4ZLE.

Jay and I gave it a spin yesterday to make sure we could connect during the Symposium in January, and in addition to working well, Mikogo was mighty cool. You install the extra from the Skype Extras menu, and it comes down the same way that other Skype extras do. Once installed, you can create a 1-to-1 or 1-to-many connection with anybody else who has the Mikogo Skype extra running. Skype handles the audio, and where the connection is between two machines, the “presenter” (the machine that provides a screen echo to the other) can be switched back and forth at any time. Mikogo has a simple whiteboard feature that allows the presenter to draw lines in various thicknesses, colors, and shapes on the screen. It also has the option of remote control, so that the non-presenter can use the mouse and keyboard on the presenter’s machine. Pete Albrecht and I plan to try using Mikogo over Skype to allow me to control Pete’s big Meade telescope from here in Colorado, at least when it stops raining in Orange County.

I don’t have a great deal of experience with the Mikogo system yet, but after an hour or so of solid connections with Jay and with Pete, I can say that it’s well worth trying if you have any use for that sort of thing.