> Sorry for not having done my own homework but here it goes:
> Last time somebody asked (was in early 2.0, now I'm running 2.1)
> what would be the implications of not having the kernel support
> a.out format besides loosing a.out binary compatibility, the answer
> at that point was (if my memory servers me right) that there were
> some features that had been implemented in a more efficient way
> when a.out support was included in the kernel and that there were
> some generally needed functionality that came with a.out support
> only besides just running a.out binaries.
> Now, I ask everyone on this list that knows something about the
> subject to give their input on the subject - if possible don't turn
> this into a flame fest about what's better a.out or ELF, I'm just
> asking because I want to understand what a.out support brings into
> the kernel besides a.out binary support.
> Thank you for your time.
Well, I've tried it both ways, and now run with a.out support NOT
compiled in because the main program I run (SatTrack 3.1.5) runs
considerably slower when it is compiled in. The said program is
running under OpenWindows with a graphics window active showing the
current locations of all the amateur radio satellites currently up
there for which I have details, and is definately processor intensive
since there are some SERIOUS calculations to be performed for every
update...
For reference, my system is based on an Intel P166 processor with 96M
of RAM and (currently) 4.5G of HD space, to be upped to 10.9G shortly
(I bought the drive today, but have yet to fit it) running RedHat 5.0
and I've also verified that I currently don't have any a.out binaries
on my system using the following command as root:
Q> for Z in `find / -name '*'` ; do file $Z ; done \
Q> | grep executable | grep -v ELF | grep -v script | less
On my system, that produced a blank display...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu