On Sun, 20 May 2001, Joerg Schilling wrote:
>>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
Yes, it is. Sorry, I think there was a misunderstanding
somewhere, either by me or you...
>- 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.
One might point out that the number of installations of a lot of
those 30 OS's is negligible, and many of those OS's are legacy
OS's. In the same line of reasoning that everyone with a old
CDROM should upgrade to a newer Plextor drive, one might be
tempted to conclude that those running one of the many ancient
OS's out of the 30 supported by cdrtools should upgrade their
ancient OS to a modern OS such as Linux/BSD/etc. ;o) After all,
then the development efforts of the software could be spent
adding new features that help out a greater majority of users
using modern OS's on modern computers, than does having the most
portable-to-microwave-oven-from-1969 development effort.
That is of course just a hypothetical conclusion that someone
could make without knowing the critical importance of supporting
those 30 OS's other than WOW factor, and a mess of conditional
code that is hard to read and/or understand, that is hard enough
to understand even if only supported on one platform. ;o)
>>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.
I wouldn't consider a 300Mhz machine with UDMA-66 controller a
slow machine. ;o) Not for the purposes of testing CDROM speed
anyway, and not when the Kenwood ATAPI drive does in fact deliver
6Mb/s at 40x. The conclusion is that the drive manufacturers
lie.
>>>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.
Something like that, yes. The last full PC I bought was in 1994
- a 386. I've done partial upgrades ever since. Still using my
original 1994 keyboard with no Windows96 keys on it, albeit the
right shift key no longer works and there is so much food caked
to the thing that it is a miracle it still works at all. That
and an original SB16 Basic edition ISA, that thank God I'll still
be able to use in my dual Tyan Thunderbird HEsl motherboard - it
has a single ISA slot (so I can disable the onboard sound). ;o)
Stick with what works is my motto. ;o)
>> 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...
Yes, it is.
>Toshiba is the onlx excuse ;-)
;o)
>>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).
The speed of improvement isn't as important as the quality and
stability of improvement IMHO. Linux isn't about having the
biggest feature checklist.
>>>- 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.
And that is a very excellent idea indeed - for anyone or any
project.
>I hope that the Linux kernel maintainers are doing the same.
It certainly appears that that is occuring to me, however
sometimes it does as you've remarked seem slow. Rushing things
can have bad consequences though so it may be better this way...
>>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 use ide-scsi on my writer because I have to, I use ide-cd on my
reader because ide-scsi does not do everything I want to use the
drive for. Personally, I couldnt care less if there was a single
driver written in fortran that was a 2Mb kernel module as long as
it works for me. I would not want to see it become the only
driver however because that would mean a lot of hardware (older)
would be unsupported. Keeping existing drivers for older
hardware, and using new drivers for new hardware sounds sane
though - if that is what you propose. It isn't IMHO necessary to
have a one driver fits all solution.
>>> 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.
I believe it works as you like if you set the environment
variable "POSIX_ME_HARDER", or somesuch. Personally, I wouldn't
go near another OS without installing all the GNU utilities
anyway so GNU tar is everywhere IMHO, or can easily be everywhere
- it is free.
>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 think people refuse many of your suggestions because of the
method in which they are suggested. I don't have the past
threads on these topics in front of me, but would you say that it
was a polite request/discussion between people trying to work
together, or was it frought with negativity and perhaps bias? As
I commented in my last mail, and believe you have replied to
below (I respond as I read), "you get further with honey than you
do with guns". These are indeed words to live by. I've got a
lot more patience than most people, and even if I get pissed off
at someone, I often clear my mind and get back to the
job/goal/whatever at hand and try to keep things focussed, and
stay away from personal attacks, bias, etc. I'm not perfect of
course so sometimes some brown stuff comes through, but it
usually gets cleaned up in short order anyways. It is a bigger
challenge to one perhaps to engage in kernel development without
losing one's cool than it is to do the code in the first place.
>>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.
I do not know the "obscure things", so I cant comment accurately
about that, however the decisions made by Linus, Alan, etc. are
made for various reasons, some of which are stability,
maintainablility, and a willingness of developers to cooperate
with each other in a sane manner, among many other things. When
someone brings up an issue with someone else's code, ideas,
designs, etc.. it needs to be discussed, and various issues in
ones code that they may not see are an issue, others may see it
that they are an issue, and that needs to be fixed, and agreed
to. I believe that your changes were rejected based on this
aspect. Douglas's changes IMHO did a great job, and work well
for me at least. I don't know the low level tech details of all
of that code, or the detailed decisions made by
Linus/Alan/whoever. Only they can speak for themselves.
>>>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.
How did you try to stimulate positive discussion about it?
>>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...
Criticizing something is one thing, beating on it constantly
every time someone mentions it is another. I beat on Microsoft
much in the way you talk about Linux (I do it much worse actually
<grin>), and so I appear biased against M$, and you against
Linux. You wont shed this perception people have by bashing
Linux continuously.
>>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!
Who did Douglas fail to cooperate with? I find Douglas quite a
positive guy myself. Very friendly, and cooperative in any
discussions I've seen him in, at least when other parties were
also being sensible.
>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.
In fairness Jeorg, I recall seeing the same sort of offensiveness
from you back then. When someone attacks someone else in a
negative manner, r attacks or criticizes in a negative manner, it
invites the same from another person. This is very much the
psychology of human nature. We are ALL susceptible to it to a
certain extent. There are ways of criticizing or disagreeing
with someone in a positive and productive manner. I try to do
this as much as possible. It doesn't always work that way
because I am human as well, but when I do do it I get very good
results, and a little positive minded cooperation with someone
can go a LONG way.
>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.
I'm sure that there are in fact bugs to find and fix. I'm not
skilled in SCSI to do so, I'll be the first to admit that. In
fact if I had a SCSI question, I'd ask Douglas and yourself about
it - at the risk of filling up your mailbox even more. ;o)
>>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...
That is your perception, however did Douglas attack Alan, Linus
or other core developers in a negative manner and tell them the
way things fly? Not that I recall.. He was cooperative with the
kernel folk. Kernel folk often bicker with each other about many
things, but they sort things out in the end whilst maintaining
their various subsystems, etc.
You are a skilled person in what you do, but as far as the Linux
kernel is concerned, you're an outsider, and your comments public
towards Linux, and some of the perceived shortcomings it has, put
up a wall between you and those that _could_ be working _with_
you. That is the biggest problem IMHO. It isn't that nobody is
listening... it is that nobody wants to listen to an outsider
tell them the way things should be and attack that which they do.
My perception of it all is that you did not appear to be someone
who would stick around as a Linux kernel developer for the long
haul maintaining any code that you submitted, but would likely
alienate yourself from other developers due to your negativity
towards Linux.
Another way of looking at it is to look at other developers that
have come into the viewfinder in Linux... Most new developers I
see entering lkml that end up becoming contributors, or even core
maintainers have a natural attachment to Linux to start with.
They enjoy Linux, enjoy working with it, and helping others that
are working on it. They get into it deeper and deeper and
perhaps make some important new contribution and end up as a core
maintainer of that code. They have worked with Alan, Linus, and
many others and are more or less quite cooperative and do not
refer to Linux in a negative manner comparing it to some other OS
that does it better, etc... Sure, some other OS might do
something better, but saying things in a negative way like that
makes one look like they are anti-Linux, and not too interested
in trying to help.
The majority if not all of the Maintainers, and most contributors
seem to me to LIKE Linux, and look at it from its strengths,
while working on its weaknesses. It is not hard to tell if
someone is a fan of Linux or not, and I think it is important
that the people working on the code in the kernel are sitting in
the same corner of the ring, not across from each other.
>>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.
THat may all be true, but you also wont be able to march in and
assume takeover. If you truely want to help Linux, it will
require IMHO some humbling and perhaps dropping some ego. Yes,
you very much do know what you are doing WRT SCSI - no argument
from me on that, but if you work with others in the Linux kernel
you will not be able to just say "my way or the highway, I know
more than you about this so just do it my way or not at all".
I'm no kernel developer, I'll admit that, but I do know a lot
about the way things run in the "circle" if you will, from
monitoring lkml for many years quite closely and seeing every
argument come and go. Other peoples concerns can't just be
pushed aside because they don't apply to one persons way of
thinking, all things must be considered, and clearly thought out.
That is important IMHO in any development, not just in the
kernel.
>>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.
Facts are fine, it is in presentation that I am refering to.
Presenting facts with honey, or presenting them flying out of a
gun. Choice is yours of course, but guns will not let anyone
promote their ideas very far. It is all very much in the manner
one uses to communicate. Communication skills make or break it
basically IMHO.
>>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.
But that attention is _negative_ attention, and it works
_against_ you.
>So again: Nobody was able to give me any tecnically based issue
>against making ide-scsi the default.
There is more to it than that. I believe totally that it all
comes down to mannerism as I've said above. I am more inclined
personally to ignore someone who is complaining/nagging/yelling
or otherwise attacking me, than I am to listen to them - even if
I KNOW they are right. Nobody likes a preacher, and nobody likes
being hammered on unnecessarily.
>>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!
EXACTLY! See, I watch these things VERY closely, and the thing
that sucks the most with some of it is that I know exactly where
developer A is coming from and read him clearly, know exactly
where developer B is coming from as well, but they don't
understand each OTHER, and the battle continues! ;o) I
sometimes get involved, and sometimes it goes towards the good
side, and other times I get dragged in and do some cussin too.
;o)
I sometimes wish I could sit in the middle of some arguments as a
filter for people and keep communication going on a positive
level - when I can actually understand the topic at hand anyway.
It frustrates me to see someone else get frustrated due to
communication issues, and then a big negative bruhaha occurs and
people lose site of the goals. I shake my head often... I'm
glad I don't do much more than minor hacks to the kernel, and
keep them to myself mostly, because I would likely wear out all
the four letter words if I were in kernel development all the
time. ;o)
>>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.
It isn't necessarily that nobody cares, rather sometimes they
need to be sold on something, and that means that you need to
have a solution for all their arguments against what your code
does. Look at devfs for example. There are many other examples
also. Mr. Gooch demonstrated his idea of devfs with code, and
then constantly updated it and posted notices to lkml. When a
new kernel came out, he tracked it with new releases of devfs,
even though many people were very much against it, and STILL are.
In the end, his dedication to the solution he proposed finally
paid off by it being included by Linus. It is that sort of
commitment to the kernel and to one's code which I think is
pretty much a requirement nowadays for any kernel subsystem
maintainer. A die hard willingness to produce patches against
the current codebase, fix bugs, and keep it up to date until and
also after it is included in the kernel - also dealing with
various other problems that come up along the way. In the
example of devfs - I think R Gooch did this very well, even
though I'm no devfs fan.
>>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.
Yes, but you tell me how to do it and I know squat about SCSI and
only little about kernel development. I also have no time. It
takes someone with the knowhow, skill, time, patience and
willingness to cooperate to get the job done IMHO for what you
propose is needed.
>>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.
No, I see your point, and agree with it to an extent, however if
you want to redo ide-scsi, how does that affect ide-cd? Why not
leave ide-cd alone, and the legacy drivers and just redo ide-scsi
the way you believe it should be done? I know not if this makes
sense of course because I know shit about SCSI admitedly, but I
cant see how one driver affects another unless they are
subsystems of each other or dependant somehow on each other.
>>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.
I don't see that as a problem actually. For example, if you
decide you would like to do this, and are willing to do so as I
outline above, and with patience, how does that affect someone
else working on their own part of the kernel? Perhaps I
misunderstand what you mean above.
This is 2.5 material for Linux if it does get worked on IMHO.
It could be done well I suppose, but it will take someone with
both the skill, patience, communication skills, and the time to
do it.
You definitely have the skill IMHO, but only you can determine if
you have the other three areas as well. If you do decide to give
it a shot, I'd be glad to try to mediate discussion if that would
help at all. There would be a possiblity of past grudges from
others there still I presume, so it would be something touchy
perhaps. I don't hold grudges myself...
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]
