Jeff Duntemann's Contrapositive Diary Rotating Header Image

software

Odd Lots

  • My installation of Thunderbird 3 has correlated with a lot of weirdness, not only in system performance but in taskbar “stalls” in response to clicked links in messages. I’ve heard a lot of people having trouble with it as well, and we are apparently not in the minority.
  • How can I have lived the last ten years as an SF writer and never heard of John Titor, Time Traveler?
  • Stephen Hawking has told us that we must abandon Earth or die. Agreed. Now, Dr. Hawking, would you please invent us a hyperdrive already?
  • No, bichons are not groomed this way. (That’s for miniature poodles.) Thanks to Jim Strickland for the link.
  • Microsoft is working on a tablet prototype with keys on the back surface, opposite the display, so you can type with the fingers that you’re using to grip the device. (Thumbs remain on the front.) This looks better than it tells; do follow the link. Will it work? No opinion until I try it.
  • If anyone here has not yet been to thereifixedit.com, Go. There. Right. Now. (Via Make.)
  • Many people have sent me a link to this item from City Journal , which may indicate that some sense is finally creeping into the nutrition world. Sugar and grains may be killing you. Meat, eggs, dairy, and animal fat are probably not. I’ve known this from my research for a long time. Now, to get the government to admit that they’ve been slowly killing their citizens for over 30 years…
  • Not convinced? Fructose seems to be the preferred sugar of cancer cells.
  • Still not convinced? The inventor of Cheese Doodles just died at age 90. So much for salt and fat being deadly. (The food dyes worry me more than either.)
  • Pete Albrecht points out that LA coffee shops are beginning to unplug their Wi-Fi access points and plaster over all their wall outlets. They’ve found that people buy more coffee and snacks when they actually talk to one another. No shirt, Sherlock!
  • Formufit: PVC pipe fittings for when you’re not using PVC pipe for plumbing. Fine stuff!
  • I think that what we’ll miss most about our deathwish-afflicted newspapers are all the silly headlines.
  • And anyone who has ever scratched his or her head over that famous if gappy Latin expression “Et in Arcadia ego” should look at the variations here. (I find myself thinking of a paraphrase of another classic expression from junk mail: “You may already be in Arcadia!”)
  • Heh. As long as Carol’s beside me, I am.

Insight Is Gone From Ubuntu…

…and in fact from everything else based on Debian. Not six months after I saw Assembly Language Step By Step, Third Edition hit the shelves, the Debian team decided to pull the Insight debugger package from their seminal Linux distribution, on which Ubuntu, Kubuntu, Mint, and several others are based. Come Ubuntu 10.04 Lucid Lynx at the end of this past April, and suddenly people reading my book can’t work through the examples, because the software that I used in those examples (for single-stepping and examining registers and memory) is no longer available for their version of the OS.

This isn’t new news, and I’ve been trying to figure out how to finesse the problem ever since I heard about it mid-May. I got a number of queries this past week, suggesting that I had better get on it. (This is why you haven’t seen much from me in recent days.) Assuming at first that Insight had been dropped just to keep the distro CD-size, I tried to install it under Lucid from Software Center (not found), next a deb package, and finally from source, but nothing worked quite right. As the months have passed and more and more people are installing Lucid, I’m getting more and more mail about this. It’s a serious problem: A lot of the skill of assembly programming lies in debugging at the instruction level, and much of the tutorial depends on being able to run a debugger. Insight was that debugger. It’s GUI-based, rather than purely textual, and I think it’s a great deal easier to grasp, especially for newcomers.

So why didn’t I just use gdb?

Um…I did. Or at least I thought I did. Insight is an odd case. Most people assume (as I did) that it works the same way that Nemiver, KDbg, and DDD work, as independent front ends for gdb, passing textual commands to gdb and getting textual data back for display. Not so: Insight is gdb, and therein lies (in my opinion) most of the problem. What Insight’s originators did was take the gdb source code and add a built-in GUI, using Tcl/Tk. In effect, they forked gdb and produced a new custom version that contains all of gdb (at least gdb as of 2007) plus a windowing visual wrapper.

