path: root/FAQ/misc.sgml

<!-- $Id: misc.sgml,v 1.10 1999-01-28 00:00:50 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>
        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>