Talk:Cdrtools/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Change log table

I've restored the removal of the change log table. In this particular article where notability is tied to the licensing changes over the project's history, having a timeline of those changes is particularly useful for understanding the topic. I'm not opposed to make the table tighter, but an overview of the releases that impacted the users of this software is a good thing to have here. Diego (talk) 11:03, 13 June 2014 (UTC)

Instead of listing all versions, it should be focused on the most essential features. I believe it should list 1. initial version, 2. license change / fork 3. first version with DVD writing support 4. first version with blue-ray support 5. latest version. The focus should be on such milestone features, not on the version numbers. --Chire (talk) 12:09, 13 June 2014 (UTC)

That sounds OK. The change of name at version 1.10a01 should also appear. The rest of intermediate versions could be represented as a range (for example versions 1.01-1.07 from dates such to such). Diego (talk) 12:41, 13 June 2014 (UTC)

Trimming the article

I started to trim down the article to what really belongs to an online encyclopedia. Please don't add everything back. The article was an unreadable mess. Instead, consider if there is further cruft that can be removed. Think of the audience - this isn't a report for a lawyer or court listing every fact, this is meant for everyday readers that wonder why cdrtools is not included in major distributions ... --94.216.209.108 (talk) 11:58, 16 November 2014 (UTC)

Also, we should add archiving to this disgraceful talk page... 94.216.209.108 (talk) 13:42, 16 November 2014 (UTC)

Preserved content

Per WP:PRESERVE, I'm adding links to the removed sections, for reference to potential future researchers on the topic. Diego (talk) 23:11, 16 November 2014 (UTC)

• Timeline of licensing disagreement - links to forums where major players expressed their opinions
• cdrtools versus cdrkit versus libburnia - feature comparisons of the three software packs

False claims about alleged license problems

Hi Dsimic, nice to see that you discovered that there is a false claim written by OSS hostile people.

As there is no license problem in the original cdrtools, no distro needs to fear problems when distributing binary versions of the original cdrtools.

If you have a closer look, you will see that every distro that asked a specialized lawyer about potential problems is now shipping the original cdrtools. This includes Sun Microsystems, Oracle and SuSE. BTW: the lawyer from SuSE knows common law as well as the modern Code Napoleon based law. He is from Ireland and studied law in Ireland and Germany. The distros that still do not ship the original cdrtools did never ask a lawyer and refuse to have a fact based discussion.

It may help to know that at least one of the people who spend their time to introduce false claims in Wikipedia also tried to blackmail SuSE (to no avail ;-) after they published their decision to distribute the original cdrtools. I have logs that allow to prove this...

If you like to understand what happened, you should know the easy to prove time line that disproves the claims from Debian:

• May 2004, Debian started a buggy fork from the original cdrtools.
• At the same time, Debian started a defamation campaign against cdrtools.
• December 2004, asking Debian to replace the hostile packetizer (newly introduced in early 2004) did not help
• Summer 2005, Debian started to claim that cdrecord changed it's license, but not a single line from the cdrecord code changed the license yet.
• May 2006, in defense of the attacks from Debian, the license of cdrecord, cdda2wav and readcd has been changed to CDDL, mkisofs remains 100% GPL.
• September 2006, Debian still claims "GPL problems" with cdrecord even though the GPL is not affected at all anymore.
• September 2006, Debian was instructed to rename their defective fork from May 2004.
• September 2006, Debian renamed their fork and started to claim they just created it. More than 100 documented bugs from the May 2004 fork remain.
• May 2007, All significant activities in the Debian fork stop. Only typo corrections appeared since then.

Please try to match this with the alleged timeline that is seen in the WP article. Schily (talk) 13:48, 30 June 2015 (UTC)

Hello! Well, what I've noticed is that Slackware provides precompiled packages, so the related bullet point should be modified. Speaking of the licensing and related issues, please don't get me wrong but I always try to stay away from them, especially when Debian is involved. Out of curiousity, what were the actual reasons for cdrtools' change in its licensing model? I mean, how does actually CDDL provide protection you're referring to? — Dsimic (talk | contribs) 14:20, 30 June 2015 (UTC)

