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.
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.
To understand why FreeBSD uses the a.out format, you must
first know a little about the 3 currently "dominant" executable
formats for UNIX:
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
The SVR3 object format. The header now comprises a section
table, so you can have more than just .text, .data, and .bss
sections. The successor to FreeBSD tries to work around this problem somewhat by
providing a utility for branding a known for more information.
FreeBSD comes from the "classic" camp and has traditionally used
the 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.
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), 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 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,
You have to use either `` and
With the trailing slash, You'd think it'd be easy enough to change 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. Yes, starting with version 3.0 you can using BSDI's if you're interested in
joining this ongoing effort!
For pre-3.0 systems, there is a neat utility called
SUP is not bandwidth friendly, and has been retired. The current
recommended method to keep your sources up to date is
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.
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!
Seriously, both FreeBSD and Linux use the ``
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.
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.
If the noise gets to you, a good ``fdisk /mbr'' 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!
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.
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.' :-)
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.
-
One thousand, one hundred and seventy-two: + +
Twenty-three to complain to -current about the lights being + out; + +
Four to claim that it is a configuration problem, and that + such matters really belong on -questions; + +
Three to submit PRs about it, one of which is misfiled under + doc and consists only of "it's dark"; + +
One to commit an untested lightbulb which breaks buildworld, + then back it out five minutes later; + +
Eight to flame the PR originators for not including patches + in their PRs; + +
Five to complain about buildworld being broken; + +
Thirty-one to answer that it works for them, and they must + have cvsupped at a bad time; + +
One to post a patch for a new lightbulb to -hackers; + +
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; + +
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!? + +
Two hundred to complain about the color of the bicycle shed; + +
Three to point out that the patch breaks style(9); + +
Seventeen to complain that the proposed new lightbulb is + under GPL; + +
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; + +
Seven to move various portions of the thread to -chat and + -advocacy; +
One to commit the suggested lightbulb, even though it shines + dimmer than the old one; + +
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; + +
Forty-six to argue vociferously about the backing out of the + dim lightbulb and demanding a statement from -core; + +
Eleven to request a smaller lightbulb so it will fit their + Tamagotchi if we ever decide to port FreeBSD to that platform; + +
Seventy-three to complain about the SNR on -hackers and -chat + and unsubscribe in protest; + +
Thirteen to post "unsubscribe", "How do I unsubscribe?", or + "Please remove me from the list", followed by the usual footer; + +
One to commit a working lightbulb while everybody is too busy + flaming everybody else to notice; + +
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; + +
One to complain that the new lightbulb lacks fairings; + +
Nine (including the PR originators) to ask "what is MFC?"; + +
Fifty-seven to complain about the lights being out two weeks + after the bulb has been changed. + +