This is Hacker Public Radio Episode 3,655 for Friday the 5th of August 2022.
Today's show is entitled, The SD for Linux Users.
It is hosted by Ben R.C. 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 have been 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, let all one people who are subscribed to
my RSS feed for the post section of my website know that I've still alive and record
an episode.
I titled that post idiots guide to BSD.
It's pretty vague, right?
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 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 a Babies first BSD or something like that.
So let's jump in.
To compare Linux to BSD, I like to use this phrase where 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 spigetified, 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 hard it's all in good just 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 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'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, you know, different origin stories, similar
philosophy, but subtly different.
I think the next topic I have in, 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.
It 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, 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 blame me, wrote it.
And the fourth clause is, do not advertise your product as in any way that makes it seem like
the authors of the software endorse your product.
That sort of non-indorsement 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, you know, the GPL software logo on your cable providers, a 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 part of it, but with this permission,
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.
Oh, 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 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, you know,
when you see an error screen, or, you know, your set top box crashes or whatever, and it's
clearly a system D screen or something, you know, a system D crash screen, you know, that's Unix
immediately, and 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 projects, I should say. There's no one
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 an
Android runs BSD and various corporate Unix abandoned wires 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 has Richard Stollman would say exists for the sole purpose
of disempowering and in-trapping end users, because really, why do you need a Wi-Fi enabled
toaster and dishwasher? It's just a kind of 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 four 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 as, 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 and software accessible to more people. Or 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, right? That's just not a thing.
Kind of 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.
And 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 and various BSD forums or IRC groups,
you know, 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 logistic 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. And not everyone's this bitter, but I think sort of the attitude of
consulting your available resources before bothering someone else.
And 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.
You know, consult your resources first before asking. Not everyone's this bitter, of course. I've had
a couple of people help me with things, specifically broad calm ships on free BSD, but I'll get back
to that. Their general answer was by 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 versus distros. In Linux line, 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 Debbie and 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 distro. So the big three are our free BSD, net BSD, and open BSD. They're entirely independent
from each other. They don't share a common upstream that they're pulling updates from.
Their forks of, like I said previously, what we would call primordial BSD, okay, for
it off for 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 free BSD box to an open BSD box or vice versa and expected to just run.
There is a caveat here, though, there are meta distributions of free BSD. I call them meta
distributions because a lot of it really just feels like, or a lot of them really just feel like someone
have someone has written sort of an installed desktop.sh type script and then just ran it and then
built an ISO. It's still very much feel like free BSD. And that leads us into the next section.
What I have titled officially the section, the idiots guide to picking a BSD.
Not that you're an idiot, but maybe if you are walking through a baby steps.
This is a series of like, 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 NeoFetch 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 works.
Right, the old ones that don't exist is like PCBSD 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. No mad BSD. The sort of the idea there is
like a bootable live USB stick with persistence and a desktop environment. Sort of 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, or free BSD would be midnight BSD.
I don't think these are really the best way to experience BSD, but if you want
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, there would be free
BSD, specifically with a desktop environment that is not gonna own.
The reason I say not gonna own is because the gonna own desktop hooks too much into system D and
various system B components. So the gonna own 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 Montet on free BSD and then
pretty much every tiling window manager. Right now I run DWM on free BSD because I like
the cyclist tools. I like the aspect of modifying source code and being able to sort of 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 unveil 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 LS command. They're PWD command.
It's so short and simple and almost clever. Although I do write my programs more complicated than
this is a blooping BSD way. If you want to prevent shoot footing incidents, what I mean by
foot shooting incidents is sort of that a computer is 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 in 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 is 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
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 that installer
and all of the software available for that architecture are actually built on a Vax machine.
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 kind of is more focused on on a
cross compile based architect or I guess a cross compile based workflow to getting software
around 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. It's 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
one of the most people are interested in not not the extremely niche aspects of you know and the
nuances between unix-like operating systems. As for hardware, 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 it 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 the laptop, I recommend Lenovo Thinkpads by 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 T460 I think is what that one is. It typically just runs. Similarly
by a Dell desktop, those usually work but there are some caveats. One thing you have to think about
is that BSD is sort of a server operating system right. Unix is general purpose but
it 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 wire was chipset specifically as Centrino,
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
Start 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 right? That's kind of
the attitude. Haven't noticed any difference between Intel processors with V Pro and without V Pro,
all I've noticed is that V Pro turns your computer into an oven, even having an Intel sticker.
An Intel sticker will make VSD run better. As for, okay, circling back to the Broadcom idea.
This is sort of my anecdote about why I say just by 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 ask the forums, hey, is there any way
to fix this? They say you just buy an Intel card. You know, you ask the RSC, is there any way to make
my computer not crash all the time because the Broadcom drivers crashing? The answer is just buying
Intel wireless chipset. Okay, so I'm getting into the specifics. So I'm going to go over free
VSD, open VSD, and the net VSD. Talk about sort of their merits and de-marrits and go on long
tangents. An interesting fourth VSD is Dragonfly VSD. 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 VSD is a multi-processor
system. So either, you know, like a dual-zion motherboard or 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's sort of eliminates the the need for, you know, proxies behind proxies behind proxies
behind load balancer's 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 in 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 VSD.
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 VSD. Sort of the goal of the free VSD 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 via steep server desktop operating
system, network area storage, hypervisor, anything you can think of. It pretty much does the job
and 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. 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 the
short live free VSD forks. I mean free VSD distros. It's not like downloading in a bunch of
image that comes with all of the software out of the box. It's more like an arch Linux or a Gen2
image. We're choices left to the user on exactly how to configure the system, what things you
want installed, 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 Linux. And that's because
there's not these two mutually exclusive sort of head-butting ideas of, you know, Linux versus Genu.
So 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 I can think of
for free BSD is that everything required to boot the system is in the root directory. At 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 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 then else. 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 the FS. 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-val. Z-val is just think partition when I say Z-val. 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-val for their home directory. Any Z-val can be encrypted.
This is kind of what they're trying to accomplish with encrypted home directory using system
be 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 monster's 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,
will we have a boot environment that boots into the old kernel where we still have our Wi-Fi drivers
working. ZFS is 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 with that 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 a full disk encryption that's pretty standard with with Gelly and encrypted Z-val's
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. 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 for a millionaire
if you've ever used like an app or a DNF or a Yam 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 if you need a feature
I guess sort of an obscure feature. For example, you're Apache web server. You can compile that in.
And there's a cool tool for free bsd code 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 free bsd 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 and that work for all your various Gen2 machines.
Another interesting feature of free bsd is jails. So when I think of jails, I think of a jail as
like a charute. But the jails 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 get hub and blindly trusting it. Although there are 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. It's the same as a charute. But they have separate host names, IP addresses,
network interfaces, so on and so forth. On free bsd there is virtualization. That's kind of a standard
thing nowadays. There's the beehive hypervisor. I believe it can, I believe the beehive 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 vert manager to plug into beehive although I haven't tested it. I have
actually ran vert manager to connect to like a QEMU machine across the network. The virtualization
stuff is all there. I don't really use beehive very much when I need to build a hypervisor. I just use
KVM because it's what I know security. A free bst has access control lists. Access control lists are
kind of like mandatory access control, except not quite. Free bst 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. Free bst security as you can kind of tell is more so based around a 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 into different jails from your DNS server from your mail server and
someone and so forth. The one thing that makes a free bst sort of the cream of the crop for the
Linux guys is that free bst 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 free bst has a Linux compatibility layer making that Windows game possible to run on free
bst. 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 why in works on free bst. 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 free bst 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 detriments for free bst. So file system. The UFS file system is not journaled by default.
It's possible to enable journaling. Although nobody really does that. My recommendation just use
the UFS. Just use the UFS. It's way easier. Virtualization. The detriment here is they have a virtual
box port. Why put this in detriments 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. I'll elaborate on that.
No. Security. So free bst 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 free bst 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's 7 security.
It walks you through all the different security things. And also the handbook walks you through
the security things. So you're just getting started. You're curious about the bst world.
Jump into free bst. There's a lot of shoot 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. Here's the next thing I'm going to talk about. Open bst. So sort of the goals of open bst
are simplicity, portability, standardization, correctness, proactive security, and cryptography.
So the big use cases for open bst are networking appliances, servers, and then the final one is
desktops. Really the only people who run an open bst desktops 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 be created a better product. So some merits,
the core operating system webcam and microphone are disabled by default. The only way you can
reenable these is by changing a boot time option in your rc.com. I think that's what it's called.
Yeah, it's the rc.com to enable them. I should say all of these systems use this v and it's style
and it's system. What that means is unique style not bst style. Everything is pretty much shell
scripts. It's how the boot, the init system works. So the big thing about open bst 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 library 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 dot h are leaky and they like to leak memory and
cause crashes and seg vaults. So they wrote their implementations instead of like
STRN copy. They have STRL copy and STRA. STRL cat. And these what these functions do is crash
instead of allow bad behavior. Another interesting feature at every time you reboot
or boot an open bst system, the kernel is randomly re-linked. What this means is
a for a potential attacker. For example, if they know there is a vulnerability in one of your standard
libraries, they can install open bst themselves. Figure out where that standard library is for the
kernel in memory and then run that exploit. When you randomly re-link, 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 re-linked 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 them 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 the entire deck of standard libraries. They also do some
memory protection. So they have a right, a right sort of execute protection. What this means is that
a segment of memories either exclusively rightable 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 memories 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, seg fault and the crash very loudly. And this also makes
debugging a little bit difficult, but that's one of the reasons I like programming on open
BSD is because when you have a memory error, your program just crashes. So you know there's
a memory error. And this is also a 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
swastways. You know, various cryptography algorithms, the TCP-IP stack randomizes things, crypto,
you know, stuff that I don't know a whole lot about except for full disk encryption.
And so their X11 fork is called 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, pledging 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 unix's, 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
just kills 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 privileged separation. So what this
means is your HTTPD runs in a charute, your DNS server runs in a charute, your like NTP server runs
in a charute, and this charute is more secure. They've done some work on this route. It's like
more secure than a Linux charute where a charute escape is possible, and 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 space layout randomization and a million other things.
As for third party software support, open BSDs 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 INADD. 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 ways in the package add command. That's
PKG underscore add. And then for example, you want XFCE instead of CWM because you're not
DO himself. What you do is you package add XFCE and then you modify your your dot accession 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 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 people that made people mad. The do-as program,
do-as is a lot like pseudo, but the code base is significantly smaller, which means it's
significantly less opportunity for exploitation. Open BSD, HTTPD, right, a small web server,
Libre SSL, a small version of SSL, 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 either of 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. I guess the last example of documentation
is just read the source code. Open BSD source code is fairly small. The security theme kind of
makes sense for why the source code is fairly short. That's because the larger your code
base gets the more unmanageable it becomes and the more opportunity for, I guess, unseen air.
Comes in the play. So 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-feature, some de-marriage 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,
something stupid like putting home directories on Apache instead of just copying files.
Something like that. Deterence if you use open BSD, people will call you probably
paranoid and say that you fall in 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 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 a just works, a trademark Unicode 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. Another thing open BSD
is 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 charute anyway. But more power to him. 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 in bedded environments and then desktop if you're
a flagellant 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. 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 an older 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
you're extremely niche, deprecated architecture takes and get it to boot. I've 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 sources, it's very cool. Package sources of 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.
Minux uses package source. If anyone even uses minux, it's sort of the idea behind package source
is similar to, like I described earlier, the free BSD ports tree, except that it's operating system
agnostic. So you can run package source on net BSD, Mac, Alumos, Linux, OpenBSD if you're a
glutton for punishment. 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 a package source, and it's all make files and
shell scripts, right? Virtualization. Zen hypervisor runs on net BSD. There's also NVAMM,
which is an NVSD VMM, just like OpenBSD's NVAMM. It's a lot similar to KVM, and it works with
QEMU. So I mean, you can run your wacky architectures inside of a virtual machine on
that BSD, because I was QEMU support. Storage, they have a whole bunch of file systems, including
journal, DGFS, and CFS. I've always just used journal, DGFS on that BSD, because it seems to just work.
They also have LVM, that's kind of like Linux logical value management.
LVM, right? That's what it is, logical value management.
NetBSD 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 netBSD is that the kernel is entirely scriptable with Lua. And it systems
are scriptable in 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 insistent use case, nightmare language is 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 netBSD a whole lot. I need to play with it more in the same way
than you need to play with. Dragonflymore. So to recap, let's talk about some of these bigger
ideas, right? The non-specific ideas. So all the BSD systems use the, you know,
positioning at style in it system. What this means is basically an RC script, right? Etsy slash RC.com.
The old style way, right? The pre, uh, 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.
Uh, almost like an if you've ever used open RC. It's almost like using open RC.
And sort of the the resistance for system D like thing. Although they are coming, right? You can't
resist multi-threaded. Uh, or I can not multi-thread it, but sequentially starting process that boot.
You can't resist that forever if you want to compete. Um, I guess some other interesting
things, uh, more emphasis on the Unix philosophy. So the Unix philosophy is, um, you know,
do each process, each program should do one thing and do it well, uh, in Linux, we kind of have
these big, almost windows like amalgamations of things, right? System D is an example. Genome is an example,
but in the BSD world, they try to modularize things to the point where, uh, when something in
the pipe breaks, you can sort of, uh, figure out which one it is. Um, and I think, you know,
sort of the uniqueness, each of these operating systems feels genuinely different. We need to
sit down at the console, right? Uh, FreeBSD has like an end curses style display, uh, for installation
openBSD is a peer command line installation, but you just mash the enter button, uh, a bunch of
times and guess what, you have a net BSC installation, right? You don't even have to type anything,
except a root password. Uh, net BSD, they have an end curses installation also. Um, you know,
they all have update mechanisms, they're all, uh, in my opinion, quite fun to use, um, you know,
that's the whole, that's the whole reason why we're here on the computers because they find it fun,
and I think sort of resisting, you know, something because you don't like the license,
or because you, you got burned by it once or twice, um, and it doesn't make a whole lot of sense,
because there's a lot of fun to be had in, in sort of, uh, a unique implementation you've never used
before, uh, you know, I've been burned by FreeBSD a bunch of times and openBSD. I have an openBSD
installation that I can't upgrade, because I let it sit for too long, right? We've all been burned
before, uh, right? 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, uh, 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. Um, and I think closing opinions, uh, if any of these
appealed to you, right, if any of these operating systems appealed to you, uh, I go ahead and pick
that one out, um, you know, if you don't know which one to pick, pick FreeBSD. If you're a little
bit paranoid, I really recommend openBSD, um, and if you're learning C programming, uh, I recommend
reading openBSD source code, uh, quite heavily, um, although I still do most of my debugging on
Linux just because all of the security features on openBSD make, make debugging a little bit difficult,
uh, and as for NetBSD, um, as I said, I haven't used it much, but I've used it enough to know,
uh, that it really is portable, you know, when you download the, uh, system source code, uh,
you know, package source and all these things, they're entire, they're entire emphasis is based on
hey, let's make this run everywhere. Uh, you know, you go to the list and you see that it actually
does run everywhere. It's quite, uh, it's, it's quite, uh, I guess sublime, right? That would be the
word I used to see, uh, that the Unix philosophy, uh, right C because it's just abstract enough that
the compiler can turn it into whatever, uh, machine, obcodes, we, we need it for the specific architecture.
And, you know, seeing NetBSD running on everything is, uh, you know, you, that's the whole point behind
Unix is right once run everywhere. Um, I think, I think closing words here, uh, of course I am
long-winded. That's how all of my shows will probably go, uh, as that I am a very long-winded person.
Um, uh, future episodes, I, I started working on like a C programming episode and then I realized
it's going to have to be a C programming series. Uh, I think that something I've known all along
is that C programming is big and I can't just make a very 1000 foot view, uh, a comparing contrast type
thing, uh, between all of all of the various, you know, C, C function calls in ways of writing,
C like I did with the BSD episode, um, uh, and for a plan I in episode, uh, that's another thing.
I'm going to have to actually sit down and use plan 9 again. I have it used plan 9,
uh, and almost seven months now, um, even though, uh, I bought a laptop specifically to run
plan 9, uh, because that's what hackers do, right? You can't resist, uh, 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, uh,
uh, I'm sorry to any of these BSDs, of course, I'm not an authoritative source, uh,
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, uh, feel free to ask for help. I probably
won't have a 100% solution, uh, but I'll be able to point you in the right direction, um,
you know, if you want in-depth free BSD, right? How do free BSD jails work?
I'm gonna have to learn and then tell you, right? Uh, or, you know, how do I get an open
BSD workstation? Uh, I can do a episode on that, or, you know, whatever. Um, so anyway, thanks for
listening, uh, time to edit up this show, see if there are any, uh, noises I didn't catch,
and then, uh, I'll upload it. Hopefully this show not stayed correct. They're probably wrong,
but hopefully they'll stay correct. Uh, anyway, thanks for listening.
You have been listening to Hacker Public Radio at Hacker Public Radio.org.
Today's show was contributed by a HBR this night like yourself,
if you ever thought of a coin podcast, click on our contributally to find out how easy it means.
Hosting for HBR has been kindly provided by an onsthost.com,
internet archive, and our synced.net. On this otherwise stages,
today's show is released on our creative comments.
Attribution for.0.0 international license.