That in itself is unorthodox but not necessarily damaging, though forking something as fundamental as gdb should not be done lightly. Still, if you do it, you have to do it well, and I’m seeing indications that Insight isn’t nearly as clean a product as it should be. The Debian team spoke tersely; see the bug report and resolution here: “RoQA; insane packaging; unmaintained; low popcon.” (Yes, I read “popcorn” at first too.) More details may be found here. (Warning! DDG: Deep Debian Geekery.)

Quick translation:

  • RoQA means “Request of Quality Assurance”; basically, Debian’s QA team decided that the package was too broken to keep in the Debian distribution and requested that it be removed.
  • Two release candidate (RC) bugs were reported by the Debian team to Insight’s maintainer, but no one there responded. This is odd, because the maintainer is none other than Red Hat.
  • An NMU is a non-maintainer upload, which is when a package is sent to the distro team by someone other than the package maintainer of record. It is often a sign that the maintainer has abandoned the package, especially if the maintainer never acknowledges the third-party fix.
  • “Low popcon” is a reference to Debian’s unique “popularity contest” system for gaging how much individual distro packages are being used. Insight got 36 votes, which, in browsing the rest of the stats, seems low but not fatally low.

The real problem is that “insane packaging” issue. Insight contains embedded copies of software that is maintained by others and would be better linked in as libraries. The embedded bits “age” with respect to the current release of the OS and its libraries, eventually getting out of sync to the point that the package will not understand the current system well enough to function correctly. Tcl and Tk are either part of or easily installable to any Linux distro there is; you do not have to cut’n’paste them into your program source. With old software copied into its sources the package may build correctly, but might not necessarily run.

That said, the right way to approach the problem may be no more complex than taking the most recent release of Insight and making a proper Debian package out of it. The version I used last year in Karmic Koala goes back to 2007, and that’s the version pulled from Debian. The July 2009 release may be better. I’ve read enough on building Debian packages to know that I’m not the guy to do it, but I hope that somebody with better Debian chops will eventually try it, so that we can tell if Insight was just wounded, or if it’s really and quite sincerely dead.

In the meantime, the best fix appears to be falling back to Ubuntu 9.10. More here as I learn it.

Odd Lots

  • Please read this short article by Mark Shuttleworth. I’ve been saying this for years, but he’s a lot more famous than I am: Tribalism makes you stupid. It also means that you are owned, and are not a free man or woman.
  • The Insight debugger front end for gdb has been removed from all Debian-based Linux distributions, and is not present in Ubuntu 10.4. The Debian package for Insight has been criticized as “insane” and unmaintained, and I’m curious: Has anyone here used it in recent releases of Fedora or OpenSuse?
  • Autodesk founder John Walker has an interesting free Web toy for Greasemonkey, which attempts to spot “media trigger words” and alert you when weaselspeak is being attempted. (Thanks to Jason Kaczor for the tipoff.)
  • Oh, no! It’s the Pluto Effect for dinosaurs! Triceratops is actually an immature Torosaurus!
  • Man, turn your head for ten minutes and there’s a whole new kind of punk out there. But this one I may actually like: Dieselpunk. Think Art Deco urban fantasy, with the cultural clock set at 1920-1945. This might include the first Indiana Jones movie, and certainly one of my personal favorites, The Rocketeer. Lessee, we still need Musketpunk, for gritty urban fantasy in 1780 Philadelphia. Ben Franklin with tattoos. Could work, no?
  • Don’t be drinkin’ Diet Mountain Dew while reading this site. Trust me.
  • There is an entire news site devoted to good news. Perky people like me and Flo read it every day now.
  • Sheesh. What’s wrong with “Hi! Is this seat taken?” (Wait, no, that was the 70s. And purely analog.)
  • I don’t think I posted a link to this back in April, but I should have. There’s a rectangle of this identical cloth hanging on my workshop wall as framed art. Pray without ceasing, even when you’re soldering up a regenerative receiver.

App Inventor for Android

AppInventorBlocksEditor.png