After I was attacked and got no help, I took some time to find a way what I could do to disprove the claims from the attacks. I had a discussion with Heiko Eißfeldt (long before that incident) about a new license that gives more freedom and that allows to reuse parts of the code from my work for other OSS work, regardless of the license they use. Heiko promised me to donate his (at that time closed source) Reed-Solomon decoder, in case I would use a freer license for cdrtools. After the attacks started, I had also many discussions with FreeBSD people about constraints from licensing. So changing the license was something that was already under discussion. As you see from my timeline, the license change successfully verified that the Debian people behind these attacks did not check things and continued to claim there was a GPL problem with cdrecord ;-)

BTW: it was me who wrote the changes for the final CDDL proposal that is compatible with the EU law (MPL-2.0 still isn't) and it was me who convinced the FreeBSD people to include ZFS. Maybe this helps to understand why I used the CDDL as the new license. Schily (talk) 15:52, 30 June 2015 (UTC)

As a note, this is bordering with the type of talk page discussions WP:NOTFORUM advises against, but it might be beneficial anyway.

Could you, please, explain what were the actual attacks you've experienced? I've read a lengthy LKML thread discussing cdrtools, and it seems that people only wanted to incorporate Linux-specific things into cdrtools, and you were against those (for example, the way recorder devices are addressed, bus/device/LUN triplets vs. device files). Sure thing, there were some Linux-kernel-related bugs as well, but people were rather willing to work on them. All of the POSIX standards are there and should be respected as much as possible, but we must also follow the "new wave" – that's the way cookie crumbles. You know, it's all about the teamwork, giving up a little bit so you can have much more in return.

Also, what's quite interesting is the DVD recording support, for which you've created a closed-source commercial solution. I'm really curious what were your reasons not to include that into the open-source cdrtools? I don't find something like that as a possibly lucrative business, while the benefits to the community would have been huge. — Dsimic (talk | contribs) 16:53, 30 June 2015 (UTC)

It has been explained several times before, let me try to do it again. Schily (talk) 19:35, 30 June 2015 (UTC)

There have been several attempts to send so called patches, they all cause problems instead of solving any problem. Furthermore, libscg is a generic SCSI transport that supports to send any SCSI command to any SCSI device. Libscg is the first attempt for such a transport worldwide; ADAPTECs ASPI appeared 2 years after libscg in 1988, but it basically does the same what libscg did now exactly 29 years ago. Note that libscg did never need to change it's interface in order allow for being used, Linux did introduce 3-4 complete incompatible changes during the past 20 years. Also note that libscg supports 25 different operating systems; only 6 of them allow to use a /dev/syntax to address SCSI. Two most widespread ones (Win-DOS and Mac OS X) don't allow /dev/syntax at all. It makes no sense to implement something that cannot be used for the majority of the supported platforms. Minority platforms such as Linux need top follow the majority and cannot expect to get a special way for their incompatible wishes. Schily (talk) 20:00, 30 June 2015 (UTC)

This is wrong: DVD support in cdrecord was added as the third program worldwide with help from Pioneer and on request of the worlds largest oservatory (ESO at paranal). At that time (1997), a single writer did cost 15000 US$, a single media did cost 100 US$ and you could only get one if you had the OK from the CEO of Pioneer. ESO did get the SW for free, but I had to sign an NDA with Pioneer. Since everybody can buy a drive, the code was available for personal use for free. My NDA did not allow me to publish the source until this was publically known by everyone. Since the largest company in that area did already steal code from cdrecord in the past, I beyond that had no interest to let this happen again - note that you cannot enforce the GPL for software only projects. Once this company did learn how to write DVDs, I published the DVD sources (May 2006), so what is your problem here? Note that if you are interested in people who have monetary interests, look at Debian, they make promotion for commercial CD writing software. Schily (talk) 20:12, 30 June 2015 (UTC)

IMHO, supporting more options is always better; that way, people are able to choose whichever option they prefer to use. Furthermore, if some patches implement new features in a wrong way, it's up to the maintainer to decide whether those patches should be treated as new feature requests instead of acting as good implementations of those new features. Open-source community and businesses built around it are like water, which will always find its way down while the only question is which path it will take; in other words, if you, as the top maintainer, don't take appropriate actions toward implementing new features people demand and love, some other people will create out-of-tree patches of questionable quality, or even fork the whole project, and the only results are bad feelings and lowered quality of software. Nothing good, in a few words.

Just look at the Android Binder thing. It drove a wedge between the kernel.org-provided Linux kernel and it's patched Android variant, but over time it became mainlined. Why? Because Android doesn't care, so it's better to have it mainlined rather than driving the whole Android ecosystem away from the kernel.org sources, no matter how crappy Binder might be. Furthermore, Binder doesn't destroy anything, it's all fenced in a dozen of #ifdef directives. Who knows, maybe Binder will once be replaced with kdbus, who knows? But, if kernel.org and Android were to provide two different-world kernels, it's almost for sure that kdbus would never replace Binder. The whole thing has also a few grains of politics and complicated human psychology.

I do agree that some things don't give a good first impression; for example, back at the time I've absolutely hated udev and the whole Linux hotplug thing (including the file system UUIDs), but it grew up on me over time as it solves a very common problem of new hardware that appears after booting. Even those crappy Windows-like file system UUIDs are actually a good thing, as the /dev layout and its association with the actual hardware do change between reboots. And I truly used to hate the whole hotplug "ecosystem".

With that in mind, if Linux people want something badly, and that's used for other purposes in Linux, it would be the best to provide them with that alternative cdrecord option. If you, as someone with the best possible knowledge of crdrecord's internals, don't do that, some other people will botch it up even if it's only about politics. And nothing good happens. Also, let's face it, Linux can't be called a minority platform – so many people use it, and (which was the case especially a few years ago) burning CDs and DVDs on Linux is a good thing. :)

