.comment: Coming Kicking and Screaming Into Digital Photography - page 2
Making PicturesUntil last week, my lone experience with CD burners had been watching a friend, who knows his way around things Windows pretty well, destroy a stack of CD-Rs before getting one properly written -- and at that time, they were three or four bucks apiece. On the other hand, I know people who burn CDs regularly and who either have no difficulty or are concealing a high failure rate.
In any case, a CD burner seemed the logical accessory to my new digital camera. Knowing nothing about the subject, I poked around online, emailed a few friends, and settled on Iomega's ATAPI drive because it apparently would work and because at $70 it was cheap. Ever the optimist in technical matters, I also got a whole bunch of CD-Rs with the extra-thin jewel boxes -- CDs without cases are potential disasters.
XCDRoast is a nice, graphical front end to cdrecord, so before I did anything else I had to get and build that package. The docs suggested that cdrecord would be difficult to compile, but it wasn't. Then came XCDRoast. The compile blew up because my Tk now carried unresolved symbols (my guess is that this is due to its having been compiled against glibc-2.1, while I'm now running 2.2), so I got and built Tcl and Tk, and then the XCDRoast compile worked just fine. But when I fired it up, I got a world of errors: First, that I had to be root to run it, then that I had no SCSI support (which I didn't), then that I hadn't configured it (which, of course, I hadn't).
The cdrecord docs are a little obscure, mostly because they haven't been updated since about Linux-2.0.36 but also because the part dealing with ATAPI CD burners is a copy of an email discussion on the subject. From these sparse documents I gleaned that ATAPI CD burners, though living on an IDE channel, are actually SCSI devices. This means that the kernel must not have ATAPI CD support, but must have generic SCSI support, after which one may go back and choose IDE-SCSI emulation. (There was discussion of getting both a regular ATAPI CD reader and an ATAPI/IDE/SCSI CD writer to live together, though apparently not on the same channel, via an option in lilo.conf. I did not indulge in this, mainly because I don't have a spare IDE channel to play with but, too, because I don't plan to copy CDs. And it may well be that more recent kernels obviate the need for these machinations.)
So I burned a new kernel using the recipe hinted at in the docs. And, wonder of wonders, it worked!
I now indulged in a security risk, making XCDRoast SUID (as root, chmod u+s /usr/X11R6/bin/xcdroast). And my long-ago experience watching my friend try to write to CD had left me with the lone useful memory that success is unlikely unless an image of the proposed CD is made on the hard drive before the burn is attempted. The mkisofs program (which comes with cdrecord) does this; XCDRoast is not entirely intuitive in this regard, but after looking around it for five minutes or so I realized that I wanted to make a directory, ~/cdimage, where this image would be built. XCDRoast had autodetected my CD burner, which seemed great at the time but which only postponed a little problem I'll get to in a minute.
I'd already copied the wedding pictures to a directory under my home directory. (The Sony camera produces index pictures with a .411 extension that are useful only to itself, so I'd not copied them over; nor did I copy the little html file that it makes for each floppy, because the little html file is mostly useless, in that it has the same name on each floppy, so unless you're putting each floppy into a subdirectory of its own you lose all but the last one. And in any case it merely lists the images by filename -- it would be cool if it thumbnailed 'em, using those otherwise wasted .411 files -- so the convenience to those who would view by browser is minimal.) I pointed XCDRoast to that directory, asked it to calculate the size of the image -- a mere 11 megs -- and then to create the image, which took no time. I then told it to burn the CD. This took 49 seconds for the burn and three or four minutes for what it calls "fixating."
There had been one tiny concern -- the CD file format. It's all iso9660, of course, but there are various extensions that can be employed to make use of long filenames. If one is writing for use by a Windows machine (and, I suppose, if one has compiled support into the kernel, but this is just a guess; it may be included in cdrecord), the choice is the Joliet extensions. If one is making a backup of Linux stuff, the RockRidge extensions are the answer. In that the Mavica saves its images in 8.3 files, I chickened out and chose MS-DOS, which anything will read.
Soon enough I had my burned CD. There is a "verify" option in XCDRoast, and I used it. It reported that everything had been transferred successfully. Problem was, I couldn't mount the CD!
As any Linux user who has spent time at the command prompt knows, Linux error messages are not especially informative. In that XCDRoast had found my CD drive without any trouble, I'd hoped that the system in general was aware of it. My hopes were dashed, but due to the error message -- that the filesystem type must be specified -- when I tried to mount /dev/cdrom (and the subsequent error message, to the effect that I was trying to mount a hard drive partition, not a CD, when I specified the filesystem type) -- it took a (very) little playing around to realize that I needed to delete the /dev/cdrom symlink (to /dev/hdc) and replace it with one pointing to /dev/scd0. Now I could mount the CD and look at the pictures.
My final test was on a different machine, a notebook running OS/2. I slipped in the CD, and there were all the pictures. Cool.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.