Re: Memory Mangement Problem in 5.1-RELEASE

Shawn wrote:
> On Fri, 2003-07-25 at 02:21, Terry Lambert wrote:
> > You probably can't get away with the old gcc, since the binary
> > format changed For No Good Reason(tm).
> 
> Didn't the GNU people say they had to change it to be more ABI compliant
> with the 'standard'?

I will believe that when they upgrade their FORTRAN compiler
to be more compliant with 'the standard'.

Some standards are not worth complying with; I still have yet
to see anyone tell me exactly what the practical benefit of
doing this is.

It's like the ELF standard instead of a.out; I was very much
in favor of the change-over because it was supposed to let us
have section attribution and multiple text and data segements
that got loaded in the same executable.

Is your FreeBSD kernel capable of defragging kernel memory to
permit large contiguaous allocations for a device driver like
the BT848 to happen well after boot time?  Mine isn't.

Is your FreeBSD kernel capable of dicarding the code and data
for the probe routines that are not currently being executed
and are not used in the common operational case?  Mine isn't.

Is your FreeBSD kernel capable of paging out any kernel page
that's not in the paging path, so that if you, for example,
have sound hardware and aren't using your sound driver, you
have the ability to use the physical memory to instead open
more sockets?  Mine isn't.

Is your FreeBSD kernel capable of loading *only* the probe
code for a device, and, if it doesn't probe as being there,
never loading the rest of the device driver and cotributing
to KVA fragmentation?  Mine isn't.

Does your system have a libc.so linked against a libresolv.so
that's totally seperate so that you can pull in new libraries
from ISC whenever you need to do that the name lookups aren't
serialized and make your Netscape slow?  Mine doesn't.

Is your entire system linked shared?  Well, mine is.  8-).
But it was under a.out, too.

ELF promised a lot of things that never ended up having any
practical value beyond what we already had with a.out, which
was one BSS, one TEXT, and one DATA: just like before ELF.

So what exactly is being promised by "being more standards
compliant" in this particular instance?

I can tell you what isn't: binaries are larger and compilation
is slower than in previous releases; keeping up with GCC feels
like running further and deeper into a swamp filled with
molasses.

Yeah, it's nice that we support 64 bit architectures (sorta)
now, but that particular feature didn't need the binary format
changed.


Does anyone else ever suspect that some standards are written to
cripple your competition, if they are stupid enough to fully
comply with them?

-- Terry