>From [EMAIL PROTECTED] Sun May 20 11:58:56 2001
>>>from a 4x to an 8x perhaps... ;o) A 40x drive is really more
>>>like 12x from my measurements...
>>
>>So you never tried to copy a Audio CD... your old drive will
>>not allow you to extract audio at all or if, it will do it in
>>catrastrophical quality.
>I don't know where you draw that conclusion from. I use my 4x
>drive for audio DAE all the time. Works perfect, no noticeable
>quality loss. The output of cdparanoia is usually very clean
>(few errors read).
A bit later you tell me that your drive is a Toshiba.
- This makes it very probable that it already _is_ ATAPI
- Toshiba was the only company that made drives useful
for DAE before ~ 1997 (or do you know when the Plextor 20x drive
came out).
Note that the DAE quality is still bad compared to modern
Plextor drives. There is jitter that may be corrected
by cdparanoia but as paranoia is nonportable I cannot
promote it as cdrtools work on 30 different OS and it makes
no sense to recommend a program that only work on one of them.
>>If I rip audio off a CD using the new PX40, I get an average of
>>32x. If I do the same with the old PX40, I get an average of 24x.
>>
>>There is nothing prooving your statement that it is only 12x.
>That very much depends on the drive at hand Jeorg as you very
>well know. I tried 4 different 40x readers one night and did a
>simple copy-image-to-hd operation of full CD's. When figuring
>out the average speed from the time it took and the amount of
>data copied, all 40x drives tested resulted in a true average
>speed of 12-13x MAX. This doesn't account for every drive ever
This is what I get frrm my UPLEX 40 on a SS II where the SCSI speed
is limited to 8MB/s. If I need to pass the data 2x on the SCSI
bus in order to have in on HD, the max speed is limited to 4MB/s
which is 26x. On a slow machine, this will force you down to 12-13x.
>>>The point to Jeorg being that there is no reason for me (or you
>>>Alan) to upgrade a perfectly good working drive that we are happy
>>>with and which works fine today.
>>
>>I cannot believe that you are still running a P60 based PC from 1994. This
>>would be a lot slower than my 1989 Sparcstation II ...
>Why would I make such a statement if it weren't true?
>3 root@asdf:~# cat /proc/cpuinfo
>processor : 0
>vendor_id : AuthenticAMD
>cpu family : 5
>model : 8
>model name : AMD-K6(tm) 3D processor
>stepping : 12
>cpu MHz : 300.684
So your PC is less than 3 years old. While your CD-ROM is 7 years old.
>/dev/hdd:
> Model=TOSHIBA CD-ROM XM-5302TA, FwRev=2095, SerialNo=5500034702
> Config={ SpinMotCtl Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
> RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
> BuffType=unknown, BuffSize=256kB, MaxMultSect=0
> (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
> IORDY=on/off, tPIO={min:240,w/IORDY:180}
> PIO modes: pio0 pio1 pio2 pio3
> DMA modes:
Most likely ATAPI...
>>Next point: non SCSI drives from 1993 are crap, they have only been
>>made by low quality companies and they have big problems reading
>>old worn out CD's correctly.
>The 2x drive I have works ok for what it needs to do when it
>needs to do it. That amounts to reading a few files off a data
>CD once in a very blue moon. There is no reason to replace it as
>long as it serves the purpose it is being used for - regardless
>of how obsolete or crappy it may be perceived to be. It works
>for me(tm).
This is from my 1989 SS-II
Cdrecord-ProDVD 1.11a01 (sparc-sun-solaris2.4) Copyright (C) 1995-2001 J�rg Schilling
Using libscg version 'schily-0.5'
scsibus0:
0,0,0 0) 'IBM ' 'DDRS-34560 ' 'S92A' Disk
0,1,0 1) 'SEAGATE ' 'ST11200N ' '8334' Disk
0,2,0 2) *
0,3,0 3) 'TOSHIBA ' 'MK537FB/ ' '6258' Disk
0,4,0 4) 'WANGTEK ' '5150ES SCSI-36 ' 'ESB6' Removable Tape
0,5,0 5) 'EXABYTE ' 'EXB-8500-85QUE ' '0428' Removable Tape
0,6,0 6) 'TOSHIBA ' 'XM-3401TASUNSLCD' '3593' Removable CD-ROM
0,7,0 7) HOST ADAPTOR
scsibus1:
1,0,0 100) 'IBM ' 'DCAS-34330 ' 'S65A' Disk
1,1,0 101) *
1,2,0 102) *
1,3,0 103) 'PLEXTOR ' 'CD-ROM PX-40TS ' '1.04' Removable CD-ROM
1,4,0 104) 'PLEXTOR ' 'CD-R PX-W8220T' '1.00' Removable CD-ROM
1,5,0 105) *
1,6,0 106) *
1,7,0 107) HOST ADAPTOR
Toshiba is the onlx excuse ;-)
>>>No kidding.. Jeorg, Linux isn't a company ran OS that Alan or
>>>someone can say "hey you - you must code this". It is "you have
>>>an idea you think is good, well then by all means show me the
>>>code, and we'll talk" OS. So Jeorg, where is that code?
>>
>>Nice idea but it misses important facts:
>>
>>- If Linux is maintained this way it will not improove in
>> quality and maintainability.
>Linux has been maintained this way for 10 years. During that
>time, it has improved in both quality and maintainability.
And as it has been prooven, this method reduces the speed of
improvements (see sg.c).
>>- Alan already _is_ deciding what is going into the kernel.
>> If he does, he should do it on a rational base.
>Certainly, and I think Alan does a wonderful job of maintaining
>all of the stuff he maintains. Sometimes I wonder if he is even
>human to be able to handle all of the stuff he takes care of.
>;o)
As I am dealing with a lot of OSS too, I know what that means...
Have a look at: ftp://ftp.fokus.gmd.de/pub/unix/ with a few
execptions (cdda2wav and mkisofs partially) this is all my SW and
there is still SW waiting for being published.
>>- I am working mainly on cdrecord. The fact that most
>> people in this mailing list do not help other people
>> causes a high mail effort for me.
>Which IMHO indicates a problem that isn't being addressed
>significantly. FAQ's are nice, but there is a reason that a Q is
>FA, and that is usually because something is not obvious to
>someone, or something doesn't work as people expect, etc...
This is why I am trying to change my SW to make the numbers
of Q going down.
I hope that the Linux kernel maintainers are doing the same.
>There are certainly good reasons for FAQ's and mailing lists such
>as this one, but a lot of questions would be NOP's if the
>software did what people expect it to do, and did so with a
So you are proposing the same as I: make IDE-SCSI the default on Linux...
>I have no idea how you can address that however...
>> I not even have the time for other important projects
>> from me. Look at star, it is much better than GNU tar in
>> many points but as I did not have the time to add large
>> file support and incremental backups, people are still
>> using the crappy GNU tar...
>GNU tar works for me... Not that it couldn't be better mind you,
>but it does the job for most users I think.
If you are a Linux only user, your impression may be right.
If you are dealing with other systems, the missing standard compliance
in GNUtar is a pain in the ass.
About a year ago, I pleased Alan to change the Linux mt ioctl
interface to make it UNIX compliant and he told me that he will not :-(
Then I wrote a /etc/rmt server that is superior to all known
implementations and tries to hide the Linux design bugs that
make interoperability over the wire hard... GNU tar stil uses
the GNU /etc/rmt implementation and nobody seems to care.
Note that I should add a note on Paul Eggert (the current GNUtar
maintainer). He is one of the rare people in FSF who has a great
backgound knowledge...but he seems to have no spare time as me.
Since he is doing development on Solaris as I do, the quality in
terms of portability of GNutar increased signifiant after he
became the maintainer.
>> I started to make the Linux sg driver better 3 years
>> ago. Alan did not include my changes into Linux but
>> rather added some code of a SCSI novice (Douglas Gilbert)
>> who did some work on sg.c that was completely unnessecary
>> if the Linux SCSI system would have a decent structure.
>> A driver like the sg driver should never know about
>> scatter gather DMA at all! The effect of that decision
>> was that it took 2 years for Douglas Gilbert to learn
>> the basics of SCSI transport. Now we have a new interface
>> with a quality we could have 3 years eralier....
>I don't want to debate that whole issue as we've all seen it
>enough times already and know the story well. One thing to
>consider about your perceived failure is "why"?
This is simple: Because the Linux kernel team did not select
code based on quality but on obscure things.
>>From what I understand about the Linux kernel development
>process, and Alan can correct me if I'm wrong, etc.. For new
>code to succeed in the Linux kernel, and be accepted, one must
>prove their design ideas, and the best way to do that is by
>"showing the code". This will often get met with criticism on
>lkml - which is part of the whole "being part of kernel design"
>thing. If one cant stand the heat, then one could potentially
>drop out of the ballgame anytime and including one's code in the
>kernel is a risk - a support risk.
If your statement was right, then my code should have been used
because it was better than the code from Douglas Gilbert.
Instead there was _no_ discussion based on rational criteria.
>Another thing, is that you are known by everyone to be very
>anti-Linux, and very critical of Linux. That is NOT the right
Being someone who is critical does not mean that he is against
the thing he critisizes. I am critisizing Solaris too...
>approach to take when doing kernel development if you want to be
>taken seriously. One needs to do the work, and also to POLITELY
>try to cooperate with the other developers, and address their
>concerns, etc. If one is perceived anti-linux one will then have
>a hard time because the "does not play well with others" effect
>kicks in. One must be persistent, and able to discuss technical
>matters with other developers with a cool head. I claim none of
>these qualities myself, but I'm no kernel developer per se
>either. I've followed lkml long enough to know what people will
>succeed and what people will fail horribly.
Interesting: Douglas Gilbert was the guy who failed to be abe to
cooperate with other peple and gets accepted!
I tried to point him to the pitfalls in his code and to the (to him
unknown) fact that SCSI commands in a high level protocol will
frequently fail by design. He was unwilling and unable to understand
that it makes no sense to have a sg.c that only works correctly
when a SCSI does _not_ fail. Instead of haveing a useful discussion
I got harsh offensively relpies.
OK, now I created 'scgcheck' and anybody who is interested in the
problems in the Linux SCSI kernel impelentation may run it
and see what does not work correctly.
>The failures are usually those that do not submit to Linus/Alan
>or other maintainers on a frequent basis, and instead go off on
>their own development to poke their heads up once every 4 months
>with a 2Mb patch. Or people who just bitch and complain about
>"how much Linux sucks" and similar negative garbage. These
>people are setting themselves up to be met with equal negativity
>and putting up their own walls. Direct attacks for no reason
>other than to be negative about Linux, is not going to get any
>developer much help, nor is it going to make anyone on lkml very
>willing to work with someone or consider there work.
Well Douglas Gilbert was succesful with direct attacks against me
and with a bad design compared to mine...
>Do you jump and do things when someone TELLS you to do it? If
>they yell at you and tell you "your program xyz sucks because of
>abc", do you say "ok, I'll fix it, just wait a few days". I'll
>bet you say in your own mind something more akin to "fuck you
>buddy, don't talk to me and put my program down like that. your
>problem just got demoted to last priority". THAT is a natural
>reaction in our own minds when people attack us be it personally,
>or on a design issue, etc.. Negativity does not promote positive
>change.
Well see above! It is now up to the Linux team to an approach towards me.
I know what I can do and other people may learn easily that
I had thorougly UNIX experience long before Linux even exists.
I know other solutions and I am able to compare quality and design.
I don't need Linux people to tell me what I am able to do.
>It summarizes down to "You can get further with honey than you
>can with guns."
I don't use honey... I use facts. If other people are not interested
in facts, then they should not wonder when I am going to critisize them.
>Don't be hard on yourself for it Jeorg. In order to succeed at
>such a task it would require a different approach from you. One
>with an open mind, and a willingness to accept criticism without
>getting worked up and attacking Linux. Keeping things clear on
>technical issues, and explaining things clearly when people do
>not understand it.
That's what I do. ... if people don't listen to me as in the current
cases with ide-scsi, I start a bit more aggressive to get attention.
So again: Nobody was able to give me any tecnically based issue against
making ide-scsi the default.
>It can be frustrating having to explain something you know very
>well to someone who doesn't know shit about it and says your
>wrong - I have to do that with various things as well. If
>explanations cannot be put into words very well, writing the code
>does. If you read lkml you know that some developers have
>difficulty at times expressing themselves clearly and this often
>causes dispute. Sometimes I believe it is because they know the
>shit so good that they are way above a lot of the others in
>understanding their particular niche, and due to poor
>communication skills and/or general frustration and/or saying
>things before the right time and/or many other reasons, a lot of
>negativity occurs, and a lot of people are turned off from
>development.
You hit the nail!
>Another thing I notice is that often one persons solution to a
>given problem might solve that problem, but at the expense of
>making another problem that they don't care much about, but that
>someone else does. When solving problems in something global
>like the kernel, one must be careful to have an open mind and
>take other peoples problems into consideration and fix things in
>a way that is more universal than the problem one was initially
>trying to solve.
I know about the whole kernel but the problem with out curent
discusion _is_ that some people simply say: I like to keep
ide-cdrom full stop. When I come up with global background it seems
that nonody cares.
>If you think you can fix SCSI in Linux, and can do it without
>dropping support for things that are there that people out there
>do care about - like 2x CDROM drives, etc. then I think it would
>be a very good thing to attempt. Only worth it though if you can
>put aside any qualms you have about Linux, and accept that there
>are some weaknesses, and try to fix them, without being perceived
>as threatening by those who hold he kernel close to their heart.
I don't ave the time to do this. This is the reason why I tell
you how to do it.
...
>that can allow them to use X still - 3.3.6. I myself use the
>"your hardware is ancient, please upgrade" comment occasionally,
>but really, if one's hardware worked for them before, and isn't
>broken, and does all they need, this is not fair for them at all.
I believe that you may safelyy assume that people who are running
8 year old hardware may safely use 5 year old software on it.
Maybe this is the important point you are missing.
>If Linux has problems in the area of ide/atapi/scsi, that need to
>be addressed, then hopefully someone that knows the stuff well
>will do the work and do so in a cooperative way with the other
>developers. Who that person will be is not for me to say or even
>guess, but the likelyhood of any perceived problems in the linux
>kernel going away until someone that does know the stuff fixes
>it, is effectively very small.
The problem in Linux is that there is a lot of people doing development
in their peep hole. There is no global coordination that tells them
your part is now of low interest because we must adress other important
issues.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
