diff --git a/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml b/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml index 5cf6ac0b1c..45702bf0db 100644 --- a/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml @@ -1,609 +1,609 @@ Introduction FreeBSD is a 4.4BSD-Lite2 based operating system for Intel architecture (x86) and DEC Alpha based computer systems. For an overview of FreeBSD, see FreeBSD in a nutshell. For a history of the project, read a brief history of FreeBSD. To see a description of the latest release, read about the current release. If you are interested in contributing something to the FreeBSD project (code, equipment, sacks of unmarked bills), please see about contributing to FreeBSD. FreeBSD in a Nutshell FreeBSD is a state of the art operating system for computer systems based on both the Intel CPU architecture, which includes the 386 and Pentium family of processors as well as Intel compatible CPUs from Cyrix and AMD, and the DEC Alpha architecture. FreeBSD provides you with many advanced features previously available only on much more expensive systems. These features include: Preemptive multitasking with dynamic priority adjustment to ensure smooth and fair sharing of the computer between applications and users, even under the heaviest of loads. Multiuser access means that many people can use a FreeBSD system simultaneously for a variety of things. This means, for example, that system peripherals such as printers and tape drives are properly shared between all users on the system or the network and that individual resource limits can be placed on users or groups of users, protecting critical system resources from over-use. Strong TCP/IP networking with support for industry standards such as SLIP, PPP, NFS, DHCP and NIS support. This means that your FreeBSD machine can inter-operate easily with other systems as well act as an enterprise server, providing vital functions such as NFS (remote file access) and e-mail services or putting your organization on the Internet with WWW, ftp, routing and firewall (security) services. Memory protection ensures that applications (or users) cannot interfere with each other. One application crashing will not affect others in any way. FreeBSD is a 32-bit operating system (64-bit on the Alpha) and was designed as such from the ground up. The industry standard X Window System (X11R6) provides a graphical user interface (GUI) for the cost of a common VGA card and monitor and comes with full sources. Binary compatibility with many programs built for Linux, SCO, SVR4, BSDI and NetBSD. Thousands of ready-to-run applications are available from the FreeBSD ports and packages collection. Why search the net when you can find it all right here? Thousands of additional and easy-to-port applications available on the Internet. FreeBSD is source code compatible with most popular commercial Unix systems and thus most applications require few, if any, changes to compile. Demand paged virtual memory and “merged VM/buffer cache” design efficiently satisfies applications with large appetites for memory while still maintaining interactive response to other users. SMP support for machines with multiple CPUs (Intel only). A full complement of C, C++ and Fortran development tools. Many additional languages for advanced research and development are also available in the ports and packages collection. Source code for the entire system means you have the greatest degree of control over your environment. Why be locked into a proprietary solution and at the mercy of your vendor when you can have a truly Open System? Extensive on-line documentation. And many more! FreeBSD is based on the 4.4BSD-Lite2 release from Computer Systems Research Group (CSRG) at the University of California at Berkeley, and carries on the distinguished tradition of BSD systems development. In addition to the fine work provided by CSRG, the FreeBSD Project has put in many thousands of hours in fine tuning the system for maximum performance and reliability in real-life load situations. As many of the commercial giants struggle to field PC operating systems with such features, performance and reliability, FreeBSD can offer them now! The applications to which FreeBSD can be put are truly limited only by your own imagination. From software development to factory automation, inventory control to azimuth correction of remote satellite antennae; if it can be done with a commercial UNIX product then it is more than likely that you can do it with FreeBSD, too! FreeBSD also benefits significantly from the literally thousands of high quality applications developed by research centers and universities around the world, often available at little to no cost. Commercial applications are also available and appearing in greater numbers every day. Because the source code for FreeBSD itself is generally available, the system can also be customized to an almost unheard of degree for special applications or projects, and in ways not generally possible with operating systems from most major commercial vendors. Here is just a sampling of some of the applications in which people are currently using FreeBSD: Internet Services: The robust TCP/IP networking built into FreeBSD makes it an ideal platform for a variety of Internet services such as: FTP servers World Wide Web servers (standard or secure [SSL]) Firewalls and NAT ("IP masquerading") gateways. Electronic Mail servers USENET News or Bulletin Board Systems And more... With FreeBSD, you can easily start out small with an inexpensive 386 class PC and upgrade all the way up to a quad-processor Xeon with RAID storage as your enterprise grows. Education: Are you a student of computer science or a related engineering field? There is no better way of learning about operating systems, computer architecture and networking than the hands on, under the hood experience that FreeBSD can provide. A number of freely available CAD, mathematical and graphic design packages also make it highly useful to those whose primary interest in a computer is to get other work done! Research: With source code for the entire system available, FreeBSD is an excellent platform for research in operating systems as well as other branches of computer science. FreeBSD's freely available nature also makes it possible for remote groups to collaborate on ideas or shared development without having to worry about special licensing agreements or limitations on what may be discussed in open forums. Networking: Need a new router? A name server (DNS)? A firewall to keep people out of your internal network? FreeBSD can easily turn that unused 386 or 486 PC sitting in the corner into an advanced router with sophisticated packet filtering capabilities. X Window workstation: FreeBSD is a fine choice for an inexpensive X terminal solution, either using the freely available XFree86 server or one of the excellent commercial servers provided by X Inside. Unlike an X terminal, FreeBSD allows many applications to be run locally, if desired, thus relieving the burden on a central server. FreeBSD can even boot “diskless”, making individual workstations even cheaper and easier to administer. Software Development: The basic FreeBSD system comes with a full complement of development tools including the renowned GNU C/C++ compiler and debugger. FreeBSD is available in both source and binary form on CDROM and via anonymous ftp. See Obtaining FreeBSD for more details. A Brief History of FreeBSD Contributed by &a.jkh;. The FreeBSD project had its genesis in the early part of 1993, partially as an outgrowth of the “Unofficial 386BSD Patchkit” by the patchkit's last 3 coordinators: Nate Williams, Rod Grimes and myself. Our original goal was to produce an intermediate snapshot of 386BSD in order to fix a number of problems with it that the patchkit mechanism just was not capable of solving. Some of you may remember the early working title for the project being “386BSD 0.5” or “386BSD Interim” in reference to that fact. 386BSD was Bill Jolitz's operating system, which had been up to that point suffering rather severely from almost a year's worth of neglect. As the patchkit swelled ever more uncomfortably with each passing day, we were in unanimous agreement that something had to be done and decided to try and assist Bill by providing this interim “cleanup” snapshot. Those plans came to a rude halt when Bill Jolitz suddenly decided to withdraw his sanction from the project and without any clear indication of what would be done instead. It did not take us long to decide that the goal remained worthwhile, even without Bill's support, and so we adopted the name “FreeBSD”, coined by David Greenman. Our initial objectives were set after consulting with the system's current users and, once it became clear that the project was on the road to perhaps even becoming a reality, I contacted Walnut Creek CDROM with an eye towards improving FreeBSD's distribution channels for those many unfortunates without easy access to the Internet. Walnut Creek CDROM not only supported the idea of distributing FreeBSD on CD but went so far as to provide the project with a machine to work on and a fast Internet connection. Without Walnut Creek CDROM's almost unprecedented degree of faith in what was, at the time, a completely unknown project, it is quite unlikely that FreeBSD would have gotten as far, as fast, as it has today. The first CDROM (and general net-wide) distribution was FreeBSD 1.0, released in December of 1993. This was based on the 4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components also provided by 386BSD and the Free Software Foundation. It was a fairly reasonable success for a first offering, and we followed it with the highly successful FreeBSD 1.1 release in May of 1994. Around this time, some rather unexpected storm clouds formed on the horizon as Novell and U.C. Berkeley settled their long-running lawsuit over the legal status of the Berkeley Net/2 tape. A condition of that settlement was U.C. Berkeley's concession that large parts of Net/2 were “encumbered” code and the property of Novell, who had in turn acquired it from AT&T some time previously. What Berkeley got in return was Novell's “blessing” that the 4.4BSD-Lite release, when it was finally released, would be declared unencumbered and all existing Net/2 users would be strongly encouraged to switch. This included FreeBSD, and the project was given until the end of July 1994 to stop shipping its own Net/2 based product. Under the terms of that agreement, the project was allowed one last release before the deadline, that release being FreeBSD 1.1.5.1. FreeBSD then set about the arduous task of literally re-inventing itself from a completely new and rather incomplete set of 4.4BSD-Lite bits. The “Lite” releases were light in part because Berkeley's CSRG had removed large chunks of code required for actually constructing a bootable running system (due to various legal requirements) and the fact that the Intel port of 4.4 was highly incomplete. It took the project until November of 1994 to make this transition, at which point it released FreeBSD 2.0 to the net and on CDROM (in late December). Despite being still more than a little rough around the edges, the release was a significant success and was followed by the more robust and easier to install FreeBSD 2.0.5 release in June of 1995. We released FreeBSD 2.1.5 in August of 1996, and it appeared to be popular enough among the ISP and commercial communities that another release along the 2.1-STABLE branch was merited. This was FreeBSD 2.1.7.1, released in February 1997 and capping the end of mainstream development on 2.1-STABLE. Now in maintenance mode, only security enhancements and other critical bug fixes will be done on this branch (RELENG_2_1_0). FreeBSD 2.2 was branched from the development mainline (“-CURRENT”) in November 1996 as the RELENG_2_2 branch, and the first full release (2.2.1) was released in April, 1997. Further releases along the 2.2 branch were done in the Summer and Fall of '97, the last of which (2.2.8) appeared in November, 1998. The first official 3.0 release appeared in October, 1998 and spelled the beginning of the end for the 2.2 branch. The tree branched again on Jan 20, 1999, leading to the 4.0-CURRENT and 3.X-STABLE branches. From 3.X-STABLE, 3.1 was released on February 15th, 1999 and 3.2 on May 15, 1999. The most current release on this branch is 3.3, which was released on September 16th, 1999. Long term development projects continue to take place in the 4.0-CURRENT branch, and SNAPshot releases of 4.0 on CDROM (and, of course, on the net) are continually made available as work progresses. FreeBSD Project Goals Contributed by &a.jkh;. The goals of the FreeBSD Project are to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we are definitely not prepared to insist on it. We believe that our first and foremost “mission” is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, I believe, one of the most fundamental goals of Free Software and one that we enthusiastically support. That code in our source tree which falls under the GNU General Public License (GPL) or Library General Public License (LGPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software we do, however, prefer software submitted under the more relaxed BSD copyright when it's a reasonable option to do so. The FreeBSD Development Model Contributed by &a.asami;. The development of FreeBSD is a very open and flexible process, FreeBSD being literally built from the contributions of hundreds of people around the world, as can be seen from our list of contributors. We are constantly on the lookout for new developers and ideas, and those interested in becoming more closely involved with the project need simply contact us at the &a.hackers;. The &a.announce; is also available to those wishing to make other FreeBSD users aware of major areas of work. Useful things to know about the FreeBSD project and its development process, whether working independently or in close cooperation: The CVS repository The central source tree for FreeBSD is maintained by CVS (Concurrent Version System), a freely available source code control tool which comes bundled with FreeBSD. The primary CVS repository resides on a machine in Concord CA, USA from where it is replicated to numerous mirror machines throughout the world. The CVS tree, as well as the -CURRENT and -STABLE trees which are checked out of it, can be easily replicated to your own machine as well. Please refer to the Synchronizing your source tree section for more information on doing this. The committers list The committers are the people who have write access to the CVS tree, and are thus authorized to make modifications to the FreeBSD source (the term “committer” comes from the &man.cvs.1; commit command, which is used to bring new changes into the CVS repository). The best way of making submissions for review by the committers list is to use the &man.send-pr.1; command, though if something appears to be jammed in the system then you may also reach them by sending mail - to committers@FreeBSD.org. + to cvs-committers@FreeBSD.org. The FreeBSD core team The FreeBSD core team would be equivalent to the board of directors if the FreeBSD Project were a company. The primary task of the core team is to make sure the project, as a whole, is in good shape and is heading in the right directions. Inviting dedicated and responsible developers to join our group of committers is one of the functions of the core team, as is the recruitment of new core team members as others move on. Most current members of the core team started as committers whose addiction to the project got the better of them. Some core team members also have specific areas of responsibility, meaning that they are committed to ensuring that some large portion of the system works as advertised. Most members of the core team are volunteers when it comes to FreeBSD development and do not benefit from the project financially, so “commitment” should also not be misconstrued as meaning “guaranteed support.” The “board of directors” analogy above is not actually very accurate, and it may be more suitable to say that these are the people who gave up their lives in favor of FreeBSD against their better judgement! ;-) Outside contributors Last, but definitely not least, the largest group of developers are the users themselves who provide feedback and bug-fixes to us on an almost constant basis. The primary way of keeping in touch with FreeBSD's more non-centralized development is to subscribe to the &a.hackers; (see mailing list info) where such things are discussed. The list of those who have contributed something which made its way into our source tree is a long and growing one, so why not join it by contributing something back to FreeBSD today? :-) Providing code is not the only way of contributing to the project; for a more complete list of things that need doing, please refer to the how to contribute section in this handbook. In summary, our development model is organized as a loose set of concentric circles. The centralized model is designed for the convenience of the users of FreeBSD, who are thereby provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent application programs that the users can easily install and use, and this model works very well in accomplishing that. All we ask of those who would join us as FreeBSD developers is some of the same dedication its current people have to its continued success! About the Current Release FreeBSD is a freely available, full source 4.4BSD-Lite2 based release for Intel i386/i486/Pentium/PentiumPro/Pentium II (or compatible) and DEC Alpha based computer systems. It is based primarily on software from U.C. Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD, 386BSD, and the Free Software Foundation. Since our release of FreeBSD 2.0 in late 94, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped virtual memory system with a merged VM/file buffer cache that not only increases performance, but reduces FreeBSD's memory footprint, making a 5MB configuration a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial-on-demand PPP, integrated DHCP support, an improved SCSI subsystem, ISDN support, support for ATM, FDDI, Fast and Gigabit Ethernet (1000Mbit) adapters, improved support for the latest Adaptec controllers and many hundreds of bug fixes. We have also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this (constantly evolving) process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with hundreds of commonly sought-after programs. By mid-November 1999, there were nearly 2800 ports! The list of ports ranges from http (WWW) servers, to games, languages, editors and almost everything in between. The entire ports collection requires approximately 50MB of storage, all ports being expressed as “deltas” to their original sources. This makes it much easier for us to update ports, and greatly reduces the disk space demands made by the older 1.0 ports collection. To compile a port, you simply change to the directory of the program you wish to install, type make all followed by make install after successful compilation and let the system do the rest. The full original distribution for each port you build is retrieved dynamically off the CDROM or a local ftp site, so you need only enough disk space to build the ports you want. (Almost) every port is also provided as a pre-compiled “package” which can be installed with a simple command (pkg_add) by those who do not wish to compile their own ports from source. A number of additional documents which you may find very helpful in the process of installing and using FreeBSD may now also be found in the /usr/share/doc directory on any machine running FreeBSD 2.1 or later. You may view the locally installed manuals with any HTML capable browser using the following URLs: The FreeBSD Handbook file:/usr/share/doc/handbook/handbook.html The FreeBSD FAQ file:/usr/share/doc/FAQ/FAQ.html You can also visit the master (and most frequently updated) copies at http://www.FreeBSD.org/. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. There is an add-on package to the core distribution, for use only in the United States, that contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely (from outside the U.S.) exportable European distribution of DES for our non-U.S. users also exists and is described in the FreeBSD FAQ. If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from different hosts (Suns, DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require! We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. If you are outside (or even inside) the U.S., give it a try! diff --git a/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml b/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml index a95f3724d0..fed0b12ec2 100644 --- a/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml @@ -1,1007 +1,1007 @@ Linux Mode Contributed by &a.handy; and &a.rich; How to Install the Linux Mode Linux binary compatibility in FreeBSD has reached a point where it is possible to run a large fraction of Linux binaries in both a.out and ELF format. The Linux compatibility in the 2.1-STABLE branch is capable of running Linux DOOM and Mathematica; the version present in &rel.current;-RELEASE is vastly more capable and runs all these as well as Oracle8, WordPerfect, StarOffice, Acrobat, Quake, Abuse, IDL, and netrek for Linux and a whole host of other programs. There are some Linux-specific operating system features that are not supported on FreeBSD. Linux binaries will not work on FreeBSD if they overly use the Linux /proc filesystem (which is different from the optional FreeBSD /proc filesystem) or i386-specific calls, such as enabling virtual 8086 mode. Depending on which version of FreeBSD you are running, how you get Linux mode up will vary somewhat: Installing Linux Mode in 3.0-RELEASE and later It is no longer necessary to specify options LINUX or options COMPAT_LINUX. Linux binary compatibility is done with an KLD object (“Kernel LoaDable object”) so it can be installed on the fly without having to reboot. You will need the following things in your startup files, however: In /etc/rc.conf, you need the following line: linux_enable=YES This, in turn, triggers the following action in /etc/rc.i386: # Start the Linux binary compatibility if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi If you want to verify that the KLD is loaded, kldstat will do that: &prompt.user; kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko If for some reason you do not want to or cannot load the Linux KLD, then statically link the binary compatibility in the kernel by adding options LINUX to your kernel config file. Then run config and install the new kernel as described in the kernel configuration section. Installing Linux Mode in 2.2.2-RELEASE and later 2.2.x versions It is no longer necessary to specify options LINUX or options COMPAT_LINUX. Linux binary compatibility is done with an LKM (“Loadable Kernel Module”) so it can be installed on the fly without having to reboot. You will need the following things in your startup files, however: In /etc/rc.conf, you need the following line: linux_enable=YES This, in turn, triggers the following action in /etc/rc.i386: # Start the Linux binary emulation if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi If you want to verify that the LKM is running, modstat will do that: &prompt.user; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod However, there have been reports that this fails on some 2.2-RELEASE and later systems. If for some reason you cannot load the Linux LKM, then statically link the Linux compatibility in the kernel by adding options LINUX to your kernel config file. Then run config and install the new kernel as described in the kernel configuration section. Installing Linux Mode in 2.1-STABLE The GENERIC kernel in 2.1-STABLE is not configured for Linux compatibility so you must reconfigure your kernel for it. There are two ways to do this: 1. linking the binary compatibility statically in the kernel itself and 2. configuring your kernel to dynamically load the Linux loadable kernel module (LKM). To enable Linux binary compatibility, add the following to your configuration file (c.f. /sys/i386/conf/LINT): options COMPAT_LINUX If you want to run doom or other applications that need shared memory, also add the following. options SYSVSHM The Linux system calls require 4.3BSD system call compatibility. So make sure you have the following. options "COMPAT_43" If you prefer to statically link the binary compatibility in the kernel rather than use the loadable kernel module (LKM), then add options LINUX Then run config and install the new kernel as described in the kernel configuration section. If you decide to use the LKM you must also install the loadable module. A mismatch of versions between the kernel and loadable module can cause the kernel to crash, so the safest thing to do is to reinstall the LKM when you install the kernel. &prompt.root; cd /usr/src/lkm/linux &prompt.root; make all install Once you have installed the kernel and the LKM, you can invoke linux as root to load the LKM. &prompt.root; linux Linux emulator installed Module loaded as ID 0 To see whether the LKM is loaded, run modstat. &prompt.user; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator You can cause the LKM to be loaded when the system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and 2.1-STABLE enable it in /etc/sysconfig linux=YES by changing it from NO to YES. FreeBSD 2.1 RELEASE and earlier do not have such a line and on those you will need to edit /etc/rc.local to add the following line. linux Installing Linux Runtime Libraries Installing using the linux_base port Most Linux applications use shared libraries, so you are still not done until you install the shared libraries. It is possible to do this by hand, however, it is vastly simpler to just grab the linux_base port: &prompt.root; cd /usr/ports/emulators/linux_base &prompt.root; make all install and you should have working Linux binary compatibility. Legend (and the mail archives :-) seems to hold that Linux mode works best with Linux binaries linked against the ZMAGIC libraries; QMAGIC libraries (such as those used in Slackware V2.0) may tend to give the Linux mode heartburn. Also, expect some programs to complain about incorrect minor versions of the system libraries. In general, however, this does not seem to be a problem. Installing libraries manually If you do not have the “ports” distribution, you can install the libraries by hand instead. You will need the Linux shared libraries that the program depends on and the runtime linker. Also, you will need to create a "shadow root" directory, /compat/linux, for Linux libraries on your FreeBSD system. Any shared libraries opened by Linux programs run under FreeBSD will look in this tree first. So, if a Linux program loads, for example, /lib/libc.so, FreeBSD will first try to open /compat/linux/lib/libc.so, and if that does not exist then it will try /lib/libc.so. Shared libraries should be installed in the shadow tree /compat/linux/lib rather than the paths that the Linux ld.so reports. FreeBSD-2.2-RELEASE and later works slightly differently with respect to /compat/linux: all files, not just libraries, are searched for from the “shadow root” /compat/linux. Generally, you will need to look for the shared libraries that Linux binaries depend on only the first few times that you install a Linux program on your FreeBSD system. After a while, you will have a sufficient set of Linux shared libraries on your system to be able to run newly imported Linux binaries without any extra work. How to install additional shared libraries What if you install the linux_base port and your application still complains about missing shared libraries? How do you know which shared libraries Linux binaries need, and where to get them? Basically, there are 2 possibilities (when following these instructions: you will need to be root on your FreeBSD system to do the necessary installation steps). If you have access to a Linux system, see what shared libraries the application needs, and copy them to your FreeBSD system. Example: you have just ftp'ed the Linux binary of Doom. Put it on the Linux system you have access to, and check which shared libraries it needs by running ldd linuxxdoom: &prompt.user; ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 You would need to get all the files from the last column, and put them under /compat/linux, with the names in the first column as symbolic links pointing to them. This means you eventually have these files on your FreeBSD system: /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 Note that if you already have a Linux shared library with a matching major revision number to the first column of the ldd output, you will not need to copy the file named in the last column to your system, the one you already have should work. It is advisable to copy the shared library anyway if it is a newer version, though. You can remove the old one, as long as you make the symbolic link point to the new one. So, if you have these libraries on your system: /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 and you find a new binary that claims to require a later version according to the output of ldd: libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 If it is only one or two versions out of date in the in the trailing digit then do not worry about copying /lib/libc.so.4.6.29 too, because the program should work fine with the slightly older version. However, if you like you can decide to replace the libc.so anyway, and that should leave you with: /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 The symbolic link mechanism is only needed for Linux binaries. The FreeBSD runtime linker takes care of looking for matching major revision numbers itself and you do not need to worry about it. Configuring the <filename>ld.so</filename> — for FreeBSD 2.2-RELEASE and later This section applies only to FreeBSD 2.2-RELEASE and later. Those running 2.1-STABLE should skip this section. Finally, if you run FreeBSD 2.2-RELEASE you must make sure that you have the Linux runtime linker and its config files on your system. You should copy these files from the Linux system to their appropriate place on your FreeBSD system (to the /compat/linux tree): /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config If you do not have access to a Linux system, you should get the extra files you need from various ftp sites. Information on where to look for the various files is appended below. For now, let us assume you know where to get the files. Retrieve the following files (all from the same ftp site to avoid any version mismatches), and install them under /compat/linux (i.e. /foo/bar is installed as /compat/linux/foo/bar): /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so ldconfig and ldd do not necessarily need to be under /compat/linux; you can install them elsewhere in the system too. Just make sure they do not conflict with their FreeBSD counterparts. A good idea would be to install them in /usr/local/bin as ldconfig-linux and ldd-linux. Create the file /compat/linux/etc/ld.so.conf, containing the directories in which the Linux runtime linker should look for shared libraries. It is a plain text file, containing a directory name on each line. /lib and /usr/lib are standard, you could add the following: /usr/X11/lib /usr/local/lib When a Linux binary opens a library such as /lib/libc.so the Linux ABI support maps the name to /compat/linux/lib/libc.so internally. All Linux libraries should be installed under /compat/linux (e.g. /compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so, etc.) in order for the Linux ABI loader to find them. Those running FreeBSD 2.2-RELEASE should run the Linux ldconfig program. &prompt.root cd /compat/linux/lib &prompt.root; /compat/linux/sbin/ldconfig ldconfig is statically linked, so it does not need any shared libraries to run. It creates the file /compat/linux/etc/ld.so.cache which contains the names of all the shared libraries and should be rerun to recreate this file whenever you install additional shared libraries. On 2.1-STABLE do not install /compat/linux/etc/ld.so.cache or run ldconfig; in 2.1-STABLE the syscalls are implemented differently and ldconfig is not needed or used. You should now be set up for Linux binaries which only need a shared libc. You can test this by running the Linux ldd on itself. Supposing that you have it installed as ldd-linux, it should produce something like: &prompt.root; ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 This being done, you are ready to install new Linux binaries. Whenever you install a new Linux program, you should check if it needs shared libraries, and if so, whether you have them installed in the /compat/linux tree. To do this, you run the Linux version ldd on the new program, and watch its output. ldd (see also the manual page for &man.ldd.1;) will print a list of shared libraries that the program depends on, in the form majorname (jumpversion) => fullname. If it prints not found instead of fullname it means that you need an extra library. The library needed is shown in majorname and will be of the form libXXXX.so.N. You will need to find a libXXXX.so.N.mm on a Linux ftp site, and install it on your system. The XXXX (name) and N (major revision number) should match; the minor number(s) mm are less important, though it is advised to take the most recent version. Installing Linux ELF binaries ELF binaries sometimes require an extra step of “branding”. If you attempt to run an unbranded ELF binary, you will get an error message like the following; &prompt.user; ./my-linux-elf-binary ELF binary type not known Abort To help the FreeBSD kernel distinguish between a FreeBSD ELF binary from a Linux binary, use the &man.brandelf.1; utility. &prompt.user; brandelf -t Linux my-linux-elf-binary The GNU toolchain now places the appropriate branding information into ELF binaries automatically, so you should be needing to do this step increasingly rarely in future. Configuring the host name resolver If DNS does not work or you get the messages resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword then you need to configure a /compat/linux/etc/host.conf file containing: order hosts, bind multi on where the order here specifies that /etc/hosts is searched first and DNS is searched second. When /compat/linux/etc/host.conf is not installed linux applications find FreeBSD's /etc/host.conf and complain about the incompatible FreeBSD syntax. You should remove bind if you have not configured a name-server using the /etc/resolv.conf file. Lastly, those who run 2.1-STABLE need to set an the RESOLV_HOST_CONF environment variable so that applications will know how to search the host tables. If you run FreeBSD 2.2-RELEASE or later, you can skip this. For the /bin/csh shell use: &prompt.user; setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf For /bin/sh use: &prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF Finding the necessary files The information below is valid as of the time this document was written, but certain details such as names of ftp sites, directories and distribution names may have changed by the time you read this. Linux is distributed by several groups that make their own set of binaries that they distribute. Each distribution has its own name, like “Slackware” or “Yggdrasil”. The distributions are available on a lot of ftp sites. Sometimes the files are unpacked, and you can get the individual files you need, but mostly they are stored in distribution sets, usually consisting of subdirectories with gzipped tar files in them. The primary ftp sites for the distributions are: sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions Some European mirrors: ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/unix/linux src.doc.ic.ac.uk:/packages/linux/distributions For simplicity, let us concentrate on Slackware here. This distribution consists of a number of subdirectories, containing separate packages. Normally, they are controlled by an install program, but you can retrieve files “by hand” too. First of all, you will need to look in the contents subdirectory of the distribution. You will find a lot of small text files here describing the contents of the separate packages. The fastest way to look something up is to retrieve all the files in the contents subdirectory, and grep through them for the file you need. Here is an example of a list of files that you might need, and in which contents-file you will find it by grepping through them: Library Package ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf_lib libXt.so.6.0 xf_lib libX11.so.3 oldlibs libXt.so.3 oldlibs So, in this case, you will need the packages ldso, shlibs, xf_lib and oldlibs. In each of the contents-files for these packages, look for a line saying PACKAGE LOCATION, it will tell you on which “disk” the package is, in our case it will tell us in which subdirectory we need to look. For our example, we would find the following locations: Package Location ldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9 The locations called “diskXX” refer to the slakware/XX subdirectories of the distribution, others may be found in the contrib subdirectory. In this case, we could now retrieve the packages we need by retrieving the following files (relative to the root of the Slackware distribution tree): slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs.tgz slakware/x9/xf_lib.tgz Extract the files from these gzipped tarfiles in your /compat/linux directory (possibly omitting or afterwards removing files you do not need), and you are done. See also: ftp://ftp.FreeBSD.org/pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README and /usr/src/sys/i386/ibcs2/README.iBCS2 How to Install Mathematica on FreeBSD Contributed by &a.rich; and &a.chuck; This document shows how to install the Linux binary distribution of Mathematica 2.2 on FreeBSD 2.1. Mathematica supports Linux but not FreeBSD as it stands. So once you have configured your system for Linux compatibility you have most of what you need to run Mathematica. For those who already have the student edition of Mathematica for DOS the cost of upgrading to the Linux version at the time this was written, March 1996, was $45.00. It can be ordered directly from Wolfram at (217) 398-6500 and paid for by credit card. Unpacking the Mathematica distribution The binaries are currently distributed by Wolfram on CDROM. The CDROM has about a dozen tar files, each of which is a binary distribution for one of the supported architectures. The one for Linux is named LINUX.TAR. You can, for example, unpack this into /usr/local/Mathematica: &prompt.root; cd /usr/local &prompt.root; mkdir Mathematica &prompt.root; cd Mathematica &prompt.root; tar -xvf /cdrom/LINUX.TAR Obtaining your Mathematica Password Before you can run Mathematica you will have to obtain a password from Wolfram that corresponds to your “machine ID”. Once you have installed the Linux compatibility runtime libraries and unpacked Mathematica you can obtain the “machine ID” by running the program mathinfo in the Install directory. &prompt.root; cd /usr/local/Mathematica/Install &prompt.root; mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 So, for example, the “machine ID” of richc is 9845-03452-90255. You can ignore the message about the ioctl that is not implemented. It will not prevent Mathematica from running in any way and you can safely ignore it, though you will see the message every time you run Mathematica. When you register with Wolfram, either by email, phone or fax, you will give them the “machine ID” and they will respond with a corresponding password consisting of groups of numbers. You need to add them both along with the machine name and license number in your mathpass file. You can do this by invoking: &prompt.root; cd /usr/local/Mathematica/Install &prompt.root; math.install It will ask you to enter your license number and the Wolfram supplied password. If you get them mixed up or for some reason the math.install fails, that is OK; you can simply edit the file mathpass in this same directory to correct the info manually. After getting past the password, math.install will ask you if you accept the install defaults provided, or if you want to use your own. If you are like us and distrust all install programs, you probably want to specify the actual directories. Beware. Although the math.install program asks you to specify directories, it will not create them for you, so you should perhaps have a second window open with another shell so that you can create them before you give them to the install program. Or, if it fails, you can create the directories and then restart the math.install program. The directories we chose to create beforehand and specify to math.install were: /usr/local/Mathematica/bin for binaries /usr/local/Mathematica/man/man1 for man pages /usr/local/Mathematica/lib/X11 for the XKeysymb file You can also tell it to use /tmp/math.record for the system record file, where it puts logs of sessions. After this math.install will continue on to unpacking things and placing everything where it should go. The Mathematica Notebook feature is included separately, as the X Front End, and you have to install it separately. To get the X Front End stuff correctly installed, cd into the /usr/local/Mathematica/FrontEnd directory and execute the xfe.install shell script. You will have to tell it where to put things, but you do not have to create any directories because it will use the same directories that had been created for math.install. When it finishes, there should be a new shell script in /usr/local/Mathematica/bin called mathematica. Lastly, you need to modify each of the shell scripts that Mathematica has installed. At the beginning of every shell script in /usr/local/Mathematica/bin add the following line: &prompt.user; XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB This tells Mathematica were to find its own version of the key mapping file XKeysymDB. Without this you will get pages of error messages about missing key mappings. On 2.1-STABLE you need to add the following as well: &prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF This tells Mathematica to use the Linux version of host.conf. This file has a different syntax from FreeBSD's host.conf, so you will get an error message about /etc/host.conf if you leave this out. You might also want to modify your /etc/manpath.config file to read the new man directory, and you may need to edit your ~/.cshrc file to add /usr/local/Mathematica/bin to your path. That is about all it takes. With this you should be able to type mathematica and get a really slick looking Mathematica Notebook screen up. Mathematica has included the Motif user interfaces, but it is compiled in statically, so you do not need the Motif libraries. Good luck doing this yourself! Bugs The Notebook front end is known to hang sometimes when reading notebook files with an error messages similar to: File .../Untitled-1.mb appears to be broken for OMPR.257.0 We have not found the cause for this, but it only affects the Notebook's X Window front end, not the mathematica engine itself. So the command line interface invoked by math is unaffected by this bug. Acknowledgments A well-deserved thanks should go to &a.sos; and &a.peter; who made Linux mode what it is today, and Michael Smith who drove these two guys like dogs to get it to the point where it runs Linux binaries better than Linux! :-) How does the Linux mode work? This section is based heavily on an e-mail written to the - chat@FreeBSD.org mailing list, written by Terry Lambert + freebsd-chat@FreeBSD.org mailing list, written by Terry Lambert tlambert@primenet.com (Message ID: <199906020108.SAA07001@usr09.primenet.com>). FreeBSD has an abstraction called an “execution class loader”. This is a wedge into the &man.execve.2; system call. What happens is that FreeBSD has a list of loaders, instead of a single loader with a fallback to the #! loader for running any shell interpreters or shell scripts. Historically, the only loader on the UNIX platform examined the magic number (generally the first 4 or 8 bytes of the file) to see if it was a binary known to the system, and if so, invoked the binary loader. If it was not the binary type for the system, the &man.execve.2; call returned a failure, and the shell attempted to start executing it as shell commands. The assumption was a default of “whatever the current shell is”. Later, a hack was made for &man.sh.1; to examine the first two characters, and if they were :\n, then it invoked the &man.csh.1; shell instead (we believe SCO first made this hack). What FreeBSD does now is go through a list of loaders, with a generic #! loader that knows about interpreters as the characters which follow to the next whitespace next to last, followed by a fallback to /bin/sh. For the Linux ABI support, FreeBSD sees the magic number as an ELF binary (it makes no distinction between FreeBSD, Solaris, Linux, or any other OS which has an ELF image type, at this point). The ELF loader looks for a specialized brand, which is a comment section in the ELF image, and which is not present on SVR4/Solaris ELF binaries. For Linux binaries to function, they must be branded as type Linux; from &man.brandelf.1;: &prompt.root; brandelf -t Linux file When this is done, the ELF loader will see the Linux brand on the file. When the ELF loader sees the Linux brand, the loader replaces a pointer in the proc structure. All system calls are indexed through this pointer (in a traditional UNIX system, this would be the sysent[] structure array, containing the system calls). In addition, the process flagged for special handling of the trap vector for the signal trampoline code, and sever other (minor) fix-ups that are handled by the Linux kernel module. The Linux system call vector contains, among other things, a list of sysent[] entries whose addresses reside in the kernel module. When a system call is called by the Linux binary, the trap code dereferences the system call function pointer off the proc structure, and gets the Linux, not the FreeBSD, system call entry points. In addition, the Linux mode dynamically reroots lookups; this is, in effect, what the union option to FS mounts ( not the unionfs!) does. First, an attempt is made to lookup the file in the /compat/linux/original-path directory, then only if that fails, the lookup is done in the /original-path directory. This makes sure that binaries that require other binaries can run (e.g., the Linux toolchain can all run under Linux ABI support). It also means that the Linux binaries can load and exec FreeBSD binaries, if there are no corresponding Linux binaries present, and that you could place a &man.uname.1; command in the /compat/linux directory tree to ensure that the Linux binaries could not tell they were not running on Linux. In effect, there is a Linux kernel in the FreeBSD kernel; the various underlying functions that implement all of the services provided by the kernel are identical to both the FreeBSD system call table entries, and the Linux system call table entries: file system operations, virtual memory operations, signal delivery, System V IPC, etc… The only difference is that FreeBSD binaries get the FreeBSD glue functions, and Linux binaries get the Linux glue functions (most older OS's only had their own glue functions: addresses of functions in a static global sysent[] structure array, instead of addresses of functions dereferenced off a dynamically initialized pointer in the proc structure of the process making the call). Which one is the native FreeBSD ABI? It does not matter. Basically the only difference is that (currently; this could easily be changed in a future release, and probably will be after this) the FreeBSD glue functions are statically linked into the kernel, and the Linux glue functions can be statically linked, or they can be accessed via a kernel module. Yeah, but is this really emulation? No. It is an ABI implementation, not an emulation. There is no emulator (or simulator, to cut off the next question) involved. So why is it sometimes called “Linux emulation”? To make it hard to sell FreeBSD! 8-). Really, it is because the historical implementation was done at a time when there was really no word other than that to describe what was going on; saying that FreeBSD ran Linux binaries was not true, if you did not compile the code in or load a module, and there needed to be a word to describe what was being loaded—hence “the Linux emulator”. diff --git a/en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml b/en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml index 5cf6ac0b1c..45702bf0db 100644 --- a/en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml @@ -1,609 +1,609 @@ Introduction FreeBSD is a 4.4BSD-Lite2 based operating system for Intel architecture (x86) and DEC Alpha based computer systems. For an overview of FreeBSD, see FreeBSD in a nutshell. For a history of the project, read a brief history of FreeBSD. To see a description of the latest release, read about the current release. If you are interested in contributing something to the FreeBSD project (code, equipment, sacks of unmarked bills), please see about contributing to FreeBSD. FreeBSD in a Nutshell FreeBSD is a state of the art operating system for computer systems based on both the Intel CPU architecture, which includes the 386 and Pentium family of processors as well as Intel compatible CPUs from Cyrix and AMD, and the DEC Alpha architecture. FreeBSD provides you with many advanced features previously available only on much more expensive systems. These features include: Preemptive multitasking with dynamic priority adjustment to ensure smooth and fair sharing of the computer between applications and users, even under the heaviest of loads. Multiuser access means that many people can use a FreeBSD system simultaneously for a variety of things. This means, for example, that system peripherals such as printers and tape drives are properly shared between all users on the system or the network and that individual resource limits can be placed on users or groups of users, protecting critical system resources from over-use. Strong TCP/IP networking with support for industry standards such as SLIP, PPP, NFS, DHCP and NIS support. This means that your FreeBSD machine can inter-operate easily with other systems as well act as an enterprise server, providing vital functions such as NFS (remote file access) and e-mail services or putting your organization on the Internet with WWW, ftp, routing and firewall (security) services. Memory protection ensures that applications (or users) cannot interfere with each other. One application crashing will not affect others in any way. FreeBSD is a 32-bit operating system (64-bit on the Alpha) and was designed as such from the ground up. The industry standard X Window System (X11R6) provides a graphical user interface (GUI) for the cost of a common VGA card and monitor and comes with full sources. Binary compatibility with many programs built for Linux, SCO, SVR4, BSDI and NetBSD. Thousands of ready-to-run applications are available from the FreeBSD ports and packages collection. Why search the net when you can find it all right here? Thousands of additional and easy-to-port applications available on the Internet. FreeBSD is source code compatible with most popular commercial Unix systems and thus most applications require few, if any, changes to compile. Demand paged virtual memory and “merged VM/buffer cache” design efficiently satisfies applications with large appetites for memory while still maintaining interactive response to other users. SMP support for machines with multiple CPUs (Intel only). A full complement of C, C++ and Fortran development tools. Many additional languages for advanced research and development are also available in the ports and packages collection. Source code for the entire system means you have the greatest degree of control over your environment. Why be locked into a proprietary solution and at the mercy of your vendor when you can have a truly Open System? Extensive on-line documentation. And many more! FreeBSD is based on the 4.4BSD-Lite2 release from Computer Systems Research Group (CSRG) at the University of California at Berkeley, and carries on the distinguished tradition of BSD systems development. In addition to the fine work provided by CSRG, the FreeBSD Project has put in many thousands of hours in fine tuning the system for maximum performance and reliability in real-life load situations. As many of the commercial giants struggle to field PC operating systems with such features, performance and reliability, FreeBSD can offer them now! The applications to which FreeBSD can be put are truly limited only by your own imagination. From software development to factory automation, inventory control to azimuth correction of remote satellite antennae; if it can be done with a commercial UNIX product then it is more than likely that you can do it with FreeBSD, too! FreeBSD also benefits significantly from the literally thousands of high quality applications developed by research centers and universities around the world, often available at little to no cost. Commercial applications are also available and appearing in greater numbers every day. Because the source code for FreeBSD itself is generally available, the system can also be customized to an almost unheard of degree for special applications or projects, and in ways not generally possible with operating systems from most major commercial vendors. Here is just a sampling of some of the applications in which people are currently using FreeBSD: Internet Services: The robust TCP/IP networking built into FreeBSD makes it an ideal platform for a variety of Internet services such as: FTP servers World Wide Web servers (standard or secure [SSL]) Firewalls and NAT ("IP masquerading") gateways. Electronic Mail servers USENET News or Bulletin Board Systems And more... With FreeBSD, you can easily start out small with an inexpensive 386 class PC and upgrade all the way up to a quad-processor Xeon with RAID storage as your enterprise grows. Education: Are you a student of computer science or a related engineering field? There is no better way of learning about operating systems, computer architecture and networking than the hands on, under the hood experience that FreeBSD can provide. A number of freely available CAD, mathematical and graphic design packages also make it highly useful to those whose primary interest in a computer is to get other work done! Research: With source code for the entire system available, FreeBSD is an excellent platform for research in operating systems as well as other branches of computer science. FreeBSD's freely available nature also makes it possible for remote groups to collaborate on ideas or shared development without having to worry about special licensing agreements or limitations on what may be discussed in open forums. Networking: Need a new router? A name server (DNS)? A firewall to keep people out of your internal network? FreeBSD can easily turn that unused 386 or 486 PC sitting in the corner into an advanced router with sophisticated packet filtering capabilities. X Window workstation: FreeBSD is a fine choice for an inexpensive X terminal solution, either using the freely available XFree86 server or one of the excellent commercial servers provided by X Inside. Unlike an X terminal, FreeBSD allows many applications to be run locally, if desired, thus relieving the burden on a central server. FreeBSD can even boot “diskless”, making individual workstations even cheaper and easier to administer. Software Development: The basic FreeBSD system comes with a full complement of development tools including the renowned GNU C/C++ compiler and debugger. FreeBSD is available in both source and binary form on CDROM and via anonymous ftp. See Obtaining FreeBSD for more details. A Brief History of FreeBSD Contributed by &a.jkh;. The FreeBSD project had its genesis in the early part of 1993, partially as an outgrowth of the “Unofficial 386BSD Patchkit” by the patchkit's last 3 coordinators: Nate Williams, Rod Grimes and myself. Our original goal was to produce an intermediate snapshot of 386BSD in order to fix a number of problems with it that the patchkit mechanism just was not capable of solving. Some of you may remember the early working title for the project being “386BSD 0.5” or “386BSD Interim” in reference to that fact. 386BSD was Bill Jolitz's operating system, which had been up to that point suffering rather severely from almost a year's worth of neglect. As the patchkit swelled ever more uncomfortably with each passing day, we were in unanimous agreement that something had to be done and decided to try and assist Bill by providing this interim “cleanup” snapshot. Those plans came to a rude halt when Bill Jolitz suddenly decided to withdraw his sanction from the project and without any clear indication of what would be done instead. It did not take us long to decide that the goal remained worthwhile, even without Bill's support, and so we adopted the name “FreeBSD”, coined by David Greenman. Our initial objectives were set after consulting with the system's current users and, once it became clear that the project was on the road to perhaps even becoming a reality, I contacted Walnut Creek CDROM with an eye towards improving FreeBSD's distribution channels for those many unfortunates without easy access to the Internet. Walnut Creek CDROM not only supported the idea of distributing FreeBSD on CD but went so far as to provide the project with a machine to work on and a fast Internet connection. Without Walnut Creek CDROM's almost unprecedented degree of faith in what was, at the time, a completely unknown project, it is quite unlikely that FreeBSD would have gotten as far, as fast, as it has today. The first CDROM (and general net-wide) distribution was FreeBSD 1.0, released in December of 1993. This was based on the 4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components also provided by 386BSD and the Free Software Foundation. It was a fairly reasonable success for a first offering, and we followed it with the highly successful FreeBSD 1.1 release in May of 1994. Around this time, some rather unexpected storm clouds formed on the horizon as Novell and U.C. Berkeley settled their long-running lawsuit over the legal status of the Berkeley Net/2 tape. A condition of that settlement was U.C. Berkeley's concession that large parts of Net/2 were “encumbered” code and the property of Novell, who had in turn acquired it from AT&T some time previously. What Berkeley got in return was Novell's “blessing” that the 4.4BSD-Lite release, when it was finally released, would be declared unencumbered and all existing Net/2 users would be strongly encouraged to switch. This included FreeBSD, and the project was given until the end of July 1994 to stop shipping its own Net/2 based product. Under the terms of that agreement, the project was allowed one last release before the deadline, that release being FreeBSD 1.1.5.1. FreeBSD then set about the arduous task of literally re-inventing itself from a completely new and rather incomplete set of 4.4BSD-Lite bits. The “Lite” releases were light in part because Berkeley's CSRG had removed large chunks of code required for actually constructing a bootable running system (due to various legal requirements) and the fact that the Intel port of 4.4 was highly incomplete. It took the project until November of 1994 to make this transition, at which point it released FreeBSD 2.0 to the net and on CDROM (in late December). Despite being still more than a little rough around the edges, the release was a significant success and was followed by the more robust and easier to install FreeBSD 2.0.5 release in June of 1995. We released FreeBSD 2.1.5 in August of 1996, and it appeared to be popular enough among the ISP and commercial communities that another release along the 2.1-STABLE branch was merited. This was FreeBSD 2.1.7.1, released in February 1997 and capping the end of mainstream development on 2.1-STABLE. Now in maintenance mode, only security enhancements and other critical bug fixes will be done on this branch (RELENG_2_1_0). FreeBSD 2.2 was branched from the development mainline (“-CURRENT”) in November 1996 as the RELENG_2_2 branch, and the first full release (2.2.1) was released in April, 1997. Further releases along the 2.2 branch were done in the Summer and Fall of '97, the last of which (2.2.8) appeared in November, 1998. The first official 3.0 release appeared in October, 1998 and spelled the beginning of the end for the 2.2 branch. The tree branched again on Jan 20, 1999, leading to the 4.0-CURRENT and 3.X-STABLE branches. From 3.X-STABLE, 3.1 was released on February 15th, 1999 and 3.2 on May 15, 1999. The most current release on this branch is 3.3, which was released on September 16th, 1999. Long term development projects continue to take place in the 4.0-CURRENT branch, and SNAPshot releases of 4.0 on CDROM (and, of course, on the net) are continually made available as work progresses. FreeBSD Project Goals Contributed by &a.jkh;. The goals of the FreeBSD Project are to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we are definitely not prepared to insist on it. We believe that our first and foremost “mission” is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, I believe, one of the most fundamental goals of Free Software and one that we enthusiastically support. That code in our source tree which falls under the GNU General Public License (GPL) or Library General Public License (LGPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software we do, however, prefer software submitted under the more relaxed BSD copyright when it's a reasonable option to do so. The FreeBSD Development Model Contributed by &a.asami;. The development of FreeBSD is a very open and flexible process, FreeBSD being literally built from the contributions of hundreds of people around the world, as can be seen from our list of contributors. We are constantly on the lookout for new developers and ideas, and those interested in becoming more closely involved with the project need simply contact us at the &a.hackers;. The &a.announce; is also available to those wishing to make other FreeBSD users aware of major areas of work. Useful things to know about the FreeBSD project and its development process, whether working independently or in close cooperation: The CVS repository The central source tree for FreeBSD is maintained by CVS (Concurrent Version System), a freely available source code control tool which comes bundled with FreeBSD. The primary CVS repository resides on a machine in Concord CA, USA from where it is replicated to numerous mirror machines throughout the world. The CVS tree, as well as the -CURRENT and -STABLE trees which are checked out of it, can be easily replicated to your own machine as well. Please refer to the Synchronizing your source tree section for more information on doing this. The committers list The committers are the people who have write access to the CVS tree, and are thus authorized to make modifications to the FreeBSD source (the term “committer” comes from the &man.cvs.1; commit command, which is used to bring new changes into the CVS repository). The best way of making submissions for review by the committers list is to use the &man.send-pr.1; command, though if something appears to be jammed in the system then you may also reach them by sending mail - to committers@FreeBSD.org. + to cvs-committers@FreeBSD.org. The FreeBSD core team The FreeBSD core team would be equivalent to the board of directors if the FreeBSD Project were a company. The primary task of the core team is to make sure the project, as a whole, is in good shape and is heading in the right directions. Inviting dedicated and responsible developers to join our group of committers is one of the functions of the core team, as is the recruitment of new core team members as others move on. Most current members of the core team started as committers whose addiction to the project got the better of them. Some core team members also have specific areas of responsibility, meaning that they are committed to ensuring that some large portion of the system works as advertised. Most members of the core team are volunteers when it comes to FreeBSD development and do not benefit from the project financially, so “commitment” should also not be misconstrued as meaning “guaranteed support.” The “board of directors” analogy above is not actually very accurate, and it may be more suitable to say that these are the people who gave up their lives in favor of FreeBSD against their better judgement! ;-) Outside contributors Last, but definitely not least, the largest group of developers are the users themselves who provide feedback and bug-fixes to us on an almost constant basis. The primary way of keeping in touch with FreeBSD's more non-centralized development is to subscribe to the &a.hackers; (see mailing list info) where such things are discussed. The list of those who have contributed something which made its way into our source tree is a long and growing one, so why not join it by contributing something back to FreeBSD today? :-) Providing code is not the only way of contributing to the project; for a more complete list of things that need doing, please refer to the how to contribute section in this handbook. In summary, our development model is organized as a loose set of concentric circles. The centralized model is designed for the convenience of the users of FreeBSD, who are thereby provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent application programs that the users can easily install and use, and this model works very well in accomplishing that. All we ask of those who would join us as FreeBSD developers is some of the same dedication its current people have to its continued success! About the Current Release FreeBSD is a freely available, full source 4.4BSD-Lite2 based release for Intel i386/i486/Pentium/PentiumPro/Pentium II (or compatible) and DEC Alpha based computer systems. It is based primarily on software from U.C. Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD, 386BSD, and the Free Software Foundation. Since our release of FreeBSD 2.0 in late 94, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped virtual memory system with a merged VM/file buffer cache that not only increases performance, but reduces FreeBSD's memory footprint, making a 5MB configuration a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial-on-demand PPP, integrated DHCP support, an improved SCSI subsystem, ISDN support, support for ATM, FDDI, Fast and Gigabit Ethernet (1000Mbit) adapters, improved support for the latest Adaptec controllers and many hundreds of bug fixes. We have also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this (constantly evolving) process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with hundreds of commonly sought-after programs. By mid-November 1999, there were nearly 2800 ports! The list of ports ranges from http (WWW) servers, to games, languages, editors and almost everything in between. The entire ports collection requires approximately 50MB of storage, all ports being expressed as “deltas” to their original sources. This makes it much easier for us to update ports, and greatly reduces the disk space demands made by the older 1.0 ports collection. To compile a port, you simply change to the directory of the program you wish to install, type make all followed by make install after successful compilation and let the system do the rest. The full original distribution for each port you build is retrieved dynamically off the CDROM or a local ftp site, so you need only enough disk space to build the ports you want. (Almost) every port is also provided as a pre-compiled “package” which can be installed with a simple command (pkg_add) by those who do not wish to compile their own ports from source. A number of additional documents which you may find very helpful in the process of installing and using FreeBSD may now also be found in the /usr/share/doc directory on any machine running FreeBSD 2.1 or later. You may view the locally installed manuals with any HTML capable browser using the following URLs: The FreeBSD Handbook file:/usr/share/doc/handbook/handbook.html The FreeBSD FAQ file:/usr/share/doc/FAQ/FAQ.html You can also visit the master (and most frequently updated) copies at http://www.FreeBSD.org/. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. There is an add-on package to the core distribution, for use only in the United States, that contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely (from outside the U.S.) exportable European distribution of DES for our non-U.S. users also exists and is described in the FreeBSD FAQ. If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from different hosts (Suns, DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require! We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. If you are outside (or even inside) the U.S., give it a try! diff --git a/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml b/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml index a95f3724d0..fed0b12ec2 100644 --- a/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml @@ -1,1007 +1,1007 @@ Linux Mode Contributed by &a.handy; and &a.rich; How to Install the Linux Mode Linux binary compatibility in FreeBSD has reached a point where it is possible to run a large fraction of Linux binaries in both a.out and ELF format. The Linux compatibility in the 2.1-STABLE branch is capable of running Linux DOOM and Mathematica; the version present in &rel.current;-RELEASE is vastly more capable and runs all these as well as Oracle8, WordPerfect, StarOffice, Acrobat, Quake, Abuse, IDL, and netrek for Linux and a whole host of other programs. There are some Linux-specific operating system features that are not supported on FreeBSD. Linux binaries will not work on FreeBSD if they overly use the Linux /proc filesystem (which is different from the optional FreeBSD /proc filesystem) or i386-specific calls, such as enabling virtual 8086 mode. Depending on which version of FreeBSD you are running, how you get Linux mode up will vary somewhat: Installing Linux Mode in 3.0-RELEASE and later It is no longer necessary to specify options LINUX or options COMPAT_LINUX. Linux binary compatibility is done with an KLD object (“Kernel LoaDable object”) so it can be installed on the fly without having to reboot. You will need the following things in your startup files, however: In /etc/rc.conf, you need the following line: linux_enable=YES This, in turn, triggers the following action in /etc/rc.i386: # Start the Linux binary compatibility if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi If you want to verify that the KLD is loaded, kldstat will do that: &prompt.user; kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko If for some reason you do not want to or cannot load the Linux KLD, then statically link the binary compatibility in the kernel by adding options LINUX to your kernel config file. Then run config and install the new kernel as described in the kernel configuration section. Installing Linux Mode in 2.2.2-RELEASE and later 2.2.x versions It is no longer necessary to specify options LINUX or options COMPAT_LINUX. Linux binary compatibility is done with an LKM (“Loadable Kernel Module”) so it can be installed on the fly without having to reboot. You will need the following things in your startup files, however: In /etc/rc.conf, you need the following line: linux_enable=YES This, in turn, triggers the following action in /etc/rc.i386: # Start the Linux binary emulation if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi If you want to verify that the LKM is running, modstat will do that: &prompt.user; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod However, there have been reports that this fails on some 2.2-RELEASE and later systems. If for some reason you cannot load the Linux LKM, then statically link the Linux compatibility in the kernel by adding options LINUX to your kernel config file. Then run config and install the new kernel as described in the kernel configuration section. Installing Linux Mode in 2.1-STABLE The GENERIC kernel in 2.1-STABLE is not configured for Linux compatibility so you must reconfigure your kernel for it. There are two ways to do this: 1. linking the binary compatibility statically in the kernel itself and 2. configuring your kernel to dynamically load the Linux loadable kernel module (LKM). To enable Linux binary compatibility, add the following to your configuration file (c.f. /sys/i386/conf/LINT): options COMPAT_LINUX If you want to run doom or other applications that need shared memory, also add the following. options SYSVSHM The Linux system calls require 4.3BSD system call compatibility. So make sure you have the following. options "COMPAT_43" If you prefer to statically link the binary compatibility in the kernel rather than use the loadable kernel module (LKM), then add options LINUX Then run config and install the new kernel as described in the kernel configuration section. If you decide to use the LKM you must also install the loadable module. A mismatch of versions between the kernel and loadable module can cause the kernel to crash, so the safest thing to do is to reinstall the LKM when you install the kernel. &prompt.root; cd /usr/src/lkm/linux &prompt.root; make all install Once you have installed the kernel and the LKM, you can invoke linux as root to load the LKM. &prompt.root; linux Linux emulator installed Module loaded as ID 0 To see whether the LKM is loaded, run modstat. &prompt.user; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator You can cause the LKM to be loaded when the system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and 2.1-STABLE enable it in /etc/sysconfig linux=YES by changing it from NO to YES. FreeBSD 2.1 RELEASE and earlier do not have such a line and on those you will need to edit /etc/rc.local to add the following line. linux Installing Linux Runtime Libraries Installing using the linux_base port Most Linux applications use shared libraries, so you are still not done until you install the shared libraries. It is possible to do this by hand, however, it is vastly simpler to just grab the linux_base port: &prompt.root; cd /usr/ports/emulators/linux_base &prompt.root; make all install and you should have working Linux binary compatibility. Legend (and the mail archives :-) seems to hold that Linux mode works best with Linux binaries linked against the ZMAGIC libraries; QMAGIC libraries (such as those used in Slackware V2.0) may tend to give the Linux mode heartburn. Also, expect some programs to complain about incorrect minor versions of the system libraries. In general, however, this does not seem to be a problem. Installing libraries manually If you do not have the “ports” distribution, you can install the libraries by hand instead. You will need the Linux shared libraries that the program depends on and the runtime linker. Also, you will need to create a "shadow root" directory, /compat/linux, for Linux libraries on your FreeBSD system. Any shared libraries opened by Linux programs run under FreeBSD will look in this tree first. So, if a Linux program loads, for example, /lib/libc.so, FreeBSD will first try to open /compat/linux/lib/libc.so, and if that does not exist then it will try /lib/libc.so. Shared libraries should be installed in the shadow tree /compat/linux/lib rather than the paths that the Linux ld.so reports. FreeBSD-2.2-RELEASE and later works slightly differently with respect to /compat/linux: all files, not just libraries, are searched for from the “shadow root” /compat/linux. Generally, you will need to look for the shared libraries that Linux binaries depend on only the first few times that you install a Linux program on your FreeBSD system. After a while, you will have a sufficient set of Linux shared libraries on your system to be able to run newly imported Linux binaries without any extra work. How to install additional shared libraries What if you install the linux_base port and your application still complains about missing shared libraries? How do you know which shared libraries Linux binaries need, and where to get them? Basically, there are 2 possibilities (when following these instructions: you will need to be root on your FreeBSD system to do the necessary installation steps). If you have access to a Linux system, see what shared libraries the application needs, and copy them to your FreeBSD system. Example: you have just ftp'ed the Linux binary of Doom. Put it on the Linux system you have access to, and check which shared libraries it needs by running ldd linuxxdoom: &prompt.user; ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 You would need to get all the files from the last column, and put them under /compat/linux, with the names in the first column as symbolic links pointing to them. This means you eventually have these files on your FreeBSD system: /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 Note that if you already have a Linux shared library with a matching major revision number to the first column of the ldd output, you will not need to copy the file named in the last column to your system, the one you already have should work. It is advisable to copy the shared library anyway if it is a newer version, though. You can remove the old one, as long as you make the symbolic link point to the new one. So, if you have these libraries on your system: /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 and you find a new binary that claims to require a later version according to the output of ldd: libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 If it is only one or two versions out of date in the in the trailing digit then do not worry about copying /lib/libc.so.4.6.29 too, because the program should work fine with the slightly older version. However, if you like you can decide to replace the libc.so anyway, and that should leave you with: /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 The symbolic link mechanism is only needed for Linux binaries. The FreeBSD runtime linker takes care of looking for matching major revision numbers itself and you do not need to worry about it. Configuring the <filename>ld.so</filename> — for FreeBSD 2.2-RELEASE and later This section applies only to FreeBSD 2.2-RELEASE and later. Those running 2.1-STABLE should skip this section. Finally, if you run FreeBSD 2.2-RELEASE you must make sure that you have the Linux runtime linker and its config files on your system. You should copy these files from the Linux system to their appropriate place on your FreeBSD system (to the /compat/linux tree): /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config If you do not have access to a Linux system, you should get the extra files you need from various ftp sites. Information on where to look for the various files is appended below. For now, let us assume you know where to get the files. Retrieve the following files (all from the same ftp site to avoid any version mismatches), and install them under /compat/linux (i.e. /foo/bar is installed as /compat/linux/foo/bar): /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so ldconfig and ldd do not necessarily need to be under /compat/linux; you can install them elsewhere in the system too. Just make sure they do not conflict with their FreeBSD counterparts. A good idea would be to install them in /usr/local/bin as ldconfig-linux and ldd-linux. Create the file /compat/linux/etc/ld.so.conf, containing the directories in which the Linux runtime linker should look for shared libraries. It is a plain text file, containing a directory name on each line. /lib and /usr/lib are standard, you could add the following: /usr/X11/lib /usr/local/lib When a Linux binary opens a library such as /lib/libc.so the Linux ABI support maps the name to /compat/linux/lib/libc.so internally. All Linux libraries should be installed under /compat/linux (e.g. /compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so, etc.) in order for the Linux ABI loader to find them. Those running FreeBSD 2.2-RELEASE should run the Linux ldconfig program. &prompt.root cd /compat/linux/lib &prompt.root; /compat/linux/sbin/ldconfig ldconfig is statically linked, so it does not need any shared libraries to run. It creates the file /compat/linux/etc/ld.so.cache which contains the names of all the shared libraries and should be rerun to recreate this file whenever you install additional shared libraries. On 2.1-STABLE do not install /compat/linux/etc/ld.so.cache or run ldconfig; in 2.1-STABLE the syscalls are implemented differently and ldconfig is not needed or used. You should now be set up for Linux binaries which only need a shared libc. You can test this by running the Linux ldd on itself. Supposing that you have it installed as ldd-linux, it should produce something like: &prompt.root; ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 This being done, you are ready to install new Linux binaries. Whenever you install a new Linux program, you should check if it needs shared libraries, and if so, whether you have them installed in the /compat/linux tree. To do this, you run the Linux version ldd on the new program, and watch its output. ldd (see also the manual page for &man.ldd.1;) will print a list of shared libraries that the program depends on, in the form majorname (jumpversion) => fullname. If it prints not found instead of fullname it means that you need an extra library. The library needed is shown in majorname and will be of the form libXXXX.so.N. You will need to find a libXXXX.so.N.mm on a Linux ftp site, and install it on your system. The XXXX (name) and N (major revision number) should match; the minor number(s) mm are less important, though it is advised to take the most recent version. Installing Linux ELF binaries ELF binaries sometimes require an extra step of “branding”. If you attempt to run an unbranded ELF binary, you will get an error message like the following; &prompt.user; ./my-linux-elf-binary ELF binary type not known Abort To help the FreeBSD kernel distinguish between a FreeBSD ELF binary from a Linux binary, use the &man.brandelf.1; utility. &prompt.user; brandelf -t Linux my-linux-elf-binary The GNU toolchain now places the appropriate branding information into ELF binaries automatically, so you should be needing to do this step increasingly rarely in future. Configuring the host name resolver If DNS does not work or you get the messages resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword then you need to configure a /compat/linux/etc/host.conf file containing: order hosts, bind multi on where the order here specifies that /etc/hosts is searched first and DNS is searched second. When /compat/linux/etc/host.conf is not installed linux applications find FreeBSD's /etc/host.conf and complain about the incompatible FreeBSD syntax. You should remove bind if you have not configured a name-server using the /etc/resolv.conf file. Lastly, those who run 2.1-STABLE need to set an the RESOLV_HOST_CONF environment variable so that applications will know how to search the host tables. If you run FreeBSD 2.2-RELEASE or later, you can skip this. For the /bin/csh shell use: &prompt.user; setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf For /bin/sh use: &prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF Finding the necessary files The information below is valid as of the time this document was written, but certain details such as names of ftp sites, directories and distribution names may have changed by the time you read this. Linux is distributed by several groups that make their own set of binaries that they distribute. Each distribution has its own name, like “Slackware” or “Yggdrasil”. The distributions are available on a lot of ftp sites. Sometimes the files are unpacked, and you can get the individual files you need, but mostly they are stored in distribution sets, usually consisting of subdirectories with gzipped tar files in them. The primary ftp sites for the distributions are: sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions Some European mirrors: ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/unix/linux src.doc.ic.ac.uk:/packages/linux/distributions For simplicity, let us concentrate on Slackware here. This distribution consists of a number of subdirectories, containing separate packages. Normally, they are controlled by an install program, but you can retrieve files “by hand” too. First of all, you will need to look in the contents subdirectory of the distribution. You will find a lot of small text files here describing the contents of the separate packages. The fastest way to look something up is to retrieve all the files in the contents subdirectory, and grep through them for the file you need. Here is an example of a list of files that you might need, and in which contents-file you will find it by grepping through them: Library Package ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf_lib libXt.so.6.0 xf_lib libX11.so.3 oldlibs libXt.so.3 oldlibs So, in this case, you will need the packages ldso, shlibs, xf_lib and oldlibs. In each of the contents-files for these packages, look for a line saying PACKAGE LOCATION, it will tell you on which “disk” the package is, in our case it will tell us in which subdirectory we need to look. For our example, we would find the following locations: Package Location ldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9 The locations called “diskXX” refer to the slakware/XX subdirectories of the distribution, others may be found in the contrib subdirectory. In this case, we could now retrieve the packages we need by retrieving the following files (relative to the root of the Slackware distribution tree): slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs.tgz slakware/x9/xf_lib.tgz Extract the files from these gzipped tarfiles in your /compat/linux directory (possibly omitting or afterwards removing files you do not need), and you are done. See also: ftp://ftp.FreeBSD.org/pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README and /usr/src/sys/i386/ibcs2/README.iBCS2 How to Install Mathematica on FreeBSD Contributed by &a.rich; and &a.chuck; This document shows how to install the Linux binary distribution of Mathematica 2.2 on FreeBSD 2.1. Mathematica supports Linux but not FreeBSD as it stands. So once you have configured your system for Linux compatibility you have most of what you need to run Mathematica. For those who already have the student edition of Mathematica for DOS the cost of upgrading to the Linux version at the time this was written, March 1996, was $45.00. It can be ordered directly from Wolfram at (217) 398-6500 and paid for by credit card. Unpacking the Mathematica distribution The binaries are currently distributed by Wolfram on CDROM. The CDROM has about a dozen tar files, each of which is a binary distribution for one of the supported architectures. The one for Linux is named LINUX.TAR. You can, for example, unpack this into /usr/local/Mathematica: &prompt.root; cd /usr/local &prompt.root; mkdir Mathematica &prompt.root; cd Mathematica &prompt.root; tar -xvf /cdrom/LINUX.TAR Obtaining your Mathematica Password Before you can run Mathematica you will have to obtain a password from Wolfram that corresponds to your “machine ID”. Once you have installed the Linux compatibility runtime libraries and unpacked Mathematica you can obtain the “machine ID” by running the program mathinfo in the Install directory. &prompt.root; cd /usr/local/Mathematica/Install &prompt.root; mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 So, for example, the “machine ID” of richc is 9845-03452-90255. You can ignore the message about the ioctl that is not implemented. It will not prevent Mathematica from running in any way and you can safely ignore it, though you will see the message every time you run Mathematica. When you register with Wolfram, either by email, phone or fax, you will give them the “machine ID” and they will respond with a corresponding password consisting of groups of numbers. You need to add them both along with the machine name and license number in your mathpass file. You can do this by invoking: &prompt.root; cd /usr/local/Mathematica/Install &prompt.root; math.install It will ask you to enter your license number and the Wolfram supplied password. If you get them mixed up or for some reason the math.install fails, that is OK; you can simply edit the file mathpass in this same directory to correct the info manually. After getting past the password, math.install will ask you if you accept the install defaults provided, or if you want to use your own. If you are like us and distrust all install programs, you probably want to specify the actual directories. Beware. Although the math.install program asks you to specify directories, it will not create them for you, so you should perhaps have a second window open with another shell so that you can create them before you give them to the install program. Or, if it fails, you can create the directories and then restart the math.install program. The directories we chose to create beforehand and specify to math.install were: /usr/local/Mathematica/bin for binaries /usr/local/Mathematica/man/man1 for man pages /usr/local/Mathematica/lib/X11 for the XKeysymb file You can also tell it to use /tmp/math.record for the system record file, where it puts logs of sessions. After this math.install will continue on to unpacking things and placing everything where it should go. The Mathematica Notebook feature is included separately, as the X Front End, and you have to install it separately. To get the X Front End stuff correctly installed, cd into the /usr/local/Mathematica/FrontEnd directory and execute the xfe.install shell script. You will have to tell it where to put things, but you do not have to create any directories because it will use the same directories that had been created for math.install. When it finishes, there should be a new shell script in /usr/local/Mathematica/bin called mathematica. Lastly, you need to modify each of the shell scripts that Mathematica has installed. At the beginning of every shell script in /usr/local/Mathematica/bin add the following line: &prompt.user; XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB This tells Mathematica were to find its own version of the key mapping file XKeysymDB. Without this you will get pages of error messages about missing key mappings. On 2.1-STABLE you need to add the following as well: &prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF This tells Mathematica to use the Linux version of host.conf. This file has a different syntax from FreeBSD's host.conf, so you will get an error message about /etc/host.conf if you leave this out. You might also want to modify your /etc/manpath.config file to read the new man directory, and you may need to edit your ~/.cshrc file to add /usr/local/Mathematica/bin to your path. That is about all it takes. With this you should be able to type mathematica and get a really slick looking Mathematica Notebook screen up. Mathematica has included the Motif user interfaces, but it is compiled in statically, so you do not need the Motif libraries. Good luck doing this yourself! Bugs The Notebook front end is known to hang sometimes when reading notebook files with an error messages similar to: File .../Untitled-1.mb appears to be broken for OMPR.257.0 We have not found the cause for this, but it only affects the Notebook's X Window front end, not the mathematica engine itself. So the command line interface invoked by math is unaffected by this bug. Acknowledgments A well-deserved thanks should go to &a.sos; and &a.peter; who made Linux mode what it is today, and Michael Smith who drove these two guys like dogs to get it to the point where it runs Linux binaries better than Linux! :-) How does the Linux mode work? This section is based heavily on an e-mail written to the - chat@FreeBSD.org mailing list, written by Terry Lambert + freebsd-chat@FreeBSD.org mailing list, written by Terry Lambert tlambert@primenet.com (Message ID: <199906020108.SAA07001@usr09.primenet.com>). FreeBSD has an abstraction called an “execution class loader”. This is a wedge into the &man.execve.2; system call. What happens is that FreeBSD has a list of loaders, instead of a single loader with a fallback to the #! loader for running any shell interpreters or shell scripts. Historically, the only loader on the UNIX platform examined the magic number (generally the first 4 or 8 bytes of the file) to see if it was a binary known to the system, and if so, invoked the binary loader. If it was not the binary type for the system, the &man.execve.2; call returned a failure, and the shell attempted to start executing it as shell commands. The assumption was a default of “whatever the current shell is”. Later, a hack was made for &man.sh.1; to examine the first two characters, and if they were :\n, then it invoked the &man.csh.1; shell instead (we believe SCO first made this hack). What FreeBSD does now is go through a list of loaders, with a generic #! loader that knows about interpreters as the characters which follow to the next whitespace next to last, followed by a fallback to /bin/sh. For the Linux ABI support, FreeBSD sees the magic number as an ELF binary (it makes no distinction between FreeBSD, Solaris, Linux, or any other OS which has an ELF image type, at this point). The ELF loader looks for a specialized brand, which is a comment section in the ELF image, and which is not present on SVR4/Solaris ELF binaries. For Linux binaries to function, they must be branded as type Linux; from &man.brandelf.1;: &prompt.root; brandelf -t Linux file When this is done, the ELF loader will see the Linux brand on the file. When the ELF loader sees the Linux brand, the loader replaces a pointer in the proc structure. All system calls are indexed through this pointer (in a traditional UNIX system, this would be the sysent[] structure array, containing the system calls). In addition, the process flagged for special handling of the trap vector for the signal trampoline code, and sever other (minor) fix-ups that are handled by the Linux kernel module. The Linux system call vector contains, among other things, a list of sysent[] entries whose addresses reside in the kernel module. When a system call is called by the Linux binary, the trap code dereferences the system call function pointer off the proc structure, and gets the Linux, not the FreeBSD, system call entry points. In addition, the Linux mode dynamically reroots lookups; this is, in effect, what the union option to FS mounts ( not the unionfs!) does. First, an attempt is made to lookup the file in the /compat/linux/original-path directory, then only if that fails, the lookup is done in the /original-path directory. This makes sure that binaries that require other binaries can run (e.g., the Linux toolchain can all run under Linux ABI support). It also means that the Linux binaries can load and exec FreeBSD binaries, if there are no corresponding Linux binaries present, and that you could place a &man.uname.1; command in the /compat/linux directory tree to ensure that the Linux binaries could not tell they were not running on Linux. In effect, there is a Linux kernel in the FreeBSD kernel; the various underlying functions that implement all of the services provided by the kernel are identical to both the FreeBSD system call table entries, and the Linux system call table entries: file system operations, virtual memory operations, signal delivery, System V IPC, etc… The only difference is that FreeBSD binaries get the FreeBSD glue functions, and Linux binaries get the Linux glue functions (most older OS's only had their own glue functions: addresses of functions in a static global sysent[] structure array, instead of addresses of functions dereferenced off a dynamically initialized pointer in the proc structure of the process making the call). Which one is the native FreeBSD ABI? It does not matter. Basically the only difference is that (currently; this could easily be changed in a future release, and probably will be after this) the FreeBSD glue functions are statically linked into the kernel, and the Linux glue functions can be statically linked, or they can be accessed via a kernel module. Yeah, but is this really emulation? No. It is an ABI implementation, not an emulation. There is no emulator (or simulator, to cut off the next question) involved. So why is it sometimes called “Linux emulation”? To make it hard to sell FreeBSD! 8-). Really, it is because the historical implementation was done at a time when there was really no word other than that to describe what was going on; saying that FreeBSD ran Linux binaries was not true, if you did not compile the code in or load a module, and there needed to be a word to describe what was being loaded—hence “the Linux emulator”.