A: 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.
A: The simple answer is that free memory is wasted memory. Any memory that your programs don't actively allocate is used within the FreeBSD kernel as disk cache. The values shown by top(1) labelled as Inact, Cache, and Buf are all cached data at different aging levels. This cached data means the system does not have to access a slow disk again for data it has accessed recently, thus increasing overall performance. In general, a low value shown for Free memory in top(1) is good, provided it is not very low.
A: To understand why FreeBSD uses the ELF format, you must first know a little about the 3 currently "dominant" executable formats for UNIX:
Note: Prior to FreeBSD 3.x, FreeBSD used the a.out format.
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 a.out(5) for more details). It contains three loaded segments: .text, .data, and .bss plus a symbol table and a string table.
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 COFF, featuring Multiple sections and 32-bit or 64-bit possible values. One major drawback: 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.
FreeBSD tries to work around this problem somewhat by providing a utility for branding a known ELF executable with information about the ABI it's compliant with. See the man page for brandelf for more information.
FreeBSD comes from the "classic" camp and has traditionally used the 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 ELF binaries (and kernels) on a FreeBSD system, FreeBSD initially resisted the "push" to switch to ELF as the default format. Why? Well, when the Linux camp made their painful transition to ELF, it was not so much to flee the 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 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.
In FreeBSD's case, our shared library mechanism is based more closely on Sun's SunOS-style shared library mechanism and, as such, is very easy to use. However, starting with 3.0, FreeBSD officially supports ELF binaries as the default format. Even though the a.out executable format has served us well, the GNU people, who author the compiler tools we use, have dropped support for the 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 ELF support in future FreeBSD releases.
A: 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), 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 a.out format could offer. Things like COFF, ECOFF, and a few obscure others were invented and their limitations explored before things seemed to settle on ELF.
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 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 a.out format to allow all of these things to happen, and they basically worked for a time. In time, a.out wasn't up to handling all these problems without an ever increasing overhead in code and complexity. While ELF solved many of these problems, it would be painful to switch from the system that basically worked. So ELF had to wait until it was more painful to remain with a.out than it was to migrate to ELF.
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, ELF, shared libraries, C++ extnensions, etc. In addition, many vendors are releasing ELF binaries, and it is a good thing for FreeBSD to run them. And if it is running ELF binaries, why bother having 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.
ELF is more expressive than a.out and will allow more extensibility in the base system. The ELF tools are better maintained, and offer cross compilation support, which is important to many people. 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 a.out will be moved out of the GENERIC kernel, and eventually removed from the kernel once the need to run legacy a.out programs is past.
A: Symlinks do not have permissions, and by default, chmod(1) will not follow symlinks to change the permissions on the target file. So if you have a file, foo, and a symlink to that file, bar, then this command will always succeed.
% chmod g-w bar
However, the permissions on foo will not have changed.
WARNING the ``-R'' option does a RECURSIVE chmod. Be careful about specifying directories or symlinks to directories to chmod. If you want to change the permissions of a directory referenced by a symlink, use chmod without any options and follow the symlink with a trailing slash (``/''). For example, if ``foo'' is a symlink to directory ``bar'', and you want to change the permissions of ``foo'' (actually ``bar''), you would do something like:
chmod 555 foo/
With the trailing slash, chmod will follow the symlink, ``foo'', to change the permissions of the directory, ``bar''.
A: You'd think it'd be easy enough to change 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.
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.
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.
A: Yes, starting with version 3.0 you can using BSDI's doscmd DOS emulation which has been integrated and enhanced. Send mail to The FreeBSD emulation discussion list if you're interested in joining this ongoing effort!
For pre-3.0 systems, there is a neat utility called 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).
A: 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.
SUP is not bandwidth friendly, and has been retired. The current recommended method to keep your sources up to date is Handbook entry on CVSup
A: 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 ``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.
A: 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!
A: 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.
A: 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.
A: A repo-copy (which is a short form of ``repository copy'') refers to the direct copying of files within the CVS repository.
Without a repo-copy, if a file needed to be copied or moved to another place in the repository, the committer would run cvs add to put the file in its new location, and then cvs rm on the old file if the old copy was being removed.
The disadvantage of this method is that the history (i.e. the entries in the CVS logs) of the file would not be copied to the new location. As the FreeBSD Project considers this history very useful, a repository copy is often used instead. This is a process where one of the repository meisters will copy the files directly within the repository, rather than using the cvs program.
A: The really, really short answer is that you shouldn't. The somewhat longer answer is that just because you are capable of building a bikeshed doesn't mean you should stop others from building one just because you don't like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.
The longer and more complete answer is that after a very long argument about whether sleep(1) should take fractional second arguments, Poul-Henning Kamp <phk@FreeBSD.org> posted a long message entitled ``A bike shed (any colour will do) on greener grass...''. The appropriate portions of that message are quoted below.
``What is it about this bike shed?'' Some of you have asked me.
It's a long story, or rather it's an old story, but it is quite short actually. C. Northcote Parkinson wrote a book in the early 1960'ies, called ``Parkinson's Law'', which contains a lot of insight into the dynamics of management.
[snip a bit of commentary on the book]
In the specific example involving the bike shed, the other vital component is an atomic power-plant, I guess that illustrates the age of the book.
Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions.
Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. Richard P. Feynmann gives a couple of interesting, and very much to the point, examples relating to Los Alamos in his books.
A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is here.
In Denmark we call it ``setting your fingerprint''. It is about personal pride and prestige, it is about being able to point somewhere and say ``There! I did that.'' It is a strong trait in politicians, but present in most people given the chance. Just think about footsteps in wet cement.
|--Poul-Henning Kamp <phk@FreeBSD.org> on freebsd-hackers, October 2, 1999|
A: 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.
Nik Clayton <nik@FreeBSD.org> adds:
I was laughing quite hard at this.
And then I thought, "Hang on, shouldn't there be '1 to document it.' in that list somewhere?"
And then I was enlightened :-)
This entry is Copyright (c) 1999 Dag-Erling C. Smørgrav <des@FreeBSD.org>. Please do not reproduce without attribution.
For questions about FreeBSD, e-mail
For questions about this documentation, e-mail <doc@FreeBSD.org>.