[EMAIL PROTECTED] wrote:
> >From: [EMAIL PROTECTED] (Bill Davidsen)
>
> > Why "blame" anyone? The default is what most people use. Linux is
> >about choice, most people choose ATAPI including drivers.
>
> And ATAPI _is_ SCSI so what?
So they gain nothing with CD readers by adding SCSI anything. And Alan
is giving the default of the simplest setup which will work for most
people, many of whom wouldn't have a clue why they were getting a SCSI
message if there was a problem.
This follows Plauger's "rule of least astonishment."
> >> - binary incompatibility of cdrecord with the kernel.
> >> Please always make sure that you compiled cdrecord on the
> >> machine you are using. A cdrecord binary compiled on a
> >> 3 month old Linux-2.4-xxx.yyyy.zzz would not run on a
> >> 4 month old linux-2.4-xxx.yyyy.zzz.
>
> > Again, this could happen, but a kernel change with the same libraries
> >is unlikely to cause a problem. A library change can always be a
> >learning experience. I built an old cdrecord under 2.3.something, and it
> >works today. I haven't recompiled most of my other applications, either,
> >I just don't have the need or an uber-makefile to do it all.
>
> It seems you meissed the point: I did not say that an old binary _will_
> cause problems on a new kernel, I sayd that using a new binary
> on an old kernel definitely will cause problems.
I did miss the direction of your old and new issues, but it certainly
is not certainly a problem. If the library matches the kernel, a month
of updates is unlikely to be an issue. I'm NFS exporting a binary
toolkit, with a matching library, from a 2.4 machine. It runs fine on
older kernels, at least back to some 2.3 machines which are still up and
won't get an upgrade until they have some problem.
> Things like this happen every few weeks (only with Linux).
See? Comments like this are why people think you don't like Linux. If
you had access to development kernels for other o/s you would probably
have a similar experience. Upgrades within a stable kernel series are
less likely to be an issue.
And I've had programs which ran on AIX 4.3.2 which didn't on 4.3.3, so
it's not only on Linux, just that more people run development kernels on
Linux, because they can. (Guilty, I've run things like test4pre5ac2).
> I hope you now understand why I am annoyed with binary compatibility
> on Linux and why I first tell people to compile cdrecord from sources
> and check again.
I agree this is good practice if you have a problem, but only Redhat
seems to have sent out a binary which didn't work as part of an official
distribution. Stuff happens, at least it wasn't the compiler!
> > I'll let the driver maintainer speak to that, assuming he still reads
> >this list.
>
> The interesting thing is that I got at least 3 similar reports during
> the last few weeks (all related to Linux-2.4). There is a problem
> with the CHECK_CONDITION #define in a Linux system include file.
> It is just wrong (right shifted by one). When the first USB-SCSI
> came out, I could not run cdrecord because I did not get
> SCSI sense data (caused by the fact that the mass storage driver
> did not set the right bit in the SCSI structures).
Obviously this should be fixed (how could it get broken in the first
place??), but that would make a check report as something else, no? Is
there some other condition being reported as a check?
And why does this hurt anything, it's going to be wrong in your
program as well, because you always compile from source and would have
the same bit, even if it is wrong?
> > Firmware was my first guess. If only you had a clue who built this
> >thing...
>
> I don't know. From the inquiry string, it doesn't look like a Sony
> as the other HP drives.
I have mentioned static linking several times and you have not
commented. Was there a reason why your program which only runs with the
obsolete libc.5 isn't just linked static, so you wouldn't get all these
question?
--
-bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
