How to learn FreeBSD deeply?

[bakul]

This has strayed quite a bit from the subject of this thread. There is the "off-topic" forum for discussing things like Distro, Linux, GPL, FSF, RMS, what Free really means....

 

[Cath O'Deray]

… to build a BSD distribution … Something that will teach me step by step how to do this.

Popular in 2021: obiwac comments on Building a FreeBSD based distribution.

The UFS filesystem image step might be outdated, in that it's now possible to use ZFS.

makefs: Add ZFS support · freebsd/freebsd-src@240afd8

This allows one to take a staged directory tree and create a file consisting of a ZFS pool with one or more datasets that contain the contents of the directory tree. This is useful for creating vi...

github.com

makefs: Fix ZFS cross-reference sections · freebsd/freebsd-src@518a1fd

MFC after: 1 week Fixes: 240afd8c1fcc ("makefs: Add ZFS support") Pull Request: https://github.com/freebsd/freebsd-src/pull/979

github.com

Etc.

 

[hack3rcon]

What should a "BSD distribution" be? As I explained earlier, today's BSDs are complete operating systems, the D in the name is historic. They also typically come with their own distribution of 3rd-party software (packages) built from ports.

Linux is only a kernel, you need quite some userspace tools to create a full OS (and the "base tools" typically come from GNU). That's why following LFS, you have to build a lot of packages just to get a working base system. With a BSD, you get the whole system in a single source tree, and you can build and install from that in a few simple steps. The process for FreeBSD is described in the handbook and there are reference docs in manpages like build(7) and release(7).

So, the word "distribution" makes little sense here, you just build and install it. If you want to change anything, you'd actually create a "fork".

Finally, for building 3rd-party software, there's already a well-working framework with ports to build and install packages from upstream sources. And there are tools like poudriere to automate bulk builds and reliably create a package repository.

All a "BSD distribution" could mean would be to combine the base system (maybe slightly modified) with a predefined and preconfigured set of 3rd-party packages, like some systems are doing in order to provide some "out of the box FreeBSD desktop" or whatever.

Hello,
Thank you so much for your reply.
You said:

Linux is only a kernel, you need quite some userspace tools to create a full OS (and the "base tools" typically come from GNU). That's why following LFS, you have to build a lot of packages just to get a working base system. With a BSD, you get the whole system in a single source tree, and you can build and install from that in a few simple steps.

1. Can you explain the phrase the whole system in a single source tree?
2. Isn't GNU/Linux better in this regard? You can have a package in your distribution and not have another package. How about the BSD?
3. If someone wants to build a BSD, which BSD is less complicated and simpler? I mean, it's easier to understand!

 

[zirias@]

Can you explain the phrase the whole system in a single source tree?

src - FreeBSD source tree

cgit.freebsd.org

Isn't GNU/Linux better in this regard? You can have a package in your distribution and not have a package. How about the BSD?

In all my experience, having to pull together all the bits and pieces necessary to build some working GNU/Linux "OS" is a major drawback. Actually, you should get an idea about it when reading LFS. How many packages do you have to build, in the correct order, applying all sorts of hacks and patches to make them work together, just to have a working system? LFS gives you one possible "recipe", there are countless other possibilities. None will ever work without patching the one or other thing, as all components are developed in isolated projects, Linux, several GNU projects, and a variety of third-party projects ... like e.g. nowadays, you certainly want base tools supporting bzip2, lzma, most likely zstd as well, which are all coming from different (non-GNU) upstream projects, but e.g. GNU coreutils can link and use them ....

In contrast to that, when FreeBSD includes some 3rd party component, it's pulled into the tree and all the integration and maintenance work is done. Build a single source tree, get a working system, simple as that.

The only possible downside is endless debates about what should be part of base and what not. Although it's simple in theory (the minimal useful base system), it's often possible to discuss individual components. The build system is already flexible, see e.g. src.conf(5), you can configure which components you want to build and install, but for that, you have to build and install from source. But then, have a look at upcoming PkgBase. All it adds is the possibility to build a set of many binary packages (instead of a single large one) from the single source tree. So, perfect integration of all components will stay, still users will be able to only install the components they want, without building themselves.

 

[hack3rcon]

src - FreeBSD source tree

cgit.freebsd.org

In all my experience, having to pull together all the bits and pieces necessary to build some working GNU/Linux "OS" is a major drawback. Actually, you should get an idea about it when reading LFS. How many packages do you have to build, in the correct order, applying all sorts of hacks and patches to make them work together, just to have a working system? LFS gives you one possible "recipe", there are countless other possibilities. None will ever work without patching the one or other thing, as all components are developed in isolated projects, Linux, several GNU projects, and a variety of third-party projects ... like e.g. nowadays, you certainly want base tools supporting bzip2, lzma, most likely zstd as well, which are all coming from different (non-GNU) upstream projects, but e.g. GNU coreutils can link and use them ....

In contrast to that, when FreeBSD includes some 3rd party component, it's pulled into the tree and all the integration and maintenance work is done. Build a single source tree, get a working system, simple as that.

The only possible downside is endless debates about what should be part of base and what not. Although it's simple in theory (the minimal useful base system), it's often possible to discuss individual components. The build system is already flexible, see e.g. src.conf(5), you can configure which components you want to build and install, but for that, you have to build and install from source. But then, have a look at upcoming PkgBase. All it adds is the possibility to build a set of many binary packages (instead of a single large one) from the single source tree. So, perfect integration of all components will stay, still users will be able to only install the components they want, without building themselves.

Hello,
Thank again.
Where exactly is the FreeBSD kernel? In Linux, you can download and install it separately.

 

[decuser]

Kernel chapter in the handbook

If you're trolling, please stop. Otherwise, see above.

 

[zirias@]

Where exactly is the FreeBSD kernel?

Where it traditionally was in every unixy source tree: in the sys subdirectory.

 

[astyle]

Hello,
Thank again.
Where exactly is the FreeBSD kernel? In Linux, you can download and install it separately.

Whoa, whoa, whoa... slow down...

Kernel installation is a pretty advanced topic... Yeah, it sounds cool. But there's some basics that one needs to have down before attempting to tackle that topic. That's why people are saying to get familiar with installing FreeBSD on bare metal (or a VM) first. Yeah, getting basics down is a lot of work, it takes a lot of time - no way around that. Otherwise, the tools mentioned here (and importance of following steps correctly) won't make sense.

Reading about how stuff is put together is good, but not enough. Having failures with actual metal that you can practice on - that's part of real learning.

Having said that - FreeBSD does offer PkgBase, which is the equivalent to the 'Download and install kernel separately' idea from the Linux world.

Where it traditionally was in every unixy source tree: in the sys subdirectory.

I thought that's where the compiled kernel gets copied/installed... Sources are still in /usr/src/ ...

 

[Cath O'Deray]

Where exactly is the FreeBSD kernel? In Linux, you can download and install it separately.

A snippet from the first table at <https://mastodon.bsd.cafe/@grahamperrin/111788546018714310>:

ports collection​

kernel and world​

You can take the kernel in isolation, however there's little or no point in doing so, because kernel and world are developed in concert with each other in the src tree.

The screenshot at <https://docs.freebsd.org/en/books/handbook/book/#bsdinstall-view-probe> shows a system with a single kernel. If you install multiple kernels: you can use menu option 6 to choose a kernel.

I have four kernels:

% pwd
/boot
% ls -dhln kernel*
drwxr-xr-x  2 0 0  862B 13 Jan 20:01 kernel
drwxr-xr-x  2 0 0  862B 13 Jan 20:02 kernel.GENERIC-NODEBUG
drwxr-xr-x  2 0 0  856B 16 Nov 01:30 kernel.GENERIC-NODEBUG.old
drwxr-xr-x  2 0 0  862B  4 Jan 03:21 kernel.old
% uname -aKU
FreeBSD mowa219-gjp4-zbook-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT #1 main-n267555-e3c7b76fa810-dirty: Sat Jan 13 19:34:36 GMT 2024     grahamperrin@mowa219-gjp4-zbook-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1500010 1500010
%

The .old kernels are present for emergency/fallback purposes. Fallbacks are extremely rare (might be required if, for example, a mistake is made).

I booted the GENERIC kernel, which uses the kernel directory.

I often prefer the GENERIC-NODEBUG kernel.

 

[zirias@]

Kernel installation is a pretty advanced topic...

make installkernel? ?‍ One of the advantages of a single source tree for the whole OS....
Maybe you meant kernel hacking?

Where it traditionally was in every unixy source tree: in the sys subdirectory.

I thought that's where the compiled kernel gets copied/installed... Sources are still in /usr/src/ ...

The compiled kernel gets installed to /boot/kernel. And /usr/src is where you typically place the source tree, but any other location works as well as long as you let the build system know.

Still, the sys subdirectory is where kernel source resides.