DVD-related things are much more clear with your additional explanation, thank you. Regarding "since everybody can buy a drive, the code was available for personal use for free", that actually refers to the binary-only version that used to be free for personal use, right? Why this explanation of the whole thing hasn't been published anywhere? I remember very well that no such explanation was around back at the time. — Dsimic (talk | contribs) 21:04, 30 June 2015 (UTC)

This information was published several times in the past already, e.g. on the cdrecord web site since the attacks from Debian begun. I don't know why you did not read it at the other places.

The /dev/ patch had a big problem: it did not work, because it depends on the false assumption that you don't need root privileges in order to get the permission to send the appropriate SCSI commands to the drives. I hope you understand that it makes no sense to include code that does not give any benefit to the user. Please also note that there is no general universal DMA interface in the Linux kernel. libscg uses the drivers that give useful DMA support and this does not work with the /dev/ interface that some people want me to use. A part of the defamation campaign from Debian was to claim that no root privileges are needed by cdrecord but Debian recently started to tell people to run their defective fork as root in order to cure privilege based problems. cdrecord was the first 100% root free privileged program on Solaris in January 2006 (based on fine grained privs) and cdrecord has become the first 100% root free privileged program on Linux in 2013 after Linux finally developed similar fine grained support. SuSE and Gentoo install cdrtools based on this method. Schily (talk) 21:56, 30 June 2015 (UTC)

For some reason, it seems like that information hasn't reached far enough.

Speaking of all the obstacles, software doesn't need to be perfect nor it will ever be. At one point in time, it's slightly imperfect, and some time later it will be bettered. That's called progress. — Dsimic (talk | contribs) 22:41, 30 June 2015 (UTC)

Let us remove links and quotations to/from Jonathan Corbet and his writings as he is no more than a really bad Journalist

Let me first explain what a decent journalist should do before writing an article about a conflict that could harm others:

- Ask both parties to understand what's really happening

- Try to verify which claims from which party may be wrong

- Write carefully about the topic.

