Joerg Schilling wrote:
Darren J Moffat <[EMAIL PROTECTED]> wrote:
Opinion:
Personally I detest with a passion the CLI that cdrecord has despite it
being technically good at actually doing the writing. I like the
simple interface that cdrw provides. The simple cdrw CLI could be
implemented as a wrapper around cdrecord and I'd be happy with that, but
don't force me to use cdrecord CLI.
I am not sure whether you did read the man page for cdrecord in depth
The very fact you have to read the cdrecord man page in depth is the
issue.
This is strange, it seems that you did not realize that it is not possible
to use cdrw without reading it's man page. The CLI from cdrw seems to be
even worse than the one from cdrecord.
The online help from cdrw is not helpful but confusing.
Take as an example the second paragraph of the cdrecord man page dives
straight into talking about SCSI buses targets and luns this then goes
on for paragraphs.
Now compare this with the cdrw man page.
The cdrw man page is definitely not better.
It confuses the reader and forces him to scroll down to the examples section
in order to understand the concept. I believe that the cdrecord man page even
gives a better overview in the first pages...
Look also at the examples, the first example in each man page attempts
to show the simple case of burning a disk using an existing iso file.
Again the cdrecord man page is talking about SCSI buses and targets,
something that is way beyond the knowledge of many users that are
otherwise very comfortable with the CLI.
Well, bot programs are build on top of SCSI pass thrugh...
And BTW: this week we are celebrating the 20th aniversary of SCSI pass through.
I did develop the SCG driver and the base of libscg in the first week of 1986.
but it seems that you don't know that it is not harder to use cdrecord
(you need to spedicfy even less parameters in case you like to do the
simple tasks that cdrw only supports) than to use cdrw.
Personally I find the man page for cdrecord very technical, this is good
if you really need to know all the details of how to write different
types of media on different drives.
The man page for cdrw is confusing and if at all, I did write only one CD
with cdrw. mostly because it's CLI is counter intuitive.
Similarly the help output for cdrecord is 82 lines long, I find that
excessive and useless. I just recently fixed a similar issue with zfs(1).
The gelp output for cdrw is completely confusing and not helpful at all.
For this reason, I would call cdrecord more user friendly.
That depends on how technical you are. Joeg you know probably more than
anyone else all the issues with writting CD/DVD media and issues with
different drives. As a result cdrecord has the ability to workaround
all these issues and has lots of command options for doing so, this is
great for technical people but cdrw is simple.
Well, this would be an argument in case that the cdrw CLI was better than
the one from cdrecord.
Don't confuse this with the "feeled complecity", it may be that you just
are afraid of the various possibilities of cdrecord but the absolute
complexity of the CLI of cdrw is a real bad example of unneeded comlexity
that iy already present althouth cdrw does nto support many options.
I'd class myself as a very experienced UNIX user but I'm pretty much a
novice when it comes to SCSI and I really have to stop and think about
what is a bus what a target is and what a lun is. I shouldn't need to
have to know or even read about this just to burn an iso file on to
CD/DVD media when there is only one writable device on the system
(probably the case of the vast majority of systems).
So for me cdrw(1) is much more friendly than cdrecord(1), thats just
they way it is for me.
It is definitely not. I guess that you just did read the man page for cdrw
many times but did not do the same for cdrecord.
Well I did use it without ever reading the man page (and neither you are
I can prove otherwise :-)). I know that with some level of certainty
since I'm pretty sure I used from bfu archives when it first integrated
and the man page wasn't integrated yet.
I typed cdrw and it was completely obvious to me what I had to do from
the very first line of the synopsis. I don't think I had ever read the
man page for cdrw(1) until this email thread. cdrecord(1) I did
cdrecord -help and when straight to the man page which was even more
confusing (see my previous email about how technical it is so very quickly).
I think it is great that cdrecord can do so much but for me the UI is
too complex and the man page is far too technical too quickly.
And the CLI for cdrw is way too complex for such a simple program.
Well we will just have to disagree on that, for me cdrw(1) is very
simple and its list of options is just right
for me; even though I hardly use any of them.
BTW: similar things aply to "star" vs. Sun tar. I should make a demo
of star on the Sun tech days.... it is intesting that all people who did
try to use star for one day will never like to use something else later.
I have used star (years ago and looked at it again recently), however it
really depends on what your needs are and for me the Sun tar program
does what I need since I almost never do anything other than:
$ tar xvf file.tar
or
$ gzip -dc foo.tar.gz | tar xvf -
$ bzip2 -dc foo.tar.bz2 | tar xvf -
or
$ tar cf file.tar files/
or maybe
$ tar cf - files | (cd foo/bar && tar xvf -)
Don't need star for any of that.
For stuff going on tape for backups I use Legato Networker.
I try to let my programs base on a simple concept and later add
more options. It is obvious that the simple fact that there are so many options
may be a problem for the "first contact".
Yep you got it, you have to deal with the first contact problem when
designing a good UI. It is unfortunately very hard to do this well for
CLIs, I personally believe even more so for CLIs than GUIs that this is
hard.
--
Darren J Moffat
_______________________________________________
opensolaris-discuss mailing list
[email protected]
