X-CD-Roast is Roasting

[swestrup]

It took something like four hours of work, but I've finally gotten XCDRoast working on Webigail again. So now I can once more make backup DVDs.

XCDRoast, it turns out, relies on a command line program called cdrecord, maintained by someone else. It used to have a variant called cdrecord-ProDVD that could record DVDs. In order to use the free version, you needed to register for a free time-limited DVD key, which I did.

Eventually, of course, it ran out. Only, you can't get the keys any more, because the DVD writing feature is now just part of the newest version of cdrecord, now called cdrtools.

Fine, I would install the latest version, but currently RPM is broken on Webigail (something else I will need to spend many (more) hours fixing sometime). So, I had to download the source and compile it.

It needed a version of gdk-pixbuf installed. Now, I had that package installed, but it didn't have some of the required files for the compilation, so I downloaded its source, and compiled and installed it. That, at least, went off without a hitch. (although with RPM broken, I can't record the fact I've overwritten an installed RPM...)

Then I compiled the cdrtools, and installed them, only to discover they installed to /opt/schily/bin, not /usr/bin where the current versions are. (Of course, I ended up having to scan the whole file system to figure out where the damn files were installed to.)  If there were any way to tell it to install elsewhere, it wasn't in the docs, and cdrtools doesn't use configure for its configurations either. Then again, the docs haven't really been updated since 2004. There have been many revisions of the code since then, but version numbers have only incremented from 2.01.01alpha1 to 2.01.01alpha23. Am I the only one who thinks that's insane?

Okay, so I write a script to find all files in /usr/bin that have counterparts in /opt/schily/bin, back them up, and create soft-links to the new versions. This, I imagine, is minimally disruptive.

Then I try to run xcdroast, and discover that this version isn't compatible with the latest cdrecord. I have to download the source for that too, and then patch it to deal with the latest latest updates that broke compatibility.

Even then, xcdroast would only run if I invoked it as root (because it seems kernel 2.6 broke user space writing of DVDs) and added a '-n' parameter to tell it not to check the version number of cdrecord because it can't parse version numbers like 2.01.01alpha23. (apparently the previous version had been patched to produce a different format of version number...)

And so, after all that, I managed to burn a DVD, although I did have to grovel around in /dev to find out what device name to use.

Is it any wonder that I keep saying Linux isn't ready for prime time yet?

Comments

[pphaneuf.livejournal.com]

Writing of DVDs has always been in user-space on just about every Unixy system I've ever seen, Linux 2.6 included. In fact, it's even lighter on kernel-space wonkiness, because nowadays the SCSI emulation for IDE drives is deprecated (ah, good times!).

Combined with your mention of groveling in /dev, I'd claim plain old insufficient permissions on the said device.

Or your previous cdrecord's packager was nuts and installed it SUID.

That said, I know there's hope for Unix in general: on my XNU system, I can burn an ISO image with a simple drag-and-drop, while azrhey couldn't figure out at all how to do it on her Windows XP. She eventually managed to download some sketchy software in order to do it, but there might have been a CD or two burned with a single ISO file at their root in the process. ;-)

[swestrup]

The DVD burner software needs to know the name of my DVD drive. It gives no indication of how I'm supposed to figure that out. Looking in /dev was the only way to find out that I could see, and I was just lucky that there was a /dev/cdrom and that it pointed to the right thing.

[pphaneuf.livejournal.com]

Some people are just too pedantic for their own good (referring to the authors of xcdroast here).

See, they could have their program glance at /proc/ide/*/*/media, pick out the "cdrom" ones, and then give them a choice between those, probably also showing the content of /proc/ide/*/*/model as part of the description, to help the user pick. I mean, really. There are some SCSI versions of those, of course, but they're writing a GUI program to make this easy, sorry, but there is some work involved, of course.

But they'll say "no, that's not portable, we can't do that!". Never mind that most of the underlying programs are already extremely sensitive to platform differences, they could also enable those "easy features" only on supporting platforms. Say, having a function to generate the list of devices, pick one at compile time, fill a combo box with it, and let users of unsupported platforms just not have available choices, forcing them to use the text field (which would be handy on supported platforms too, for those cases where there's something weird).

For goodness sake's, bloody Ethereal is more user-friendly, and it's a freakin' protocol analyzer!

[sps.livejournal.com]

See, that's why we don't want Linux to be ‘ready for prime time’: install scripts should be written in sh, so you can read them! ;)

Seriously, though

[sps.livejournal.com]

‘Prime time’ means installing only through a gui-based package installer, and accepting automatic updates. I don't think it is reasonable for someone who does any manual sysadmin to complain that the system is not usable by their granny, because the granny's eye view is ‘does more work out of the box, on my income, with this system or with that system?’

So the ‘ready for prime time’ question actually reduces to whether the system adequately prevents you from getting a root shell, and if so, whether it can run for the lifetime of the hardware without the graphic install tool breaking.

So I guess I'm arguing it's a race between YaST2 (let's say) and Google Updater (the closest thing I've yet seen to a Windows install tool). And Lord they both suck.

Summary: Linux installers give way too much of the wrong information; Windows installers, for practical purposes, do not exist.

Re: Seriously, though

[swestrup]

In this particular instance the problem stemmed from the fact that cdrecord runs on six dozen Unix variants including AIX, Sun OS, BSD and Linux. They all store things in different places, and each Linux distro has different ideas of where those places might be.

What would have made life MUCH easier would have been an introspection tool that would tell me what the placement philosophy of my particular distribution was, and some easy way to know what parameters had been used to generate the versions that were currently installed.

Re: Seriously, though

[pphaneuf.livejournal.com]

YaST2 got worse, recently, from what I could see. Ow.

But on the other hand, the Ubuntu people seems to be doing good work at making APT easier to use. If I'd have to run a box for a very long time, Debian or Ubuntu would be my choice, because of APT, I'd say.

Re: Seriously, though

[sps.livejournal.com]

Yeah. Suse just confused itself into the ground. I'd be recommending Ubuntu to my granny, too; I just happened to be sitting at a Suse.

Re: Seriously, though

[pphaneuf.livejournal.com]

Yeah, used to as well, with a trusty 9.2, but 10.x, whew, what a circus...

Re: Seriously, though

[pphaneuf.livejournal.com]

Generalizing a bit, also, I'd point out Mac OS X is a Unix derivative as well, and a fair number of people would probably grant it "ready for prime time" status.

And it pulls this off without preventing you from having a root shell (well, okay, they require the use of "sudo", but still).

[hendrikboom.livejournal.com]

Which Linux?

Re: Seriously, though

[swestrup]

Mandriva.

Re: Seriously, though

[pphaneuf.livejournal.com]

Oh, the French one.

A few of my co-workers are ex-Mandriva, and, uh, I'd steer clear. ;-)

Re: Seriously, though

[swestrup]

Too late now! It would be a big pain to switch to some other distro at this point, as that box is now running my web and mail servers.

Re: Seriously, though

[pphaneuf.livejournal.com]

Good luck, then!

[peaceful-dragon.livejournal.com]

I'll second pphaneuf on that and try Ubuntu. APT is great.

[sfllaw.livejournal.com]

I don't want to be pushing for a particular distribution as I'm biased, but it looks like your box is a little more broken than it ought to be. Surely having a modern system would prevent much pain.