Whoa. Yesterday morning Google took the wraps off App Inventor, a visual development environment for the Android mobile OS. I’m still trying to slurp from the firehose, even though I’m finding that all the hoses have basically the same information, and in truth not a great deal of that. But I’ll tell you right now: It stopped me in my tracks on the iPad decision. As of yesterday morning, I wanted something that runs Android. The new search is on.

You know me. I’m the Visual Developer guy, and the fact that my magazine’s been dead for ten years doesn’t change that. I still believe that visual metaphors for programming are not only useful but necessary, if certain kinds of software development are to happen at all. (More on this below.)

If you haven’t looked into App Inventor at all yet, a very good place to start would be Jason Kincaid on TechCrunch. He’s got a good overview and some screenshots (including the one I show above) that will give you a sense for what Google’s cooking up. I’ll summarize here. App Inventor has two major subsystems:

  • The Designer is basically a form designer, not conceptually different from that in Delphi, VB, and many other more recent environments. You drag UI components from a palette and arrange them on a form.
  • Far cooler (if less proven in its approach) is the Blocks Editor. Here’s where program logic happens, and it happens by snapping together logic blocks that look literally like jigsaw puzzle pieces. Clusters of blocks become event handlers. You connect a cluster to an event generated by a component on the form, and the blocks in that cluster execute.

(This may not be the correct jargon. Please understand that I don’t have an instance to play with yet, so all I can do is relay what I’ve read from the fortunate few who were given early copies.)

I knew what the major problem was going to be before Jason told me: In any system like this, you’re limited by the selectable elements on your palette. He didn’t mention where the blocks come from (I assume they’re written in Java using some relative of the MIT Open Blocks technology) nor whether user-created blocks will be importable into the product as shipped. I’m a lot less worried than he seems to be about this, because Google isn’t stupid, and they know damned well that the system lives or dies by the richness of the set of available logic blocks from which the apps are generated. If it’s anything like an open system, there will be an explosion in third-party blocks once a few Java guys get the system and figure out how to do it.

Jason provides some screenshots with his article, and I borrowed one above to get your attention. Here’s another page with a description of a more complex app, with a much more representative Blocks Editor display.

There’s not a lot more that I can say about App Inventor itself, at least until I can get a workable instance installed here. But it’s been interesting seeing all the dorks in the comments to the news stories, dumping on the system for its simplicity, and for the (frightening) possibility that the hoi-polloi will be able to use it to write their own software. They scream the obvious: You can’t write a word processor with a tool like this!

Fersure. And that’s not what it’s for. I’ll respond with something that should be equally obvious: The mobile phone environment is fundamentally different from the desktop environment. From the beginning, it’s been about smallish apps that do one or two things of interest, and no more. Mobile phone computing for the most part is about getting in, doing something with a few quick clicks, perhaps reading the screen, and getting out. The apps are very focused and often extremely specialized. Some are obviously going to be a lot more difficult to write than others, but a useful mobile app does not necessarily require man-years of development time.

And if it ever did, it won’t anymore once App Inventor hits its stride.

I think that I’ll use App Inventor for the same reasons that I use Delphi: To play with ideas, see how things work, and gen up one-time test apps that may lead in useful directions. I’m guessing that App Inventor will enable people to create apps for an audience of one–themselves–and not have to spend six months of free time to do it. Companies may experiment with different approaches to mobile computing without having to commit millions of dollars in dev costs to any one approach, just to see if it’s useful or even doable.

I have never had a smart phone, and I’ve been waiting for my current cell provider contract to expire early next year before getting one. I may have to accelerate the schedule a little. This thing’s making me itch in places I haven’t itched in for a long time.

