Quote of the week
Quote of the week
Posted Feb 23, 2006 11:12 UTC (Thu) by Quazatron (guest, #4368)Parent article: Quote of the week
It would be interesting for the rest of us that don't follow the Linux kernel mailing list to know what is the issue with cdrecord.
I can deduce from past error messages in cdrecord that it is about the access to ide devices using scsi IDs or something like that, but I'd like to know what is the direction developers are taking in this matter.
I miss Zack Brown's KernelTraffic... :-(
Posted Feb 23, 2006 16:43 UTC (Thu)
by vmole (guest, #111)
[Link] (9 responses)
(Hoping this doesn't initiate a similar flamewar on LWN; Jon, feel free to delete this if you think it's out of line.)
Mr. Schilling apparently believes that Solaris methods for naming and accessing SCSI devices are the One True Way. Thus, you get names like "6,0,1" for your CD recorder, rather than the more Linux friendly names like /dev/hdb. (Yes, I know /dev/hdb is not a SCSI device. This is another issue). Also, the Linux generic SCSI interface is not equivalent to the Solaris generic SCSI interface. My (limited) understanding is that the Linux version doesn't provide all the info/capability that the Solaris version does; the LKML take is that the missing functionality is available in other ways.
Attempts to modify cdrecord to be more "Linux friendly" resulted in Mr. Schilling requiring that modified versions a) refer the user the modifier,
not Mr. Schilling (which is completely legitimate) and b) display warning messages implying that the modifications had "broken" cdrecord.
There have been additional minor wobbles along the way. You can search the LKML for threads involving Mr. Schilling and form your own opinions. My personal opinion is that there is plenty of blame to go around on both sides, but I'd give Mr. Schilling the overall prize...
Posted Feb 23, 2006 17:35 UTC (Thu)
by allesfresser (guest, #216)
[Link] (1 responses)
Posted Feb 27, 2006 3:55 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
Look at your friendly distribution, they will most probably have done the heavy listing to make it work reasonably.
Posted Feb 23, 2006 20:44 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (1 responses)
Personally, I think the flamewar is missing Luben Tuikov flaming Joerg over his incorrect assumptions about the possible forms of SCSI addresses, but he evidentally doesn't care about people who shouldn't be doing direct SCSI stuff at all doing it wrong.
Posted Feb 24, 2006 1:25 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
Absolutely. Since both believe the best way to win an argument is to insult the other guy into submission, it would have added flare.
But it also would have drawn out the thread a lot longer, because Luben believes the second best way to win an argument to repeat the same words over and over again, louder each time.
Posted Feb 24, 2006 22:38 UTC (Fri)
by elanthis (guest, #6227)
[Link] (2 responses)
His problem is that none of the device names are stable. If you change up hardware, you might end up with a different device name or SCSI id (unlike Solaris), so any scripts or config files the admin had would break.
Posted Feb 26, 2006 14:01 UTC (Sun)
by job (guest, #670)
[Link]
Linux device naming sucks badly. To me, devfs was promising, and I don't think anyone has quite picked up that ball for udev.
In the meantime, I've had to get used to the hd*/sd*-naming again. It's not that I can't change it, it's that the standard sucks. At least I have Logical Volumes to restore a little bit saneness, but that doesn't help with things such as dvd-burners and tapes.
Posted Feb 28, 2006 14:58 UTC (Tue)
by vmole (guest, #111)
[Link]
Um, no, it's not.
However, your implication that the only complaint Mr. Schilling has is about the instability of device names is misleading. As far as I can tell, that's not anywhere near the top of his list.
Let's take a specific example. Mr. Schilling contends that there's no way to enumerate all the devices that accept SCSI commands (which is not the same as SCSI devices), because not all such devices show up under '/dev/sg*'. The Linux developers contend that this easily solved by searching both '/dev/sg*' and '/dev/hd*'. Mr. Schilling doesn't want to do that, since that's not the way it works on that other OS. Since one can make cdrecord scan /dev/hd* with the right options, one must assume that Mr. Schilling's refusal to make that the default under Linux is more about stubborness than a technical issue.
The truly sad part about this is that it doesn't even really matter who is technically correct any more. Both sides have turned it into a pissing contest, and I can't see either side giving way.
Posted Feb 27, 2006 10:16 UTC (Mon)
by pr1268 (guest, #24648)
[Link] (1 responses)
If Mr. Schilling's cdrecord is so Linux-unfriendly, why isn't there any competition? Not to impugn Mr. Schilling's nice product (if only to abhor his tactics/behavior). Cdrecord is a wonderfully powerful utility which many eye-candy burning suites (XCDRoast, Nautilus, K3b etc.) depend on. So why not someone else write such a utility from scratch and release it under the GPL in order to get away from Mr. Schilling's "Linux is wrong" attitude? Every Linux distribution I know of which offers cd burning software includes cdrecord or cdrtools. We (the distros AND end-users) put up with Mr. Schilling's ranting because...??? I personally like having a choice. Thus I can choose to use KDE instead of GNOME. Or emacs instead of vi(m). Or Firefox instead of Konqueror. Or Linux instead of Windows. So seeing how I have to (get to) choose from 3 browsers, 4 PDF viewers, 3 Office Suites, and about 10 editors, how come I (we) only have one media writing application?
Posted Feb 28, 2006 13:53 UTC (Tue)
by vmole (guest, #111)
[Link]
Because it's *hard*. There have been several projects kicked off; all of them (except maybe libburn) have died, because not only do you have to understand a fairly complicated process, you have to compensate for a world of idiosyncratic or just plain broken hardware/firmware. This means you need access to all that hardware. Mr. Schilling gets this access, because he's put many years into this, and he makes things work. Newcomers simply aren't going to get new hardware sent to them until they've shown they'll actually do the work. Also, cdrecord runs on pretty much anything; a Linux only product is not going to get as much support from the hardware people.
Quote of the week
So is there a reliable source for a Linux-friendly modified version of cdrecord? It seems like someone would just fork the project to avoid all the partisan fighting (since it's such a useful utility), but maybe there's things I am not understanding...Quote of the week
Quote of the week
Just one more detail: the Linux way is actually to give the path of a device node (or symlink to a device node). While you can use /dev/hdb, you can also use /dev/cdrom. Except that cdrecord actually wants to talk to an SPI SCSI bus and send SCSI commands through it to the device, and therefore needs to get the device's SCSI bus address.Quote of the week
Quote of the week
I think the flamewar is missing Luben Tuikov flaming Joerg over his incorrect assumptions about the possible forms of SCSI addresses,
That is totally an inaccurate representation.Quote of the week
And he's completely right about that!Quote of the week
Quote of the week
Why not just write a new media writer program and GPL it?
Why not just write a new media writer program and GPL it?