Instead of doing this, Mr. Corbet just forwarded the claims from the attacking party (which is Debian in case of cdrtools).

Mr. Corbet just literarily forwarded claims from the attacking party (Debian in our case).

Mr. Corbet did never even try to ask me or other neutral people about what really happened, so his writings can be seen as a part of the attacking party against cdrtools, which is Debian as mentioned already.

Repeating unverified claims from an attacking party is very bad journalism and for this reason, I propose to remove all quotations to attacks from Mr. Corbet from the cdrtools article. Schily (talk) 11:35, 28 October 2015 (UTC)

Not really related to the Mr. Corbet topic above

BTW: given that User:Chire and User:Diego Moya are obviously both part of Debian, they should immediately stop editing the cdrtools article. Schily (talk) 11:39, 28 October 2015 (UTC)

I've said this before, but I'll repeat it again since you keep saying that as if it was some sort of accusation: I have no relation with Debian whatsoever. My only relation with cdrtools is editing this article, and wanting it to comply with Wikipedia neutrality and verifiability policies.

Schily, you should have proof of what you say about editors before you make claims of any kind about them. We have rules for everything, and one of them says that you don't make personal attacks against editors. Diego (talk) 12:28, 28 October 2015 (UTC)

P.S. There's a full Internet where you can publish your counterclaims against what Debian or Corbet said. You're simply not allowed to add them directly into this article if you're the author of the cdrtools software. Why is this too hard for you to understand? Diego (talk) 12:32, 28 October 2015 (UTC)

Good point, so please follow your rules and post your non-neutral claims against cdrtools elsewhere. Schily (talk) 12:40, 28 October 2015 (UTC)

Diego; you are part of Debian and Debian is the attacking party against cdrtools. You should stop posting here. Schily (talk) 12:42, 28 October 2015 (UTC)

I am not part of Debian, I'm not part of Debian, I'm not part of Debian, I'm not part of Debian... Do you want me to repeat it any more times? This is becoming childish. Diego (talk) 13:24, 28 October 2015 (UTC)

Well, the most easy way to make us believe that you are not part of Debian would not be this kind of childish reply but reverting yopur habbit to neutral acting. So please verify that you are not biased and not in a conflict of interest by reverting your biased edit that removed the information about /dev/ based access and CAM (SCSI common access method). Schily (talk) 13:31, 28 October 2015 (UTC)

I'm acting neutrally and not biased. You're entitled to disagree. Diego (talk) 13:32, 28 October 2015 (UTC)

So you may either verify this claim by reverting your removal of the mentioned neutral information on CAM or you may keep your removal as a verification of your missing neutrality. Schily (talk) 13:40, 28 October 2015 (UTC)

See false dichotomy. Diego (talk) 18:48, 28 October 2015 (UTC)

You have any possible way to verify that you are not a Debian member that has just an interest to harm cdrtools. The fact that you removed the neutral explanation about the CAM interface standard is a strong hint that you are biased. As mentioned: One method to verify that you are interested in a balanced text would be to revert your removal. Schily (talk) 14:19, 29 October 2015 (UTC)

I removed that content because it was very poorly sourced. If you want it back, source it properly and I'll have no problem in including it. But since it's you who want the content back, it is you who have to do the hard work of showing how exactly the references support the sentences included in the article. Diego (talk) 16:39, 29 October 2015 (UTC)

If you believe it is poorly sourced, you would need to explain why you believe so, or revert your removal. Schily (talk) 16:48, 29 October 2015 (UTC)

I already did, and you ignored it. Either the text you included in the article does not appear in the references, or appears only in sources that are not reliable for such claims. Diego (talk) 17:46, 29 October 2015 (UTC)

It seems that you do not understand how references work. They explain a topic in general, but they rarely contain a directly related text. This is not a problem with the text you removed but with fact that you seem to miss the skills to understand the topic. If you cannot explain what you believe to miss, we need to assume that you removed valid text without a valid reason. Schily (talk) 18:07, 29 October 2015 (UTC)

