It doesn't. You might mean ``why does my swap seem full?''. If that is what you really meant, it's because putting stuff in swap rather than discarding it makes it faster to recover than if the pager had to go through the file system to pull in clean (unmodified) blocks from an executable.

The actual amount of dirty pages that you can have in core at once is not reduced; the clean pages are displaced as necessary. Why use (what are) a.out and ELF executable formats?

To understand why FreeBSD uses the a.out format, you must first know a little about the 3 currently "dominant" executable formats for UNIX:

The oldest and `classic' unix object format. It uses a short and compact header with a magic number at the beginning that's often used to characterize the format (see for more details). It contains three loaded segments: .text, .data, and .bss plus a symbol table and a string table. COFF

The SVR3 object format. The header now comprises a section table, so you can have more than just .text, .data, and .bss sections. ELF

The successor to FreeBSD tries to work around this problem somewhat by providing a utility for branding a known for more information.

FreeBSD comes from the "classic" camp and has traditionally used the format, a technology tried and proven through many generations of BSD releases. Though it has also been possible for some time to build and run native In FreeBSD's case, our shared library mechanism is based more closely on Sun's SunOS-style shared library mechanism and, as such, is very easy to use. However, starting with 3.0, FreeBSD officially supports Yes, but why are there so many different formats?

Back in the dim, dark past, there was simple hardware. This simple hardware supported a simple, small system. a.out was completely adequate for the job of representing binaries on this simple system (a PDP-11). As people ported unix from this simple system, they retained the a.out format because it was sufficient for the early ports of unix to architectures like the Motorola 68k, VAXen, etc.

Then some bright hardware engineer decided that if he could force software to do some sleazy tricks, then he'd be able to shave a few gates off the design and allow his CPU core to run faster. While it was made to work with this new kind of hardware (known these days as RISC), In addition, program sizes were getting huge and disks (and physical memory) were still relatively small so the concept of a shared library was born. The VM system also became more sophisticated. While each one of these advancements was done using the However, as time passed, the build tools that FreeBSD derived their build tools from (the assembler and loader especially) evolved in two parallel trees. The FreeBSD tree added shared libraries and fixed some bugs. The GNU folks that originally write these programs rewrote them and added simpler support for building cross compilers, plugging in different formats at will, etc. Since many people wanted to build cross compilers targeting FreeBSD, they were out of luck since the older sources that FreeBSD had for as and ld weren't up to the task. The new gnu tools chain (binutils) does support cross compiling, Why won't chmod change the permissions on symlinks?

You have to use either `` and man pages for more info.

without any options and follow the symlink with a trailing slash (``/''). For example, if `` chmod 555 foo/

With the trailing slash, will follow the symlink, `` Why are login names

You'd think it'd be easy enough to change In FreeBSD 3.0 and later, the maximum name length has been increased to 16 characters and those various utilities with hard-coded name sizes have been found and fixed. The fact that this touched so many areas of the system is why, in fact, the change was not made until 3.0.