Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Dec 2015 14:23:58 +0100
From:      Polytropon <>
To:        Waitman Gobble <>
Cc:        "" <>
Subject:   Re: Migrating to FreeBSD from Debian
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Mon, 7 Dec 2015 22:05:11 -0800, Waitman Gobble wrote:
> The machines I use mostly run FreeBSD-CURRENT or Debian unstable on a
> mainline Linux system. If you are not so interested in matters regarding
> license, then the biggest difference you will see is that ports/packages
> are installed in /usr/local, while the BSD system is in /usr.

While /usr/local is the default location for installed ports
("3rd party software"), it's possible to configure certain
ports to overwrite base programs ("OS software") or put stuff
in locations other than /usr/local. For example, bash has the
option of being /bin/bash instead of /usr/local/bin/bash;
CUPS also can install its binaries into system locations.

> It's possible
> to delete /usr/local and start fresh, without botching your system.  So we
> have a system of user software mostly isolated from operating system.

That's correct - a big advantage so even a totally messed up
ports build won't stop you from booting a working OS.

> Sometimes it's easier to start fresh, especially if you have a system which
> has not been updated in several months, which can cause seemingly
> chicken-and-egg kinds of problems.

Updating major versions (like, 9.3 -> 10.2) tend to be easier
that way.

> Most software configurations are in your
> home directory, so it's pretty easy to rebuild and not lose any settings.

That is true for user programs. System programs have configuration
files in /usr/local/etc which is worth backing up. However, it might
be possible that configuration file syntax or content changes, so
re-instantiating those files 1:1 probably won't work for every case.

> A Debian system is not configured in such a way, everything is co-mingled,
> co-related, co-linked (in /usr). Your /usr/local will be completely empty,
> unless you compile something and intentionally install it there.

Linux doesn't have that strict understanding of "the OS" and "3rd
party software" and the intended barrier between them. Even what
_could_ be considered "the OS" is different among the many distributions.
The maintainers decide what belongs to their base system, and it
can be different in regards of the package manager or even the
default scripting shell. Here everything can be considered a
package (or "a port", as they are basically the same in FreeBSD
termonology), and even the kernel can be seen as a package. So
when an upgrade fails, you might be left with a system that won't
even boot anymore...

> Additionally, in my opinion, a FreeBSD system is much more 'hackable'. If
> you take a look at the source code of the kernel and FreeBSD system, it's
> very well documented, easy to change and fiddle with to suit your needs.
> and recompile.

As a developer, allow me to mention the excellent documentation
found in the manpages: system programs, kernel interfaces, library
calls, configuration files, procedures - nearly everything you find
can be prefixed with "man" - and you'll get lots of valuable
information. Even many ported applications follow this approach,
like "man opera", "man mplayer" or "man xmms" and even "man xzgv" -
but don't try "man firefox". :-)

The sources of the OS are also very tidy and well written. For
many tweaking needs, you don't even need to deal with them:
There are switches in /etc/src.conf (see "man src.conf") which
allow you to automate many things.

> There have been times when ports and packages were out of sync, the port
> version might be newer than the available package, and this reason is
> essentially why it could be problematic to mix ports and packages. In the
> past this has caused some issues and inconvenience, however in recent years
> it seems packages are typically in sync with ports tree.

The packages you install via pkg and the content of a ports
tree updated with portsnap are pretty in sync. If you check
out a ports tree which is more recent, this problem might
occur, but you usually don't mix ports and packages without
the required precautions ("pkg (un)lock" or "poudriere").

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

Want to link to this message? Use this URL: <>