Let me be more specific: you removed balanced text that applies to 99% of all installed computers and that explains a design decision for libscg (why it uses CAM standard based dev= addresses), but you did not remove unbalanced and offensive hostile text that applies to less than 1% of the computers and that was added by a user with a verified WP:COI. When asked, you have not been able to explain your behavior. So either we either need to assume that you have a conflict of interest as well, or you need to explain your behavior. Schily (talk) 19:04, 29 October 2015 (UTC)

It is you who do not understand how references are used in Wikipedia. Absolutely all sentences included in an article must have been directly asserted by an external reliable source, in a more or less explicit way (more explicit is better). That's the law of the land, and you would know it if you had read and understood the WP:No original research policy. Your approach to including content is simply not acceptable for this project, and will not be included unless you find ways to support the content you want to add under the constraints that the community has agreed upon.

So either we either need to assume that no one has made the assertions you want to include, or you're not willing to make the hard work to identify them and single them out processed in the manner that we can use them. Diego (talk) 19:41, 29 October 2015 (UTC)

In other words: you are still unable to explain why you believe that the text you removed was not sufficiently sourced. As a result, we would need to revert your removal. Schily (talk) 11:40, 30 October 2015 (UTC)

How many times do I need to repeat myself for you to see it? I already explained it here and repeated it here. The text was not sourced because the references do not make the assertions that you placed in the text, which is required by Wikipedia policy. What is there in those explanations that you don't find adequate? Diego (talk) 14:56, 30 October 2015 (UTC)

How often do I need to repeat that you missunderstand things? There is no need to find a citation that repeats the same text that is in the article. The given reference does exactly what is needed: it explains the CAM addressing scheme. Everybody who reads the reference will see that CAM standardized just the addressing scheme used by libscg QED. Schily (talk) 11:44, 2 November 2015 (UTC)

While you may think that it's not needed, the rest of editors that collaborate on writing this encyclopedia think it is needed. Therefore, they will remove content that does not match that requirement, just as I did. Also, your content was *not* limited to a mere description of the CAM addressing scheme - it contained a number of assertions about the relative frequency of libscg and the reasons why cdrtools used it, which were completely unsupported by the CAM standard FreeBSD manual. Diego (talk) 14:13, 2 November 2015 (UTC)

Discussion of above topic that Schily calls "off topic", but that is on LWN, too.

Let's keep all sourced opinions, whether they agree with you, or not! Wikipedia is about reliable sources, and LWN does constitute a reliable source. And so does Linus Torvalds. Stop censoring other opinions. Also, stop taking it personally if someone has a different opinion and tries to balanced things. If you look at my recent edit to the article: [1]. I challenge you to get a WP:3O on this edit, if it is in line with Wikipedia policy. What I did is adding the sourced opinion of Linus Torvalds (yours already is there - so I did not add it again). I'm removing your bias, by adding a second and sourced opinion. All according to Wikipedia standards, so please get a WP:3O if you disagree. Please, stop your attack spree against everybody who happens to have a different opinion. Fact: I replaced an earlier reference where Linus called you names, with one that does not include insults but focuses on the technical arguments against SCSI LUNs. So stop claiming that I have anything against you. It is you, who is on a crusade against alternate opinions; everywhere. It is you, who is attacking people, e.g. Talk:Unix with Huihermit, Talk:Terminfo and Talk:GNU Readline with Tedickey and probably many more. Stop blaming others; either the whole world is agaist you, or you are overreacting here. Calm down. --Chire (talk) 12:54, 28 October 2015 (UTC)

• Just one technical note, Chire - WP:3O is not adecuate, as there are more than two people involved. The tool to request further opinion would be a request for comment. Diego (talk) 13:27, 28 October 2015 (UTC)

