|This is the talk page for discussing improvements to the Cdrtools article.
This is not a forum for general discussion of the article's subject.
|This article is of interest to the following WikiProjects:|
|The following Wikipedia contributors may be personally or professionally connected to the subject of the article. Relevant policies and guidelines may include conflict of interest, autobiography, and neutral point of view.|
|This talk page is automatically archived by lowercase sigmabot III. Any threads with no replies in 30 days may be automatically moved. Sections without timestamps are not archived.|
I've been looking for references that may cover how cdrtools handle SCSI device names. Below I'll post what I've found so that we can discuss what can be said from them. None of them addresses the controversy with Debian about how to best handle device names, but maybe we can use some of those to write a short description of how cdrtools does it, to showcase the different approaches (at least on the covered Linux distributions).
- Red Hat for dummies (2003).
- Fedora 8 Linux Bible (2008).
- Beginning Ubuntu Linux (2007) explains why man pages are not a good resource on which to base an encyclopedia.
- Red Hat Linux Networking and System Administration (2006).
- Linux System Administration mentions the ide-scsi emulation driver.
- The Design and Implementation of the FreeBSD Operating System explains that CAM is an ANSI standard, therefore the FreeBSD manual is not necessarily a reliable source for it - any content should be referenced to the original official published standard document.
The text you removed contained a pointer to the official CAM standard.
Giving many examples for Linux only does not seem to be a helpful idea as Linux is just one of many Operating Systems and one that is amongst the ones with the worst SCSI implementations.
There is e.g. no way to get the required (by the SCSI standard) 18 bytes of auto-sense data from Linux and there are several drivers that are competing for the same hardware device.
Together with the fact that there is no unified DMA driver implementation in various Linux drivers, several of the competing drivers do not support DMA at all or do not support a sufficient DMA blocksize. Given that all known DVD writers require DMA to be supported in order to work correctly, you may enforce cdrecord (libscg) to use one of the non-working of several competing drivers in case you specify a /dev/* based dev= parameter.
If you however use the CAM addresses or if you let cdrtools auto-select the single drive in a system, libscg auto-selects the best available driver from the list of cometing drivers for a specific hardware device. This is the backside of Linux - a backside that is hidden by libscg for the convenience of the users that follow the manual pages. Schily (talk) 14:50, 4 November 2015 (UTC)
---Device Name — Preceding unsigned comment added by Knutjb (talk • contribs) 09:58, 17 November 2015 (UTC) Are there just dead-end platform that cannot use devices name? Most modern os should be able to use devices name. Why need Cdrtools to use a different user interface than all other Unix programs, and this need to be addressed in this page in order to improve this page? — Preceding unsigned comment added by Knutjb (talk • contribs) 06:43, 17 November 2015 (UTC)
- Attacking platforms the way you do is not what people like to see on WP.
- Why don't you just read the documentation about device naming to understand why you are uninformed about UNIX device naming in general and SCSI device naming in special?
This information do not prove anything and do not exlpain why libscg can not use device name as cdrkit can. — Preceding unsigned comment added by 2001:464A:38F6:0:3A2C:4AFF:FE6E:C19 (talk) 13:14, 19 November 2015 (UTC)
- He just did: Linux has multiple drivers for SCSI devices. Each of these drivers has different capabilities and shortcomings, none of them is optimal for all applications Each driver has its own set of device files and there can be more than one device file for one device as more than one driver can be responsible for a device. If you specify a drive by device file name like
/dev/sr0(which is supported with the shortcomings explained henceforth), cdrecord is forced to use whatever driver supplies the device files. cdrecord also has no way to find out what driver supplied this device file (short of guessing), so it cannot apply fixes for the various driver quirks it knows about. Some of these drivers do not support all features required to burn optical media (such as DMA or access to sense data), which makes them unsuitable for cdrecord. Some of these drivers are known to silently corrupt and filter SCSI commands with no way to find out if that happened. This causes data loss and incorrectly burned discs in some situations. The libscg (SCSI library used by cdrecord) provides an abstraction that automatically chooses the best suited driver for the given task. This can only be done when provided with a three-part SCSI address as that's the only way to find all drivers that operate on a given SCSI device.
- What cdrkit (remember, it's a fork of cdrecord) did was simply removing the warning message when you attempt to specify a drive by device file name. cdrkit did not solve any of the shortcomings of this approach (because that's not possible) and did not fix any of the problems. The cdrkit maintainers ignorantly claim that specifying a drive by file name works “just fine,” apparently without having ever understood the problem. --FUZxxl (talk) 11:43, 20 November 2015 (UTC)
- Hi 2001:464A:38F6:0:3A2C:4AFF:FE6E:C19, you forgot to log in.....
- and you forgot to read what I did write before on the topic already.
- For further studies, you may like to check the documentation on special privileges needed to send SCSI commands and the documentation on the Linux SCSI kernel driver problems. Schily (talk) 14:29, 20 November 2015 (UTC)
- That is your personal biased opinion, not a reliable source. Linus Torvalds appears to disagree. Who has more clue about SCSI on Linux? Your Slowaris-Evangelism, or us on linux-scsi who know how to use the modern interfaces instead of claiming CAM is the one ring? — Preceding unsigned comment added by 220.127.116.11 (talk) 20:58, 20 November 2015 (UTC)
The page the documentation on the Linux SCSI kernel driver problems is outdate as it referees to an old version of Linux not 4.3, and the page do not provide citations to other reliable sources. 07:32, 21 November 2015 (UTC) — Preceding unsigned comment added by Knutjb (talk • contribs)
- In other words: you decided not to reply at all and instead give us a number without relation to the topic, so you seem to 100% endorse the statements. Schily (talk) 11:19, 21 November 2015 (UTC)
- @Knutjb: Didn't you promise not to start an edit war again? Schily (talk) 11:08, 30 November 2015 (UTC)
Recent vandalism / edit warring by User:Knutjb
|Conversation about an editor's behavior|
|The following discussion has been closed. Please do not modify it.|
This user repeatedly tries to add false claims to the Cdrtools article and similar articles.
All his claims are void because it is a verifyable fact that CD/DVD/BluRay burning requires more than the privileges of a normal user. In addition, this is confirmed by many bug reports in the bug tracking systems of various Linux distros that confirm that burning fails with programs like "wodim" when done as a normal user but works with the same programs under the otherwise same conditions when called as root.
Wodim and similar software has no concept of dealing with this problem, but cdrtools implement support for Solaris fine grained privileges and for Linux capabilities via setcap, so cdrtools currently is the only burning software that allows a non-root user to burn optical media without problem.
Did you "remove" (hide) your personal attack? I cannot see a personal attack as a personal attack is an attack against properties of a person that are not controllable by that person. A personal attack is definitely not a description of actions of a person done willingly.
If you don't use cdrtools, why do you use this article to place attacks against the Linux kernel? You are even uninformed about the fact that the code structure and presented function pointers for irrelevant fallback code. Anyway, your rants do not belong here, cdrtools do not suffer from the Linux defects you presented. Schily (talk) 10:24, 28 November 2015 (UTC)
Please read WP:CSECTION - criticism and commentary about a product is recommended to be presented with positive and negative reviews interspersed in chronological order - not with "bad" sections highlighted in their own section.
As a general note, Wikipedia should be written for the benefit of ordinary readers, who want to know what software does, not from the perspective of groups that want to score points for their interest group (cddl vs gpl). -- Callinus (talk) 18:47, 22 April 2016 (UTC)
New vandalism attacks against this article
A person from Norway that is well known for frequent vandalism attacks using IPs hits again.
This time, he claims that "modern" OS support SCSI transport via a file descriptor opened from a /dev/* based driver entry.
Provable fact is however that most OS do not support the non-standard /dev/* based interface for SCSI at all but rather only implement an interface that is identical or similar to the SCSI CAM standard interface.
Conclusion: There is somebody who likes do abuse Wikipedia to harm a OSS project with false claims. Software that ignores the SCSI CAM standard and that is based on SCSI transport on a filedescriptor opened from a /dev/* entry only, could only support 20% of the platforms that are supported by cdrecord and would need to ignore the vast majority of the installed computer base, as it could neither support MS Windows nor OSX.
The fact that cdrecord does not follow the wishes from people like our attacker, but rather honors existing standards results in the support for nearly any system in the world. Schily (talk) 10:05, 1 June 2016 (UTC)