The Substantially Similar Weblog

I just came across a transcript of a hearing in the Elektra v. Santangelo lawsuit, one of the Recording Industry file-sharing lawsuits that didn’t settle immediately. Santangelo is a single mom who is representing herself (thus far) in the lawsuit. She asserts that the file sharing perpetrator was not her or even her children, but rather one of her children’s friends. Moreover, the accused computer is no longer in her possession, making it quite difficult to research the Recording Industry’s claims.

The judge is quite sympathetic to Ms. Santangelo, and the transcript is worth reading:

MS. SANTANGELO: I realized when I looked at this that the downloads, I guess they call it Exhibit B, the screen name that this Kazaa was under doesn’t belong to anyone in my family. And that’s most likely why I was never notified by AOL or any of my — the companies that I have online service with that my children had downloaded anything. Apparently, it belongs to a friend of my son, who is now 14.

THE COURT: I see.

MS. SANTANGELO: And I didn’t know about it. And I really don’t know where to go from here. And so I’m a little dumbfounded by the whole thing.

THE COURT: Yes, I know. I keep saying I live in — although I’ve read the riot act to my own kids a hundred times —

MS. SANTANGELO: Oh, yeah, now I have.

THE COURT: — I live in perpetual fear that something I don’t know my kids are doing is going to come back and bite me in the butt. And the difference between you and me, Ms. Santangelo, if it happens to me, it will be in the headlines of the New York Post.

[…]

THE COURT: Okay. Well, I think it would be a really good idea for you to get a lawyer, because I would love to see a mom fighting one of these.

Below is a sampling of devices present at a small family gathering on Martha’s Vineyard. Not shown is the digital camera used to take this photo, as well as a number of chargers, USB cables, and devices including an iPod, a GPS mapping device, a Nintendo 64, more cell phones, and binoculars. (Well, okay, I don’t know if “binoculars” count as a device).

Are we going to look back on these days of endless device proliferation and laugh at our erstwhile profligacy, or are we going to sink further into the unholy morass? So far “all-in-one-devices” (cell phone/PDA/camera/MP3 player) have been kind of sucky, so I fear we are heading more toward the latter option.

I’ve just spent several days (on and off) trying to get an old PIII box up and running as a file server. Now that 250G drives are down to about $80, there’s no reason anyone should be concerned about disk space anymore. Anyway, the computer kept locking (hard) whenever I tried to mkfs the disk, regardless of the filesystem.

I tried several different drives; different controllers; moving the drives around to different positions (master/slave); different kernels; different BIOS settings; and some other things—but every time the machine just locked on “Writing inode table…”

So, as a final straw, I decided to drop down to 128M RAM from 384M. Then it worked fine. Up to 256M—still fine. 384M—hard crash.

Problem solved.

I hate this kind of thing, though. It’s painful manipulating the insides of these old boxes, and there’s precious little feedback about what’s going wrong. Maybe a more wizened hacker than I would have thought to check the memory first, but everything else appeared to be working fine which isn’t usually the case when you’ve got bad memory.

An old friend of mine called this kind of experience “tuition.” It costs a lot, but in the end you learn your lesson.

I just got my first cell phone text message spam. I’m glad to have finally arrived.

Get the latest version of salonify as a tarball (v0.82, released 9/15/05). Or read the changelog.

salonify is a free software web-based image gallery system written by Adam Rosi-Kessel in perl 5.8. Here is a sample installation with a few images. The Electronic Privacy Information Center serves photos with a stripped down version for their Observing Surveillance website. I hope other people will find it useful.

salonify generates thumbnails and a slideshow based on an entire directory hierarchy of images. The slideshow takes advantage of JavaScript features, but it works perfectly well with JavaScript turned off. The viewer can also choose from three image sizes and rotate images if they are not properly oriented. The presentation is reasonably consistent across all browsers; it even renders well in w3m–img. It also permits anybody looking at the images to add or modify the captions, turning the act of viewing the photos into more of a participatory activity. In future versions, the administrator will be able to selectively allow certain people to change captions or turn off the feature entirely (right now, the administrator can turn captioning on or off for everyone as desired).

Please email me with a link if you use salonify, and let me know whether I can list your site here.

salonify is listed on freshmeat.net.

There is an old Debian package for salonify, but it needs to be redone and updated for the latest version. For now, I would suggest using the tarball.

A more complete feature list and some more information will appear here some day. For now, get the tarball above, which includes some documentation. Also check out the sample installation.

Contents (full package):

