Index: head/en_US.ISO8859-1/articles/explaining-bsd/article.xml =================================================================== --- head/en_US.ISO8859-1/articles/explaining-bsd/article.xml (revision 45695) +++ head/en_US.ISO8859-1/articles/explaining-bsd/article.xml (revision 45696) @@ -1,581 +1,581 @@
Explaining BSD GregLehey
grog@FreeBSD.org
 &tm-attrib.freebsd; &tm-attrib.amd; &tm-attrib.apple; &tm-attrib.intel; &tm-attrib.linux; &tm-attrib.opengroup; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.unix; &tm-attrib.general; $FreeBSD$ $FreeBSD$ In the open source world, the word Linux is almost synonymous with Operating System, but it is not the only open source &unix; operating system. According to the Internet Operating System Counter, as of April 1999 31.3% of the world's network connected machines run Linux. 14.6% run BSD &unix;. Some of the world's largest web operations, such as Yahoo!, run BSD. The world's busiest FTP server of 1999 (now defunct), ftp.cdrom.com, used BSD to transfer 1.4 TB of data a day. Clearly this is not a niche market: BSD is a well-kept secret. So what is the secret? Why is BSD not better known? This white paper addresses these and other questions. Throughout this paper, differences between BSD and Linux will be noted like this. What is BSD? BSD stands for Berkeley Software Distribution. It is the name of distributions of source code from the University of California, Berkeley, which were originally extensions to AT&T's Research &unix; operating system. Several open source operating system projects are based on a release of this source code known as 4.4BSD-Lite. In addition, they comprise a number of packages from other Open Source projects, including notably the GNU project. The overall operating system comprises: The BSD kernel, which handles process scheduling, memory management, symmetric multi-processing (SMP), device drivers, etc. Unlike the Linux kernel, there are several different BSD kernels with differing capabilities. The C library, the base API for the system. The BSD C library is based on code from Berkeley, not the GNU project. Utilities such as shells, file utilities, compilers and linkers. Some of the utilities are derived from the GNU project, others are not. The X Window system, which handles graphical display. The X Window system used in most versions of BSD is maintained by the X.Org project. &os; allows the user to choose from a variety of desktop environments, such as Gnome, KDE, or Xfce; and lightweight window managers like Openbox, Fluxbox, or Awesome. Many other programs and utilities. What, a real &unix;? The BSD operating systems are not clones, but open source derivatives of AT&T's Research &unix; operating system, which is also the ancestor of the modern &unix; System V. This may surprise you. How could that happen when AT&T has never released its code as open source? It is true that AT&T &unix; is not open source, and in a copyright sense BSD is very definitely not &unix;, but on the other hand, AT&T has imported sources from other projects, noticeably the Computer Sciences Research Group (CSRG) of the University of California in Berkeley, CA. Starting in 1976, the CSRG started releasing tapes of their software, calling them Berkeley Software Distribution or BSD. Initial BSD releases consisted mainly of user programs, but that changed dramatically when the CSRG landed a contract with the Defense Advanced Research Projects Agency (DARPA) to upgrade the communications protocols on their network, ARPANET. The new protocols were known as the Internet Protocols, later TCP/IP after the most important protocols. The first widely distributed implementation was part of 4.2BSD, in 1982. In the course of the 1980s, a number of new workstation companies sprang up. Many preferred to license &unix; rather than developing operating systems for themselves. In particular, Sun Microsystems licensed &unix; and implemented a version of 4.2BSD, which they called &sunos;. When AT&T themselves were allowed to sell &unix; commercially, they started with a somewhat bare-bones implementation called System III, to be quickly followed by System V. The System V code base did not include networking, so all implementations included additional software from the BSD, including the TCP/IP software, but also utilities such as the csh shell and the vi editor. Collectively, these enhancements were known as the Berkeley Extensions. The BSD tapes contained AT&T source code and thus required a &unix; source license. By 1990, the CSRG's funding was running out, and it faced closure. Some members of the group decided to release the BSD code, which was Open Source, without the AT&T proprietary code. This finally happened with the Networking Tape 2, usually known as Net/2. Net/2 was not a complete operating system: about 20% of the kernel code was missing. One of the CSRG members, William F. Jolitz, wrote the remaining code and released it in early 1992 as 386BSD. At the same time, another group of ex-CSRG members formed a commercial company called Berkeley Software Design Inc. and released a beta version of an operating system called BSD/386, which was based on the same sources. The name of the operating system was later changed to BSD/OS. 386BSD never became a stable operating system. Instead, two other projects split off from it in 1993: NetBSD and FreeBSD. The two projects originally diverged due to differences in patience waiting for improvements to 386BSD: the NetBSD people started early in the year, and the first version of FreeBSD was not ready until the end of the year. In the meantime, the code base had diverged sufficiently to make it difficult to merge. In addition, the projects had different aims, as we will see below. In 1996, OpenBSD split off from NetBSD, and in 2003, DragonFlyBSD split off from FreeBSD. Why is BSD not better known? For a number of reasons, BSD is relatively unknown: The BSD developers are often more interested in polishing their code than marketing it. Much of Linux's popularity is due to factors external to the Linux projects, such as the press, and to companies formed to provide Linux services. Until recently, the open source BSDs had no such proponents. BSD developers tend to be more experienced than Linux developers, and have less interest in making the system easy to use. Newcomers tend to feel more comfortable with Linux. In 1992, AT&T sued BSDI, the vendor of BSD/386, alleging that the product contained AT&T-copyrighted code. The case was settled out of court in 1994, but the spectre of the litigation continues to haunt people. As recently as March 2000 an article published on the web claimed that the court case had been recently settled. One detail that the lawsuit did clarify is the naming: in the 1980s, BSD was known as BSD &unix;. With the elimination of the last vestige of AT&T code from BSD, it also lost the right to the name &unix;. Thus you will see references in book titles to the 4.3BSD &unix; operating system and the 4.4BSD operating system. There is a perception that the BSD projects are fragmented and belligerent. The Wall Street Journal spoke of balkanization of the BSD projects. Like the law suit, this perception bases mainly on ancient history. Comparing BSD and Linux So what is really the difference between, say, Debian Linux and FreeBSD? For the average user, the difference is surprisingly small: Both are &unix; like operating systems. Both are developed by non-commercial projects (this does not apply to many other Linux distributions, of course). In the following section, we will look at BSD and compare it to Linux. The description applies most closely to FreeBSD, which accounts for an estimated 80% of the BSD installations, but the differences from NetBSD, OpenBSD and DragonFlyBSD are small. Who owns BSD? No one person or corporation owns BSD. It is created and distributed by a community of highly technical and committed contributors all over the world. Some of the components of BSD are Open Source projects in their own right and managed by different project maintainers. How is BSD developed and updated? The BSD kernels are developed and updated following the Open Source development model. Each project maintains a publicly accessible source tree under the Concurrent Versions System (CVS), which contains all source files for the project, including documentation and other incidental files. CVS allows users to check out (in other words, to extract a copy of) any desired version of the system. A large number of developers worldwide contribute to improvements to BSD. They are divided into three kinds: Contributors write code or documentation. They are not permitted to commit (add code) directly to the source tree. In order for their code to be included in the system, it must be reviewed and checked in by a registered developer, known as a committer. Committers are developers with write access to the source tree. In order to become a committer, an individual must show ability in the area in which he is active. It is at the individual committer's discretion whether he should obtain authority before committing changes to the source tree. In general, an experienced committer may make changes which are obviously correct without obtaining consensus. For example, a documentation project committer may correct typographical or grammatical errors without review. On the other hand, developers making far-reaching or complicated changes are expected to submit their changes for review before committing them. In extreme cases, a core team member with a function such as Principal Architect may order that changes be removed from the tree, a process known as backing out. All committers receive mail describing each individual commit, so it is not possible to commit secretly. The Core team. FreeBSD and NetBSD each have a core team which manages the project. The core teams developed in the course of the projects, and their role is not always well-defined. It is not necessary to be a developer in order to be a core team member, though it is normal. The rules for the core team vary from one project to the other, but in general they have more say in the direction of the project than non-core team members have. This arrangement differs from Linux in a number of ways: No one person controls the content of the system. In practice, this difference is overrated, since the Principal Architect can require that code be backed out, and even in the Linux project several people are permitted to make changes. On the other hand, there is a central repository, a single place where you can find the entire operating system sources, including all older versions. BSD projects maintain the entire Operating System, not only the kernel. This distinction is only marginally useful: neither BSD nor Linux is useful without applications. The applications used under BSD are frequently the same as the applications used under Linux. As a result of the formalized maintenance of a single CVS source tree, BSD development is clear, and it is possible to access any version of the system by release number or by date. CVS also allows incremental updates to the system: for example, the FreeBSD repository is updated about 100 times a day. Most of these changes are small. BSD releases FreeBSD, NetBSD and OpenBSD provide the system in three different releases. As with Linux, releases are assigned a number such as 1.4.1 or 3.5. In addition, the version number has a suffix indicating its purpose: The development version of the system is called CURRENT. FreeBSD assigns a number to CURRENT, for example FreeBSD 5.0-CURRENT. NetBSD uses a slightly different naming scheme and appends a single-letter suffix which indicates changes in the internal interfaces, for example NetBSD 1.4.3G. OpenBSD does not assign a number (OpenBSD-current). All new development on the system goes into this branch. At regular intervals, between two and four times a year, the projects bring out a RELEASE version of the system, which is available on CD-ROM and for free download from FTP sites, for example OpenBSD 2.6-RELEASE or NetBSD 1.4-RELEASE. The RELEASE version is intended for end users and is the normal version of the system. NetBSD also provides patch releases with a third digit, for example NetBSD 1.4.2. As bugs are found in a RELEASE version, they are fixed, and the fixes are added to the CVS tree. In FreeBSD, the resultant version is called the STABLE version, while in NetBSD and OpenBSD it continues to be called the RELEASE version. Smaller new features can also be added to this branch after a period of test in the CURRENT branch. By contrast, Linux maintains two separate code trees: the stable version and the development version. Stable versions have an even minor version number, such as 2.0, 2.2 or 2.4. Development versions have an odd minor version number, such as 2.1, 2.3 or 2.5. In each case, the number is followed by a further number designating the exact release. In addition, each vendor adds their own userland programs and utilities, so the name of the distribution is also important. Each distribution vendor also assigns version numbers to the distribution, so a complete description might be something like TurboLinux 6.0 with kernel 2.2.14 What versions of BSD are available? In contrast to the numerous Linux distributions, there are only four major open source BSDs. Each BSD project maintains its own source tree and its own kernel. In practice, though, there appear to be fewer divergences between the userland code of the projects than there is in Linux. It is difficult to categorize the goals of each project: the differences are very subjective. Basically, FreeBSD aims for high performance and ease of use by end users, and is a favourite of web content providers. It runs on a number of platforms, including &i386; based systems (PCs), systems based on the AMD 64-bit processors, &ultrasparc; based systems, systems based on Compaq's Alpha processors and systems based around the NEC PC-98 specification. The FreeBSD project has significantly more users than the other projects. NetBSD aims for maximum portability: of course it runs NetBSD. It runs on machines from palmtops to large servers, and has even been used on NASA space missions. It is a particularly good choice for running on old non-&intel; hardware. OpenBSD aims for security and code purity: it uses a combination of the open source concept and rigorous code reviews to create a system which is demonstrably correct, making it the choice of security-conscious organizations such as banks, stock exchanges and US Government departments. Like NetBSD, it runs on a number of platforms. DragonFlyBSD aims for high performance and scalability under everything from a single-node UP system to a massively clustered system. DragonFlyBSD has several long-range technical goals, but focus lies on providing a SMP-capable infrastructure that is easy to understand, maintain and develop for. There are also two additional BSD &unix; operating systems which are not open source, BSD/OS and Apple's &macos; X: BSD/OS was the oldest of the 4.4BSD derivatives. It was not open source, though source code licenses were available at relatively low cost. It resembled FreeBSD in many ways. Two years after the acquisition of BSDi by Wind River Systems, BSD/OS failed to survive as an independent product. Support and source code may still be available from Wind River, but all new development is focused on the VxWorks embedded operating system. &macos; X is the latest version of the operating system for - Apple Computer Inc.'s - &macintosh; line. The BSD core of this operating + &apple;'s + &mac; line. The BSD core of this operating system, Darwin, is available as a fully functional open source operating system for x86 and PPC computers. The Aqua/Quartz graphics system and many other proprietary aspects of &macos; X remain closed-source, however. Several Darwin developers are also FreeBSD committers, and vice-versa. How does the BSD license differ from the GNU Public license? Linux is available under the GNU General Public License (GPL), which is designed to eliminate closed source software. In particular, any derivative work of a product released under the GPL must also be supplied with source code if requested. By contrast, the BSD license is less restrictive: binary-only distributions are allowed. This is particularly attractive for embedded applications. What else should I know? Since fewer applications are available for BSD than Linux, the BSD developers created a Linux compatibility package, which allows Linux programs to run under BSD. The package includes both kernel modifications, in order to correctly perform Linux system calls, and Linux compatibility files such as the C library. There is no noticeable difference in execution speed between a Linux application running on a Linux machine and a Linux application running on a BSD machine of the same speed. The all from one supplier nature of BSD means that upgrades are much easier to handle than is frequently the case with Linux. BSD handles library version upgrades by providing compatibility modules for earlier library versions, so it is possible to run binaries which are several years old with no problems. Which should I use, BSD or Linux? What does this all mean in practice? Who should use BSD, who should use Linux? This is a very difficult question to answer. Here are some guidelines: If it ain't broke, don't fix it: If you already use an open source operating system, and you are happy with it, there is probably no good reason to change. BSD systems, in particular FreeBSD, can have notably higher performance than Linux. But this is not across the board. In many cases, there is little or no difference in performance. In some cases, Linux may perform better than FreeBSD. In general, BSD systems have a better reputation for reliability, mainly as a result of the more mature code base. BSD projects have a better reputation for the quality and completeness of their documentation. The various documentation projects aim to provide actively updated documentation, in many languages, and covering all aspects of the system. The BSD license may be more attractive than the GPL. BSD can execute most Linux binaries, while Linux can not execute BSD binaries. Many BSD implementations can also execute binaries from other &unix; like systems. As a result, BSD may present an easier migration route from other systems than Linux would. Who provides support, service, and training for BSD? BSDi / FreeBSD Mall, Inc. have been providing support contracts for FreeBSD for nearly a decade. In addition, each of the projects has a list of consultants for hire: FreeBSD, NetBSD, and OpenBSD.