Odd Lots

  • Before GPS, there was…rolled paper. I’m not sure how useful a one-dimensional scrollable map is, but it was a good start. (And now, all you steampunkers, figure out how to do the same thing in two dimensions.)
  • Shortwave radio and one-time pads are still being used, as we discovered in the recent Russian spy foofaraw. Slate’s done a decent overview of number-station covert communication. The late Harry Helms wrote a lot about these, and most of what I know came from his books. Some technologies just don’t get better over time. They were optimal from just about the beginning.
  • This Lifehacker tutorial tells you in agonizing detail how to install OS X Snow Leopard in a VirtualBox VM. Cool enough–but when did that become legal? (My guess: It didn’t.)
  • From Pete Albrecht comes a pointer to an item describing a proposed copyright law in Brazil that provides penalties for attempting to limit use of public-domain material, or fair use of copyrighted material via DRM. That is a remarkably good idea. (Maybe we’ll see the Viagens someday after all.)
  • This looks real (i.e., not Photoshopped) but as at least one commenter has pointed out, there seems to be no way to get inside. Maybe it’s the ultimate RC car.
  • Speaking of cars, in reading the comments for this Wired Blog article (titled “What’s the Fastest You’ve Driven?”) I felt old and frumpy. The fastest I’ve ever driven in my life was 95 or 96 MPH: in 1971, in my mom’s battered teal-green 1965 six-banger Chevy Biscayne, northbound on the Edens Expressway just before the I-290 junction…in the rain. Why? I no longer remember. And that’s probably just as well.
  • And yet more about cars: Buss Ford Lincoln Mercury in McHenry, Illinois posts YouTube video endorsements from their happy customers. Buy a Merc before they’re gone…and be famous! (It worked for Carol’s sister and her husband.)
  • And now, for quite enough about cars: Pete Albrecht reminds us that in 1973 somebody glued the rear portion of a Cessna Skymaster to a Ford Pinto, and it flew…for awhile. (What do people say? “Don’t fly 70s cars?” Uh, yeah.)
  • DARPA wants a flying submarine. They should ask Irwin Allen. Or Tom Swift, Jr. (Thanks to Frank Glover for the link.)

Realtime Cloud Logging to Spot Band Openings

(Note: This is a total ham radio geek-out entry, so if such things make your eyes glaze over, be advised that there’s an extreme glaze warning in effect until at least tomorrow morning.)

Anyway. I stumbled on a band opening yesterday by accident: I scanned the 6 meter band, expecting its usual near-silence, and instead heard something like a continuous pileup from 50.2 up to 50.6. Such openings happen semiregularly, especially in the summer and during sunspot maxima, but they’re not reliably present when you want them. Typically, people either monitor the bands for openings using a panadaptor (a way to visualize the whole band at once, often built into high-end radios) or they hear about it from their friends via Skype or some other chat system. (Hey Jeff! 6 is going batshit nuts!)

While copying my notesheet to my log last night, I thought of a better way. Suppose there were a sophisticated Web app allowing people to record their contacts in a central database off in the cloud somewhere. Serious contesters work their radios with both hands on a keyboard these days anyway, but they’re logging their contacts locally, on their own PCs. If enough people were logging enough contacts online in realtime, you could plot those contacts on a map as great-circle lines between one station and another. If you wanted, you could age the plots, so that a given line was displayed on the map for a selectable period of time, say the past fifteen minutes. Older plots would vanish and new ones would be continually added. What you’d have is a lookback time window onto what’s happening on the ham bands, plotted geographically. If you click on the “6 Meters” map and alluva sudden there’s a thick web of lines between Colorado and the east coast, you’d know that there’s a band opening underway.

This would be possible in part because the geographical coordinate locations of stations are implicit in logged contacts. Base (at home) stations are licensed by the FCC to particular addresses, and these addresses are matters of public record, easily queried by software. Mobile stations aren’t required to be at any particular location, but GPS logging for mobiles is possible, and I think has been done, if not commercially. Plus, there’s another way: More and more people (especially on higher bands like 6 meters) log the “grid squares” of the stations that they’ve worked. There’s a system for tagging 2 degree by 1 degree rectangles of the Earth’s surface, such that each rectangle has a 4-character callout. (There are an additional two characters of precision that almost no one uses.) My own is DM78. Here’s a map for the US and for the Earth as a whole. Plotting a line between DM78 and EM94 isn’t hugely precise, but it will tell you that radio signals are propagating usefully between central Colorado and northern South Carolina, and that’s all most of us need to know to make us scramble downstairs and turn the radio on.

