Accustomed

I heard a story on NPR on "smart elevators" last year. The premise is simple: instead of getting into an elevator and then selecting your floor, you first select your floor and are then directed to the elevator that will get you to your floor the fastest. There was a quote from a business executive used to riding in smart elevators about how dysfunctional he is when he steps into a normal elevator: he forgets to press the button for his desired floor and instead just stands there, sometimes riding for awhile before he remembers that he needs to take action. I remember very clearly thinking what an idiot this guy must be to forget how to operate something so simple as an elevator.

And then, the other day, I was out somewhere and had just used the bathroom. I soaped up my hands at the sink and then waved my hands under the faucet several times, waiting for the water to turn on. You see, at work we have motion-activated water faucets. I've become so accustomed to the automatic faucets that I was complete unable to operate a simple sink lever. Eventually I realized what an idiot I was, and turned the lever manually to activate the water so that I could wash my hands. I then stood there staring at the sink, wondering why the water didn't shut off. Finally I remembered that I needed to operate the lever to stop the water.

I always find it funny when a restroom has an automated sink, but a manual towel dispenser. Sometimes it's the other way around. Sometimes there's an automatic soap dispenser while everything else is manual! Either way, all the sanitary savings of the one are completely offset by the other(s). And it's all moot because invariably the trashcan is overflowing with soppy wet paper towels because no one bothers to actually get the towels into the trashcan (and why do men feel compelled to use ten sheets of paper towels just to dry their hands?!). Or, just as often, the trash isn't emptied with any regularity. I've complained about toilets before, though, so there's no need to belabor that issue.

I'm all for automation, and intelligently using technology to make our lives simpler. It's important to remember, though, that technology adoption doesn't occur uniformly across the world. So don't forget how to use a faucet or an elevator, or you'll look like an idiot like me!

Google Reader Trends

I just noticed that Google Reader has a "trends" link. I don't recall seeing that before; though I admit that I don't often look at the interface for Google Reader, as I'm too focused on the news content it is displaying to me.

From your 83 subscriptions, over the last 30 days you read 4,730 items

I haven't starred, shared, or emailed any items. I'm not much for social networking functionality, which explains why I haven't shared or emailed anything.

What's really interesting in the trends is both my personal reading habits, and the posting habits of the sites I read. I read more items between 7 and 9 AM than at any other time through the day. This makes sense, since all the news that has accumulated overnight is waiting for me. And for some reason, I read more items on Wednesdays than any other day of the week.

BoingBoing and Slashdot both post about 20 items per day. The feed for my Flickr contacts is running around 15 items per day, while the Flickr feed for the tag "skippy" is about five items per day.

Ultimately, all of these stats are completely meaningless, and not particularly useful to me. I don't really care how often sites publish, or what percentage of their posts I read, or when I read news the most. I care about reading the news, not reading metadata plotting trends about me reading the news. That said, I'm now interested in subscribing to a variety of feeds to which I wouldn't normally subscribe, just to see what sort of trends might develop.

A Little DAAP Will Do Ya

I've been eyeing the Linksys NSLU2 for a little while, contemplating its use as a file server for the house. I'm attracted to the (extremely!) small form factor, the low power consumption, and the fact that Debian is fully supported on it (see Debian on the Linksys NSLU2). I'm not keen on actually buying it, though, especially since I still own a Shuttle XPS small form factor PC. I'm also worried that the NSLU2 will ultimately prove to be underpowered for my goals.

I want a low-profile file server for two basic reasons:

  1. I want to be able to keep convenient, centralized backups of the various computers in the house
  2. I want a repository of music files accessible to all computers in the house

The MVix MX-760HD can play music files but its support for playlists is extremely lacking, and it doesn't expose the collection of music to other devices on the network. So I want to move all the music from the MVix to somewhere else. The MVix could still access the music from the network server, though I doubt I'd use it much for audio playback. (Incidentally, I'm still delighted with the MVix: it's been a great addition to our entertainment center: not having to shuffle DVDs to watch some of our favorite programming is a real treat.)