Index: head/en_US.ISO8859-1/books/handbook/virtualization/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/virtualization/chapter.xml (revision 45695) +++ head/en_US.ISO8859-1/books/handbook/virtualization/chapter.xml (revision 45696) @@ -1,1606 +1,1606 @@ Virtualization Murray Stokely Contributed by Allan Jude bhyve section by Synopsis Virtualization software allows multiple operating systems to run simultaneously on the same computer. Such software systems for PCs often involve a host operating system which runs the virtualization software and supports any number of guest operating systems. After reading this chapter, you will know: The difference between a host operating system and a guest operating system. How to install &os; on an &intel;-based &apple; - &macintosh; computer. + &mac; computer. How to install &os; on µsoft.windows; with Virtual PC. How to install &os; as a guest in byhve. How to tune a &os; system for best performance under virtualization. Before reading this chapter, you should: Understand the basics of &unix; and &os;. Know how to install &os;. Know how to set up a network connection. Know how to install additional third-party software. &os; as a Guest OS <application>Parallels</application> on &macos; X Parallels Desktop for &mac; is a commercial software product available for &intel; based &apple; &mac; computers running &macos; 10.4.6 or higher. &os; is a fully supported guest operating system. Once Parallels has been installed on &macos; X, the user must configure a virtual machine and then install the desired guest operating system. Installing &os; on Parallels/&macos; X The first step in installing &os; on Parallels is to create a new virtual machine for installing &os;. Select &os; as the Guest OS Type when prompted: Choose a reasonable amount of disk and memory depending on the plans for this virtual &os; instance. 4GB of disk space and 512MB of RAM work well for most uses of &os; under Parallels: Select the type of networking and a network interface: Save and finish the configuration: After the &os; virtual machine has been created, &os; can be installed on it. This is best done with an official &os; CD/DVD or with an ISO image downloaded from an official FTP site. Copy the appropriate ISO image to the local &mac; filesystem or insert a CD/DVD in the &mac;'s CD drive. Click on the disc icon in the bottom right corner of the &os; Parallels window. This will bring up a window that can be used to associate the CDROM drive in the virtual machine with the ISO file on disk or with the real CDROM drive. Once this association with the CDROM source has been made, reboot the &os; virtual machine by clicking the reboot icon. Parallels will reboot with a special BIOS that first checks if there is a CDROM. In this case it will find the &os; installation media and begin a normal &os; installation. Perform the installation, but do not attempt to configure &xorg; at this time. When the installation is finished, reboot into the newly installed &os; virtual machine. Configuring &os; on <application>Parallels</application> After &os; has been successfully installed on &macos; X with Parallels, there are a number of configuration steps that can be taken to optimize the system for virtualized operation. Set Boot Loader Variables The most important step is to reduce the tunable to reduce the CPU utilization of &os; under the Parallels environment. This is accomplished by adding the following line to /boot/loader.conf: kern.hz=100 Without this setting, an idle &os; Parallels guest will use roughly 15% of the CPU of a single processor &imac;. After this change the usage will be closer to 5%. Create a New Kernel Configuration File All of the SCSI, FireWire, and USB device drivers can be removed from a custom kernel configuration file. Parallels provides a virtual network adapter used by the &man.ed.4; driver, so all network devices except for &man.ed.4; and &man.miibus.4; can be removed from the kernel. Configure Networking The most basic networking setup uses DHCP to connect the virtual machine to the same local area network as the host &mac;. This can be accomplished by adding ifconfig_ed0="DHCP" to /etc/rc.conf. More advanced networking setups are described in . <application>Virtual PC</application> on &windows; Virtual PC for &windows; is a µsoft; software product available for free download. See this website for the system requirements. Once Virtual PC has been installed on µsoft.windows;, the user can configure a virtual machine and then install the desired guest operating system. Installing &os; on <application>Virtual PC</application> The first step in installing &os; on Virtual PC is to create a new virtual machine for installing &os;. Select Create a virtual machine when prompted: Select Other as the Operating system when prompted: Then, choose a reasonable amount of disk and memory depending on the plans for this virtual &os; instance. 4GB of disk space and 512MB of RAM work well for most uses of &os; under Virtual PC: Save and finish the configuration: Select the &os; virtual machine and click Settings, then set the type of networking and a network interface: After the &os; virtual machine has been created, &os; can be installed on it. This is best done with an official &os; CD/DVD or with an ISO image downloaded from an official FTP site. Copy the appropriate ISO image to the local &windows; filesystem or insert a CD/DVD in the CD drive, then double click on the &os; virtual machine to boot. Then, click CD and choose Capture ISO Image... on the Virtual PC window. This will bring up a window where the CDROM drive in the virtual machine can be associated with an ISO file on disk or with the real CDROM drive. Once this association with the CDROM source has been made, reboot the &os; virtual machine by clicking Action and Reset. Virtual PC will reboot with a special BIOS that first checks for a CDROM. In this case it will find the &os; installation media and begin a normal &os; installation. Continue with the installation, but do not attempt to configure &xorg; at this time. When the installation is finished, remember to eject the CD/DVD or release the ISO image. Finally, reboot into the newly installed &os; virtual machine. Configuring &os; on <application>Virtual PC</application> After &os; has been successfully installed on µsoft.windows; with Virtual PC , there are a number of configuration steps that can be taken to optimize the system for virtualized operation. Set Boot Loader Variables The most important step is to reduce the tunable to reduce the CPU utilization of &os; under the Virtual PC environment. This is accomplished by adding the following line to /boot/loader.conf: kern.hz=100 Without this setting, an idle &os; Virtual PC guest OS will use roughly 40% of the CPU of a single processor computer. After this change, the usage will be closer to 3%. Create a New Kernel Configuration File All of the SCSI, FireWire, and USB device drivers can be removed from a custom kernel configuration file. Virtual PC provides a virtual network adapter used by the &man.de.4; driver, so all network devices except for &man.de.4; and &man.miibus.4; can be removed from the kernel. Configure Networking The most basic networking setup uses DHCP to connect the virtual machine to the same local area network as the µsoft.windows; host. This can be accomplished by adding ifconfig_de0="DHCP" to /etc/rc.conf. More advanced networking setups are described in . <application>VMware Fusion</application> on &macos; VMware Fusion for &mac; is a commercial software product available for &intel; based &apple; &mac; computers running &macos; 10.4.9 or higher. &os; is a fully supported guest operating system. Once VMware Fusion has been installed on &macos; X, the user can configure a virtual machine and then install the desired guest operating system. Installing &os; on <application>VMware Fusion</application> The first step is to start VMware Fusion which will load the Virtual Machine Library. Click New to create the virtual machine: This will load the New Virtual Machine Assistant. Click Continue to proceed: Select Other as the Operating System and either &os; or &os; 64-bit, as the Version when prompted: Choose the name of the virtual machine and the directory where it should be saved: Choose the size of the Virtual Hard Disk for the virtual machine: Choose the method to install the virtual machine, either from an ISO image or from a CD/DVD: Click Finish and the virtual machine will boot: Install &os; as usual: Once the install is complete, the settings of the virtual machine can be modified, such as memory usage: The System Hardware settings of the virtual machine cannot be modified while the virtual machine is running. The number of CPUs the virtual machine will have access to: The status of the CDROM device. Normally the CD/DVD/ISO is disconnected from the virtual machine when it is no longer needed. The last thing to change is how the virtual machine will connect to the network. To allow connections to the virtual machine from other machines besides the host, choose Connect directly to the physical network (Bridged). Otherwise, Share the host's internet connection (NAT) is preferred so that the virtual machine can have access to the Internet, but the network cannot access the virtual machine. After modifying the settings, boot the newly installed &os; virtual machine. Configuring &os; on <application>VMware Fusion</application> After &os; has been successfully installed on &macos; X with VMware Fusion, there are a number of configuration steps that can be taken to optimize the system for virtualized operation. Set Boot Loader Variables The most important step is to reduce the tunable to reduce the CPU utilization of &os; under the VMware Fusion environment. This is accomplished by adding the following line to /boot/loader.conf: kern.hz=100 Without this setting, an idle &os; VMware Fusion guest will use roughly 15% of the CPU of a single processor &imac;. After this change, the usage will be closer to 5%. Create a New Kernel Configuration File All of the FireWire, and USB device drivers can be removed from a custom kernel configuration file. VMware Fusion provides a virtual network adapter used by the &man.em.4; driver, so all network devices except for &man.em.4; can be removed from the kernel. Configure Networking The most basic networking setup uses DHCP to connect the virtual machine to the same local area network as the host &mac;. This can be accomplished by adding ifconfig_em0="DHCP" to /etc/rc.conf. More advanced networking setups are described in . &virtualbox; Guest Additions on a &os; Guest The &virtualbox; guest additions provide support for: Clipboard sharing. Mouse pointer integration. Host time synchronization. Window scaling. Seamless mode. The following commands are run in the &os; guest. First, install the emulators/virtualbox-ose-additions package or port in the &os; guest. This will install the port: &prompt.root; cd /usr/ports/emulators/virtualbox-ose-additions && make install clean Add these lines to /etc/rc.conf: vboxguest_enable="YES" vboxservice_enable="YES" When Xorg will be used in the guest, any required supporting services must also be enabled just as if the guest was a physical machine. Typically, these lines would also be added to /etc/rc.conf: hald_enable="YES" dbus_enable="YES" See for details. If &man.ntpd.8; or &man.ntpdate.8; is used, disable host time synchronization: vboxservice_flags="--disable-timesync" Xorg will automatically recognize the vboxvideo driver. It can also be manually entered in /etc/X11/xorg.conf: Section "Device" ### Available Driver options are:- ### Values: <i>: integer, <f>: float, <bool>: "True"/"False", ### <string>: "String", <freq>: "<f> Hz/kHz/MHz" ### [arg]: arg optional Identifier "Card0" Driver "vboxvideo" VendorName "InnoTek Systemberatung GmbH" BoardName "VirtualBox Graphics Adapter" BusID "PCI:0:2:0" EndSection To use the vboxmouse driver, adjust the mouse section in /etc/X11/xorg.conf: Section "InputDevice" Identifier "Mouse0" Driver "vboxmouse" EndSection HAL users should create the following /usr/local/etc/hal/fdi/policy/90-vboxguest.fdi or copy it from /usr/local/share/hal/fdi/policy/10osvendor/90-vboxguest.fdi: <?xml version="1.0" encoding="utf-8"?> <!-- # Sun VirtualBox # Hal driver description for the vboxmouse driver # $Id: chapter.xml,v 1.33 2012-03-17 04:53:52 eadler Exp $ Copyright (C) 2008-2009 Sun Microsystems, Inc. This file is part of VirtualBox Open Source Edition (OSE, as available from http://www.virtualbox.org. This file is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License (GPL) as published by the Free Software Foundation, in version 2 as it comes in the "COPYING" file of the VirtualBox OSE distribution. VirtualBox OSE is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY of any kind. Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, CA 95054 USA or visit http://www.sun.com if you need additional information or have any questions. --> <deviceinfo version="0.2"> <device> <match key="info.subsystem" string="pci"> <match key="info.product" string="VirtualBox guest Service"> <append key="info.capabilities" type="strlist">input</append> <append key="info.capabilities" type="strlist">input.mouse</append> <merge key="input.x11_driver" type="string">vboxmouse</merge> <merge key="input.device" type="string">/dev/vboxguest</merge> </match> </match> </device> </deviceinfo> &os; as a Host with <application>VirtualBox</application> &virtualbox; is an actively developed, complete virtualization package, that is available for most operating systems including &windows;, &macos;, &linux; and &os;. It is equally capable of running &windows; or &unix;-like guests. It is released as open source software, but with closed-source components available in a separate extension pack. These components include support for USB 2.0 devices. More information may be found on the Downloads page of the &virtualbox; wiki. Currently, these extensions are not available for &os;. Installing &virtualbox; &virtualbox; is available as a &os; package or port in emulators/virtualbox-ose. The port can be installed using these commands: &prompt.root; cd /usr/ports/emulators/virtualbox-ose &prompt.root; make install clean One useful option in the port's configuration menu is the GuestAdditions suite of programs. These provide a number of useful features in guest operating systems, like mouse pointer integration (allowing the mouse to be shared between host and guest without the need to press a special keyboard shortcut to switch) and faster video rendering, especially in &windows; guests. The guest additions are available in the Devices menu, after the installation of the guest is finished. A few configuration changes are needed before &virtualbox; is started for the first time. The port installs a kernel module in /boot/modules which must be loaded into the running kernel: &prompt.root; kldload vboxdrv To ensure the module always gets loaded after a reboot, add the following line to /boot/loader.conf: vboxdrv_load="YES" To use the kernel modules that allow bridged or host-only networking, add the following to /etc/rc.conf and reboot the computer: vboxnet_enable="YES" The vboxusers group is created during installation of &virtualbox;. All users that need access to &virtualbox; will have to be added as members of this group. pw can be used to add new members: &prompt.root; pw groupmod vboxusers -m yourusername The default permissions for /dev/vboxnetctl are restrictive and need to be changed for bridged networking: &prompt.root; chown root:vboxusers /dev/vboxnetctl &prompt.root; chmod 0660 /dev/vboxnetctl To make this permissions change permanent, add these lines to /etc/devfs.conf: own vboxnetctl root:vboxusers perm vboxnetctl 0660 To launch &virtualbox;, type from a &xorg; session: &prompt.user; VirtualBox For more information on configuring and using &virtualbox;, refer to the official website. For &os;-specific information and troubleshooting instructions, refer to the relevant page in the &os; wiki. &virtualbox; USB Support In order to be able to read and write to USB devices, users need to be members of operator: &prompt.root; pw groupmod operator -m jerry Then, add the following to /etc/devfs.rules, or create this file if it does not exist yet: [system=10] add path 'usb/*' mode 0660 group operator To load these new rules, add the following to /etc/rc.conf: devfs_system_ruleset="system" Then, restart devfs: &prompt.root; service devfs restart USB can now be enabled in the guest operating system. USB devices should be visible in the &virtualbox; preferences. &virtualbox; Host DVD/CD Access Access to the host DVD/CD drives from guests is achieved through the sharing of the physical drives. Within &virtualbox;, this is set up from the Storage window in the Settings of the virtual machine. If needed, create an empty IDE CD/DVD device first. Then choose the Host Drive from the popup menu for the virtual CD/DVD drive selection. A checkbox labeled Passthrough will appear. This allows the virtual machine to use the hardware directly. For example, audio CDs or the burner will only function if this option is selected. HAL needs to run for &virtualbox; DVD/CD functions to work, so enable it in /etc/rc.conf and start it if it is not already running: hald_enable="YES" &prompt.root; service hald start In order for users to be able to use &virtualbox; DVD/CD functions, they need access to /dev/xpt0, /dev/cdN, and /dev/passN. This is usually achieved by making the user a member of operator. Permissions to these devices have to be corrected by adding these lines to /etc/devfs.conf: perm cd* 0660 perm xpt0 0660 perm pass* 0660 &prompt.root; service devfs restart &os; as a Host with <application>bhyve</application> Starting with &os; 10.0-RELEASE, the bhyve BSD-licensed hypervisor is part of the base system. This hypervisor supports a number of guests, including &os;, OpenBSD, and many &linux; distributions. Currently, bhyve only supports a serial console and does not emulate a graphical console. As a legacy-free hypervisor, it relies on the virtualization offload features of newer CPUs, instead of translating instructions and manually managing memory mappings. Due to the design of bhyve, it requires a computer with a newer processor that supports &intel; Extended Page Tables (EPT) or &amd; Rapid Virtualization Indexing (RVI), also known as Nested Page Tables (NPT). Most newer processors, specifically the &intel; &core; i3/i5/i7 and &intel; &xeon; E3/E5/E7, support this feature. For a complete list of &intel; processors that support EPT, refer to http://ark.intel.com/search/advanced?s=t&ExtendedPageTables=true. RVI is found on the 3rd generation and later of the &amd.opteron; (Barcelona) processors. The easiest way to check for support of EPT or RVI is to look for the POPCNT processor feature flag on the Features2 line in dmesg or /var/run/dmesg.boot. Preparing the Host The first step to creating a virtual machine in bhyve is configuring the host system. First, load the bhyve kernel module: &prompt.root; kldload vmm Then, create a tap interface for the network device in the virtual machine to attach to. In order for the network device to participate in the network, also create a bridge interface containing the tap interface ane the physical interface as members. In this example, the physical interface is igb0: &prompt.root; ifconfig tap0 create &prompt.root; sysctl net.link.tap.up_on_open=1 net.link.tap.up_on_open: 0 -> 1 &prompt.root; ifconfig bridge0 create &prompt.root; ifconfig bridge0 addm igb0 addm tap0 &prompt.root; ifconfig bridge0 up Creating a FreeBSD Guest Create a file to use as the virtual disk for the guest machine. Specify the size and name of the virtual disk: &prompt.root; truncate -s 16G guest.img Download an installation image of &os; to install: &prompt.root; fetch ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/10.0/FreeBSD-10.0-RELEASE-amd64-bootonly.iso FreeBSD-10.0-RELEASE-amd64-bootonly.iso 100% of 209 MB 570 kBps 06m17s &os; comes with an example script for running a virtual machine in bhyve. The script will start the virtual machine and run it in a loop, so it will automatically restart if it crashes. The script takes a number of options to control the configuration of the machine: controls the number of virtual CPUs, limits the amount of memory available to the guest, defines which tap device to use, indicates which disk image to use, tells bhyve to boot from the CD image instead of the disk, and defines which CD image to use. The last parameter is the name of the virtual machine, used to track the running machines. This example starts the virtual machine in installation mode: &prompt.root; sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d guest.img -i -I FreeBSD-10.0-RELEASE-amd64-bootonly.iso guestname The virtual machine will boot and start the installer. After installing a system in the virtual machine, when the system asks about dropping in to a shell at the end of the installation, choose Yes. A small change needs to be made to make the system start with a serial console. Edit /etc/ttys and replace the existing ttyu0 line with: ttyu0 "/usr/libexec/getty 3wire" xterm on secure Beginning with &os; 9.3-RELEASE and 10.1-RELEASE the console is configured automatically. Reboot the virtual machine. While rebooting the virtual machine causes bhyve to exit, the vmrun.sh script runs bhyve in a loop and will automatically restart it. When this happens, choose the reboot option from the boot loader menu in order to escape the loop. Now the guest can be started from the virtual disk: &prompt.root; sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d guest.img guestname Creating a &linux; Guest In order to boot operating systems other than &os;, the sysutils/grub2-bhyve port must be first installed. Next, create a file to use as the virtual disk for the guest machine: &prompt.root; truncate -s 16G linux.img Starting a virtual machine with bhyve is a two step process. First a kernel must be loaded, then the guest can be started. The &linux; kernel is loaded with sysutils/grub2-bhyve. Create a device.map that grub will use to map the virtual devices to the files on the host system: (hd0) ./linux.img (cd0) ./somelinux.iso Use sysutils/grub2-bhyve to load the &linux; kernel from the ISO image: &prompt.root; grub-bhyve -m device.map -r cd0 -M 1024M linuxguest This will start grub. If the installation CD contains a grub.cfg, a menu will be displayed. If not, the vmlinuz and initrd files must be located and loaded manually: grub> ls (hd0) (cd0) (cd0,msdos1) (host) grub> ls (cd0)/isolinux boot.cat boot.msg grub.conf initrd.img isolinux.bin isolinux.cfg memtest splash.jpg TRANS.TBL vesamenu.c32 vmlinuz grub> linux (cd0)/isolinux/vmlinuz grub> initrd (cd0)/isolinux/initrd.img grub> boot Now that the &linux; kernel is loaded, the guest can be started: &prompt.root; bhyve -AI -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-net,tap1 -s 3:0,virtio-blk,./linux.img \ -s 4:0,ahci-cd,./somelinux.iso -l com1,stdio -c 4 -m 1024M linuxguest The system will boot and start the installer. After installing a system in the virtual machine, reboot the virtual machine. This will cause bhyve to exit. The instance of the virtual machine needs to be destroyed before it can be started again: &prompt.root; bhyvectl --destroy --vm=linuxguest Now the guest can be started directly from the virtual disk. Load the kernel: &prompt.root; grub-bhyve -m device.map -r hd0,msdos1 -M 1024M linuxguest grub> ls (hd0) (hd0,msdos2) (hd0,msdos1) (cd0) (cd0,msdos1) (host) (lvm/VolGroup-lv_swap) (lvm/VolGroup-lv_root) grub> ls (hd0,msdos1)/ lost+found/ grub/ efi/ System.map-2.6.32-431.el6.x86_64 config-2.6.32-431.el6.x 86_64 symvers-2.6.32-431.el6.x86_64.gz vmlinuz-2.6.32-431.el6.x86_64 initramfs-2.6.32-431.el6.x86_64.img grub> linux (hd0,msdos1)/vmlinuz-2.6.32-431.el6.x86_64 root=/dev/mapper/VolGroup-lv_root grub> initrd (hd0,msdos1)/initramfs-2.6.32-431.el6.x86_64.img grub> boot Boot the virtual machine: &prompt.root; bhyve -AI -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-net,tap1 \ -s 3:0,virtio-blk,./linux.img -l com1,stdio -c 4 -m 1024M linuxguest &linux; will now boot in the virtual machine and eventually present you with the login prompt. Login and use the virtual machine. When you are finished, reboot the virtual machine to exit bhyve. Destroy the virtual machine instance: &prompt.root; bhyvectl --destroy --vm=linuxguest Virtual Machine Consoles It is advantageous to wrap the bhyve console in a session management tool such as sysutils/tmux or sysutils/screen in order to detach and reattach to the console. It is also possible to have the console of bhyve be a null modem device that can be accessed with cu. To do this, load the nmdm kernel module and replace with . The /dev/nmdm devices are created automatically as needed, where each is a pair, corresponding to the two ends of the null modem cable (/dev/nmdm1A and /dev/nmdm1B). See &man.nmdm.4; for more information. &prompt.root; kldload nmdm &prompt.root; bhyve -AI -H -P -s 0:0,hostbridge -s 1:0,lpc -s 2:0,virtio-net,tap1 -s 3:0,virtio-blk,./linux.img \ -l com1,/dev/nmdm0A -c 4 -m 1024M linuxguest &prompt.root; cu -l /dev/nmdm0B -s 9600 Connected Ubuntu 13.10 handbook ttyS0 handbook login: Managing Virtual Machines A device node is created in /dev/vmm for each virtual machine. This allows the administrator to easily see a list of the running virtual machines: &prompt.root; ls -al /dev/vmm total 1 dr-xr-xr-x 2 root wheel 512 Mar 17 12:19 ./ dr-xr-xr-x 14 root wheel 512 Mar 17 06:38 ../ crw------- 1 root wheel 0x1a2 Mar 17 12:20 guestname crw------- 1 root wheel 0x19f Mar 17 12:19 linuxguest crw------- 1 root wheel 0x1a1 Mar 17 12:19 otherguest A specified virtual machine can be destroyed using bhyvectl: &prompt.root; bhyvectl --destroy --vm=guestname Persistent Configuration In order to configure the system to start bhyve guests at boot time, add the following entries to in the following files: <filename>/etc/sysctl.conf</filename> net.link.tap.up_on_open=1 <filename>/boot/loader.conf</filename> vmm_load="YES" nmdm_load="YES" if_bridge_load="YES" if_tap_load="YES" <filename>/etc/rc.conf</filename> cloned_interfaces="bridge0 tap0" ifconfig_bridge0="addm igb0 addm tap0" Index: head/en_US.ISO8859-1/books/handbook/x11/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/x11/chapter.xml (revision 45695) +++ head/en_US.ISO8859-1/books/handbook/x11/chapter.xml (revision 45696) @@ -1,1475 +1,1475 @@ The X Window System Synopsis An installation of &os; using bsdinstall does not automatically install a graphical user interface. This chapter describes how to install and configure &xorg;, which provides the open source X Window System used to provide a graphical environment. It then describes how to find and install a desktop environment or window manager. Users who prefer an installation method that automatically configures the &xorg; and offers a choice of window managers during installation should refer to the pcbsd.org website. For more information on the video hardware that &xorg; supports, refer to the x.org website. After reading this chapter, you will know: The various components of the X Window System, and how they interoperate. How to install and configure &xorg;. How to install and configure several window managers and desktop environments. How to use &truetype; fonts in &xorg;. How to set up your system for graphical logins (XDM). Before reading this chapter, you should: Know how to install additional third-party software as described in . Terminology While it is not necessary to understand all of the details of the various components in the X Window System and how they interact, some basic knowledge of these components can be useful: X server X was designed from the beginning to be network-centric, and adopts a client-server model. In this model, the X server runs on the computer that has the keyboard, monitor, and mouse attached. The server's responsibility includes tasks such as managing the display, handling input from the keyboard and mouse, and handling input or output from other devices such as a tablet or a video projector. This confuses some people, because the X terminology is exactly backward to what they expect. They expect the X server to be the big powerful machine down the hall, and the X client to be the machine on their desk. X client Each X application, such as XTerm or Firefox, is a client. A client sends messages to the server such as Please draw a window at these coordinates, and the server sends back messages such as The user just clicked on the OK button. In a home or small office environment, the X server and the X clients commonly run on the same computer. It is also possible to run the X server on a less powerful computer and to run the X applications on a more powerful system. In this scenario, the communication between the X client and server takes place over the network. window manager X does not dictate what windows should look like on screen, how to move them around with the mouse, which keystrokes should be used to move between windows, what the title bars on each window should look like, whether or not they have close buttons on them, and so on. Instead, X delegates this responsibility to a separate window manager application. There are dozens of window managers available. Each window manager provides a different look and feel: some support virtual desktops, some allow customized keystrokes to manage the desktop, some have a Start button, and some are themeable, allowing a complete change of the desktop's look-and-feel. Window managers are available in the x11-wm category of the Ports Collection. Each window manager uses a different configuration mechanism. Some expect configuration file written by hand while others provide graphical tools for most configuration tasks. desktop environment KDE and GNOME are considered to be desktop environments as they include an entire suite of applications for performing common desktop tasks. These may include office suites, web browsers, and games. focus policy The window manager is responsible for the mouse focus policy. This policy provides some means for choosing which window is actively receiving keystrokes and it should also visibly indicate which window is currently active. One focus policy is called click-to-focus. In this model, a window becomes active upon receiving a mouse click. In the focus-follows-mouse policy, the window that is under the mouse pointer has focus and the focus is changed by pointing at another window. If the mouse is over the root window, then this window is focused. In the sloppy-focus model, if the mouse is moved over the root window, the most recently used window still has the focus. With sloppy-focus, focus is only changed when the cursor enters a new window, and not when exiting the current window. In the click-to-focus policy, the active window is selected by mouse click. The window may then be raised and appear in front of all other windows. All keystrokes will now be directed to this window, even if the cursor is moved to another window. Different window managers support different focus models. All of them support click-to-focus, and the majority of them also support other policies. Consult the documentation for the window manager to determine which focus models are available. widgets Widget is a term for all of the items in the user interface that can be clicked or manipulated in some way. This includes buttons, check boxes, radio buttons, icons, and lists. A widget toolkit is a set of widgets used to create graphical applications. There are several popular widget toolkits, including Qt, used by KDE, and GTK+, used by GNOME. As a result, applications will have a different look and feel, depending upon which widget toolkit was used to create the application. Installing <application>&xorg;</application> &xorg; is the implementation of the open source X Window System released by the X.Org Foundation. In &os;, it can be installed as a package or port. The meta-port for the complete distribution which includes X servers, clients, libraries, and fonts is located in x11/xorg. A minimal distribution is located in x11/xorg-minimal, with separate ports available for docs, libraries, and apps. The examples in this section install the complete &xorg; distribution. To build and install &xorg; from the Ports Collection: &prompt.root; cd /usr/ports/x11/xorg &prompt.root; make install clean To build &xorg; in its entirety, be sure to have at least 4 GB of free disk space available. Alternatively, &xorg; can be installed directly from packages with this command: &prompt.root; pkg install xorg <application>&xorg;</application> Configuration &xorg; &xorg; In most cases, &xorg; is self-configuring. Those with older or unusual equipment may find it helpful to gather some hardware information before beginning configuration. Monitor sync frequencies Video card chipset Video card memory horizontal sync frequency horizontal scan rate horizontal sync frequency refresh rate vertical sync frequency refresh rate vertical scan rate refresh rate Screen resolution and refresh rate are determined by the monitor's horizontal and vertical sync frequencies. Almost all monitors support electronic autodetection of these values. A few monitors do not provide these values, and the specifications must be determined from the printed manual or manufacturer web site. The video card chipset is also autodetected, and used to select the proper video driver. It is beneficial for the user to be aware of which chipset is installed for when autodetection does not provide the desired result. Video card memory determines the maximum resolution and color depth which can be displayed. Caveats The ability to configure optimal resolution is dependent upon the video hardware and the support provided by its driver. At this time, driver support is as follows: NVIDIA: several NVIDIA drivers are available in the x11 category of the FreeBSD Ports Collection. Install the driver that matches the model of the NVIDIA hardware. Intel: as of FreeBSD 9.1, 3D acceleration on most Intel graphics, including IronLake, SandyBridge, and IvyBridge, is supported. Due to the current KMS implementation, it is not possible to switch between the graphical console and a virtual console using Crtl+Alt+F#. ATI/Radeon: 3D acceleration will not work on ATI or Radeon cards until FreeBSD completes its TTM work. These cards will need to be configured with the 2D driver, and if that does not work, with the Vesa driver. Optimus: currently there is no switching support between the two graphics adapters provided by Optimus. Optimus implementations vary, so FreeBSD may or may not be able to successfully load a graphics driver on all hardware. If you get a blank screen, check if the BIOS has an option to disable one of the graphics adapters or to set discrete mode. Configuring <application>&xorg;</application> &xorg; uses HAL to autodetect keyboards and mice. The sysutils/hal and devel/dbus ports are automatically installed as dependencies of x11/xorg, but must be enabled by adding the following entries to /etc/rc.conf: hald_enable="YES" dbus_enable="YES" Start these services before configuring &xorg;: &prompt.root; service hald start &prompt.root; service dbus start Once these services are started, check if &xorg; auto-configures itself by typing: &prompt.root; Xorg -configure This will generate a file named /root/xorg.conf.new which attempts to load the proper drivers for the detected hardware. Next, test that the automatically generated configuration file works with the graphics hardware by typing: &prompt.root; Xorg -config xorg.conf.new -retro If a black and grey grid and an X mouse cursor appear, the configuration was successful. To exit the test, switch to the virtual console used to start it by pressing Ctrl Alt Fn (F1 for the first virtual console) and press Ctrl C . The Ctrl Alt Backspace key combination may also be used to break out of &xorg;. To enable it, you can either type the following command from any X terminal emulator: &prompt.user; setxkbmap -option terminate:ctrl_alt_bksp or create a keyboard configuration file for hald called x11-input.fdi and saved in the /usr/local/etc/hal/fdi/policy directory. This file should contain the following lines: <?xml version="1.0" encoding="iso-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.keyboard"> <merge key="input.x11_options.XkbOptions" type="string">terminate:ctrl_alt_bksp</merge> </match> </device> </deviceinfo> You will have to reboot your machine to force hald to read this file. The following line will also have to be added to xorg.conf.new, in the ServerLayout or ServerFlags section: Option "DontZap" "off" If the test is unsuccessful, skip ahead to . Once the test is successful, copy the configuration file to /etc/X11/xorg.conf: &prompt.root; cp xorg.conf.new /etc/X11/xorg.conf Desktop environments like GNOME, KDE or Xfce provide graphical tools to set parameters such as video resolution. If the default configuration works, skip to for examples on how to install a desktop environment. Using Fonts in <application>&xorg;</application> Type1 Fonts The default fonts that ship with &xorg; are less than ideal for typical desktop publishing applications. Large presentation fonts show up jagged and unprofessional looking, and small fonts are almost completely unintelligible. However, there are several free, high quality Type1 (&postscript;) fonts available which can be readily used with &xorg;. For instance, the URW font collection (x11-fonts/urwfonts) includes high quality versions of standard type1 fonts (Times Roman, Helvetica, Palatino and others). The Freefonts collection (x11-fonts/freefonts) includes many more fonts, but most of them are intended for use in graphics software such as the Gimp, and are not complete enough to serve as screen fonts. In addition, &xorg; can be configured to use &truetype; fonts with a minimum of effort. For more details on this, see the &man.X.7; manual page or . To install the above Type1 font collections from the Ports Collection, run the following commands: &prompt.root; cd /usr/ports/x11-fonts/urwfonts &prompt.root; make install clean And likewise with the freefont or other collections. To have the X server detect these fonts, add an appropriate line to the X server configuration file (/etc/X11/xorg.conf), which reads: FontPath "/usr/local/lib/X11/fonts/URW/" Alternatively, at the command line in the X session run: &prompt.user; xset fp+ /usr/local/lib/X11/fonts/URW &prompt.user; xset fp rehash This will work but will be lost when the X session is closed, unless it is added to the startup file (~/.xinitrc for a normal startx session, or ~/.xsession when logging in through a graphical login manager like XDM). A third way is to use the new /usr/local/etc/fonts/local.conf file as demonstrated in . &truetype; Fonts TrueType Fonts fonts TrueType &xorg; has built in support for rendering &truetype; fonts. There are two different modules that can enable this functionality. The freetype module is used in this example because it is more consistent with the other font rendering back-ends. To enable the freetype module just add the following line to the "Module" section of the /etc/X11/xorg.conf file. Load "freetype" Now make a directory for the &truetype; fonts (for example, /usr/local/lib/X11/fonts/TrueType) and copy all of the &truetype; fonts into this directory. Keep in - mind that &truetype; fonts cannot be directly taken from a - &macintosh;; they must be in &unix;/&ms-dos;/&windows; format + mind that &truetype; fonts cannot be directly taken from an + &apple; &mac;; they must be in &unix;/&ms-dos;/&windows; format for use by &xorg;. Once the files have been copied into this directory, use ttmkfdir to create a fonts.dir file, so that the X font renderer knows that these new files have been installed. ttmkfdir is available from the FreeBSD Ports Collection as x11-fonts/ttmkfdir. &prompt.root; cd /usr/local/lib/X11/fonts/TrueType &prompt.root; ttmkfdir -o fonts.dir Now add the &truetype; directory to the font path. This is just the same as described in : &prompt.user; xset fp+ /usr/local/lib/X11/fonts/TrueType &prompt.user; xset fp rehash or add a FontPath line to the xorg.conf file. That's it. Now Gimp, Apache OpenOffice, and all of the other X applications should now recognize the installed &truetype; fonts. Extremely small fonts (as with text in a high resolution display on a web page) and extremely large fonts (within &staroffice;) will look much better now. Anti-Aliased Fonts anti-aliased fonts fonts anti-aliased All fonts in &xorg; that are found in /usr/local/lib/X11/fonts/ and ~/.fonts/ are automatically made available for anti-aliasing to Xft-aware applications. Most recent applications are Xft-aware, including KDE, GNOME, and Firefox. In order to control which fonts are anti-aliased, or to configure anti-aliasing properties, create (or edit, if it already exists) the file /usr/local/etc/fonts/local.conf. Several advanced features of the Xft font system can be tuned using this file; this section describes only some simple possibilities. For more details, please see &man.fonts-conf.5;. XML This file must be in XML format. Pay careful attention to case, and make sure all tags are properly closed. The file begins with the usual XML header followed by a DOCTYPE definition, and then the <fontconfig> tag: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> As previously stated, all fonts in /usr/local/lib/X11/fonts/ as well as ~/.fonts/ are already made available to Xft-aware applications. If you wish to add another directory outside of these two directory trees, add a line similar to the following to /usr/local/etc/fonts/local.conf: <dir>/path/to/my/fonts</dir> After adding new fonts, and especially new font directories, you should run the following command to rebuild the font caches: &prompt.root; fc-cache -f Anti-aliasing makes borders slightly fuzzy, which makes very small text more readable and removes staircases from large text, but can cause eyestrain if applied to normal text. To exclude font sizes smaller than 14 point from anti-aliasing, include these lines: <match target="font"> <test name="size" compare="less"> <double>14</double> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> <match target="font"> <test name="pixelsize" compare="less" qual="any"> <double>14</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match> fonts spacing Spacing for some monospaced fonts may also be inappropriate with anti-aliasing. This seems to be an issue with KDE, in particular. One possible fix for this is to force the spacing for such fonts to be 100. Add the following lines: <match target="pattern" name="family"> <test qual="any" name="family"> <string>fixed</string> </test> <edit name="family" mode="assign"> <string>mono</string> </edit> </match> <match target="pattern" name="family"> <test qual="any" name="family"> <string>console</string> </test> <edit name="family" mode="assign"> <string>mono</string> </edit> </match> (this aliases the other common names for fixed fonts as "mono"), and then add: <match target="pattern" name="family"> <test qual="any" name="family"> <string>mono</string> </test> <edit name="spacing" mode="assign"> <int>100</int> </edit> </match> Certain fonts, such as Helvetica, may have a problem when anti-aliased. Usually this manifests itself as a font that seems cut in half vertically. At worst, it may cause applications to crash. To avoid this, consider adding the following to local.conf: <match target="pattern" name="family"> <test qual="any" name="family"> <string>Helvetica</string> </test> <edit name="family" mode="assign"> <string>sans-serif</string> </edit> </match> Once you have finished editing local.conf make sure you end the file with the </fontconfig> tag. Not doing this will cause your changes to be ignored. Finally, users can add their own settings via their personal .fonts.conf files. To do this, each user should simply create a ~/.fonts.conf. This file must also be in XML format. LCD screen Fonts LCD screen One last point: with an LCD screen, sub-pixel sampling may be desired. This basically treats the (horizontally separated) red, green and blue components separately to improve the horizontal resolution; the results can be dramatic. To enable this, add the line somewhere in the local.conf file: <match target="font"> <test qual="all" name="rgba"> <const>unknown</const> </test> <edit name="rgba" mode="assign"> <const>rgb</const> </edit> </match> Depending on the sort of display, rgb may need to be changed to bgr, vrgb or vbgr: experiment and see which works best. The X Display Manager Seth Kingsley Contributed by X Display Manager &xorg; provides an X Display Manager, XDM, which can be used for login session management. XDM provides a graphical interface for choosing which display server to connect to and for entering authorization information such as a login and password combination. This section demonstrates how to configure the X Display Manager on &os;. Some desktop environments provide their own graphical login manager. Refer to for instructions on how to configure the GNOME Display Manager and for instructions on how to configure the KDE Display Manager. Configuring <application>XDM</application> To install XDM, use the x11/xdm package or port. Once installed, XDM can be configured to run when the machine boots up by editing this entry in /etc/ttys: ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure Change the off to on and save the edit. The ttyv8 in this entry indicates that XDM will run on the ninth virtual terminal. The XDM configuration directory is located in /usr/local/lib/X11/xdm. This directory contains several files used to change the behavior and appearance of XDM, as well as a few scripts and programs used to set up the desktop when XDM is running. summarizes the function of each of these files. The exact syntax and usage of these files is described in &man.xdm.1;. XDM Configuration Files File Description Xaccess The protocol for connecting to XDM is called the X Display Manager Connection Protocol (XDMCP) This file is a client authorization ruleset for controlling XDMCP connections from remote machines. By default, this file does not allow any remote clients to connect. Xresources This file controls the look and feel of the XDM display chooser and login screens. The default configuration is a simple rectangular login window with the hostname of the machine displayed at the top in a large font and Login: and Password: prompts below. The format of this file is identical to the app-defaults file described in the &xorg; documentation. Xservers The list of local and remote displays the chooser should provide as login choices. Xsession Default session script for logins which is run by XDM after a user has logged in. Normally each user will have a customized session script in ~/.xsession that overrides this script Xsetup_* Script to automatically launch applications before displaying the chooser or login interfaces. There is a script for each display being used, named Xsetup_*, where * is the local display number. Typically these scripts run one or two programs in the background such as xconsole. xdm-config Global configuration for all displays running on this machine. xdm-errors Contains errors generated by the server program. If a display that XDM is trying to start hangs, look at this file for error messages. These messages are also written to the user's ~/.xsession-errors file on a per-session basis. xdm-pid The running process ID of XDM.
Configuring Remote Access By default, only users on the same system can login using XDM. To enable users on other systems to connect to the display server, edit the access control rules and enable the connection listener. To configure XDM to listen for any remote connection, comment out the DisplayManager.requestPort line in /usr/local/lib/X11/xdm/xdm-config by putting a ! in front of it: ! SECURITY: do not listen for XDMCP or Chooser requests ! Comment out this line if you want to manage X terminals with xdm DisplayManager.requestPort: 0 Save the edits and restart XDM. To restrict remote access, look at the example entries in /usr/local/lib/X11/xdm/Xaccess and refer to &man.xdm.1; for further information. Desktop Environments Valentino Vaschetto Contributed by This section describes how to install three popular desktop environments on a &os; system. A desktop environment can range from a simple window manager to a complete suite of desktop applications. Over a hundred desktop environments are available in the x11-wm category of the Ports Collection. GNOME GNOME GNOME is a user-friendly desktop environment. It includes a panel for starting applications and displaying status, a desktop, a set of tools and applications, and a set of conventions that make it easy for applications to cooperate and be consistent with each other. More information regarding GNOME on &os; can be found at http://www.FreeBSD.org/gnome. That web site contains additional documentation about installing, configuring, and managing GNOME on &os;. This desktop environment can be installed from a package: &prompt.root; pkg install gnome2 To instead build GNOME from ports, use the following command. GNOME is a large application and will take some time to compile, even on a fast computer. &prompt.root; cd /usr/ports/x11/gnome2 &prompt.root; make install clean For proper operation, GNOME requires the /proc file system to be mounted. Add this line to /etc/fstab to mount this file system automatically during system startup: proc /proc procfs rw 0 0 Once GNOME is installed, configure &xorg; to start GNOME. The easiest way to do this is to enable the GNOME Display Manager, GDM, which is installed as part of the GNOME package or port. It can be enabled by adding this line to /etc/rc.conf: gdm_enable="YES" It is often desirable to also start all GNOME services. To achieve this, add a second line to /etc/rc.conf: gnome_enable="YES" GDM will now start automatically when the system boots. A second method for starting GNOME is to type startx from the command-line after configuring ~/.xinitrc. If this file already exists, replace the line that starts the current window manager with one that starts /usr/local/bin/gnome-session. If this file does not exist, create it with this command: &prompt.user; echo "exec /usr/local/bin/gnome-session" > ~/.xinitrc A third method is to use XDM as the display manager. In this case, create an executable ~/.xsession: &prompt.user; echo "#!/bin/sh" > ~/.xsession &prompt.user; echo "exec /usr/local/bin/gnome-session" >> ~/.xsession &prompt.user; chmod +x ~/.xsession KDE KDE KDE is another easy-to-use desktop environment. This desktop provides a suite of applications with a consistent look and feel, a standardized menu and toolbars, keybindings, color-schemes, internationalization, and a centralized, dialog-driven desktop configuration. More information on KDE can be found at http://www.kde.org/. For &os;-specific information, consult http://freebsd.kde.org. To install the KDE package, type: &prompt.root; pkg install x11/kde4 To instead build the KDE port, use the following command. Installing the port will provide a menu for selecting which components to install. KDE is a large application and will take some time to compile, even on a fast computer. &prompt.root; cd /usr/ports/x11/kde4 &prompt.root; make install clean KDE display manager KDE requires the /proc file system to be mounted. Add this line to /etc/fstab to mount this file system automatically during system startup: proc /proc procfs rw 0 0 The installation of KDE includes the KDE Display Manager, KDM. To enable this display manager, add this line to /etc/rc.conf: kdm4_enable="YES" A second method for launching KDE is to type startx from the command line. For this to work, the following line is needed in ~/.xinitrc: exec /usr/local/kde4/bin/startkde A third method for starting KDE is through XDM. To do so, create an executable ~/.xsession as follows: &prompt.user; echo "#!/bin/sh" > ~/.xsession &prompt.user; echo "exec /usr/local/kde4/bin/startkde" >> ~/.xsession &prompt.user; chmod +x ~/.xsession Once KDE is started, refer to its built-in help system for more information on how to use its various menus and applications. Xfce Xfce is a desktop environment based on the GTK+ toolkit used by GNOME. However, it is more lightweight and provides a simple, efficient, easy-to-use desktop. It is fully configurable, has a main panel with menus, applets, and application launchers, provides a file manager and sound manager, and is themeable. Since it is fast, light, and efficient, it is ideal for older or slower machines with memory limitations. More information on Xfce can be found at http://www.xfce.org. To install the Xfce package: &prompt.root; pkg install xfce Alternatively, to build the port: &prompt.root; cd /usr/ports/x11-wm/xfce4 &prompt.root; make install clean Unlike GNOME or KDE, Xfce does not provide its own login manager. In order to start Xfce from the command line by typing startx, first add its entry to ~/.xinitrc: &prompt.user; echo "exec /usr/local/bin/startxfce4" > ~/.xinitrc An alternate method is to use XDM. To configure this method, create an executable ~/.xsession: &prompt.user; echo "#!/bin/sh" > ~/.xsession &prompt.user; echo "exec /usr/local/bin/startxfce4" >> ~/.xsession &prompt.user; chmod +x ~/.xsession Troubleshooting If the mouse does not work, you will need to first configure it before proceeding. See in the &os; install chapter. In recent Xorg versions, the InputDevice sections in xorg.conf are ignored in favor of the autodetected devices. To restore the old behavior, add the following line to the ServerLayout or ServerFlags section of this file: Option "AutoAddDevices" "false" Input devices may then be configured as in previous versions, along with any other options needed (e.g., keyboard layout switching). As previously explained the hald daemon will, by default, automatically detect your keyboard. There are chances that your keyboard layout or model will not be correct, desktop environments like GNOME, KDE or Xfce provide tools to configure the keyboard. However, it is possible to set the keyboard properties directly either with the help of the &man.setxkbmap.1; utility or with a hald's configuration rule. For example if, one wants to use a PC 102 keys keyboard coming with a french layout, we have to create a keyboard configuration file for hald called x11-input.fdi and saved in the /usr/local/etc/hal/fdi/policy directory. This file should contain the following lines: <?xml version="1.0" encoding="iso-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.keyboard"> <merge key="input.x11_options.XkbModel" type="string">pc102</merge> <merge key="input.x11_options.XkbLayout" type="string">fr</merge> </match> </device> </deviceinfo> If this file already exists, just copy and add to your file the lines regarding the keyboard configuration. You will have to reboot your machine to force hald to read this file. It is possible to do the same configuration from an X terminal or a script with this command line: &prompt.user; setxkbmap -model pc102 -layout fr The /usr/local/share/X11/xkb/rules/base.lst file lists the various keyboard, layouts and options available. &xorg; tuning The xorg.conf.new configuration file may now be tuned to taste. Open the file in a text editor such as &man.emacs.1; or &man.ee.1;. If the monitor is an older or unusual model that does not support autodetection of sync frequencies, those settings can be added to xorg.conf.new under the "Monitor" section: Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" HorizSync 30-107 VertRefresh 48-120 EndSection Most monitors support sync frequency autodetection, making manual entry of these values unnecessary. For the few monitors that do not support autodetection, avoid potential damage by only entering values provided by the manufacturer. X allows DPMS (Energy Star) features to be used with capable monitors. The &man.xset.1; program controls the time-outs and can force standby, suspend, or off modes. If you wish to enable DPMS features for your monitor, you must add the following line to the monitor section: Option "DPMS" xorg.conf While the xorg.conf.new configuration file is still open in an editor, select the default resolution and color depth desired. This is defined in the "Screen" section: Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1024x768" EndSubSection EndSection The DefaultDepth keyword describes the color depth to run at by default. This can be overridden with the command line switch to &man.Xorg.1;. The Modes keyword describes the resolution to run at for the given color depth. Note that only VESA standard modes are supported as defined by the target system's graphics hardware. In the example above, the default color depth is twenty-four bits per pixel. At this color depth, the accepted resolution is 1024 by 768 pixels. Finally, write the configuration file and test it using the test mode given above. One of the tools available to assist you during troubleshooting process are the &xorg; log files, which contain information on each device that the &xorg; server attaches to. &xorg; log file names are in the format of /var/log/Xorg.0.log. The exact name of the log can vary from Xorg.0.log to Xorg.8.log and so forth. If all is well, the configuration file needs to be installed in a common location where &man.Xorg.1; can find it. This is typically /etc/X11/xorg.conf or /usr/local/etc/X11/xorg.conf. &prompt.root; cp xorg.conf.new /etc/X11/xorg.conf The &xorg; configuration process is now complete. &xorg; may be now started with the &man.startx.1; utility. The &xorg; server may also be started with the use of &man.xdm.1;. Configuration with &intel; <literal>i810</literal> Graphics Chipsets Intel i810 graphic chipset Configuration with &intel; i810 integrated chipsets requires the agpgart AGP programming interface for &xorg; to drive the card. See the &man.agp.4; driver manual page for more information. This will allow configuration of the hardware as any other graphics board. Note on systems without the &man.agp.4; driver compiled in the kernel, trying to load the module with &man.kldload.8; will not work. This driver has to be in the kernel at boot time through being compiled in or using /boot/loader.conf. Adding a Widescreen Flatpanel to the Mix widescreen flatpanel configuration This section assumes a bit of advanced configuration knowledge. If attempts to use the standard configuration tools above have not resulted in a working configuration, there is information enough in the log files to be of use in getting the setup working. Use of a text editor will be necessary. Current widescreen (WSXGA, WSXGA+, WUXGA, WXGA, WXGA+, et.al.) formats support 16:10 and 10:9 formats or aspect ratios that can be problematic. Examples of some common screen resolutions for 16:10 aspect ratios are: 2560x1600 1920x1200 1680x1050 1440x900 1280x800 At some point, it will be as easy as adding one of these resolutions as a possible Mode in the Section "Screen" as such: Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1680x1050" EndSubSection EndSection &xorg; is smart enough to pull the resolution information from the widescreen via I2C/DDC information so it knows what the monitor can handle as far as frequencies and resolutions. If those ModeLines do not exist in the drivers, one might need to give &xorg; a little hint. Using /var/log/Xorg.0.log one can extract enough information to manually create a ModeLine that will work. Simply look for information resembling this: (II) MGA(0): Supported additional Video Mode: (II) MGA(0): clock: 146.2 MHz Image Size: 433 x 271 mm (II) MGA(0): h_active: 1680 h_sync: 1784 h_sync_end 1960 h_blank_end 2240 h_border: 0 (II) MGA(0): v_active: 1050 v_sync: 1053 v_sync_end 1059 v_blanking: 1089 v_border: 0 (II) MGA(0): Ranges: V min: 48 V max: 85 Hz, H min: 30 H max: 94 kHz, PixClock max 170 MHz This information is called EDID information. Creating a ModeLine from this is just a matter of putting the numbers in the correct order: ModeLine <name> <clock> <4 horiz. timings> <4 vert. timings> So that the ModeLine in Section "Monitor" for this example would look like this: Section "Monitor" Identifier "Monitor1" VendorName "Bigname" ModelName "BestModel" ModeLine "1680x1050" 146.2 1680 1784 1960 2240 1050 1053 1059 1089 Option "DPMS" EndSection Now having completed these simple editing steps, X should start on your new widescreen monitor.