On Sun, 20 May 2001, Joerg Schilling wrote:
>>I've also got one. My 1993 2x drive and my 1994 4x drive are
>>still running in great shape as good as they did brand new. The
>>crap they have put out in the last 5 to 6 years is designed to
>>last 6 months so you have to replace it. I'd rather not play
>>that game. We all know that a 52 speed CDROM is not really 52
>>speed by any far stretch of the imagination after all... If the
>>newer drives came with a set of earplugs I'd consider upgrading
>>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).
>52x is a joke, You know that there are two different 40x Plextor drives?
>The second was announced as 52x by some people outside Plextor...
>Plextor only named it 40x too althouhg it _is_ faster than the old
>one.
>
>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
made of course, and I never claimed that no drive out there
couldn't go faster. 99% of the drives marketed are marketed with
misleading speed labeled on them. That is a fact period. 1
speed is 150k per second. 40 times that is 6 megabytes per
second. If I put a CD into a 40x drive, and don't get 6Mb/s then
it is not a 40x drive in my books, but rather just marketing
politics. My 4x drive on the other hand puts out 600k/s which is
as it says "4x the speed of a 1x drive".
HiVal/Kenwood TrueX drives do in fact put out 40x speed. I had a
Kenwood 40x trueX drive when they first came out and that sucker
put out 6Mb/s sustained continuous output as advertised. AFAIK
though, the drives are no longer made, and I had some problems
with it in Linux, so it went back to the store.
My statements are facts, and are measured based on the hardware I
have tested. I do not speak at all for hardware which I have not
tested other than to say your run of the mill off the shelf CDROM
drives are speed labeled with marketing hype.
>>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
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips : 599.65
3 root@asdf:~# hdparm -i /dev/hdd
/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:
This is a Toshiba 4x CDROM drive from 1994. I got it used from a
friend who upgraded to an 8x in 1995, and I've used it ever
since. It started out in my 386-DX-40 back then, through
486DX2/66, K5-133, K6-200, and now my K6/3-300, and will be going
into my new dual 1Ghz P-III in another week as well. This drive
works, never gives errors, doesn't make any noise, and amazingly
seems to have been built for use in space probes or something
because it is absolutely rock solid and problem free. The best
thing of all about it - which is more important than speed to me
- is that it is absolutely silent, and doesnt sound like a
nuclear reactor starting up. This thing will get pryed out
of my hands by a crowbar only after I die. <grin>
Actually, if Alan/Arjan/Andre are correct, I may not be able to
use my trusty 4x with the new dual box as the Serverworks chipset
it uses doesn't appear to be too IDE functional currently...
>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).
>>>> OK, I'll try it but I thought that you as the integrative person may/should
>>>> issue some pressure to the developers to help Linux to evolve into a direction
>>>> that makes it easier to use for most people.
>>>
>>>I really dont follow that part of your argument at all.
>
>>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.
>- 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)
>- 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...
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
simple nice UI that is nontechnical. This problem however boils
down to the same solution as the above discussion - "show me the
code", does it not? I don't have the code to solve these
problems and most others here do not either, as such - we require
support forums like this for our questions. If people here knew
the answers that you provide, your workload would be much less I
would think.
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.
> ... so why should I help other people with their work?
>
>- I already _did_ what you propose and I miserably failed!
Ok...
> 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"?
>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.
Another thing, is that you are known by everyone to be very
anti-Linux, and very critical of Linux. That is NOT the right
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.
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.
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.
I know from my own experience of being both positive, and from
being very negative as well, in fact I've been a real bastard at
times with some topics, both on lkml, and in general. My
observation is that being a pissed off jerk gets me nowhere a lot
of the time, but being very nice and polite often gets results I
was looking for. I'm both at times, but positive attitude always
wins over the negative side.
It summarizes down to "You can get further with honey than you
can with guns."
>>Since you "know" all of the "problems" with this stuff in Linux
>>so well, with your level of talent in the field of SCSI, I would
>>think that you could design something between breakfast and
>>lunch, and implement it before dinner.
>
>>One would also think then that there would be no more problems in
>>the Linux SCSI subsystem with which you would continue to
>>incessantly attack Linux for.
>
>
>Do you really believe that I make a second try and contribute
>source to the Linux kernel after I failed so miserably?
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.
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.
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.
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.
To give you an example of how I experience similar events is with
XFree86. I maintain XFree86 at Red Hat, and would personally
drop support for 3.3.6 on a dime myself as the older hardware
support that is missing in XFree86 4.0.x is just so ancient IMHO
that it isn't worth the bother. Unfortunately, that would cut
off a lot of people from using XFree86 in Red Hat Linux, and I
would not want to see that happen when there is code out there
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.
Despite the fact that some of that hardware is so ancient that it
shouldn't be used, it is used, and IMHO should be supported if
possible, but only by someone interested in doing the work. This
whole CDROM thing fits into a very similar vein IMHO.
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.
Take care,
TTYL
------------------------------------------------------------------------
Signature poll: I'm planning on getting a 12 or 16 port autosensing
10/100 ethernet switch soon for home use, and am interested in hearing
others recommendations on what to buy. Cost isn't as important as is
functionality and quality. Any suggestions appreciated.
------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
