hpr-knowledge-base/hpr_transcripts/hpr3655.txt

Episode: 3655
Title: HPR3655: BSD for Linux users
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3655/hpr3655.mp3
Transcribed: 2025-10-25 02:57:18

---

This is Hacker Public Radio Episode 3655 for Friday the 5th of August 2022.
Today's show is entitled, The SD for Linux Users.
It is hosted by BINRC and is about 68 minutes long.
It carries an explicit flag.
The summary is I attempt to explain the wacky and wonderful world of BSD in a Linux-friendly way.
So this is my second episode.
It's going to be about BSD.
I wrote a post for my website because I haven't uploaded that post yet.
I'll just copy the text directly into the show notes.
But I noticed I hadn't written anything in a long time because I've been busy for a long time.
So I said, let's kill two birds with one stone with one stone.
Let all one people who are subscribed to my RSS feed for the post section of my website
know that I'm still alive and record an episode.
I titled that post Idiot's Guide to BSD.
It's pretty vague.
It's really just for podcast format.
I didn't include a lot of detail.
But it's sort of, here's a list of things you can research.
I will go into more detail in the podcast episode.
And I think sort of the presentation aspect will be more so BSD for Linux guys.
Because a lot of people know Linux, even Windows guys, to some extent, they know what Linux
is.
But as soon as you start talking about Berkeley Unix, they're all lost.
So this is...
Maybe I could call it Babies First BSD or something like that.
So let's jump in.
To compare Linux to BSD, I like to use this phrase, or I guess this statement.
And that statement is Linux was created by PC users attempting to use a mainframe Unix,
whereas BSD was created by mainframe Unix users attempting to use a PC.
When you look at a lot of the subtle differences in the design, this idea really starts to make
a lot of sense, where Linux is seemingly becoming more and more spaghettified, if you
will, in sort of anti-unix philosophy, BSD maintains that Unix philosophy.
In the use cases, right?
The use case for a BSD is, I want mainframe Unix on my laptop.
The use case for a Linux is, I hate Windows.
That's kind of the big, big use cases.
Don't take any of the Linux bashings to heart, it's all in good jest.
Unix is the worst operating system, but it's the least bad operating system we have.
That applies to Linux as well.
So BSD is what I like to call a pedigree Unix.
What that means is Berkeley Unix, right, the Berkeley software distribution, the original
thing that all of this BSD nonsense spawned from, was a copy of AT&T Unix, right?
It was a copy of what they were working on at Bell Labs, after the BSD lawsuit, all
of the persisting AT&T code, all of the persisting Bell Labs code was rewritten, so that it was
a wholly permissively licensed operating system.
This is what it's like primordial BSD, right?
Nobody actually runs with the Berkeley software distribution, it's old.
It exists for historical purposes only in any modern generation.
In this sort of history and contrast to Linux, we all know the Linux story, right?
Some Finnish guy didn't want to pay money for a Linux license, so he wrote his own.
Whereas BSD was originally all Bell Labs code, different origin stories, similar philosophy
but subtly different.
I think the next topic I have in, or I guess, section is BSD in the wild, so this is kind
of some of the places you will find BSD, but first we kind of have to talk about what
the BSD licensing is, so the BSD style license is pretty simple.
Compared to the GPL, there's like a four clause variant that nobody uses, a three clause
variant that some people use, and a two clause variant that most people use, really,
the any interpretation of them boiled down to do whatever the hell you want with this
code, just don't blame me when it breaks something and don't claim you wrote it.
The fourth clause is, do not advertise your product in any way that makes it seem like
the authors of the software endorse your product.
That sort of non-endorsement clause is almost like an anti-advertising clause, and some
people take it out because you want your free BSD logo on a product that contains free
BSD in the same way that you want.
The GPL software logo on your cable provider's modem router combo web interface, right?
You want to see that thing, because then people know, oh, this is free software inside,
even if it's only a part of it.
What this permissive licensing means is that companies can put BSD code into anything
they want, and then sort of pretend that, oh, no, we're not using BSD source code, right,
not advertise it.
What I have written down is that companies can put lipstick on the Unix Pig, but everybody
knows it's a pig in disguise wearing lipstick.
This is kind of the funny thing about Unix systems, and even Linux is the more time you
spend with them, the more ways you know how they break, and they all break in similar
ways, and when you see an error screen, or you know, your set top box crashes or whatever,
it's clearly a system D screen or something, you know, a system D crash screen.
You know that's Unix immediately, in the same way that you look at anything Apple has
ever manufactured, and you can very clearly see that it contains a lot of BSD code.
Similarly, if you run the strings command, if you mount a Windows drive and run the strings
command against various executables, all sorts of networking utilities are BSD licensed and
developed by BSD, various BSD projects, I should say, there's no one, the BSD company,
right, that's not a thing.
Other places you can find BSD, I think the Sony PlayStation 3, 4, and maybe the 5.
They run free BSD components of the Nintendo Switch run BSD, the International Space Station runs
BSD, pretty much every embedded device that is in Android, runs BSD, and various corporate Unix
abandonwares are BSD, so like your Wi-Fi enabled toaster that probably runs BSD, your electric
Wi-Fi enabled dishwasher that probably runs BSD if it's not running Android, and that's
just because the BSD code base is smaller, it's easier to make embedded devices with,
and you don't have to deal with the GPL when you're making a proprietary product that
as Richard Stalman would say exists for the sole purpose of disempowering and entrapping
end users, because really why do you need a Wi-Fi enabled toaster and dishwasher?
It's a kind of a ridiculous idea, but people build these things and people buy these things,
so obviously someone wants their toaster to connect to the internet, like that's not
the worst idea anyone has ever had.
The next section is sort of for Linux guys, how do you interact with BSD guys?
Most of the Linux enthusiasts, I try to think of them as, or I don't try to think of them,
but I've come to the realization that a lot of Linux enthusiasts are a lot like missionaries.
They want to sort of pull people into the community, and make the whole community in software
accessible to more people, where the BSD guys really don't care about, I guess, converting
new users, there's no big switch to BSD push every time, is something unfavorable in
Windows or Linux happens, that's just not a thing, the general attitude for BSD developers
is we wrote this code for ourselves, if it's useful for you, cool, if not, we don't care.
In this sort of attitude, right, the Linux users tend to be more helpful, but I've seen
more frequently, this is my anecdotal experience, of course, when people are asking about questions
in various BSD forums or IRC groups, the responses is typically RTFM, read the docs, or read
the source code, or why didn't you send us air logs if it's a bug and not just a configuration
mistake. A lot of it is, we have this huge existing body of documentation, why aren't you
referencing this before going on the forums and asking a question about a non-bug, something
that we've all figured out before by reading the documentation. Not everyone's this
bitter, but I think sort of the attitude of consulting your available resources before
bothering someone else. By bothering, I mean asking them a question that may or may not
be wasting their time, if they're not the type of person who enjoys talking for hours
endlessly about sort of niche things. Consulate your resources first before asking, not everyone's
this bitter, of course, I've had a couple people help me with things, specifically Broadcom
chips on FreeBSD, but I'll get back to that. Their general answer was by a different Wi-Fi
chipset. And in retrospect, I should have just listened before I even tried, but I'll
get to that again later. So the next section, Forking vs. Distros. In Linux, we all know
distributions are pretty much the same code base and the distributors and the distribution
maintainers. They just theme them a little bit differently. They change various compiled
time options. It's pretty much the same software. So in theory, you could statically link a
program, then copy it from your Debian box to your Fedora box. And if it's statically
linked, it'll probably just run as long as the kernels didn't change too much between
the two operating systems. But in BSD land, there's not really such thing as distros. So
the big three are FreeBSD, NetBSD, and OpenBSD. They're entirely independent from each
other. They don't share a common upstream that they're pulling updates from. They're
forks of, like I said previously, what we would call primordial BSD, okay, 4.4 Berkeley
software distribution, basically Berkeley Unix. Their kernels are entirely different. Their
user lands are very different. They do share code between the various projects. But you
can't just statically link a binary and dump it from like a FreeBSD box to an OpenBSD
box or vice versa and expect it to just run. There is a caveat here though. There are
meta distributions of FreeBSD. I call them meta distributions because a lot of it really
just feels like, or a lot of them really just feel like someone has written sort of an
install desktop.sh TypeScript and then just ran it and then built an ISO. They still
very much feel like FreeBSD. And that leads us into the next section. What I have titled
officially the section, the idiot's guide to picking a BSD. Knock that you're an idiot.
But maybe if you are, I'll walk you through a baby steps. This is a series of like this.
This is the thing that I want. And then my response, of course, my response is not authoritative.
So the first type of user, they're the person who wants basically a Linux desktop out of
the box, but they want a BSD kernel so they can look cool when they post their neo-fetch
logos on the forums and the Linux desktop screenshot thread. And this also applies to
people who want a desktop out of the box. I don't recommend these because they're very
short-lived and they kind of come and go with the seasons. But as of recording these sort
of desktop free BSD forks, the old ones that don't exist is like PC BSD is an example.
The ones that currently exist and probably won't exist forever, or I guess as long
as free BSD exists because they come and go. Hello systems, I guess they wanted to make
it look like macOS. Ghost BSD, I don't know much about Ghost BSD. Nomad BSD, the sort
of the idea there is like a bootable live USB stick with persistence and a desktop environment.
Live as a rescue system or as sort of bring your own OS type idea, like back in the day
when you would install like a minimal Ubuntu image to a USB stick and then take it to the
public library and just enter the BIOS on the public library computers when nobody is looking
and then boot from the USB stick and then pretend that you're not running Linux, but
you are anyway. And the last desktop environment distribution, I guess a free BSD would be midnight
BSD. I don't think these are really the best way to experience BSD, but if you want something
that comes pre-packaged with the desktop, these are options. I don't recommend these because
it's very easy to just install the desktop you want and then enable the services that make
everything run. If you want a viable desktop operating system with a BSD kernel, this is what I
would call a viable Linux replacement and we'll get to that in a minute. Why is viable? For Linux
replacement, that would be free BSD specifically with a desktop environment that is not GNOME. The
reason I say not GNOME is because the GNOME desktop hooks too much into system D and various
system D components. So the GNOME port for free BSD is somewhat janky and old. I've had much
greater success with KDE, XFCE. I don't think I've ever tried Motay on free BSD and then pretty much
every tiling window manager. Right now I run DWM on free BSD because I like the suckless tools. I
like the aspect of modifying source code and being able to compile these runtime options into the
executable because I don't need to be changing them at runtime. It doesn't make a whole lot of
sense to have dynamic configuration when I pretty much set up the window manager once and then
leave it forever and ever. If you want something to learn with specifically a learn by example for C
programming, that would be open BSD. And that's because the source code for open BSD is very simple,
short, and it's pretty fairly operating system agnostic with the exception of Pledge and
Envail system calls. A lot of my C programming came from reading open BSD source code for various
shell utilities. And that's one thing I highly recommend for everybody, even someone who's not
interested in BSD specifically is to just read the source code for, you know, the LS command,
the PWD command. It's so short and simple and almost clever. Although I do write my programs
more complicated than the simple open BSD way, if you want to prevent shoot footing incidents,
what I mean by foot shooting incidents is sort of that a computer's a loaded gun. And when it's
running Unix or any operating system for that matter, your fingers on the trigger. It's sort of a
big, you know, a gun with a sign that says shoot foot here. That's kind of what Unix is and computers
in general. Open BSD kind of prevents these incidents and scenarios. That's why I would recommend open
BSD. It's because a lot of the time when you try to do something stupid on open BSD, it either
doesn't work or it becomes crashing and buggy or it's just an absolute thorn in your side. And
it's very difficult to accomplish your bad idea. That's kind of the biggest reason I recommend open
BSD. It's just because a lot of the defaults and even the way the system comes together
is sort of designed in a way where it's a little bit more difficult to make a dumb mistake or even
intentionally make something make a decision that is something you probably shouldn't do. If you
want to run a Unix system on an obscure device, again, open BSD runs on a lot of architectures.
And these ports to various architectures are actually self hosting. What self hosting means is
when you download the open BSD image that will run on your Vax machine, that installer and all
of the software available for that architecture are actually built on a Vax machine. You know,
the Spark port is actually built on a Spark machine. The 32-bit Intel port is actually built
on a 32-bit Intel machine. They don't cross compile so you know everything works. Net BSD runs
on pretty much everything also except way more than open BSD. Although Net BSD is more focused
on a cross compile based architect or I guess a cross compile based workflow to getting
software to run on your target architecture rather than a self hosting. If you still can't decide,
just go with free BSD. It feels like old Debian but without all of the paper cuts of old Debian.
Just a standard free BSD image. It has the most software available for it which is why I
recommend it over the other BSDs because you know what is an operating system but a bootloader for
user-land applications. That's when most people are interested in not the
extremely niche aspects of you know and the nuances between
Unix-like operating systems. As for hardware, you know they say Linux runs on everything
until you've bought a computer that Linux doesn't run on. BSD hardware support is sort of
less than Linux. So you might get away with running Linux on something. It's a little bit buggy
at times but it works. BSD might not even boot. You might not get Wi-Fi. You might not get graphics
or have graphical bugs. So if you want to run a laptop, I recommend Lenovo ThinkPad's buy
something old on eBay. It doesn't have to be so old that it's like an IBM ThinkPad
but I run free BSD on an X220 and I've ran it on a T460 I think is what that one is.
Typically just runs. Similarly buy a Dell desktop. Those usually work but there are some caveats.
So one thing you have to think about is that BSD is sort of a server operating system right. Unix is
general purpose but in a mainframe context you're going to be running that on a server and now we
ask ourselves what processors, what components were we running on servers for the last I don't know
20 years. It was all Intel. So if you have an Intel processor you're going to have less of a bad time.
If you can find an Intel wireless chipset specifically SNTreno you will get Wi-Fi to work without
having to compile buggy, non-free wireless driver kernel modules into your kernel. That's why I
said not Broadcom. Let me finish with the Intel stuff first. Intel integrated graphics, those work
quite well. I have not tried Nvidia GPU or AMD GPUs because why do you need a GPU on a server
operating system? That's kind of the attitude. I haven't noticed any difference between Intel
processors with VPro and without VPro. All I've noticed is that VPro turns your computer into
an oven, even having an Intel sticker. An Intel sticker will make VSD run better.
As for circling back to the Broadcom idea, this is sort of my anecdote about why I say just buy
Intel everything, even for Linux. So I had a Broadcom wireless card and sort of the issue with
Broadcom wireless cards is the official firmware is non-free. The free implementations are buggy.
When you have a buggy Wi-Fi driver in your kernel, your kernel crashes all the time. I asked
the forums, hey, is there any way to fix this? They say just buy an Intel card. You know,
you ask the RC, is there any way to make my computer not crash all the time because the Broadcom
drivers crashing? The answer is just buy an Intel wireless chipset. Okay, so now getting into
the specifics. So I'm going to go over free BSD, open BSD, and then net BSD. Talk about sort of
their merits and demerits and go on long tangents. An interesting fourth BSD is Dragonfly BSD.
I'm not going to talk a whole lot about it because I don't know very much about it.
But sort of the use case for Dragonfly BSD is a multi-processor system. So either
like a dual zion motherboard or a cluster, a lot of the stuff in Dragonfly, although it's still
in development and it's not quite fully cooked yet, it sort of eliminates the
the need for, you know, proxies behind proxies behind proxies behind load balancers behind proxies
because instead of having, you know, layers of load balancing and proxying, you just have one cluster
and sort of the kernels decide amongst themselves. I don't understand a whole lot about
clustering. I've only built a cluster once. And by built, I mean assembled all of the components
and then wrote a Hello World program that ran on each of the cores and returned the process ID
and the host name that they ran on. But one thing, one I guess extra credit thing you can look into
is Dragonfly BSD. That's all I'll say about that. So the first one, the big one, the one that I
recommend to people who don't know what to choose is free BSD. Sort of the goal of the free BSD
project is to create a general purpose easy to use operating system. I agree with this. They kind
of have achieved their goal. You can use it for a lot of things. Use cases for free BSD, server,
desktop operating system, network area storage, hypervisor, anything you can think of it pretty much
does the job, does the job quite well because it's not purpose specific. And that's one thing you
see when you install the operating system is it doesn't come with all sorts of software, you know,
it doesn't come with a web server stack or a desktop stack. It comes fairly minimally and allows
the user administrator to choose what they want on the system.
And I think that's the thing that I should say for all of the BSDs is that it's not like when you
pick a BSD with the exception of the short live free BSD forks. I mean, free BSD distros.
It's not like downloading in a Ubuntu image that comes with all of the software out of the box.
It's more like an Arch Linux or a Gen2 image where choice is left to the user on
on exactly how to configure the system, what things you want to install, what things you want
enabled, you know, more power to the user. The user is right, the admin is right, not the
maintainers type attitude. So some free BSD features. So the core operating system feels,
it feels very clean and organized. And I think this is the same for all of the BSDs. They feel
clean and they feel organized compared to a Linux. And that's because there's not these two mutually
exclusive sort of headbutting ideas of, you know, Linux versus Gen2. These two systems that
do work together, but weren't designed to work together kind of being shoehorned in with each
other. So what I mean by this, the biggest example I can think of for free BSD is that everything
required to boot the system is in the root directory. And all of the ancillary user installed stuff,
all the stuff that's not required to boot the system is in slash user slash local. This includes
your ancillary third party standard, nonstandard libraries like end curses, so on and so forth.
Another interesting thing, actually that's a storage question. Oh well, I'll leave it in there
in the notes. Free BSD is kind of familiar to Linux users. It is a little bit alien,
but there's quite a bit of documentation. If you read the handbook, you'll be all set.
If you're like a Linux power user and you know how to read man pages, you'll be just fine.
As for storage, free BSD technically have UFS. Don't use UFS, just use ZFS. It's the only good
raid file system. ZFS brings a lot of things to the table, like better multi-disk setups than
Linux logical volume and volume management, in my opinion. ZFS brings encrypted Z volume,
so what this means is because Unix is a multi-user system, you have multiple users.
Each user can sort of get their own Z-Vall. Z-Vall is just think partition when I say Z-Vall.
It's a partition, but without a hard size. I could probably do a whole episode on ZFS,
but I'm no expert. I can just say why it's cool. So each user can get their own Z-Vall for their
home directory and each Z-Vall can be encrypted. This is kind of what they're trying to accomplish
with encrypted home directories using system D home D, except it's at a much lower layer in the
stack. It's at the file system layer instead of the sort of alien monstrous bootloader level.
The sort of bootloader that has become everything level. Another interesting thing about ZFS is
you can use ZFS boot environments. So what this means is before you upgrade your system and
break the whole thing, you can do a boot environment for it. So pre-custom kernel breaking everything,
well, we have a boot environment that boots into the old kernel where we still have our Wi-Fi
drivers working. ZFS does snapshots too, so you can roll backwards or forwards. And I think
in one example I've done, it is possible to do sort of version control with ZFS, although it is
very, very messy. And it's somewhat difficult to use without excessive scripting duct tape,
but it is kind of a fun experiment to see if you can replace sort of a get style version control
with ZFS. Also full disk encryption, that's pretty standard with Gally and encrypted Z-Valls.
Third party software for free BSD, they have the largest port system. So one thing that contrasts
sort of a BSD system from a Linux system is that in the BSD world, all of the packages are called
ports. And that's because they have been ported, they are not part of the base system,
they are ported to the system, not maintained by the operating system developers,
they're ancillary, they're ports. So the interesting thing about these port systems is that,
yes, they all ship binary packages with some sort of package utility, that's familiar if you've
ever used like an apt or a DNF or a yum or a zipper or a Pac-Man or what have you. But they also
ship the entire port tree with a series of make files. So what this means is that you can compile
all of the software in your system yourself if you really feel like it. And depending on which
options you set, you can blacklist various packages that you don't want to be installed
or set various compile time options. So if you need a feature, I guess sort of an obscure
feature. And for example, you're a patchy web server, you can compile that in. And there's a
cool tool for freeBSD called like Poudre Air. I don't know how to say it, Poudre Air. Basically,
what it is is a tool that allows you to build a local package repository, binary package repository
of all your freeBSD ports with whatever custom options you want to build. It's kind of like if you were
to basically build the Gen2 package server of binary packages and then serve it on your local
area network for all your various Gen2 machines. Another interesting feature of freeBSD is Jails.
So when I think of Jails, I think of a Jail as like a Charoute, but the Jail is actually secure.
Using some namespace nonsense or whatever you have, the way to explain Jails to a Linux user
is it's like Docker, but without downloading random stuff from GitHub and blindly trusting it.
Although there are some some recipes for making Jails, I think like the easy Jail command,
but it's not downloading an entire operating system minus the kernel and then running it
trusting that the guy who put it together isn't malicious. It's a recipe that says, hey, copy
these things from the base system into the Jail and then go into the Jail and install these packages.
It's a lot more like an Ansible script how you would use Jails.
All the Jails share a kernel, right? It's the same as a Charoute, but they have separate host
names, IP addresses, network interfaces, so on and so forth. On freeBSD, there's virtualization,
right? That's kind of a standard thing nowadays. There's the B-hive hypervisor. I believe the B-hive
hypervisor can plug into a QEMU in the same way that KVM can plug into QEMU.
I also think you might be able to get away with using VertManager to plug into B-hive,
although I haven't tested it. I have actually ran VertManager to connect to like a QEMU
machine across the network. The virtualization stuff is all there. I don't really use B-hive very
much when I need to build a hypervisor. I just use KVM because it's what I know.
Security. FreeBSD has access control lists. Access control lists are kind of like mandatory
access control except not quite. FreeBSD also has the thing called Capsicum. It's like a sandboxing
framework. Capsicum is something you want to use with your web browser. You don't want your
web browser talking to various things that shouldn't be talking to. That's the example.
FreeBSD security as you can kind of tell is more so based around
segregating parts of the system that shouldn't be talking to each other. It's like the common
usage for jails is to run your web browser in a different jail from your DNS server for
a different from your mail server and so on and so forth. The one thing that makes
FreeBSD sort of the cream of the crop for the Linux guys is that FreeBSD has a Linux compatibility
layer and some people have even successfully been able to run steam through this Linux compatibility
layer and then use the Steam's Windows compatibility layer for Linux. So how this works,
let me go from the opposite direction. So you have a game that's written for Windows. Steam makes
it possible to run that game on Linux but FreeBSD has a Linux compatibility layer making that
Windows game possible to run on FreeBSD. Obviously performance is not very good but it is possible
although buggy because they don't translate all of the system calls that are required
just most of them. Also, wine works on FreeBSD. I haven't tested it. I don't do a lot with wine
just because I don't really have any use case for or I guess any interest really in running
programs designed exclusively for Microsoft operating systems. I really could care less
about that software. As for documentation, I have a link. It's the FreeBSD handbook. If you're
jumping in, read the handbook. It's a very good resource. It's a step-by-step for everything including
installing desktop environments, web servers, security, so on and so forth. I highly recommend
the handbook. So some detriment for FreeBSD. So the UFS file system is not journaled by default.
It's possible to enable journaling. Although nobody really does that. My recommendation is just
use ZFS. Just use ZFS. It's way easier. Virtualization. The detriment here is they have a virtual box port.
Why I put this in detriment is I don't like virtual box. I'm not going to elaborate on that. I
don't like virtual box. I thought it was funny to write it there. Elaborate on that? No. Security.
So FreeBSD is faster than a lot of things you've tried. What that means is some of the security
settings are kind of lacking. If you open up your terminal on your FreeBSD machine and type man's
7 security, I think that's the syntax for man pages. Let me check real quick.
Yeah, so that is the syntax. Of course, I couldn't think of something. So man, seven security,
it walks you through all the different security things and also the handbook walks you through
those security things. So you're just getting started. You're curious about the BSD world. Jump
into FreeBSD. There's a lot of foot shooting incidents to be had, but it is pretty fun. It is a
very fun operating system, in my opinion. There's still a lot of fun to be had in it.
Okay, so the next thing I'm going to talk about open BSD. So sort of the goals of open BSD are
simplicity, portability, standardization, correctness, proactive security, and cryptography.
So the big use cases for open BSD are networking appliances, servers, and then the final one is
desktops. Really, the only people who run an open BSD desktop are paranoid or they work on the
thing all day every day. So it's kind of beneficial to, you know, do the whole dog fooding thing
where you actually use the product that you're creating to create a better product. So some merits.
The core operating system webcam and microphone are disabled by default. The only way you can
re-enable these is by changing a boot time option in your RC.conf. I think that's what it's called.
Yeah, at CRC.conf to enable them. And I should say all of these systems use a CISV in its style
in its system. What that means is unique style, not BSD style. Everything is pretty much shell scripts.
That's how the boot, the in its system works. So the big thing about open BSD is security. Okay.
So the critics are going to say this is security theater, but I'll run through these real quick
I want to elaborate too much to kind of, you know, it's not security theater. They've actually
done some things that are pretty interesting. So they've done API changes. If you've ever written C,
you know that any of the functions in string.h are leaky and they like to leak memory and
cause crashes and segvaltz. So they wrote their own implementations instead of like
STRN copy. They have STRL copy and STRA STRL cat.
In these, what these functions do is crash instead of allow bad behavior. Another interesting feature
every time you reboot or boot an open BSD system, the kernel is randomly relinked.
What this means is for a potential attacker, they for example, if they know there is a vulnerability
in one of your standard libraries, they can install open BSD themselves, figure out where that
standard library is for the kernel in memory and then run that exploit. When you randomly relink,
they try to jump on, you know, insert a vulnerability and then try to jump onto it. It's kind of
harder to find where those libraries are at when they're randomly relinked and you don't tell people
where they're at. In simpler terms, if you think of sort of an executable program, your kernel,
for example, as, you know, the kernel and then various standard libraries stack on top of it
that make it possible. Think of it like a deck of cards and then just shuffle them. Good luck
finding where the buggy standard library function is when you just shuffle the entire deck of standard
libraries. They also do some memory protections. So they have a write, writes or execute protection.
What this means is that a segment of memory is either exclusively writable or exclusively
executable. This prevents an attacker from sending some well-crafted TCP packet to your system that
writes a value to memory and then immediately executes that memory they just wrote to.
Additionally, every time you run the malloc, memory is randomly allocated. What this means is
instead of giving, you know, you say, hey, give me 2,000 bytes. Instead of giving you 2,000 bytes
sequentially, it'll give you random pages all over the place. Which means buggy programs
segfault and they crash very loudly. And this also makes debugging a little bit difficult. But that's
one of the reasons I like programming on OpenBSD is because when you have a memory error,
your program just crashes. So you know, there's a memory error.
And this is also security feature, right? When you put your memory in random locations and someone's
trying to mess with your memory, it crashes rather than just works. Cryptography. So full disk
encryption is a thing. It's a little bit difficult to do if you don't read the documentation. There's
no click the box for a full disk encryption, but it includes swath space. You know, various
cryptography algorithms, the TCPI, P-Stack, randomizes things, crypto, you know, stuff that I don't
know a whole lot about. Except for full disk encryption. So there x11 fork is called the Xenocara.
What's interesting about Xenocara is a typical X server runs as root. It kind of has to in order
to access the display device, but the Xenocara, I guess, display manager and also the child X
processes. They don't run as root. Although running an X application or an X session as root
doesn't typically cause problems if you're running something like a web browser and you have
like a federal agency coming after you, you know, something ridiculous like that. They'll be able
to get into your web browser. And because your web browser is a child process of the X session,
they'll be able to exploit the X session and because the X session is running as root,
right, you get the idea. Another interesting feature, Pledge and Unveil system calls.
So the Pledge system call restricts capabilities for a process. What this means is when a
processness behaves, the kernel instantly kills it. This is kind of a thing on all modern Unixes,
but for the average user, what this means is you don't have to be afraid of writing a buggy
program because if it's really buggy, the kernel will just kill it before your buggy program
starts corrupting the kernel and writing random stuff to disk.
The Unveil system call restricts file system access. I haven't used either of these
system calls, but as I'm talking about them, they're kind of interesting. And I might read more
into them. All of the standard demons run in a charute with privilege separation. So what this
means is your HTTPD runs in a charute, your DNS server runs in a charute, your NTP server runs
in a charute. And this charute is more secure. They've done some work on the charute. It's like
more secure than a Linux charute where charute escape is possible. An open BSD charute is a lot more
like a jail, but they've kind of made the concept of a jail, a free BSD jail. They've kind of
made the concept of the jail transparent to the end user, you know, just something behind the scenes.
They also do a address-based layout randomization and a million other things.
As for third-party software support, open BSD is a complete operating system in the same sense.
That free BSD is with the exception. That open BSD comes with like a web server.
It comes with INEDD. It comes with an email server. All of the things you might possibly need
come with open BSD, including various graphical environments, although nobody uses those
graphical environments except for Theodor at himself. And some of what you want, not everything
you want, but a lot of the things you want are available in the ports or using the Package Add command.
That's PKG underscore add. And then for example, you want XFCE instead of CWM because you're not
Theo himself. What you do is, you know, you package add XFCE and then you modify your .exession
in your home directory to boot that when you log in through the display manager.
You know, web browsers are all there. Compilers are all there. All the typical stuff you
would use, right? Because really, what more do you need than a terminal in a web browser, right?
That's all there. Some interesting open BSD sub-projects. You know, the cart protocol that makes
that made people mad. The DUAS program. DUAS is a lot like pseudo, but the code base is significantly
smaller, which means it's significantly less opportunity for exploitation. Open BSD, HTTPD,
for a small web server, Libra SSL, a small version of SSL, you know, BGPD, NTPD, SMTPD, SSH.
All of these things are open BSD projects, or at least the implementation of these protocols
that you're probably using on your Linux system, like SSH. That's probably open SSH.
Similarly, if you're running a web server, open SMTPD is probably the one you'll be looking at,
because it's the easiest to configure. You know, the PF firewall, I say it's the only easy to use
firewall. SpamD is kind of an interesting program. It's an email filter that plugs into PF.
There's a whole bunch of other sub-projects they've done that have made their way across various
operating systems. Their virtualization stack looks like VMM and VMD. I've never used
those. Like I said, I typically just use KVM on Linux. Documentation, read the FAQ. I have a
link for that. Read the handbook. I don't think the handbook's official, but it has some good
information and good examples. So, read that. And then I guess the last example of documentation
is just read the source code. Open BSD source code is fairly small. And sort of, you know, the
security theme kind of makes sense for why the source code is fairly short. And that's because
the larger your code base gets, the more unmanageable it becomes and the more opportunity for, I guess,
unseen error comes into play. It's sort of the idea of minimal code base or I guess, minimum
viable source code for what you need to accomplish a goal. That's why I recommend reading
open BSD source code. So, some like anti-features, some demerits for open BSD. A lot of these security
features can cause slowdowns. Sometimes, if you really want to shoot yourself in the foot, you can't.
When I first started using open BSD, I really wanted to shoot myself in the foot and I couldn't.
Had something to do with Apache, I think, something ridiculous like that that I wanted to,
you know, something stupid like putting home directories on Apache instead of just
copying files, something like that. Detriments, if you use open BSD, people will call you
probably paranoid and say that you've fallen for a security theater type scam.
I guess getting bullied online, if you like getting bullied online, maybe it's not a detriment.
But that's one of the biggest claims is people don't really like the open BSD developers.
People don't really like them because the idea of, you know, we're the only secure operating system.
Of course, that's sort of kind of a joke, right? Because no software is secure.
We just have least bad software. And when I say the least insecure software, it's probably not
open BSD. But there's enough security through obscurity that you're going to be fine if you're
running open BSD. Another detriment, if you want like it just works, trademark unit code symbol,
Linux desktop experiment experience, you're going to have to open up vulnerabilities.
You're going to have to install stuff like debust. You're going to have a nightmare of a time.
And another thing, open BSD does not have mandatory access control.
That's the biggest reason why the critics say it's a security theater.
Even though you really don't need mandatory access control if you're running everything inside
of a charude anyway, but more power to them. I had another idea that I lost.
We'll just go to net BSD and then I'll do some closing thoughts.
So the goal of net BSD is clean, careful design, scalability, and portability.
So the biggest use cases for net BSD are on the server, embedded environments, and then desktop
if you're a floodgillant, desktop if you're a glutton for punishment. That's mostly ingest.
I haven't used much net BSD except for an IRC bouncer. But SDF.org, they run net BSD,
embedded devices, international space station runs net BSD. Some people run it as a desktop.
I never have. I probably should. Let's go into some features. Portability.
Net BSD actually runs everywhere. I have a link for it.
The page is very long. Very, very long. They have a three tiered system.
They have the big boy architectures. They have the weird ones and then they have the really
weird ones that are on life support. The really weird ones, you can still probably get
another version of net BSD to run. An interesting thing, net BSD's build script build.sh is sort of
designed for cross-compiling. So what this means is if you have net BSD on your standard x86
machine, you can build some extremely niche architecture, build an image for it and just burn
it to a floppy or whatever your extremely niche deprecated architecture takes and get it to boot.
I have played with build.sh a little bit, but not as much as I have played with the next feature,
which is package source. If you don't know about package source, it's very cool.
Package source is a port system. It's unix agnostic, which means it runs pretty much everywhere.
It's architecture agnostic, which means it runs pretty much everywhere. It's a third-party
packaging framework. Minix uses package source. If anyone even uses minix, it's sort of the idea
behind package source is similar to like I described earlier, the free BSD porch tree,
except that it's operating system agnostic. So you can run package source on net BSD, mac,
alumos, linux, open BSD if you're a glutton for punishment. And the idea behind package source is
that if you're operating system or I guess distribution maintainers don't ship a specific package
or they don't ship them with the compile time options you really want. You can install package
source and build those things from source in a way that's a lot easier to manage than downloading
random stuff off GitHub. I think source-based package repository. That's what package
source is. And it's all make files and shell scripts, right?
Virtualization. Zen Hypervisor runs on net BSD. There's also NVMM, which is a net BSD,
net BSD, VMM, right? Just like open BSD's VMM. It's a lot similar to KVM and it works with
QEMU. So that means you can use, run your wacky architectures inside of a virtual machine on
that BSD because that's QEMU support. Storage, they have a whole bunch of file systems,
including journal, the UFS and CFS. I've always just used journal, the UFS on net BSD because it
seems to just work. They also have LVM, that's kind of like Linux logical volume management,
LVM, right? That's what it is, logical volume management. And that BSD is almost entirely
POSIX compliant, depending on which version of the POSIX spec you're referencing.
But of course, you can't get POSIX certification unless you pay big money like Apple does,
because you know, it's so important to have the sticker for POSIX compatibility,
even though all the people buying your fashion product don't care about POSIX compatibility,
they just care about what you advertise on TV. And I think one of the most interesting things
about net BSD is that the kernel is entirely scriptable with Lua. In its systems are scriptable
and Lua. Off the top of my head, I could be wrong, but I believe they have a Lua interpreter
in the kernel. Of course, it's very minimal and it does not support floating point numbers.
But sort of the idea of not having to script your entire operating system in shell scripts,
and in system D's case, nightmare languages like Python, or I guess the Red Hat case,
you know, not having to script everything in Python. It's really interesting. It's really
interesting that there's Lua interpreter in the kernel. And that's something I will have to play
with more. You know, I haven't used net BSD a whole lot. I need to play with it more in the same
way that you need to play with. DragonFly more. So to recap, let's talk about some of these
bigger ideas, right, the non-specific ideas. So all the BSD systems use a, you know,
a CISV unit style in it system. What this means is basically an RC script rate,
at cslashrc.conf, the old style way, right, the pre, what was the weird Ubuntu thing before
system D, right, the pre-upstart way of doing things on a Linux system, right, before upstart
was a thing, before, you know, the upstart fever dream was a thing, almost like an if you've
ever used open RC, it's almost like using open RC. And sort of the resistance for
system D like thing, although they are coming, right, you can't resist multi-threaded,
or I can not multi-threaded, but sequentially starting process that boot, you can't resist that
forever if you want to compete. I guess some other interesting things, more emphasis on the Unix
philosophy. So the Unix philosophy is, you know, each process, each program should do one thing
and do it well. In Linux, we kind of have these big, almost windows like amalgamations of things,
right, system D is an example, GNOME is an example, but in the BSD world, they try to modularize
things to the point where when something in the pipe breaks, you can sort of figure out which
one it is. And I think, you know, sort of the uniqueness, each of these operating systems feels
genuinely different when you sit down at the console, right? Free BSD has like an end-curses
style display. For installation, open BSD is a pure command line installation, but you just
mash the enter button a bunch of times and guess what, you have a net BSD installation, right,
you don't even have to type anything, except a root password. Net BSD, they have an end-curses
installation also. You know, they all have update mechanisms. They're all, in my opinion, quite fun
to use, you know, that's the whole, that's the whole reason why we're here on the computers because
we find it fun. And I think sort of resisting, you know, something because you don't like the license
or because you got burned by it once or twice. It doesn't make a whole lot of sense because
there's a lot of fun to be had in sort of a unique implementation you've never used before.
You know, I've been burned by free BSD a bunch of times and open BSD. I have an open BSD installation
that I can't upgrade because I let it sit for too long, right? We've all been burned before.
Or I guess I don't have the effort, I don't have the energy to work out the upgrade process for
it is the right thing. And we've all been burned. You know, there is, like I said at the beginning,
there is no perfect operating system, but Unix is the least bad thing we've had since the beginning
of time. And I think closing opinions, if any of these appealed to you, right? If any of these
operating systems appealed to you, go ahead and pick that one out. You know, if you don't know which
one to pick, pick free BSD. If you're a little bit paranoid, I really recommend open BSD.
And if you're learning C programming, I recommend reading open BSD source code quite heavily.
Although I still do most of my debugging on Linux just because all the security features on open
BSD make debugging a little bit difficult. And as for Ned BSD, as I said, I haven't used it
much, but I've used it enough to know that it really is portable. You know, when you download
the system source code, you know, package alerts on all these things, their entire emphasis is
based on, hey, let's make this run everywhere. And you know, you go to their list and you see that
it actually does run everywhere. It's quite, it's quite, I guess, sublime, right? That would be the
word I'd use to see that the Unix philosophy right C because it's just abstract enough that the
compiler can turn it into whatever machine op codes we need it for the specific architecture.
You know, seeing Ned BSD running on everything is, you know, that's the whole point behind Unix
right once run everywhere. I think, I think closing words here. Of course, I am long-winded.
That's how all of my shows will probably go as that I am a very long-winded person.
A future episodes, I started working on like a C programming episode and then I realized it's
going to have to be a C programming series. I think that's something I've known all along is that
C programming is big and I can't just make a very 1000 foot view, a comparing contrast type thing
between all of the various, you know, C function calls and ways of writing C like I did with the BSD
episode. And for a Plan 9 episode, that's another thing. I'm going to have to actually sit down and
use Plan 9 again. I have it used Plan 9 in almost seven months now, even though I bought a laptop
specifically to run Plan 9. He says what hackers do, right? You can't resist. Of course,
that laptop is running free BSD right now because I needed BSD more than Plan 9, but that's how things
go. I think an in-depth episode if anyone wants an in-depth episode,
also to any of these BSDs, of course, I'm not an authoritative source
on any of these, right? Be authoritative sources, read the source code and read the manual.
But if anyone wants an in-depth episode or gets stuck, feel free to ask for help. I probably won't
have a 100% solution, but I'll be able to point you in the right direction. You know, if you want
in-depth free BSD, all right? How do free BSD jails work? I'm going to have to learn and then tell
you, right? Or, you know, how do I get an open BSD workstation? I can do an episode on that or
you know, whatever. So anyway, thanks for listening. Time to edit up this show, see if there are any
noises I didn't catch. And then I'll upload it. Hopefully the show notes stayed correct. They're
probably wrong, but hopefully they'll stay correct. Anyway, thanks for listening.
You have been listening to Hacker Public Radio. Hacker Public Radio does work. Today's show was
contributed by a HBR listener like yourself. If you ever thought of recording a podcast,
you click on our contribute link to find out how easy it really is. Hosting for HBR has been
kindly provided by an honesthost.com, the internet archive, and our syncs.net. On this
otherwise stated, today's show is released on their creative commons, attribution 4.0 international