428 lines
20 KiB
Text
428 lines
20 KiB
Text
<!-- $Id: misc.sgml,v 1.17 1999-07-28 20:26:07 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>FreeBSD only appears to use more swap than Linux. In actual fact,
|
|
it does not. The main difference between FreeBSD and Linux in this
|
|
regard is that FreeBSD will proactively move entirely idle, unused pages
|
|
of main memory into swap in order to make more main memory available
|
|
for active use. Linux tends to only move pages to swap as a last resort.
|
|
The perceived heavier use of swap is balanced by the more efficient use
|
|
of main memory.
|
|
|
|
<p>Note that while FreeBSD is proactive in this regard, it does not
|
|
arbitrarily decide to swap pages when the system is truely idle. Thus
|
|
you will not find your system all paged out when you get up in the
|
|
morning after leaving it idle overnight.
|
|
|
|
<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/synching.html#CVSUP" 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 use 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.
|
|
|
|
<sect1>
|
|
<heading>What does 'BSD' mean?</heading>
|
|
|
|
<p>It stands for something in a secret language that only
|
|
members can know. It doesn't translate literally but its ok to
|
|
tell you that BSD's translation is something between, 'Formula-1
|
|
Racing Team', 'Penguins are tasty snacks', and 'We have a better
|
|
sense of humor than Linux.' :-)
|
|
|
|
<p>Seriously, BSD is an acronym for 'Berkeley Software
|
|
Distribution', which is the name the Berkeley CSRG (Computer
|
|
Systems Research Group) chose for their Unix distribution way
|
|
back when.
|
|
|
|
<sect1>
|
|
<heading>How many FreeBSD hackers does it take to change a lightbulb?</heading>
|
|
|
|
<p>One thousand, one hundred and seventy-two:
|
|
|
|
<p>Twenty-three to complain to -current about the lights being
|
|
out;
|
|
|
|
<p>Four to claim that it is a configuration problem, and that
|
|
such matters really belong on -questions;
|
|
|
|
<p>Three to submit PRs about it, one of which is misfiled under
|
|
doc and consists only of "it's dark";
|
|
|
|
<p>One to commit an untested lightbulb which breaks buildworld,
|
|
then back it out five minutes later;
|
|
|
|
<p>Eight to flame the PR originators for not including patches
|
|
in their PRs;
|
|
|
|
<p>Five to complain about buildworld being broken;
|
|
|
|
<p>Thirty-one to answer that it works for them, and they must
|
|
have cvsupped at a bad time;
|
|
|
|
<p>One to post a patch for a new lightbulb to -hackers;
|
|
|
|
<p>One to complain that he had patches for this three years ago,
|
|
but when he sent them to -current they were just ignored, and he
|
|
has had bad experiences with the PR system; besides, the
|
|
proposed new lightbulb is non-reflexive;
|
|
|
|
<p>Thirty-seven to scream that lightbulbs do not belong in the
|
|
base system, that committers have no right to do things like
|
|
this without consulting the Community, and WHAT IS -CORE DOING
|
|
ABOUT IT!?
|
|
|
|
<p>Two hundred to complain about the color of the bicycle shed;
|
|
|
|
<p>Three to point out that the patch breaks style(9);
|
|
|
|
<p>Seventeen to complain that the proposed new lightbulb is
|
|
under GPL;
|
|
|
|
<p>Five hundred and eighty-six to engage in a flame war about
|
|
the comparative advantages of the GPL, the BSD license, the MIT
|
|
license, the NPL, and the personal hygiene of unnamed FSF
|
|
founders;
|
|
|
|
<p>Seven to move various portions of the thread to -chat and
|
|
-advocacy;
|
|
|
|
<p>One to commit the suggested lightbulb, even though it shines
|
|
dimmer than the old one;
|
|
|
|
<p>Two to back it out with a furious flame of a commit message,
|
|
arguing that FreeBSD is better off in the dark than with a dim
|
|
lightbulb;
|
|
|
|
<p>Forty-six to argue vociferously about the backing out of the
|
|
dim lightbulb and demanding a statement from -core;
|
|
|
|
<p>Eleven to request a smaller lightbulb so it will fit their
|
|
Tamagotchi if we ever decide to port FreeBSD to that platform;
|
|
|
|
<p>Seventy-three to complain about the SNR on -hackers and -chat
|
|
and unsubscribe in protest;
|
|
|
|
<p>Thirteen to post "unsubscribe", "How do I unsubscribe?", or
|
|
"Please remove me from the list", followed by the usual footer;
|
|
|
|
<p>One to commit a working lightbulb while everybody is too busy
|
|
flaming everybody else to notice;
|
|
|
|
<p>Thirty-one to point out that the new lightbulb would shine
|
|
0.364% brighter if compiled with TenDRA (although it will have
|
|
to be reshaped into a cube), and that FreeBSD should therefore
|
|
switch to TenDRA instead of EGCS;
|
|
|
|
<p>One to complain that the new lightbulb lacks fairings;
|
|
|
|
<p>Nine (including the PR originators) to ask "what is MFC?";
|
|
|
|
<p>Fifty-seven to complain about the lights being out two weeks
|
|
after the bulb has been changed.
|
|
|
|
<p><em><url url="mailto:nik@FreeBSD.org" name="Nik Clayton">
|
|
adds:</em>
|
|
|
|
<p><em/I was laughing quite hard at this./
|
|
|
|
<p><em/And then I thought, "Hang on, shouldn't there be '1 to
|
|
document it.' in that list somewhere?"/
|
|
|
|
<p><em/And then I was enlightened :-)/
|
|
|
|
|
|
</sect>
|