Half an hour ago this was an empty disk. Now there is a login prompt, and getting here asked you nothing you had to look up on the way: no standoff over which of four bootloaders you preferred, no negotiation with the installer about whether the network should be minded by this daemon or that one. You log in. The shell is plain, almost austere. And the first thing you do, because everyone does it, is look around and ask the oldest question a new machine invites: what is here, and where does anything actually live?
On FreeBSD that question has a short answer, and the short answer is the whole of this first piece. You are not standing in a heap of software that somebody bundled together last Tuesday. You are standing in a system that was built as one thing, and you can feel it before you can explain it. This is the first of the BSD Field Guide, and the first of three on The Ground: the floor you stand on, and why it holds.
One Tree
Type man hier. It is a single manual page, and it lays out the entire geography of the system: where the kernel lives, where the C library lives, where configuration goes, where the software you add later is kept politely apart from the system's own. One page, and it is accurate, because it ships from the same source tree as the thing it describes. Nothing on the disk quietly contradicts it, for the plain reason that nothing on the disk arrived from somewhere else.
That is what a base system is. FreeBSD keeps the kernel, the shell, the core utilities, the C library, the network stack, the firewall and the manual in one repository, built and tested and released together with a single make buildworld. When you installed it, you installed something one team designed as a unit, and not a kernel from here married to a userland from there and an init from a third address, introduced by a distributor and sent out to see whether the three of them get along.
Why It Is So
The reason matters more than the neatness, and it is worth saying without decoration. When one team owns the kernel and the userland and the firewall and the manual, a decision is made once, in one place, by people who can see the whole of what it touches. I put the claim at its sharpest in the book: integrated systems solve problems once, assembled systems solve them repeatedly (Integrated by Design, ch. 1). The manual page for a system call is updated in the same commit that changes the call. The firewall is tested against the very kernel it will ship beside.
You do not experience that as a newcomer in the form of a lecture. You experience it as an absence, which is a harder thing to notice and a better thing to have: the absence of the small, standing tax of wondering which tool, which version, which file and which of several equally documented answers applies to the machine in front of you. The coherence is quiet. Most good design is.
In the Family
If this feels foreign, it needn't, because you almost certainly run a cousin of it already. Every Mac in the building stands on Darwin, and Darwin's userland is BSD; the ls on a Mac is nearer kin to FreeBSD's than to the GNU one on a Linux server. OpenBSD and NetBSD are the other two children of the same Berkeley research group, the CSRG, that shut its doors in 1995, and each kept the one-tree habit, each ships its base as a whole. OpenBSD made a discipline of it that the rest of the family quietly admires, auditing that single tree by hand, year after year, which is a thing you can only do when there is a single tree to audit.
The point is not that FreeBSD stands alone. It is that the integrated way is older and more widely carried than the assembled one, and a version of it is sitting in your pocket.
Across the Fence
The contrast is easiest to feel on the very question you began with: where do things live, and how do you get in. On Linux the honest answer is that it depends, and it starts depending remarkably early. A Debian-based system, Ubuntu and its many relations, arranges the floor one way and tends its services with one set of habits. A Red Hat-based system, Fedora or RHEL, arranges it another. And then the wild new ones, Arch on a rolling release, NixOS with the whole machine written into one functional file, Alpine pared to a few megabytes, Silverblue shipped as an immutable image, each rethink the ground from first principles, now and then brilliantly.
Not one of them is wrong. But “learn Linux” is not a single thing a person can learn; it is three or four families wearing the same kernel, and the family has already decided where you are standing before you type a command. That is nobody's fault in particular, and it is the cost of a floor that no single team owns, landing first and hardest on whoever is trying to learn it.
The Point
So the ground under FreeBSD is worth naming for what it is: one tree, one manual, one place a thing lives, one way in. That asks nothing of you the assembled world does not, save that you learn it a single time, and it hands back something the assembled world cannot, which is that what you learned on one machine holds on the next. Third-party software, meanwhile, is kept deliberately apart from the base, out in ports and packages, 37,958 of them as of the Q1 2026 status report, so that the line between the system and the things you added to it never blurs.
Almost nobody set out to build a fragmented system; the assembly accreted for sound reasons, project by honourable project. But you have just arrived, and arriving is the one moment you get to choose which floor to stand on. The coherent one is the more considered design, and it gives up nothing to get there; it has been running quietly under Netflix and every PlayStation and every Mac while the argument went on elsewhere.
You have had your look around. The next thing you will want is to make the machine actually do something, and the moment you try, you will reach for the manual to find out how. On FreeBSD that is a better instinct than the last decade has trained you to expect.
Next Friday: the manual that answers.