• salonify, the main script (or download it)
• make_salonify, generates thumbnails and indexes (or download it)
• config, salonify configuration file
• fix_permissions, a quick hack to make your files writable by salonify
• README, main documentation file
• USAGE, tells you how to use salonify
• RCSHOWTO, a one-minute primer on RCS for editing your files manually
• BUGS, known bugs
• TODO, future improvements (help is welcome!)
• changelog, updates to salonify
• style.css, sample stylesheet
• up.png, the “up” icon for collapsible lists
• down.png, the “down” icon for collapsible lists
• right.png, the “right” icon for collapsible lists
• index.txt, sample HTML for header

Oops.

Apparently, the salonify package I released a few days ago worked fine for upgrades, but not new installations.

The new version should work better. Sorry for anyone who tried it once and gave up. :)

• tarball
• Sample Gallery

I’ve released salonify 0.80, my photo gallery script. Check out the sample installation and the changelog. Most of the improvements are on the index page: nested folders are now collapsible, and you can edit the descriptions of the folders through the web. Unfortunately, the Debian package is not quite up-to-snuff, so I would just recommend the tarball for the time being.

It seems to me there is a “free support gap” (that is, a gap in free support, not a support gap which is free), for users who are not beginners but are also not master developers—for example, myself. Just about any GNU/Linux question that arises that can be answered by a manpage or googling, I can figure out myself. But for trickier problems (for example, see my null oddity issue from yesterday), there doesn’t seem to be anywhere to go. Most of the helpful subscribers on debian-user are not much more knowledgeable than I am. I run my own linux-disciples list where I can answer most questions but seldom is there anyone to help out with my own questions. Similarly, there is a perl-beginners list, but no “perl-intermediate” or “perl-advanced” list. I’ve also not had much luck writing directly to developers with questions, outside of Debian.

Just a couple cases in point:

• Using File::Find to follow symlinks — posted to perl beginners, but no response:
  
  

  I’d like to use File::Find, or some alternative, to follow symlinks; regardless of whether the file/directory has already been traversed in some other location. In other words, if there I have directories x and y, and the file a is in x and symlinked into y, I want the find &wanted function to be called on file a in both x and y.

  Possible? Do I have to write my own find function from scratch? None of the follow-find=> options seem to accomplish what I want.

  I’ve also noticed that the &wanted function is not called even *once* in some cases where there are duplicate symlink files (i.e., it is not even called on the “real” file). Switching from find to finddepth seems to fix this, but I really don’t understand what’s going on. Any pointers?

  Update: after discussing off-line with a helpful blog reader, I’ve isolated the problem to the following directory structure:

   .: y/ ./y: 1/ 3/ a.jpg ./y/1: a.jpg -> (...full path...)/y/a.jpg ./y/3: 1 -> ../1 

  In other words, a.jpg is in y/. There are two symlinks to that file, one directly — y/1/a.jpg ; the other indirectly, since y/3 contains a symlink to y/1. Perl’s find function only traverses the second instance, not the first. I would like it to do both.

• growisofs problems — write fails frequently — there doesn’t seem to be any canonical mailing list or support for growisofs, so users are directed to Debian’s cdwrite list:
  
  

  I’m using growisofs from dvd+rw-tools 5.21.4.10.8-1 from Debian Sarge on an IBM Thinkpad X40 with a DVD writer that reports itself as: “MATSHITADVD-RAM UJ-812.”

  Sometimes I will try 10 or 15 times in a row to burn a DVD and it fails each time with something like:

  :-[ WRITE@LBA=1c970h failed with SK=4h/ASC=03h/ACQ=00h]: Input/output error
  builtin_dd: 117104*2KB out @ average 1.0x1385KBps
  :-( write failed: Input/output error
  /dev/dvd: flushing cache
  /dev/dvd: updating RMA
  /dev/dvd: closing disc
  :-[ CLOSE DISC failed with SK=5h/ASC=72h/ACQ=04h]: Input/output error
  /dev/dvd: reloading tray

  In this example, I had forced the write speed to 1 (it defaults to 2) to see if it makes any difference—it didn’t.

  I would suspect bad media, except that it seems to consistently fail in exactly the same place for a given DVD image to burn. For example, this one keeps failing at 6.13% done. Another failed repeatedly at 47.47%.

  Any ideas what’s going on? Troubleshooting tips? I hate to throw away so many DVDs.

Thus, I throw myself on the mercy of my readers, in particular the Planet Debian crowd. I’ve actually had more luck in the past posting questions to my blog and letting people come to me, rather than seeking out an appropriate forum to ask the question. There seems to something backwards about that.

Inexplicable oddity of the day: X was hanging after log in. It looked like it got stuck on xrdb.

Inexplicable solution: /dev/null was not readable. (Not only do I not know why /dev/null being unreadable caused the problem, I also don’t know why /dev/null lost its world-readable bit).

There’s a first time for everything, I guess, and this is the first time /dev/null has been the crucial point in fixing my system.

I’m not sure I’d ever be able to explain how to diagnose and fix problems like this to newbies.