diff options
Diffstat (limited to 'FAQ/misc.sgml')
| -rw-r--r-- | FAQ/misc.sgml | 314 |
1 files changed, 0 insertions, 314 deletions
diff --git a/FAQ/misc.sgml b/FAQ/misc.sgml deleted file mode 100644 index 0a92dbbcb8..0000000000 --- a/FAQ/misc.sgml +++ /dev/null @@ -1,314 +0,0 @@ -<!-- $Id: misc.sgml,v 1.8 1998-11-02 03:20:46 jkoshy 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> - 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> - |