iNODE

I’ve been using the EeePC for two weeks now and it seems a good time to register a few impressions and document the four or five tweaks I’ve made to improve the overall experience.

Thanks to the weight and the form factor, I’m finding that I do actually carry this thing around with me. The wireless has worked flawlessly (both on Mason’s wireless network and my home LinkSys) and battery life seems to run about two and a half hours. I’ve had good success reading my email and OpenOffice works just fine for handling the various Word and Excel attachments (BTW, if you spend most of your time in Excel…don’t bother with one of these).

In short I had a list of tasks I hoped this machine could perform and so far it’s handled all of them.

Read more »

A month or so ago I wrote a note about switching to a smaller (even if less powerful) laptop. I now realize that was just one point on a trendline.

Went to the Mason vs. William and Mary basketball game a few weeks ago and while walking around the arena, I bumped into a friend from Mason’s networking staff. He was hunched over, typing away on some sort sort of little black box.

“It’s an EEEPC,” he laughed, “battery weighs more than the computer. Runs Linux.”

Sold me. Added it to my wish list.

Last Thursday I learned that I needed to order a computer for a staff member who’s about to start a text mining project. Aha! Here was an opportunity to save the library some money and continue my pursuit of the small.I gave him the MacBook Pro I’ve used off and on around the office for the past year and ordered myself a replacement device: a 4GB EEEPC. It arrived earlier this week.

This thing really is amazing. Just under two pounds (and under $400) it has roughly the footprint of a DVD case or small paperback. Sure, the little keyboard is cramped and the 7″ screen is pretty small but there’s still a lot here to like:

built-in wireless (802.11 b/g); 4GB SSD drive, SDHC card slot for additional storage; 56K modem; 10/100 Ethernet, 800×600 color video; 3 USB jacks; VGA-out; 2.5-3 hour battery life; 1GB memory and 10-15 second boot times.

The 4GB (on the SSD drive) sounds too small, right? Well, based on a few days use, I’m not so sure it is. As we move closer to pure cloud computing (where your documents and other files live somewhere on the net) four GB is probably sufficient for a second or third computer (particularly when that storage can be augmented with SDHC cards or USB thumbdrives).

Running a derivative of Xandros Linux, it doesn’t take much work to replace the “One Laptop Per Child” sort of simple icon interface that greets you on first bootup with a full-featured KDE desktop. Tweak a couple of system files to resize fonts and add a couple more software repositories and in no time at all you have a very functional (and toteable) travel computer.

I’m finding it very useful for day-to-day sysadmin work. I can quickly monitor one of our headless machines in the server room by jacking an RJ-45 cable into one of the hubs and ssh’ing into the server. It also makes it simple to troubleshoot wireless issues throughout the libraries. Not my sort of thing but it would also be great for notetaking/minutes at meetings (you’d tend to record only the important stuff—gets painful if you have to type too much). I’m doing this post on the EEE and I’m beginning to feel it.

Basic finding: When it weighs less than 2 pounds and boots almost instantly, it’s easy to find reasons to carry this machine around with you.

The EeeUser wiki is a great place for more information (and tweaking guidance).

Until a few weeks ago, there were basically two programs that could be used to do a screencast on a Mac: Snapz Pro X from Ambrosia Software and iShowU from shinywhitebox. Now there’s a third and it takes the genre to a completely new level.

Screenflow