I think this is one case where doing something out in the cloud that was previously done locally provides benefits that local storage alone does not. The whole point is to brag about how many locations you’ve worked worldwide, so privacy is not an issue. (If it is, just keep your logs local.) And the benefit of online collaboration is knowing just what propagation paths are open at any given moment of the day. I’d pay a quarter for that, or at least provide data by logging contacts.

I looked around just now to see how close we are, and whereas there are a couple of online logging systems in operation, they are nothing even close to realtime, and none that I can see makes any attempt to plot propagation paths for logged QSOs. That said, nothing I call out here is rocket science.

So. Did I miss something somewhere? And if not, what Ajax wizard is going to give this a try?

Odd Lots

Review: The Calibre Ebook Management System

I tried Calibre when it first came out a little over two years ago (v0.4.83) and was reasonably impressed. It did everything it said it did, reliably and without much fuss. Alas, I didn’t test most of its features back then, especially its file conversion modules. I’ve done a lot more in the past week, and overall I’m pleased.

The current version is 0.7.6, and author Kovid Goyal posts updated releases frequently, as often every couple of weeks. That’s amazing for a GPLed app, but Calibre itself is amazing in its way. If you install no other ebook reader or manager, get Calibre. It’s a Python app, and can be downloaded for Windows, Linux, or Mac.

There are three general aspects to Calibre:

  • It’s a sort of jukebox for ebooks: a simple database manager that allows you to browse your ebook collection, search for individual titles, and edit metadata by individual title or in bulk. It can send books to any of a growing list of hardware readers.
  • It’s a collection of import/export modules behind a GUI, allowing you to take an unencumbered ebook in one of a long list of formats, and export it to a different format out of that same long list.
  • It’s an ebook viewer that can render ebooks for reading in most popular formats. When a format isn’t supported, Calibre attempts to launch the associated app to render the book.

All three aspects work well, though I ran into some problems with format conversion. I tested Calibre by importing basically every ebook I have on disk, which at this point isn’t all that many. I still don’t have a portable reader device that I like, and I don’t read a lot on my PC display. So I went and got a bunch of things from Project Gutenberg (including all the pre-1923 Tom Swift Senior books) plus some religion journals and other PD oddments from Google Books, and ended up with about 150 titles.

Calibre copies imported ebooks from their original locations to a separate directory, and it operates only on those copies, leaving the originals alone. (This means that the space your library takes on disk will basically double, though I doubt that this is an issue in an era of 2 TB hard drives.) It controls the filename of each file, and imposes a filename by running a regular expression against the title and author name in its database. Change a book’s title in the database, and the filename changes in sync. Delete a book, and only the imported copy in the Calibre directory goes away. Your originals are not touched.

Once you import the ebooks you own, plan on spending some time editing the metadata. Calibre uses a regular expression to extract an author and title string from each file, and although you can change the regular expression if you want, there’s no broadly accepted standard for ebook filenames, and you’ll find that many of your books have the author name in the title field or vise versa irrespective of the expression Calibre uses. You can specify a series name and number for books in series; e.g., Tom Swift, Sr., Volume 12. There are additional fields for publisher, ISBN, pub date, and comments, and if a cover image is present in a book, a thumbnail will be displayed. There is a tagging system with a tag manager.

Sorting out the metadata was a fair bit of manual labor, even for only 150 books. You can do updates on several books at once; for example, I highlighted all the Tom Swift books and set the Author field to Victor Appleton in one operation. If you have many hundreds or perhaps thousands of ebooks (and I know people who do) good luck; you’ll need it. There is autocomplete on fields and that helps, but there’s an irreduceable amount of keystroking that has to happen to get the most from the database browser.

The ebook viewer is as good as I’ve tested so far. It renders almost every ebook format I’ve ever heard of, including the comic book formats and PDF. (You can configure it to launch an external app to handle a specific format if you choose; for example, I open CBZ and CBR files with Comical.) For EPub and MOBI files, at least, the reader automatically maintains a bookmark to the last opened location in the book, and when you reopen a book, the cursor goes right to that bookmark. (This is not true for LIT, PDB, , and LRF books.)