Having the music files in a central location is only one piece of the solution, though. I'd like to allow all our laptops to listen to different playlists in different rooms at the same time. I suppose we could all mount a network share, and simply have our local music clients parse the share contents. That's not quite the solution I'd like to pursue, though.

I looked at the SlimServer, the script that powers the Slim Devices product line. It looks neat, and should be easy to use. There is documentation for the SlimServer on the OpenSlug firmware, so it ought to work on Debian-on-NSLU2 just as well. The comments on that page, and in some Google searches for "nslu2 slimserver" made me a little concerned about whether the NSLU2 would be up to the task of serving media. We have 8000+ MP3 files, with more CDs yet to rip. A slow media solution is probably worse than the current configuration.

A little more investigation suggested a DAAP solution, the protocol used by iTunes. There is a iTunes Server for NSLU2, which uses the mt-daap package. There is a mt-daapd package for Debian, and I quickly found a Linux.com article about mt-daapd. Since Carina has been using iTunes of late to manage and play her media, the mt-daapd solution seemed like a good choice: she could move all her media to the file server, and continue to access all of it through her preferred client. I was pleased to learn that RhythmBox, the default GNOME media player, supports DAAP, too!

So last night I installed Debian Etch onto my Shuttle XPS. I executed apt-get install mt-daapd, and was quite surprised to see "Shuttle" show up in the sidebar of RhythmBox! I moved the collection of music from the MVix to the Shuttle, and restarted the mt-daapd process, which triggered it to re-index the music collection. This took several minutes on the Shuttle -- I can only imagine it would take considerably longer on the NSLU2. Clicking "Shuttle" in my RhythmBox client showed me that more than 8,000 songs were available!

I think my worries about the speed of the NSLU2 are largely misplaced: (re-)indexing the music collection isn't an everyday occurrence, so it's not something that will hamper every day music playing. If you're using the NSLU2 with mt-daapd, do please share your experiences!

QOTD: most

Mark Pilgrim:

less is better than more, but most is better than both.

Hooray for UNIX jokes!

Real World Example

We installed a SonicWall 5060 at work last week. We had some trouble at first, due to miscommunication. We wanted a transparent bridging firewall -- something that the 5060 can do. Transparent bridging is a new feature of the SonicWall firmware, though, so the installation engineer wasn't familiar with it. When we spoke about "transparent bridging", he thought we were talking about SonicWall's "layer 3 transparent firewall" configuration.

The installation engineer used his cellular phone to call his senior technician, while I called OSU's main network guy. The argument that ensued -- using my phone as the medium -- was interesting, and not entirely pleasant. We ultimately un-did what we had done so far, reverting back to our original configuration without the SonicWall. That evening, the installation engineer educated himself on the layer 2 bridge capability of the SonicWall. By lunch time the following day, the firewall was up and running without incident.

Yesterday a systems engineer in another college, with whom I sometimes eat lunch, asked if he could see the firewall and its management interface. I was only too happy to oblige. After a quick inspection of the physical box, we sat down in my office to walk through the web-based administrative tool. I showed the basics of how to configure the firewall interfaces, how to create groups of objects, and how to apply firewall rules to those groups.

Trying to show off a little, I said "And here's where we can see a snapshot of current Internet usage... See, we can see all traffic by protocol, or all traffic by destination address to see which sites are super popular, or even all traffic by source address. For example, this computer has ... wow ... 104 open connections to other systems on the Internet..." I shifted gears and identified that the system in question was busily serving BitTorrent streams. Additional investigation revealed that the machine had enough open ports as to cause alarm, and to merit investigation.

My colleague followed along as my boss and I set out to evaluate the situation, after identifying the location of this system. It turned out to be (mostly) uninteresting, and was dealt with quickly. The offender wasn't likely to attract the attention of the MPAA or RIAA given what was being shared, but nonetheless it wasn't an appropriate use of the department network.

My colleague remarked "It looks like this firewall is causing you work, not alleviating it!" And while that's true to a degree, prior to the installation of this firewall we had no meaningful way to identify this sort of thing until the University's security group would alert us to a problem. By then, of course, it was usually too late.

← Previous  1 2 3 4  14 Next →

About

Brewer philosopher.

User