>From: "Mike A. Harris" <[EMAIL PROTECTED]>
>> 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,
Do you call:
IRIX
AIX
FreeBSD
NetBSD
OpenBSD
SCO-Unixware
Solaris
BeOS
BSDi
HP-UX
OSF1 / True64
Win95
Win98
Win ME
NT-4.0
W2000
outdated?
>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.
The interesting part is that most of my time is going into
writing E-mail to support users who are unwilling to read
the documentation and into mkisofs...
>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)
If you read my source you would know, that the important thing
with my philosohy of portability is that there is only very few
conditional code...
I use modular and reusable code. This makes my code different
from most GNU code.
>>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...
Keeping ide-cdrom for ATAPI drives instead of using ide-scsi
for this purpose is not a move towards a easier to use Linux.
>>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.
My proposal is to freeze ide-cdrom and let people with antique
hardware manually configure it but make the default bedaviour
compliant with current hardware.
>>>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.
This is what most GNU user believe but it is completely wrong!
GNU tar is unable to create POSIX compliant archives nor to read them.
The only portable tar implementation that supports POSIX is star.
>>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
What is wrong with sending mail that describes the problem in neutral
technical terms?
.... but your words here are not related to the paragraph above?@!!??
>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
I told you, I don't use honey, I use neutral technical words.
In many cases the people will not understand them or are unwilling
to believe in facts...
>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.
About three years ago, I send a mail to Linus Torvaldsen that I have
an improved version of sg.c and asked him what to do to have this
integrated into Linux. I never got an answer!
Linux definitely does not work as you believe.
>>>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,
I can proove what obscure things are:
Half a year after I send mail to Linus, I got mail from Alan
stating that there was Douglas Gilbert working on the driver and
whether I could give hime some advice...
I send a mail to Douglas Gilbert and reviewed his code...
I found that he did something bad to the interface with respect to
up/downward compatiblity and that it was better to use my code because
it:
1) grants up/downward compatibility in source _and_ binary and
2) it allowes to futher enhance the interface towards a more usable
interface that gives the needed SCSI error codes back
to the user.
The answer from Gilbert was a harsh barfing that showed me that
this guy may have read the SCSI specs before but did not grok anything
from inside.
All my further tries lead to a more harsh tone in letters from Gilbert.
Altough I write to Alan that he should not include Gilbert"s code
before it has been discussed in a technical manner it was included.
>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
Douglas changes were bad and he took a long time to understand what
really was important because he was not willing to listen!
The interesting thing is that he offered a new ioctl interface for
sg.c in February 2000 that was completely rubbish because it
forced the user to set up some IO vectors similar to "readv".
He told me that the reason was that SANE needs this feature...
I answered him that:
1) SANE cannot use this feature for serious because it only would
make sense if a scanner will scan more than window at once
AND when all of these windows are non overlapping.
2) No UNIX user program uses readv()
I got only the question: how did you check that and I answered:
I grepped through all Solaris sources.
Then he did not reply anymore but half a year later suddenly the
ioctl() interface of sg.c was usable.
Now: Would you call a guy who is not willing to learn and who is very
harsh to people who write him things he obiously does not understands
a pergon who is _able_ to do cooperative work?
>>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?'
I tried more than once, I even told Heiko to write in a very
calm way to him in hope that he is only unwilling to cooperate
with me. Forget 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.
You should read comp.os.unix.solaris to see that I beat on Solaris
the same way when there is something bad going on...
>>Interesting: Douglas Gilbert was the guy who failed to be abe to
>>cooperate with other peple and gets accepted!
Maybe because these other guys were uninformed at the same level
as he. It is always easier to talk with people of the same knowledge base.
If you are looking for good hackers/code integraters you need to check
whether are able to cooperate with people why know more then they do.
>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.
He is absolutely not friendly and if you remember - there was some
time to the beginning of last year when he frequently tried to convince
that the way cdrecord uses sg.c was wrong and how beautiful the world
looks if somebody uses his eyes.
>>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
What would you do if you would have been attacked in a way that is hard to
top?
Note that you only saw the more calmful part of the "discussion".
>>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)
Two months ago, I pointed Douglas to this program and it looks
that he consideres scgcheck irrelevan to his 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
I believe that he was accepted because he is a native english speaker.
Linus was too lazy to even answer me! This was the real start of the
desaster. Alan did not understand what bad things Douglas was doing
with the sg driver and finally accepted Douglas work because
it fixed a problem he personally liked to have fixed. Unfortunaltely,
this problem was much less important.
>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
If you tell me I am an outsider, then these poeple are ignorant.
When I started trying cooperation much more than a million
people were using cdrecord.
>listening... it is that nobody wants to listen to an outsider
>tell them the way things should be and attack that which they do.
Douglas was much more an outsider!
He never contributed any significant open source.
But it seems that many GNU people are simply snooty. I write bug reports
against gnu make several time to the mailing list that was noted on
the man page. All I got was replies from people who did not even
understand what a make program is for.
NO ANSWER from anybody involved in the code.
Then I published smake sources and 2 months later I suddenly got
a reply from one of the maintainer.
>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.
I work much harder on Open Source than most people on the world.
You cannot expect me to increase my effort towards things
that are not mine.
However, I expect other people to be open minded to tips how to make
their code better. I always am!
>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
If the current Linux maintainers show me that Linux is really trying
to move towards better concepts, I would happily help.
Now all I see is that Linux is far away from becomming a motor
for new ideas in the OS world. Show me one real new idea in Linux
that has not been available on other OS years before.
So the only reason for using Linux is that there is better driver support
for intel based system then e.g. on Solaris.
With the way all people repsond to my wishes for ATAPI, it seems that
this better driver support on Linux is by accident and may soon
go away. Why are the relevant people not willing to listen to me?
Why it it more important for Alan that he has no need to make a
special configuration for his antique PC than to help newbies
to start with Linux?
>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.
If you only know M$, you _must_ like Linux! Is is far better
from perspective of core OS features.
I know UNIX, SunOS and Solaris source long long before there was Linux.
If I compare these sources with Linux, then I could tell you a lot
of things that could be improoved in Linux and if improoved
would make Linux make more maintainable.
Let me give one example:
A decent OS design like Solaris has a DMA abstraction Layer in the OS.
A driver calls ddi_dma_setup() and friends and must not know anything
about how DMA works in general nor in special for the driver he is
talking to.
The reason why Douglas code was accepted in favour of my code is that
Alan found that sg.c was not performing well and he liked a sg.c that
does not need to allocate physically continuous copy memory to do
virtual DMA. Note that Linux ( I cannot speak for 2.4 where it seems
to change) does not support raw disk device nodes! Why? Because
Linux cannot do user mode DMA (e.g. DMA into the user address space).
Douglas hacked someting that uses scatter gather to scatter the
data among the different pages in the user address space. Some
completely unneeded code if the OS has a decent DMA abstraction.
>>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
This is my last try! Please keep this in mind. If it fails, then I
prooved that Linux is rubbish and nobody cares to improove code.
I expect that Linux kernel hackers like to listen to me in this
case because it seems that I know better.
>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.
If kernel code maintainers do not listen to facts, they should be
replaced!
>But that attention is _negative_ attention, and it works
>_against_ you.
Again: I know what I know and what I can do. I don't have the time
to do it my self. As most other OSS developers are contributing
much less work the the OSS community than me, I expect that people
help to improove this special case (ATAPI & Linux). If it does
not work this way, then it prooves that OSS is not the right
way to go because OSS hackers are selfish and don"t listen to
the outside.
>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.
Well I tried the other way before and it did not work.
If you like to give me an advice, you need to take into account
that the method you are currently proposing to me did not work!
>>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
Sorry, this does not work for me as O have better things to do
in my time.
>>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
It is outdated code that needs only to be kept to allow Alan
to keep his outdated non ATAPI CD-ROM.
Any CD-ROM bought within the last years will perfectly work
with ide-scsi & sr.c
>>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.
If they would listen... no problem.
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]
