doc/FAQ/misc.sgml

<!-- $Id: misc.sgml,v 1.1 1997-11-03 08:53:49 max 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 uses 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, no official "push" to switch to
      ELF as the default format has, as yet, been made. 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, it's not quite so simple since 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.  The only thing we actually lack with <tt/a.out/
      which <tt/ELF/ would give us is cleaner support for C++ constructors
      and destructors, among other similarly esoteric things, and it
      simply hasn't become much of a problem yet (and there is quite
      a bit of C++ code in FreeBSD's source tree).  Should that change,
      a migration may, at some point, be more seriously contemplated.

    <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/ resticted 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's
      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... and it would break
      Sun's NIS clients and no doubt cause other problems in interacting
      with other UNIX systems.

    <sect1>
      <heading>Can I run DOS binaries under FreeBSD?</heading>

      <p>Not yet, though BSDI has just donated their <tt/rundos/ DOS emulation
      subsystem which we're now working on integrating and enhancing.  Send
      mail to <url url="mailto:emulation@freebsd.org"
      name="The FreeBSD emulation discussion list"> if you're interested in
      joining this effort!

      <p>For now, 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!

  </sect>