326 lines
16 KiB
Text
326 lines
16 KiB
Text
<!-- $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>
|
|
|