Chire, you added non-neutral claims to the cdrtools page and the neutral information about the SCSI transport that is used by cdrtools was removed at the same time. As long as correct information is removed in favor of attacks from other people, this needs to be corrected. Wikipedia is not a platform for uninformed cdrtools attackers to spread biased claims from people what have no clue (e.g. Mr. Torvalds). It is a matter of fact that the vast majority of operating systems do not allow to access SCSI via /dev/ nodes and it is matter of fact that Mr. Corbet did never even attempt to write a neutral explanation but rather 1:1 forwarded text from the attacking party (Debian). Schily (talk) 13:04, 28 October 2015 (UTC)

Schily, the information that was removed was not "neutral information", it was "unverifiable information" as it did not have references. You can not write whatever you want in the article, all content in the article must be reworded from an external source that states it first - this is what No Original Research means. Diego (talk) 13:31, 28 October 2015 (UTC)

You seem to be confused as your claims do not seem to be related to my text. If you have a valid on-topic opinion, explain what you are talking about. Schily (talk) 13:44, 28 October 2015 (UTC)

Let me be more obvious about what I am talking about. I am talking about this text: device naming and this link: CAM(4) – FreeBSD Kernel Interfaces Manual for the SCSI standard CAM interface. In crontrary to the attacks from Chire, this was neutral information. Schily (talk) 13:54, 28 October 2015 (UTC)

I am not confused, but you're right that I have not explained what text I was talking about.

The text you added and I removed says:

