On 6/2/2020 4:34 PM, Antonio Diaz Diaz wrote:
Scott Dwyer wrote:
The tools mentioned are not open source and
have paid versions for a reason. The authors have spent much time and
effort working on them to make them special.

Do you mean that I have not spent much time and effort working on ddrescue to make it special?
No, you have spent much time on an excellent program, the only one of its kind in the open source world, and I bet with little financial return.

Realizing the different error conditions of a device cannot be done with
normal commands.

IMO, non-standard commands should be used only when standard commands don't suffice, because non-standard commands have a much higher probability of causing a catastrophic data loss because of an incompatibility.

Ddrescue is a low-risk project. Maybe it won't maximize the probability of recovering the data in difficult cases, but it won't risk destroying your data by trying to be more clever than the kernel.

It is good that there exist low- and high-risk projects. This allows you to try the low-risk ddrescue first, and try the high-risk non-standard software if ddrescue can't recover your data.
My intention was to reply to the suggestion of error control that ddrescue doesn't do like other programs. You must go deeper to accomplish this, at a minimum SCSI passthrough. I do it in Linux, and the other program can also do it in Windows I believe. Both are specific and non-portable, due to the nature of what needs to be done at a lower level. It is obviously more complicated, but when done correctly it is no more dangerous than what the kernel does. And FYI the kernel does NOT know best when it comes to a failing drive, it will thrash it more than needed in Linux, and Windows is even worse.

Comparing those tools to ddrescue is like comparing apples to oranges.

Certainly. Ddrescue exposes its code so that everybody can see (and improve) it. OTOH, we only have your word that the secret, non-standard commands you use in your program won't eat the user's data. :-)
Then maybe someone can come up with the SCSI passthrough code for ddrescue (hint to programmers out there that want to, I have produced open source Linux patches for this in the past that would be a good starting point, look into the old ddrutility stuff). I would actually like to see this implemented in ddrescue, and while I would not give away any of my secrets, I would be willing to at least point someone in the right direction if they were trying and had technical questions, although it would obviously not be my top priority to respond to those questions in a super timely manner. And yes, users of my software have only my word and no warranty ;)

IMO every piece of software should either publish the full source code (so that users can decide if they trust it) or offer an unlimited warranty in case of misbehavior of the code.
If this were the case, then all software would be open source or open to incredible liability. Without the hope of financial gain (or having the fear of great loss), there would be much less effort, and many good programs would not exist. If you told me that my software had to be either open source or unlimited warranty, it would not exist.

By the way, would you mind toning down the ads in your emails? This mailing list is for improving GNU ddrescue, not for advertising other software. Thanks.
Sorry, the only reason I mentioned the names is that it was in the original message. I try not to respond to the list, but sometimes I see something that I feel the need to respond to (sometimes against my better judgment). Maybe I should remove myself from the list so I don't see the emails, and therefore not tempted to reply. I might just do that...


Reply via email to