<!-- $Id: misc.sgml,v 1.9 1999-01-27 00:11:44 nik Exp $ -->
<!-- The FreeBSD Documentation Project -->
<sect>
<heading>Miscellaneous Questions<label id="misc"></heading>
<sect1>
<heading>
FreeBSD uses far more swap space than Linux. Why?
</heading>
<p>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.
<p>The actual amount of dirty pages that you can have in core at
once is not reduced; the clean pages are displaced as necessary.
<sect1>
<heading>
Why use (what are) a.out and ELF executable formats?
</heading>
<p>To understand why FreeBSD uses the <tt>a.out</tt> format, you must
first know a little about the 3 currently "dominant" executable
formats for UNIX:
<itemize>
<item><htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
name="a.out">
<p>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
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
name="a.out(5)"> for more details). It contains three loaded
segments: .text, .data, and .bss plus a symbol table and a
string table.
<item><bf>COFF</bf>
<p>The SVR3 object format. The header now comprises a section
table, so you can have more than just .text, .data, and .bss
sections.</item>
<item><bf>ELF</bf>
<p>The successor to <tt/COFF/, featuring Multiple sections
and 32-bit or 64-bit possible values. One major drawback:
<tt/ELF/ was also designed with the assumption that there
would be only one ABI per system architecture. That
assumption is actually quite incorrect, and not even in the
commercial SYSV world (which has at least three ABIs: SVR4,
Solaris, SCO) does it hold true.
<p>FreeBSD tries to work around this problem somewhat by
providing a utility for <em>branding</em> a known <tt/ELF/
executable with information about the ABI it's compliant with.
See the man page for
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?brandelf"
name="brandelf"> for more information.
</itemize>
<p>FreeBSD comes from the "classic" camp and has traditionally used
the <htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
name="a.out"> 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 <tt/ELF/ binaries (and
kernels) on a FreeBSD system, FreeBSD initially resisted the "push"
to switch to <tt/ELF/ as the default format. Why? Well,
when the Linux camp made their painful transition to <tt/ELF/, it
was not so much to flee the <tt/a.out/ executable format
as it was their inflexible jump-table based shared library
mechanism, which made the construction of shared libraries
very difficult for vendors and developers alike. Since the <tt/ELF/
tools available offered a solution to the shared library
problem and were generally seen as "the way forward" anyway, the
migration cost was accepted as necessary and the transition
made.
<p>In FreeBSD's case, our shared
library mechanism is based more closely on Sun's
<tt>SunOS</tt>-style shared library mechanism and, as such, is very
easy to use.
However, starting with 3.0, FreeBSD officially supports <tt/ELF/
binaries as the default format. Even though the <tt/a.out/
executable format has served us well, the GNU people, who author the
compiler tools we use, have dropped support for the <tt/a.out/
format. This has forced us to maintain a divergent version of
the compler and linker, and has kept us from reaping the benefits
of the latest GNU development efforts. Also the demands of
ISO-C++, notably contstructors and destructors, has also led to
native <tt/ELF/ support in future FreeBSD releases.
<sect1>
<heading>Yes, but why are there so many different
formats?</heading>
<p>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.
<p>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), <tt/a.out/ was ill-suited
for this hardware, so many formats were developed to get to a
better performance from this hardware than the limited, simple
<tt/a.out/ format could offer. Things like <tt/COFF/,
<tt/ECOFF/, and a few obscure others were invented and their
limitations explored before things seemed to settle on <tt/ELF/.
<p>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 <tt/a.out/ format, its usefulness was stretched more
and more with each new feature. In addition, people wanted to
dynamically load things at run time, or to junk parts of their
program after the init code had run to save in core memory
and/or swap space. Languages became more sophistocated and
people wanted code called before main automatically. Lots of
hacks were done to the <tt/a.out/ format to allow all of these
things to happen, and they basically worked for a time. In
time, <tt/a.out/ wasn't up to handling all these problems
without an ever increasing overhead in code and complexity.
While <tt/ELF/ solved many of these problems, it would be
painful to switch from the system that basically worked. So
<tt/ELF/ had to wait until it was more painful to remain with
<tt/a.out/ than it was to migrate to <tt/ELF/.
<p>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,
<tt/ELF/, shared libraries, C++ extnensions, etc. In addition,
many vendors are releasing <tt/ELF/ binaries, and it is a good
thing for FreeBSD to run them. And if it is running <tt/ELF/
binaries, why bother having <tt/a.out/ any more? It is a tired
old horse that has proven useful for a long time, but it is time
to turn him out to pasture for his long, faithful years of
service.
<p><tt/ELF/ is more expressive than a.out and will allow more
extensibility in the base system. The <tt/ELF/ tools are better
maintained, and offer cross compilation support, which is
important to many people. <tt/ELF/ may be a little slower than
a.out, but trying to measure it can be difficult. There are
also numerous details that are different between the two in how
they map pages, handle init code, etc. None of these are very
important, but they are differences. In time support for
<tt/a.out/ will be moved out of the GENERIC kernel, and
eventually removed from the kernel once the need to run legacy
<tt/a.out/ programs is past.
<sect1>
<heading>Why won't chmod change the permissions on symlinks?</heading>
<p>You have to use either ``<tt/-H/'' or ``<tt/-L/'' together with
the ``<tt/-R/'' option to make this work. See the <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?chmod" name="chmod"> and
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?symlink" name="symlink">
man pages for more info.
<p><bf/WARNING/ the ``<tt/-R/'' option does a <bf/RECURSIVE/
<tt/chmod/. Be careful about specifying directories or symlinks
to directories to <tt/chmod/. If you want to change the
permissions of a directory referenced by a symlink, use
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod" name="chmod">
without any options and follow the symlink with a trailing slash
(``<tt>/</tt>''). For example, if ``<tt/foo/'' is a symlink to
directory ``<tt/bar/'', and you want to change the permissions of
``<tt/foo/'' (actually ``<tt/bar/''), you would do something like:
<verb>
chmod 555 foo/
</verb>
<p>With the trailing slash, <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?chmod" name="chmod"> will
follow the symlink, ``<tt/foo/'', to change the permissions of the
directory, ``<tt/bar/''.
<sect1>
<heading>
Why are login names <bf/still/ restricted to 8 characters?
</heading>
<p>You'd think it'd be easy enough to change <bf/UT_NAMESIZE/ and rebuild
the whole world, and everything would just work. Unfortunately there
are often scads of applications and utilities (including system tools)
that have hard-coded small numbers (not always "8" or "9", but oddball
ones like "15" and "20") in structures and buffers. Not only will
this get you log files which are trashed (due to variable-length
records getting written when fixed records were expected), but it can
break Sun's NIS clients and potentially cause other problems in
interacting with other UNIX systems.
<p>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.</p>
<p>If you're absolutely confident in your ability to find and fix
these sorts of problems for yourself when and if they pop up, you
can increase the login name length in earlier releases by editing
/usr/include/utmp.h and changing UT_NAMESIZE accordingly. You must
also update MAXLOGNAME in /usr/include/sys/param.h to match
the UT_NAMESIZE change. Finally, if you build from sources, don't
forget that /usr/include is updated each time! Change the appropriate
files in /usr/src/.. instead.</p>
<sect1>
<heading>Can I run DOS binaries under FreeBSD?</heading>
<p>Yes, starting with version 3.0 you can using BSDI's <tt/rundos/
DOS emulation which has been integrated and enhanced.
Send mail to <url url="mailto:freebsd-emulation@freebsd.org"
name="The FreeBSD emulation discussion list"> if you're interested in
joining this ongoing effort!
<p>For pre-3.0 systems, there is a neat utility called
<htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^pcemu" name="pcemu">
in the ports collection which emulates an 8088 and enough BIOS services
to run DOS text mode applications. It requires the X Window
System (provided as XFree86).
<sect1>
<heading>I have FreeBSD and NT installed on the same computer. Can
FreeBSD read my NT files?</heading>
<p>Yes. A read-only NTFS driver exists for FreeBSD, allowing you
to mount your NT filesystem under FreeBSD. For example, the C: drive
on NT could appear as /ntfs/c/ when in FreeBSD.
<p>For more information, see this tutorial by Mark Ovens at
<htmlurl url="http://www.users.globalnet.co.uk/~markov/ntfs_install.html"
name="http://www.users.globalnet.co.uk/~markov/ntfs_install.html">.
<sect1>
<heading>
What is ``<tt/sup/'', and how do I use it?
</heading>
<p><htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^sup" name="SUP">
stands for Software Update Protocol, and was developed by CMU
for keeping their development trees in sync. We used it to keep
remote sites in sync with our central development sources.
<p>SUP is not bandwidth friendly, and has been retired. The current
recommended method to keep your sources up to date is
<url url="../handbook/cvsup.html" name="Handbook entry on CVSup">
<sect1>
<heading>How cool is FreeBSD?</heading>
<p>Q. Has anyone done any temperature testing while running FreeBSD?
I know Linux runs cooler than dos, but have never seen a mention of
FreeBSD. It seems to run really hot.
<p>A. No, but we have done numerous taste tests on blindfolded
volunteers who have also had 250 micrograms of LSD-25
administered beforehand. 35% of the volunteers said that FreeBSD
tasted sort of orange, whereas Linux tasted like purple haze.
Neither group mentioned any particular variances in temperature
that I can remember. We eventually had to throw the results of
this survey out entirely anyway when we found that too many
volunteers were wandering out of the room during the tests, thus
skewing the results. I think most of the volunteers are at Apple
now, working on their new ``scratch and sniff'' GUI. It's a
funny old business we're in!
<p>Seriously, both FreeBSD and Linux uses the ``<tt/HLT/'' (halt)
instruction when the system is idle thus lowering its energy
consumption and therefore the heat it generates. Also if you
have APM (automatic power management) configured, then FreeBSD
can also put the CPU into a low power mode.
<sect1>
<heading>Who's scratching in my memory banks??</heading>
<p>Q. Is there anything "odd" that FreeBSD does when compiling the
kernel which would cause the memory to make a scratchy sound? When
compiling (and for a brief moment after recognizing the floppy drive
upon startup, as well), a strange scratchy sound emanates from what
appears to be the memory banks.
<p>A. Yes! You'll see frequent references to ``daemons'' in the BSD
documentation, and what most people don't know is that this
refers to genuine, non-corporeal entities that now possess your
computer. The scratchy sound coming from your memory is actually
high-pitched whispering exchanged among the daemons as they best
decide how to deal with various system administration tasks.
<p>If the noise gets to you, a good ``<tt>fdisk /mbr</tt>'' from DOS
will get rid of them, but don't be surprised if they react
adversely and try to stop you. In fact, if at any point during
the exercise you hear the satanic voice of Bill Gates coming from
the built-in speaker, take off running and don't ever look back!
Freed from the counterbalancing influence of the BSD daemons, the
twin demons of DOS and Windows are often able to re-assert total
control over your machine to the eternal damnation of your soul.
Given a choice, I think I'd prefer to get used to the scratchy
noises, myself!
<sect1>
<heading>What does 'MFC' mean?</heading>
<p>MFC is an acronym for 'Merged From -CURRENT.' It's used in the CVS
logs to denote when a change was migrated from the CURRENT to the STABLE
branches.
</sect>