Screenflow bills itself as the “Professional Screencasting Studio” and based on the hour or so I’ve spent with the program I completely agree. As you’ll see from the demo screencast featured prominently on the product site (http://www.varasoftware.com/products/screenflow/), it works pretty much like iMovie (pre iLife ‘08) and offers a number of new features that I haven’t seen in a screen capture program for any platform (yes, Camtasia users are going to be jealous).

One feature I really like is the way Screenflow will record not only your screen and an accompanying audio track, but also a video track from your webcam or iSight so you can personalize the delivery. As you’ll see in the demo, you have incredible control over the finished screencast in post-production (come to think of it, the idea of post-production is also something of a new concept for screencasting).

Some might consider the license fee expensive ($84.99 for educational affiliates, $99.00 for everyone else) but I assume if you really count on screencasting to do your job, the price to get a tool of this caliber, well, it’s a bargain.

Note: Screenflow requires Mac OS X Leopard and a Quartz Extreme capable graphics card.

http://www.varasoftware.com/products/screenflow/

I continue thinking about how to exploit a user-friendly tool like Omeka to enable library staff to build inviting exhibitions of digital objects—more particularly, those stored in our MARS (DSpace) repository.

We already stretch DSpace a bit in the sense that we use it both for the sorts of e-publishing things common to most IR’s but also as a place to archive digital objects that may have nothing at all to do with scholarly communication (e.g., digital images from our Special Collections area, a few web sites, various data files, audio files, source code archives and so on).

This dual-use of DSpace was a conscious decision from the start—we didn’t think the open access function would generate sufficient use or interest in the system quickly enough to give us an immediate and unmistakable win. By including a bit of digital archiving along the way the library took an active role in building content and made MARS a much more interesting destination. One of these days the open access activity on campus will catch up with the support infrastructure we’re building but there’s clearly value in keeping those disk drives spinning with related tasks until that happens. But I digress…

We also use DSpace as the “front door” for some of these collections but it’s far from an optimal solution. While we have an attractive local instance of DSpace (thanks to Dorothea for the initial CSS work) there just isn’t that much you can do to make DSpace look like anything more than what it is: a list-centric online catalog of digital objects.

To use a metaphor from the world of art, DSpace gives us an unadorned catalogue raisonneé and I’d like to be able to offer visually interesting exhibition catalogs.

Having this ability would enable us to focus our DSpace installation on those things it does well (bitstream ambivalence, an OAI source for Google Scholar, OAIster and similar services, a standards-compliant metadata repository, a single store to back up and so on) and use other tools to enhance the discovery and utility of some of the objects stored therein.

I think I may have figured out a strategy of sorts and post it here in hopes of getting feedback (and offers of assistance if it strikes the right note with any reader).

A year or so ago I downloaded a copy of Harvester from the Public Knowledge Project at Simon Fraser University in western Canada. At the time I used their open source product to build a “union” catalog of several local DSpace installations including our own MARS system. It worked well and I still log in and do an update “crawl” of the contributing systems from time to time.

Now I’m thinking we could perhaps modify the open-source “harvest.php” code that ships with Harvester2 to pull metadata from our MARS system via the OAI protocol and use it to populate an Omeka database. Yes, we could just write a Postgres -> MySQL conversion utility to capture our DSpace metadata (which lives in a Postgres database) but I think an OAI import module might prove more useful to the Omeka community (after all, there are DSpace sites that don’t use Postgres and OAI sources that don’t use DSpace).

Once an Omeka database of items was built using the DSpace metadata, non-technical staff could log into Omeka and build exhibits. While the metadata imported into Omeka would form the basis of the exhibition, when the time came to display a particular digital object, we’d have Omeka slipstream the bits from our DSpace repository (following the handle back to DSpace for the appropriate item).

I can think of a few gotchas right off the bat:

• DSpace handles don’t resolve to a particular bitstream (although it is possible to code an algorithm that moves from handle URL to bitstream URL on a given server). Figuring out the “appropriate” bitstream from an object that contains multiple streams is a problem we’ll have to deal with.
• It will probably be necessary to store at least a thumbnail of images in the Omeka database—not only to reduce network traffic on browse pages but also to simplify the task of staff selecting items to use in a particular exhibition.
• We’d have to figure out a mechanism to allow subsequent updating of the Omeka database to reflect changes in our DSpace installation (additions, edits, etc.).

Taking the easy way out, I’ll just assume these are the sorts of optimizations we’ll tackle once we know whether the basic functionality can be achieved. We’re now at the “delve deeper into the harvest.php code from PKP” and I’ll report back when we have something of wider interest…