Please take a look at the ports page for info on software packages ported to FreeBSD. The list currently tops 20,000 and is growing daily, so come back to check often or subscribe to the FreeBSD announcements mailing list for periodic updates on new entries.
Most ports should work on the 6.X, 7.X and 8.X branches. Each time a FreeBSD release is made, a snapshot of the ports tree at the time of release in also included in the ports/ directory.
We also support the concept of a “package”, essentially no more than a compressed binary distribution with a little extra intelligence embedded in it for doing whatever custom installation work is required. A package can be installed and uninstalled again easily without having to know the gory details of which files it includes.
Use the Packages package installation menu in sysinstall(8) (under the Configure menu item) or invoke the pkg_add(1) command on the specific package files you are interested in installing. Package files can usually be identified by their .tbz suffix and CD-ROM distribution people will have a packages/All directory on their CD which contains such files. They can also be downloaded over the net for various versions of FreeBSD at the following locations:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-stable
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7-stable
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-8-stable
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-9-current
or your nearest local mirror site.
Note that all ports may not be available as packages since new ones are constantly being added. It is always a good idea to check back periodically to see which packages are available at the ftp.FreeBSD.org master site.
Yes. Please see http://www.FreeBSD.org/java/.
If you are running a FreeBSD version that lags significantly behind -CURRENT or -STABLE, you may need to update your Ports Collection; see the Keeping Up section of the Porter's Handbook for further information on how to do this. If you are up to date, then someone might have committed a change to the port which works for -CURRENT but which broke the port for -STABLE. Please submit a bug report on this with the send-pr(1) command, since the Ports Collection is supposed to work for both the -CURRENT and -STABLE branches.
First, always make sure that you have a completely up-to-date Ports Collection. Errors that affect building INDEX from an up-to-date copy of the Ports Collection are high-visibility and are thus almost always fixed immediately.
However, if you are up-to-date, perhaps you are seeing another problem. make index has a known bug in dealing with incomplete copies of the Ports Collection. It assumes that you have a local copy of every single port that every other port that you have a local copy of depends on. To explain, if you have a copy of foo/bar on your disk, and foo/bar depends on baz/quux, then you must also have a copy of baz/quux on your disk, and the ports baz/quux depends on, and so on. Otherwise, make index has insufficient information to create its dependency tree.
This is particularly a problem for FreeBSD users who utilize cvsup(1) (or csup(1)) to track the Ports Collection but choose not to install certain categories by specifying them in refuse. In theory, one should be able to refuse categories, but in practice there are too many ports that depend on ports in other categories. Until someone comes up with a solution for this problem, the general rule is that if you want to build INDEX, you must have a complete copy of the Ports Collection.
There are rare cases where INDEX will not build due to odd cases involving WITH_* or WITHOUT_* variables being set in make.conf. If you suspect that this is the case, please try to make INDEX with those make variables turned off before reporting it to FreeBSD ports mailing list.
The FreeBSD base system is designed as self-hosting -- it should be possible to build the whole operating system starting with a very limited set of tools. Thus, the actual build tools needed to compile the FreeBSD sources are bundled with the sources themselves. This includes a C compiler (gcc(1)), make(1), awk(1), and similar tools.
Since CVSup is written in Modula-3, adding it to the FreeBSD base system would also require adding and maintaining a Modula-3 compiler. This would lead to both an increase in the disk space consumed by the FreeBSD sources and additional maintenance work. Thus, it is much easier for both the developers and users to keep CVSup as a separate port, which can be easily installed as a package bundled on the FreeBSD installation CDs.
However, FreeBSD users are not without an integrated CVSup
compatible client anymore since FreeBSD 6.2-RELEASE. Thanks to Maxime Henrion <[email protected]>
, CVSup was rewritten in C as csup(1) and it is the
part of the base system by now. Although it does not implement all the features of CVSup at the moment, it is good enough (and really fast!) to keep
your sources synchronized. For systems earlier than 6.2, it can be installed as a port or
package (see net/csup).
FreeBSD does not include a port upgrading tool, but it does have some tools to make the upgrade process somewhat easier. You can also install additional tools to simplify port handling, see the Upgrading Ports section in the FreeBSD Handbook.
By all means! While a recent system will run with software compiled under an older release, you will end up with things randomly crashing and failing to work once you start installing other ports or updating a portion of what you already have.
When the system is upgraded, various shared libraries, loadable modules, and other parts of the system will be replaced with newer versions. Applications linked against the older versions may fail to start or, in other cases, fail to function properly.
For more information, see the section on upgrades in the FreeBSD Handbook.
In general, no. FreeBSD developers do their utmost to guarantee binary compatibility across all releases with the same major version number. Any exceptions will be documented in the Release Notes, and advice given there should be followed.
Because POSIX® says that there shall be such a shell.
The more complicated answer: many people need to write shell scripts which will be portable across many systems. That is why POSIX specifies the shell and utility commands in great detail. Most scripts are written in Bourne shell, and because several important programming interfaces (make(1), system(3), popen(3), and analogues in higher-level scripting languages like Perl and Tcl) are specified to use the Bourne shell to interpret commands. Because the Bourne shell is so often and widely used, it is important for it to be quick to start, be deterministic in its behavior, and have a small memory footprint.
The existing implementation is our best effort at meeting as many of these
requirements simultaneously as we can. In order to keep /bin/sh
small, we have not provided many of the convenience features that other shells have. That
is why the Ports Collection includes more featureful shells like bash, scsh, tcsh,
and zsh. (You can compare for yourself the memory utilization of
all these shells by looking at the “VSZ” and “RSS” columns in a
ps -u
listing.)
The usual answer is that DNS on your system is misconfigured. Both Netscape and Opera perform DNS checks when starting up. The browser will not appear on your desktop until the program either gets a response or determines that the system has no network connection.
7.12. I updated parts of the Ports Collection using CVSup, and now many ports fail to build with mysterious error messages! What happened? Is the Ports Collection broken in some major way?
If you only update parts of the Ports Collection, using one of its CVSup subcollections and not the ports-all CVSup collection, you should always update the ports-base subcollection too! The reasons are described in the Handbook.
To create audio CDs from MIDI files, first install audio/timidity++ from ports then install manually the GUS patches set by Eric A. Welsh, available at http://alleg.sourceforge.net/digmid.html. After TiMidity++ has been installed properly, MIDI files may be converted to WAV files with the following command line:
% timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid
The WAV files can then be converted to other formats or burned onto audio CDs, as described in the FreeBSD Handbook.