About the conversion modules I have mixed feelings, and the problems are probably not all with Calibre. I converted my EPub version of the Beyschlag Old Catholic history to LRF, MOBI, and PDB. Results were so-so. One problem with the LRF export was that the font size was inconsistent: Parts of the text were rendered in larger type than others, and I can’t tell (yet) if that’s an issue with Calibre’s LRF viewer module or with the conversion process from EPub to LRF. The conversion to PDB stripped out all the formatting, including italics, and that does appear to be a problem with Calibre. MOBI kept the italics but didn’t center the author lines. Calibre seems happiest dealing with EPubs, and conversion from other formats to EPub works better.

Note that Calibre doesn’t deal with DRM-encumbered files at all. That’s fine with me, as I won’t buy DRM, but you need to keep it in mind if you’re looking to read DRMed books on your PC; Calibre is not the item for that.

I also installed Calibre under Linux, and I moved my entire Calibre database over to the Linux machine by simply copying the Calibre books directory to a thumb drive, and then copying the directory from the thumb drive to a folder in my home directory and telling Calibre to use it. As best I could tell, there were no functional or performance differences between the Windows and Linux versions.

There isn’t a lot of downside to Calibre. Opening and rendering an ebook on the internal reader can be slow if it’s one of the more sophisticated formats. (Txt and .rtf files open very quickly.) The viewer doesn’t downsample cover images very well when displayed at less than their native resolution, though that’s a quibble. (Reduce the display size on my Old Catholic history epub and you’ll see what I mean.) Adding bookmarks seems to take more time than it should, especially on longer books. The program crashed once when I had a lot of windows open. (These included Thunderbird 3, which seems to be causing a lot of weirdness recently.)

Calibre doesn’t help you create ebooks; that’s not what it’s for. And some issues with the conversion modules are going to keep me looking for reliable ways to make MOBIs, LRFs, and PDBs out of my EPubs. However, in terms of an ebook manager, it’s just short of stellar. The viewer modules work reasonably well, particularly with files created “natively”–that is, not converted from one format to another.

Basically, the ebook business is still mighty young, and I’m not surprised at how random things still are. Among ebook-related software products, Calibre is the least random of anything I’ve yet tested, and at this crazy stage of the game, that’s high praise.

Highly recommended.

Odd Lots

Query By Sketching

MysteryLogo.jpgEarlier today, while Carol and I were out on an errands run, we were stopped for a light behind a beat-up pickup truck. On the back of the truck was an emblem on a sticker, and Carol asked me what it was. And in truth, I don’t know, though I’ve seen it a time or two before. It looks like a band logo, though not of any band that I’ve ever listened to.

It was a right profile of a cartoonish man running, with his hair streaming in the wind. In one hand he’s holding a sheet of paper in front of him. The whole thing is in red, inside a red circle. There’s no text of any kind. (The figure is filled in with red; my sketch above is in red Sharpie. Also note the painfully obvious: I’m a words guy, not a pictures guy.)

The challenge intrigued me when I got home. How would I look something like that up? I tried text descriptions in Google Images: “little red guy running”, “red logo running man,” and so on. Saw lots of interesting things, but not that logo. I didn’t spend a great deal of time on it and gave up after a couple of minutes.

We don’t really have a search system for pictograms, and we probably don’t need one all that badly, but it made me wonder how we would make the attempt. Text descriptions? “Right-side profile of cartoon man running, holding a sheet of paper in front of him. Enclosed in circle. Color solid red.” Or perhaps a sort of Visio interface where we could drag across cartoon fragments of describable things and drop them into a rough sketch that the computer could compare against images in its database. This would require machine abstraction, but would be useful for identifying more than just band logos.

As with “query by humming” for music that sticks in your head, it’s a difficult problem computationally, and not as useful. My guess is we that won’t do it, not because we can’t, but because there’s no payoff. And thinking about it for a few minutes reminds me how really really far we still are from genuine “strong” AI.

In the meantime, does anybody know what the little running red guy represents?