Cdrtools are based on libscg (the SCSI Pass Through Interface library created in 1986) to send SCSI commands and libscg works on 28 different OS platforms. The vast majority of these platforms have no way to access SCSI devices via /dev/* based devices, e.g. common systems like Microsoft Windows and OS X (the latter is a POSIX certified platform). This is why libscg implements the portable interface via the SCSI Common Access Method (CAM) standard addresses

However, the page that you linked to as reference does not say anything of that (in fact, it doesn't mention cdrtools at all), it doesn't analyze on many platforms does libscg work, and doesn't say on how many platforms there is no way to access /dev/* devices, so it is not verifiable content.

Adding unverifiable content to Wikipedia articles is not neutral, so I won't do it. Diego (talk) 13:59, 28 October 2015 (UTC)

The fact that you do not seem understand the text, verifies that you are not allowed to remove it. Please note that the link you are talking about of course contains a table to a list of all SCSI standards including the CAM standard that applies to the portable SCSI access method that cdrtools use. The fact that you removed a neutral link to real information in favor of attacks from User Chire verifies that do not act neutral and that you should stop editing this article. You are still welcome to verify that you changed your mind by reverting your inappropriate removal. Schily (talk) 14:09, 28 October 2015 (UTC)

P.S. If you want some information from http://cdrtools.sf.net/private/cdrecord.html or CAM(4) – FreeBSD Kernel Interfaces Manual added to the article, let's discuss it first here in the talk page, and see if we can agree to which part is relevant and well sourced. Diego (talk) 14:03, 28 October 2015 (UTC)

If you like to verify that you are willing to have a fact based discussion, a good signal was to remove the recent attacks from User Chire and have a fact based discussion on his text here. Schily (talk) 14:11, 28 October 2015 (UTC)

I'm waiting for that fact-based discussion to happen. Whenever you have reliable sources that support the changes you want to make to the article, I'll be glad to discuss them.

However, according to WP:Verifiability and WP:No Original Research, the sources should state the same points that you want to include. It's not OK that you expect the reader to study the sources in order to arrive to the same conclusions; the information should be made explicit in the source, not deduced by making inferences over its contents. Diego (talk) 18:47, 28 October 2015 (UTC)

If you don't understand the topic, this is a strong reason for not editing it. As mentioned already, the text about the CAM interface you removed, contained a pointer to the standard as a reference Schily (talk) 14:17, 29 October 2015 (UTC)

Who says I don't understand the topic? That's irrelevant to the matter, the article is written for people who need to learn about the subject, not people who already know everything about it. Therefore, the references included need to explain the topic for someone that doesn't already know all the concepts involved. This is an encyclopedia, not a personal blog where the author can spit whatever they want. It's unreasonable to ask readers to wave through all the references provided and study them in order to assess whether or not they say the same thing that's included in the article - this is what we're expected to do for them. If you think the CAM link contains the same information that was removed, you need to point the reader to the exact sentence where the same thing is said, for example by quoting it in the reference. Diego (talk) 16:18, 29 October 2015 (UTC)

Your behavior verified that you have a WP:COI unless you are able to explain your removal. Unfortunately you still do not explain this even though you have been asked several times.

Claiming original research without giving a proof seems to be no more than a red herring unless you are able to explain your behavior.

The text you removed mentions that libscg (used by cdrtools) uses the CAM SCSI address method and it proves this by giving a link to the related standard. If you believe that the quoted standard does not verify the statement, you would need to explain this. Schily (talk) 11:47, 30 October 2015 (UTC)

For a start, you included the link to the CAM in the External links section, not as a reference, so it was not clear that you intended it to be used as support for your additions. The only reference for your text was to the T10 list of projects, which provides no analysis of cdrtools and does not mention libscg.

But even if you had used the CAM reference using the proper format, there are still many facts that you wrote about that do not appear either in http://www.t10.org/members/w_status.htm nor CAM(4) – FreeBSD Kernel Interfaces Manual, and are thus unsourced:

1. "Cdrtools are based on libscg". Neither T10 nor the CAM manual say this.
2. "libscg works on 28 different OS platforms". Who has done the count? Certainly not your references.
3. "The vast majority of these platforms have no way to access SCSI devices via /dev/*". We need an independent third party source who has made this assertion explicitly, as Exceptional claims require exceptional sources.
4. "This is why libscg implements the portable interface via the SCSI Common Access Method (CAM) standard addresses". As neither T10 nor FreeBSD talk about libscg, we have no way to verify why libscg implements that interface using your sources.

Is this a clear enough explanation for you now? Diego (talk) 15:10, 30 October 2015 (UTC)

• it is obvious that cdrtools are based on libscg, check the source! I see no need to "verify" obvious facts.

• echo libscg/scsi-*.c | wc lists 24 files. Some of them include support for more than a single platform. The interesting fact is that we had once a list of supported platforms in this article that was removed by unfriendly people (I believe it was Chire). So get this text back, as it contains the verification....

• Soso, you need an independent third party source for a true statement, but you do not need such a verification for all the false attacks that have been added by Chire? Most of these attacks are not verifyable as the related claims are from untrustworthy people.

• You seem to missunderstand how verifyable sources work. They usually never include text that directly confirms a statement but they usually include generic statements that allow to verify things. You would of course need to understand the topic and compare the method used by libscg with the method from the standard.

I recommend you to step back until you have the needed skills to be able to discuss the topic. Schily (talk) 15:25, 30 October 2015 (UTC)

• "I see no need to "verify" obvious facts." - It is needed because what is obvious to you may not be obvious to the rest of the world. Someone who does not know how to read source code (like, say, a journalist researching the history of cdrtools) will not know where to start navigating the code, much less how to verify its inclusion. This is why at the very least you should link to the part of the source code where the library is included.
• "So get this text back, as it contains the verification..." Even then, you first need to find someone else who explains why it is relevant to this article, that a number of projects exist which have nothing to do with cdrtools. "A is based on C" AND "B is based on C" THEREFORE "A and B work in the same way" is an invalid syllogism that you were trying to make there (with A being cdrtools, B being the 28 OS platforms and C being libcsg).
• "you need an independent third party source for a true statement, but you do not need such a verification for all the false attacks that have been added by Chire" That's because those sentences have appeared in an independent third party source. If you don't think it is reliable, you have to convince us why it's not. If I get convinced that it's unreliable I will remove it, but name-calling Corbet won't do it.
• "You seem to missunderstand how verifyable sources work". One more time, what you say may be how sources work at other places, but not how references are used in Wikipedia. If you are not willing to follow the rules of the project, please stop wasting our time. Diego (talk) 15:47, 30 October 2015 (UTC)

P.S. In general, manual pages and corporate catalogs are useless as references as they are devoid of context and don't provide any analysis of the topics covered. A design guide like this book would work much better to provide such context, and is the kind of references that we can best use. But they need to be related to the topic covered in the article. Since the License compatibility controversy is about Linux, a book about FreeBSD that does not mention cdrtools is unrelated to the topic and would need some other source explaining the connection. Diego (talk) 15:47, 30 October 2015 (UTC)

As long as you did not verify that you are not biased, you are not allowed to decide about this article. Note that we definitely know that Chire is a person with the goal to harm cdrtools, so Chire is not allowed to write anything in this article. You may have a conflict of interest or not. With your current behavior, we must assume that you have a conflict of interest. I currently see two ways to disprove this assumption from your recent behavior:

• revert your removal related to CAM

• write a similar text in your own words that meets your requirements.

Schily (talk) 16:05, 30 October 2015 (UTC)

As I am not aware of any reference showing that other operating systems work in the same way that cdrtools, the current version of the article meets my requirements. If you have better references, I will assess them and eventually include them in order to improve the neutrality of the article. However, with the current sources, the current article is the more neutral version I know how to write. Diego (talk) 16:16, 30 October 2015 (UTC)

Looks completely confused:

• cdrtools is not an operating system
• As long as the attacks from Chire stay in the article and there is not an explanation on the addressing method used by libscg, the article is heavily unbalanced and needs a fix. If you believe this is not the case, then you are not a person that is able to decide about the article. Schily (talk) 16:23, 30 October 2015 (UTC)

The fact that you did not reply seems to confirm that you conclude with the statement that the text added By Chire is unbalanced and in general without importance for cdrtools as 99% of all computers need the addressing scheme that the uninformed Mr. Torvalds likes to avoid. As a result, we definitely need either to remove this unbalanced attacks from Chire or we need to have the text about CAM that was removed. If you don't revert the removal of the CAM paragraph, I need to do this myself. Schily (talk) 11:50, 2 November 2015 (UTC)

If you touch the article with a ten foot pole, I will file a Conflict of Interest report against you. If you disagree with the status of the article, the way to follow for an editor involved with the topic is to gather external opinions through the dispute resolution process at the Wikipedia:Dispute resolution requests board. Diego (talk) 12:30, 2 November 2015 (UTC)

P.S. Also please stop putting ideas in the mouth of others when they have not expressed them - your mental model about how other people reason seems to be completely messed up. "Other operating systems" was meant as "other than Linux", not "other than cdrtools". And not replying again and again to the same point is not proof of agreement - it's more likely caused by attrition. Diego (talk) 12:36, 2 November 2015 (UTC)

P.P.S. And if you want to include the way that libscg handles SCSI units, I've already told you the only way that this can be done: find an external link from a trusted source that directly describes the process and which explains why it is relevant to cdrtools. If you provide that kind of quality source, I will not have any objection to including such content, using a wording that paraphrases the source. Diego (talk) 12:43, 2 November 2015 (UTC)

It seems that you are unable to have a fact based discussion and it is now obvious that you have a conflict of interest. Schily (talk) 17:07, 2 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. It seems that the account Knutjb only exists for attacks against the cdrtools project. @Knutjb: Stop your attacks, or you will be blocked. Schily (talk) 11:50, 3 November 2015 (UTC) Please delete this text. I do not use Cdrtools and there are alot of thing I want to do than edit wars. — Preceding unsigned comment added by Knutjb (talk • contribs) 14:18, 4 November 2015 (UTC)

(Personal attack removed) (Knutjb (talk) 10:01, 17 November 2015 (UTC))

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)

Finding evidence

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.

Diego (talk) 14:12, 2 November 2015 (UTC)

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?

• The device naming background was mentioned in the cdrtools article, see: [2], but this information has been removed. Feel free to re-add it. Schily (talk) 15:44, 17 November 2015 (UTC)

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 93.204.100.134 (talk) 20:58, 20 November 2015 (UTC)

great satire, keep it up! Schily (talk) 22:45, 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)

tags and csection

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)