632 lines
52 KiB
Plaintext
632 lines
52 KiB
Plaintext
|
|
Episode: 3705
|
||
|
|
Title: HPR3705: The Year of the FreeBSD Desktop
|
||
|
|
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3705/hpr3705.mp3
|
||
|
|
Transcribed: 2025-10-25 04:24:33
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
This is Hacker Public Radio Episode 3705 for Friday the 14th of October 2022.
|
||
|
|
Today's show is entitled, The Year of the Freebie SD Desktop.
|
||
|
|
It is hosted by BinRc and is about 69 minutes long.
|
||
|
|
It carries an explicit flag.
|
||
|
|
The summary is I talk about configuring Freebie SD as a desktop OS and give tips for those
|
||
|
|
coming from Linux.
|
||
|
|
On this episode of Hacker Public Radio, I'm going to be talking about The Year of the Freebie
|
||
|
|
SD Desktop.
|
||
|
|
I've received a few emails people asking me, hey I'm curious about Freebie SD.
|
||
|
|
How do I get a desktop installed?
|
||
|
|
How do I use this thing?
|
||
|
|
Can you help me more?
|
||
|
|
All I know is Linux.
|
||
|
|
People asking questions, asking for advice.
|
||
|
|
I thought it'd be a good idea to record an episode and I chose the title The Year of
|
||
|
|
the Freebie SD Desktop.
|
||
|
|
After being inspired by the Linux community, I still would consider myself a part of
|
||
|
|
the Linux community.
|
||
|
|
But every time there is a minor system update, you see various commenters saying, oh this
|
||
|
|
update is so good, you know, the Skynomchell update is so good, it improves the system so
|
||
|
|
much that this year, the current year will be the year of the Linux desktop.
|
||
|
|
We will see widespread adoption of Linux throughout the whole world.
|
||
|
|
I took the title there, or at least the inspiration from those types of commenters.
|
||
|
|
And community members, a little bit tongue in cheek, I think, the title of the year of
|
||
|
|
the Freebie SD Desktop and also the concept of the year of the Linux desktop.
|
||
|
|
I've always said that the year of the Linux desktop is the year that you begin using
|
||
|
|
Linux as your desktop operating system, your primary or exclusive desktop operating system.
|
||
|
|
Similarly, the year of the Freebie SD Desktop is the year that you start using Freebie SD
|
||
|
|
as your primary desktop operating system or your exclusive desktop operating system.
|
||
|
|
Now I'm not super big on exclusion.
|
||
|
|
I think another episode that may or may not be coming out, I talk about gaming on Linux
|
||
|
|
a little bit.
|
||
|
|
So obviously, there's not any exclusion when you use open source software.
|
||
|
|
You can use different operating systems for different purposes, and you know, don't
|
||
|
|
feel bad if you still have a Linux desktop and you want to be a Freebie SD desktop user or
|
||
|
|
vice versa.
|
||
|
|
It's all open source, it's all welcome.
|
||
|
|
So the first step to becoming a member of the Freebie SD Desktop year commission, I don't
|
||
|
|
know what type of group of people we could have that are involved in the year of the Freebie
|
||
|
|
SD Desktop.
|
||
|
|
So the first step is to get an installer, I have a link to Freebie SD downloads.
|
||
|
|
That's freebie SD dot org slash where.
|
||
|
|
So the first thing you need to do is pick an installer, pick the correct architecture
|
||
|
|
for your system.
|
||
|
|
Don't know a whole lot about systems architectures.
|
||
|
|
You probably want AMD 64 if you have a computer with like an Intel processor or an AMD processor
|
||
|
|
that was manufactured within the last 20 years, it's probably going to be AMD 64 otherwise.
|
||
|
|
If you have something special, I think you'll know what you need.
|
||
|
|
The rest of this, the rest of this sort of podcast is going to be about installing Freebie
|
||
|
|
SD on an AMD 64 system and configuring it as a desktop.
|
||
|
|
So when you click on the architectures button, you have a lot of different download options.
|
||
|
|
So let's go through them.
|
||
|
|
There's an installer called bootonly.iso.
|
||
|
|
It's a net install image, it's for burning to a CD.
|
||
|
|
There's disc1.iso, that's a supplementary image, CD image for bootonly.iso.
|
||
|
|
You have DVD1.iso, it's a complete DVD image, it comes with extra packages.
|
||
|
|
You have memstick.iso, it's a complete image for burning to a USB stick and you have
|
||
|
|
mini memstick.iso, that's a net install image for burning to a USB stick.
|
||
|
|
I typically just use the memstick images because I find it easier to install off of a USB.
|
||
|
|
Then to burn a CD and then re-burn a CD and I don't have a lot of computers with the
|
||
|
|
CD drive anyway.
|
||
|
|
So it doesn't really make a whole lot of sense for me to be burning CDs.
|
||
|
|
One of the memstick images is probably what you want and if it's your first time installing
|
||
|
|
free BSD, I don't recommend going with the mini memstick option.
|
||
|
|
Sometimes that makes installing wireless drivers difficult.
|
||
|
|
So once you have your memstick image downloaded, a couple of commands you can run.
|
||
|
|
X, unZ, so they distribute these.
|
||
|
|
I download the zipped ones obviously, it saves a band with X, unZ, and then the path to
|
||
|
|
your installation image.
|
||
|
|
And then I use DD, the disk destroyer program to write that installation image to a USB
|
||
|
|
drive and then I eject that USB drive.
|
||
|
|
So now that you have a free BSD installer ready to go, let's get on with the installation.
|
||
|
|
So the first step is pre-installation.
|
||
|
|
The standard steps for installing Linux apply, so you have to go into your BIOS, disable
|
||
|
|
secure boot, enable USB booting.
|
||
|
|
Depending on how you knew your hardware is, enable legacy booting.
|
||
|
|
The same type of stuff you would do for a Linux installation and then enable the default
|
||
|
|
boot device or select the boot device at startup time.
|
||
|
|
This is all hardware specific.
|
||
|
|
I almost assume that being a Linux user is a prerequisite for this episode, so you probably
|
||
|
|
know how to do all of these things.
|
||
|
|
So now actually installing the thing for BSD has a menu driven installer and it walks you
|
||
|
|
through various steps.
|
||
|
|
This program is called BSD install.
|
||
|
|
So the first thing BSD install asks you to do is set a key map.
|
||
|
|
If you have a strange keyboard, you know all about setting key maps.
|
||
|
|
If you don't know what a key map is, just leave it as default.
|
||
|
|
Set a host name and then the third step is to select sets.
|
||
|
|
There are lots of sets.
|
||
|
|
This is just, I guess modules of the base operating system.
|
||
|
|
And if it's your first time installing free BSD, you probably want to install all of them.
|
||
|
|
I typically only install the lib32 set and add the rest later.
|
||
|
|
I like to have a leaner system.
|
||
|
|
The fourth step is to partition your hard drives.
|
||
|
|
So BSD install makes it really easy to partition your drives.
|
||
|
|
The file system you want or the option you want to choose in the partition menu will
|
||
|
|
be called auto and then in parentheses ZFS.
|
||
|
|
You should probably go with ZFS.
|
||
|
|
The default UFS configuration is not journal that's not very reliable because it's not
|
||
|
|
journaled and ZFS is very robust.
|
||
|
|
So in the automatic ZFS configuration menu for a single hard drive installation, set
|
||
|
|
your pool type to one disk.
|
||
|
|
You want to stripe one disk and then select your hard drive.
|
||
|
|
If you want full disk encryption, pick encrypt disks.
|
||
|
|
And then for setting swap size, you want to bump up your swap size.
|
||
|
|
I think by default, it's only two gigabytes.
|
||
|
|
The general rule of thumb for swap size is however much RAM you have times 1.5.
|
||
|
|
So if you have four gigabytes of RAM, you want like six gigs of swap.
|
||
|
|
If you have eight gigs of RAM, you want 12 gigs of swap.
|
||
|
|
And then if you also are encrypting your disks, you should probably also encrypt your swap.
|
||
|
|
encrypting your swap space means for example, password you may are made on and turn a web
|
||
|
|
browser or stored in RAM and they're swapped out when they're not used and you don't want
|
||
|
|
those things floating around on disk.
|
||
|
|
So when you're done configuring your file system, you can proceed with the installation.
|
||
|
|
You'll see a confirmation message asking if you want to destroy the disks.
|
||
|
|
This is the last step to go back after you commit.
|
||
|
|
You're going to have ZFS on your hard drives.
|
||
|
|
And whatever you have on there before is now gone, reduced to ash, never to be seen again.
|
||
|
|
And if you did choose to encrypt your disks, you'll have a password prompt.
|
||
|
|
This is the disk encryption password, not any user password.
|
||
|
|
You should probably set these to be different things.
|
||
|
|
The fifth step, wait for sets to install, cool little progress menu shows.
|
||
|
|
The sixth step is setting a password for the root user.
|
||
|
|
The seventh step is network configuration.
|
||
|
|
So if your wireless card is already supported, all of the hard parts are done for you.
|
||
|
|
If your wireless card is not supported, you might have to plug in an ethernet cable and
|
||
|
|
either download those drivers or you'll have to compile the drivers, for example, I think
|
||
|
|
Broadcom, a lot of the Broadcom cards you have to compile the drivers into the kernel.
|
||
|
|
Hopefully though, your Wi-Fi card is just supported.
|
||
|
|
So select your card at the network config, EM, EM0, EM1, those are ethernet interfaces.
|
||
|
|
Wi-Fi cards are named after their drivers, so for example,
|
||
|
|
so I have a, my Wi-Fi card is named WLAN0.
|
||
|
|
Hey, I think this might actually be incorrect.
|
||
|
|
I'll open BSD the name after your drivers, but
|
||
|
|
no, I'm pretty sure on Fubius either also named after your drivers because I have an atheros.
|
||
|
|
USB Wi-Fi card and it's named like ath0 instead of WLAN0.
|
||
|
|
If you choose Wi-Fi, the installer is going to stand for networks and give you a menu to select one.
|
||
|
|
If the network's encrypted, you're given a password prompt.
|
||
|
|
Annic, totally sometimes it'll ask you to change the FCC region.
|
||
|
|
If you are having difficulty seeing any Wi-Fi interfaces show up, don't set the region,
|
||
|
|
just leave it as default and it typically just works.
|
||
|
|
It can be fiddly. The last time I installed Fubius, it wasn't.
|
||
|
|
I reinstalled Fubius for this episode, it was fiddly.
|
||
|
|
But if you can't get it, try different FCC regions.
|
||
|
|
For example, no region versus US region.
|
||
|
|
The 8th step is time and date setup. That's really simple. You just set the time and date.
|
||
|
|
Then you set up services so you're presented with a menu that allows you to enable or disable
|
||
|
|
services on systems startup.
|
||
|
|
For most people, you probably want all of them except local unbound,
|
||
|
|
local unbound is like a local caching DNS resolver.
|
||
|
|
If you have never used one of those things before, it can cause DNS to behave in a way you've never
|
||
|
|
experienced and you might become frustrated. Typically, I don't enable that one, at least for a
|
||
|
|
desktop that's just going to be like a DHCP client. The 10th step is to configure security.
|
||
|
|
You can enable or disable security features. The more of these you enable, the more confusing
|
||
|
|
things can become, especially for someone who might be unfamiliar with FreeBSD.
|
||
|
|
If nothing else, disable send mail and enable the clearing of the temp partition, you can do the
|
||
|
|
other things if you really want to or if you really feel like it. But that's typically what I do
|
||
|
|
just for a desktop installation. The 11th step is to add users, so you just add your user.
|
||
|
|
You might want to add your user to the wheel group if you plan on using sudo.
|
||
|
|
I also set my shell to tcsh in this menu. You can always change your shell later.
|
||
|
|
Another thing about the wheel group. A lot of the hard parts about using FreeBSD as a desktop
|
||
|
|
operating system, a lot of the manual configuration you might have to do to be able to access a lot of these.
|
||
|
|
I guess lower system things that you know you would expect a desktop operating system to do,
|
||
|
|
you probably want your user in the wheel group. The final configuration you might want to
|
||
|
|
install the handbook or modify any configurations, installing the handbook takes a little bit of time.
|
||
|
|
And then when you're done, apply the configuration and exit. And then before you reboot,
|
||
|
|
you're given the last option to do any manual configuration. Most of the time you don't need to do
|
||
|
|
this. After the installation, now it's time to install a graphical user interface. I quoted
|
||
|
|
myself, what? No gooey? Yeah, there's no gooey by default on FreeBSD. So with a fresh installation,
|
||
|
|
we want to update the system. Those commands are FreeBSD-updateFetch, FreeBSD-update install,
|
||
|
|
and reboot. So running those things will update the base system.
|
||
|
|
The next thing I usually do is install them because I don't like using VI.
|
||
|
|
I don't want to have to use Ed when I don't have to and I don't like EE.
|
||
|
|
So we need a better text editor before we start editing all these files. On FreeBSD,
|
||
|
|
the package utility is what we manage packages with, at least binary packages anyway.
|
||
|
|
It functions almost identically to any Linux package manager you've used the syntaxes,
|
||
|
|
PKG, verb, object. That's how apt works, DNF works, for example. On FreeBSD, the only editors
|
||
|
|
installed by default are VI, Ed, and EE. If you've ever used nano, EE is kind of like nano.
|
||
|
|
But I like to install VIM. There are a couple of VIM flavors. I like the VIM-tiny flavor,
|
||
|
|
just because it doesn't pull in as many things. Like I said, I like running a lean system.
|
||
|
|
You probably also want to install Sudo or do as. So package install Sudo and then run the VI
|
||
|
|
Sudo command to edit the Sudo or style and then find the line that says wheel.
|
||
|
|
And remove the leading hash because we want the wheel group to be able to do actions as root.
|
||
|
|
The next thing I do is a couple of bootloader tweaks. We can tweak the bootloader to make the
|
||
|
|
system boot faster. So how you do this is you edit a file slash boot slash loader.com.
|
||
|
|
There's a lot of default stuff in there. Don't touch that too much if you don't know what you're doing.
|
||
|
|
And then I typically go to the very bottom of that file, add a comment that says custom stuff
|
||
|
|
below and then comment what each option does. So I add a line that says auto boot underscore
|
||
|
|
delay equals to so it'll boot faster. I think I should say before I continue. I'm not doing
|
||
|
|
a lot of really implementation or I guess hardware specific stuff. This is a pretty generic
|
||
|
|
free BSD installation. But the reason I'm editing these files is sort of to show you where they're
|
||
|
|
at and show you how to, for example, edit the bootloader, edit the init system, so on and so forth.
|
||
|
|
I'm not doing a lot of the really custom stuff that might make things behave strangely and in a
|
||
|
|
non default way. So to learn more about what tweaks you can make to the bootloader, read the loader.com
|
||
|
|
man page. The free BSD also comes with default configuration examples. So if you read slash boot,
|
||
|
|
slash default slash loader.com, that is a default configuration file for the bootloader.
|
||
|
|
Lots of good examples in there very well commented. The other thing we can do is tweak the init
|
||
|
|
system. Oh boy, my notes got out of order. That's fun. We can tweak the init system by editing slash
|
||
|
|
Etsy slash RC.com. So the configuration I had in the init system is, I append a line that says
|
||
|
|
background underscore DH client equals yes. This makes the DH client start in the background.
|
||
|
|
And sort of gets you to a desktop faster maybe than if you were waiting for a DHCP lease from your
|
||
|
|
DHCP server. If you read the man page for RC.com, it'll tell you all about the different things you
|
||
|
|
can do with RC.com. If you read slash Etsy slash default slash RC.com, that is an example file filled
|
||
|
|
with comments and lots of examples on what you can do with the init system. At this point, once I
|
||
|
|
have everything sort of a sane base fresh installation, I like to take a ZFS snapshot.
|
||
|
|
This makes it really easy to roll back to a fresh known working system configuration.
|
||
|
|
So how do I do that? You run the command ZFS snapshot dash R,
|
||
|
|
Z root at fresh install. So I'm snapshotting the Z root, which is the root of the ZFS pool.
|
||
|
|
And then I'm naming the snapshot fresh install. And then to list your snapshots, you can do ZFS
|
||
|
|
list dash T snapshot. So when the system becomes unreparable, we can roll back instead of having
|
||
|
|
to reinstall with a simple command. So how you roll back is ZFS data set ZFS rollback optionally
|
||
|
|
dash R, Z root at fresh install. To roll back every data set because ZFS rollbacks aren't recursive,
|
||
|
|
you can use a little bit of XArg's magic. So how do I do that? ZFS list dash T snapshot, pipe,
|
||
|
|
grip, fresh install, pipe, cut, dash D, in quotes of space, because we want the delimiter to be a
|
||
|
|
space, dash F1, pipe XArg's dash capital I percent ZFS rollback percent. A little bit of
|
||
|
|
shell magic to get recursive rollbacks on ZFS. I think it's a good idea to take ZFS
|
||
|
|
snapshots before you make any potentially dangerous configuration. And possibly after you've
|
||
|
|
done something that's kind of difficult to configure, it saves a lot of headache in the long run
|
||
|
|
because ZFS is accessible from the recovery shell. The last word of advice is to roll back with caution.
|
||
|
|
If you run a recursive rollback, for example, and you roll back your home pool, I believe that's
|
||
|
|
what it's called. Yeah, if you roll back your Z root slash user slash home, if you roll back your
|
||
|
|
home pool, all of your user data will be lost since that snapshot. So proceed with caution.
|
||
|
|
And then a little bit of homework, write a series of cron jobs that automatically take snapshots
|
||
|
|
and clear up the old ones. Sort of as a last line of defense version control.
|
||
|
|
Now for the part everyone's waiting for graphically user interfaces. So the first thing we need to do
|
||
|
|
is install graphics drivers. This varies depending on your GPU, but generally you'll just run
|
||
|
|
package install DRM-Kmod. After you install a package, you'll get a message. That's the cool
|
||
|
|
thing about free BSD is packages will actually give you a message telling you how to use them
|
||
|
|
after you install them. So the message from the DRM-Kmod package says, how do you install this
|
||
|
|
driver? So it says for AMD GPU, you enable it one way for Intel GPU, you enable it another way
|
||
|
|
for radio and KMS, you enable it a different way. So to enable one of these, you need to add a line
|
||
|
|
to your init system, right, slash Etsy slash RC.com. The earlier you place things, different lines
|
||
|
|
and starting services in this file, the sooner they start. So for example, since I have intel
|
||
|
|
graphics, you add the following line to enable intel graphics in the file slash Etsy slash RC.com.
|
||
|
|
So you append a line that says KLD underscore list equals in quotes i915 KMS. When you boot the
|
||
|
|
system, that loads the intel graphics drivers. To load kernel modules on the fly, you can use the
|
||
|
|
the command KLD load. The interesting thing about graphics drivers on free BSD is it also increases
|
||
|
|
the resolution of a VT. VT is like the virtual terminal. It's kind of like a frame buffer console,
|
||
|
|
but not quite. You just run the command KLD load i915 KMS. I've noticed if you unload
|
||
|
|
graphics drivers on the fly, it crashes the system, but that might just be anecdotal.
|
||
|
|
The last thing you need to do is add your non-root user to the video group. You have to be in the
|
||
|
|
video group to be able to use these drivers. So how do we do that? PW, run the command. PW,
|
||
|
|
group mod, video, dash m, and then your user name. Again, notes out of order, but I'm going to
|
||
|
|
continue anyway and upload this in this way because the commentary on notes out of order is kind
|
||
|
|
of fun. So audio, hopefully audio just works. Sometimes audio doesn't, but supported audio
|
||
|
|
interfaces are enumerated in the SND man page, and details about enabling and disabling these
|
||
|
|
drivers in slashboot slash loader.com are also explained in the man page. How you manage volume
|
||
|
|
on free VSD use the mixer command. So to set the mic volume to 50% and the speaker volume to 90%,
|
||
|
|
95%, you run mixer, mic, 50 colon 50. That'll set the mic's left and right audio channels to 50%.
|
||
|
|
mixer, vol 95 colon 95, that's the output volume to left and right output volumes for the speakers to
|
||
|
|
95%. You can also use plus or minus, I believe. So for example, mixer, mic, plus five will increase
|
||
|
|
5%. I think it works that way. The mixer, TUI command can also be used. This one's not installed
|
||
|
|
by default. You'll have to install mixer, TUI. This program functions almost identically to
|
||
|
|
all some mixer on Linux. It makes, it gives you a terminal based interface, like a graphical
|
||
|
|
terminal interface to modify volume on various audio interfaces. And then depending on your hardware,
|
||
|
|
the volume keys on your keyboard might not work. I typically add a key binding that calls a
|
||
|
|
shell script or even just a command to increase or decrease volume. This is like the typical
|
||
|
|
solution for people who run tiling window managers on Linux, people who really run any window
|
||
|
|
manager without a desktop on Linux. So this should be a familiar workflow, TUI. I think a lot of
|
||
|
|
the types of people who are interested in running free VSD. The next thing I do is install XORG.
|
||
|
|
How you do that? Package install XORG. That's the command you run. The TWM window managers included
|
||
|
|
with XORG by default. And this is useful because we can test our XORG configuration, test our
|
||
|
|
mouse support. Before we install a larger desktop environment that may or may not have problems
|
||
|
|
of its own. So early troubleshooting really prevents a lot of headache, you know, test early
|
||
|
|
test often. How you test your XORG after installs start X. If it works, you should CTWM start up.
|
||
|
|
Hopefully, again, hopefully XORG configurations just work out of the box. If they don't work,
|
||
|
|
troubleshooting XORG and getting a functional XORG or X11 configuration.
|
||
|
|
That is really operating system agnostic. That's almost identical on every
|
||
|
|
Unix-like operating system except for the fact where the configuration files are stored.
|
||
|
|
Now on to desktop environments. So you can refer to the handbooks instructions on
|
||
|
|
desktops. I have a link for that.
|
||
|
|
I've tested three of these on free VSD. So KDE works XFCE works pretty reliably.
|
||
|
|
Genome is sometimes reliable. If you're running a big desktop environment, you might have to modify
|
||
|
|
the Paul kit rules, P-O-L-K-I-T policy kit rules to do things like reboot the system from the GUI.
|
||
|
|
A lot of these larger desktops rely on free desktop.org components. I don't really like those
|
||
|
|
types of things. Like I said, lean system. That's what I like. So I don't like having debust running.
|
||
|
|
I use the cyclist tools, but for the sake of completeness, I will install each of these desktop
|
||
|
|
environments for the masses. I installed each of these desktops independently and sequentially
|
||
|
|
on the same system using ZFS snapshots to roll back to a bare-bone system without any desktop
|
||
|
|
environment installed. This is another good use for ZFS snapshots. For example, you want to test
|
||
|
|
something that might break the system or might create a lot of garbage files that you don't
|
||
|
|
necessarily want on the system. It's really useful to be able to snapshot things and roll back.
|
||
|
|
So how you install Genome? You're on the following commands package. Install Genome. After that's
|
||
|
|
done, you have to add ProcFS to your Etsy FS tab. I did this with a printf,
|
||
|
|
but if you want to edit that file in VIM, your FS tab in VIM, that just looks like Proc, tab,
|
||
|
|
Proc, tab, ProcFS, tab, RW, tab, zero, tab, zero, new line. That'll enable the Proc file system.
|
||
|
|
And then to mount that on the fly, you would do mount dash A.
|
||
|
|
To enable these things, all of the services required to get Genome started.
|
||
|
|
CISRC debuts underscore enable equals in quotes capital YES. So yes, in capital letters.
|
||
|
|
CISRC GDM underscore enable equals in quotes yes and all caps.
|
||
|
|
CISRC Genome underscore enable equals in quotes yes and all caps and then reboot the system.
|
||
|
|
When your system comes back up, you should see the GDM display manager you should be able to
|
||
|
|
log into Genome. I was actually surprised about how well Genome was functioning on FreeBSD 13 point.
|
||
|
|
Am I on two or one? I can't remember which version I'm running. FreeBSD 13.1.
|
||
|
|
In the past, I've had a lot of troubles with Genome, but it seems to work fairly reliably now.
|
||
|
|
At least Genome on FreeBSD used to be difficult for me in the past. I then rolled back and installed
|
||
|
|
KDE, so how you install KDE on FreeBSD. Package install KDE5 SDDM. Again, you will add the ProcFS
|
||
|
|
here at CFS tab. Same way as above. Then you will enable a couple services. CISRC debuts underscore enable
|
||
|
|
equals yes. CISRC SDDM underscore enable equals yes and then reboot and you should get SDDM.
|
||
|
|
So the interesting thing about the CISRC command is it actually just modifies the file slash
|
||
|
|
Etsy slash RC.com. It modifies your init system. These CISRC commands are identical to just
|
||
|
|
opening up your Etsy RC.com with a text editor. For example, adding a line that says debuts underscore
|
||
|
|
enable equals yes. As far as I know, these commands mostly function like just insert a line here,
|
||
|
|
modify a line here. That's how you install KDE and then I have a screenshot of KDE running.
|
||
|
|
I'm not sure if I said it, but I also have a screenshot of Genome on FreeBSD above.
|
||
|
|
I then roll back and I install xfce. So how you install xfce package install xfce
|
||
|
|
xfce4 dash goodies. The goodies package pulls in a lot of the
|
||
|
|
xfce applets and things that make it more usable than just a window manager.
|
||
|
|
xfce doesn't provide its own login manager unlike Genome or KDE. So we're going to install
|
||
|
|
LightDM because it's fairly small, fairly fast. The graphical toolkit matches xfce.
|
||
|
|
It looks good together. So how you install LightDM package install LightDM-GTK-greeder
|
||
|
|
and then you enable LightDM with a CISRC command. CISRC LightDM underscore enable equals yes.
|
||
|
|
Another way you could accomplish this would be like
|
||
|
|
echo LightDM underscore enable equals yes and then two angle brackets, right. The append
|
||
|
|
output redirect and then append it to your EtsyRC.com. I reboot the system. You should
|
||
|
|
see LightDM be able to log in to xfce. Then I roll back and I finally install what I wanted,
|
||
|
|
which is suckless. So the suckless tools, they're tools that suckless. I have a link for suckless.org.
|
||
|
|
They're fairly small tools. The philosophy is really hey, let's
|
||
|
|
we need, although we have to use x11, we can still make desktop environments and window managers
|
||
|
|
that are modular and not really a pain to use. That stay out of your way and let you get work done.
|
||
|
|
I typically run suckless software on most computers. I think except for Fedora,
|
||
|
|
I just run Genome on Fedora because I can't be bothered to install suckless when
|
||
|
|
I can get a full screen terminal running Genome identically to how I can get a full screen terminal
|
||
|
|
running suckless software. So I just wrote a make file that bonifies the compile options so that
|
||
|
|
these tools build on FreeBSD and automatically patch them to add a theme. The way you modify
|
||
|
|
suckless software is by patching the source code or the header files or the
|
||
|
|
make options. So you have to modify each of those components of software individually for whatever
|
||
|
|
system you're on. So I just wrote some suckless duct tape that I installed suckless on FreeBSD
|
||
|
|
and writes my plan 9 theme. The make file is fairly large but pretty much what it does is just
|
||
|
|
pulls down all of the get repositories for the suckless software I use.
|
||
|
|
I have a make option to patch them, install dependencies, add a patch for themes, build and install them.
|
||
|
|
It makes it easier. At least for me when I reinstall these things I like having a consistent
|
||
|
|
a consistent way of installing think of really quickly. Although I don't
|
||
|
|
and reinstall operating system very often I thought I'd just do it this time around.
|
||
|
|
And then in addition to using the suckless tools I just use XDM. It's small and fast,
|
||
|
|
it's configurable if you care. I typically just leave it how it is except for disabling the console.
|
||
|
|
How you install XDM, pseudo package install XDM, and then pseudo service XDM enable.
|
||
|
|
In FreeBSD there are a couple ways to modify your
|
||
|
|
init system. And then I have a screenshot of suckless software with my fancy plan 9 theme
|
||
|
|
and web browser open. So final note on desktops before I continue to some more general things.
|
||
|
|
Sometimes the desktops behave unexpectedly like users can't manage power settings or reboot
|
||
|
|
the system. If the user you're logging into a desktop environment is with logging into a desktop
|
||
|
|
environment with is in the wheel group. Most of these issues are resolved for the non-wheel group
|
||
|
|
users. You have to write policy kit rules, poll kit rules. I used to do this in the past. Now I
|
||
|
|
just add every user to the wheel group. But to be fair I'm the only one using my systems as a
|
||
|
|
desktop operating system. I don't share my computer very often with people. Especially considering
|
||
|
|
that I'm using like DWM and really a terminal only interface. It's kind of hard to share that
|
||
|
|
with an average person. Another thing to watch out for a lot of the big desktops are compiled without
|
||
|
|
support for modifying network connections. So for example there's not a Wi-Fi menu in the
|
||
|
|
GNOME settings. That may or may not be something you care about. But it's just as easy to configure
|
||
|
|
those things on an operating system level. I think almost easier because you know for sure it's
|
||
|
|
going to work. I'll get into network configuration in a minute. Similar to Arch and Gen 2,
|
||
|
|
there's a little bit of legwork left for the end user. I know a lot of people might not like
|
||
|
|
this little bit of legwork. You know modifying configuration options, tweaking things to get
|
||
|
|
things to work. How do you like them to work? But I always say you know this is a good thing. You
|
||
|
|
never know what you might learn if you don't give yourself the opportunity. So there's a lot of
|
||
|
|
weird operating system or even like desktop specific things that I've learned just because I've
|
||
|
|
put them on freeBSD. You know I've never modified a poll kit rule in my life until I started using
|
||
|
|
freeBSD. You might not even know that poll kit rules exist if you don't use freeBSD. I think exposing
|
||
|
|
yourself to strange and unfamiliar systems. It builds a lot of skills that you might not ever
|
||
|
|
have been aware of before. So you have to give yourself an opportunity and you have to stay
|
||
|
|
diligent. But most of the time everything just works. At least in my anecdotal experience.
|
||
|
|
So another thing I do, I make shell tweaks. So I like colors in my system shell.
|
||
|
|
I don't use colors on OpenBSD. That was kind of a strange thing. I also like aliases. So because
|
||
|
|
the default shell on freeBSD is CSH, we can modify the configuration file to automatically do
|
||
|
|
the fancy for us. So in my CSHRC, I leave the default stuff in the prompt section.
|
||
|
|
I have a couple sampled prompts. I just set my prompt to be bold and then leave it at that.
|
||
|
|
I think I have a colorful one in there too. One of those might be red instead of bold.
|
||
|
|
You know, comment or uncomment if you want to copy my configuration.
|
||
|
|
And then in the bind key section, I add the control R keybinding to do reverse history search.
|
||
|
|
Kind of like how you would use the control R keybinding on bash to search through history.
|
||
|
|
I then add some aliases. So ls alias la to ls dash a capital f alias lf to ls dash capital f capital a alias ll to ls dash a capital
|
||
|
|
I lost that. So my l alias is for the following command ls dash l capital a capital f i alias
|
||
|
|
regular ls to ls dash capital g capital f. So the capital g gives you colors. The capital f gives you
|
||
|
|
like a slash, for example, if it's a directory, I think a star, for example, if it's executable.
|
||
|
|
Yeah, so it gives you a star if it's an executable.
|
||
|
|
Some interesting things. And then I alias lc to ls dash g capital g capital f.
|
||
|
|
The reason I alias lc is because on plan nine, lc is equivalent to ls dash dash column or
|
||
|
|
something like that. I think it's, yeah, so lc is the command on plan nine to give you a multi-column
|
||
|
|
ls output. And the muscle memory, it's a lot easier just to leave the muscle memory and adjust the
|
||
|
|
aliases. So some other packages you can install. The things that I like to install.
|
||
|
|
Firefox, Gimp, FAT, MPV, FFMPEG, ImageMagic, MUT, and NewsBoot. If you've installed a large desktop
|
||
|
|
environment, most of the applications are automatically pulled in. If they're not pulled in,
|
||
|
|
you can use xargs to pull in hundreds if not thousands of gigabytes, possibly up to petabytes
|
||
|
|
of programs. So how you do that pseudo package search, whatever your desktop environment is,
|
||
|
|
you pipe it through cut. You're going to delimit it with a space, take the first field,
|
||
|
|
and then pipe it through xargs, pseudo package install dash y.
|
||
|
|
FreeBSD package is kind of interesting. You can, I don't think it works with regular
|
||
|
|
expressions, but if you do a package list or a package search followed by a cut and then pipe
|
||
|
|
it through xargs, it'll just run. Instead of running each of those package commands,
|
||
|
|
it can currently, it'll just put them all together and run one big package command. It's really
|
||
|
|
cool. If you want to go GNU, you can do sudo package install core utils, emacs, bash, gcc,
|
||
|
|
gmake, whatever other going to do utilities you want. They're there, they're available.
|
||
|
|
I don't use them, but if you like bash, maybe more than CSH,
|
||
|
|
why not, right? That's how open source is all about making your system do what you wanted to do.
|
||
|
|
Using the computer, how you want to use it. So if you want GNU on top of freeBSD, why not?
|
||
|
|
I think the only caveat I'll say here is don't change a lot of the root users default stuff to
|
||
|
|
GNU stuff. Things start to break when you change the root user shell.
|
||
|
|
But that is also the same on Linux. For example, you don't want to change your root user shell to
|
||
|
|
one of those wacky, wacky shells people use just so they can look cool on forums like fish or
|
||
|
|
CSH. You don't want to do that. Now that you have a desktop configured, it's another good time to
|
||
|
|
take a ZFS snapshot. So you always have a working desktop configuration to go back to. For example,
|
||
|
|
if you break it in the future, you can always do a ZFS rollback, get back to your working desktop
|
||
|
|
configuration, and then proceed from there. The last section I have, actually this is not the last
|
||
|
|
section, is a quick start section. So this is a lot of, this is sort of where I take the assumptions
|
||
|
|
of people knowing how to use Linux and build on top of them. So instead of SystemD,
|
||
|
|
FreeBSD uses RC scripts for starting and stopping services. Everything is pretty much just out
|
||
|
|
shell scripts. To modify the processes that start at boot, you can edit slash Etsy slash RC.conf.
|
||
|
|
I like being able to edit my init system with the text editor. It's something that I really,
|
||
|
|
really miss when I have to use a Linux system. If you are familiar with like a system CTL
|
||
|
|
command on Linux, you can start and stop services this way. Using a different command, the service
|
||
|
|
command. So service shshd enable service shd start service shd restart stop disable one start status.
|
||
|
|
A lot of the similar system CTL commands you might be familiar with on Linux, you will just use
|
||
|
|
the service command on FreeBSD. I believe the service command on Linux also works the same.
|
||
|
|
The only thing here is that each service has its own init file. So sometimes a service might take
|
||
|
|
different arguments than one you might expect. So for example, if you modify your sshd service to
|
||
|
|
maybe use a different sshd config, you could do like service sshd start dash alt config.
|
||
|
|
Because it's all shell scripts, it's fairly easy to do.
|
||
|
|
And the other thing I should say, the syntax is backwards. So it's service, the service you want to
|
||
|
|
start or stop, the service that you're supplying an argument to, and then an action with system D,
|
||
|
|
it's system CTL verb object on FreeBSD its service object verb. This syntax messes me up sometimes,
|
||
|
|
but it's not a huge deal. You realize as soon as you do it that you've done it, you just have
|
||
|
|
to flip a couple words around. It's not super difficult. Networking. So network interfaces are
|
||
|
|
configured classically using the if config command. If you want a network interface to persist
|
||
|
|
across reboots, you add this information to slash Etsy slash rc.conf. A lot of things are
|
||
|
|
managed in the init system, including for example, you want to start a loopback device or a
|
||
|
|
bridge device, you'll just add that interface to your init configuration. And then when you
|
||
|
|
boot the system, that bridge devices automatically started that extra loopback devices automatically
|
||
|
|
started. Wi-Fi is managed with a program called WPA underscore supplicant. Read the man page for
|
||
|
|
more information. If I actually go to my file. So WPA supplicant is
|
||
|
|
fairly easy to use. So you just edit the file Etsy slash WPA supplicant.conf. And then you just add
|
||
|
|
a network and you can set priorities, add keys, so on and so forth. It's a plain text way of
|
||
|
|
configuring your Wi-Fi networks. And the only thing that ever trips me up with WPA a
|
||
|
|
supplicant is that when you assign a network a priority, higher values have a higher priority,
|
||
|
|
as opposed to lower values having a priority. Sort of intuitively, I think, oh, priority zero,
|
||
|
|
that's going to be like nice levels where a lower number has more priority. No, it's the opposite.
|
||
|
|
As for firewall, I have a link to the free BSD handbook. Use the PF firewall. The PF firewall
|
||
|
|
is very easy to use. Again, plain text configuration. A very simple PF configuration can be like one line
|
||
|
|
or two lines. Let me find a sample PF configuration. I will just read it to show you how short it is
|
||
|
|
compared to something like NIP tables configuration.
|
||
|
|
Yeah, so my PF configuration on my web server, set skip on L0, so set skip on the loop back
|
||
|
|
device. TCP underscore services equals in quotes. And then in brackets, SSH comma HTTP comma HTTPS
|
||
|
|
block in all pass in proto TCP to any port dollar TCP under services keep state pass out all.
|
||
|
|
That is all the firewall configuration you need to block all ports except for SSH HTTP and HTTPS.
|
||
|
|
That's 2280 and 443. I really like PF because it's simple and you can also, it's really flexible.
|
||
|
|
There's a lot of things you can do, for example, read a list of IP addresses or from a file and then block
|
||
|
|
those. There's lots of cool things you can do with PF and it's quite, I like it quite a lot even
|
||
|
|
though I do have a little bit of an affinity for firewall D.
|
||
|
|
The next thing I talked about, the next quick starter, the general upgrade process. So on FreeBSD,
|
||
|
|
the packages you install are separate from the base system. The base system is managed separately
|
||
|
|
from the packages. If you keep this in mind, you're going to be okay. So to update the entire system
|
||
|
|
from top to bottom, base and packages altogether. The commands look something like package update
|
||
|
|
and and package upgrades. So when I say and and that means 2 ampersands. You then run the command
|
||
|
|
FreeBSD-updateupgrade-r and then the release, in my case 13.1-release. When 13.2 comes out,
|
||
|
|
you use 13.2-release or 14.0-release. FreeBSD-update install and then you reboot.
|
||
|
|
And then you reboot the system and log in as root and then you run FreeBSD-update install again.
|
||
|
|
You want to update and upgrade your packages again that way,
|
||
|
|
if there are any major standard library or or A, B, I interface changes, they will be upgraded
|
||
|
|
and just work again. And then you run FreeBSD-update install. One more time, this will remove all of
|
||
|
|
the unnecessary A, B, I, A, B, I stuff from the package update. And then when you reboot,
|
||
|
|
your whole system will be new, all of the packages will be updated if there's any library changes,
|
||
|
|
for example. And everything should just work. This is a little bit more
|
||
|
|
comprehensive than, for example, doing a major version upgrade on something like Fedora.
|
||
|
|
But it's largely because on Fedora, the base system and the ancillary user installed packages are
|
||
|
|
both managed to the same package management system. Whereas on FreeBSD, the base system is distinct
|
||
|
|
from the user installed packages. This is for stability purposes. As for shells, FreeBSD
|
||
|
|
uses TCSH as the default shell. It includes SH for born like compatibility. So when you do
|
||
|
|
shell scripting, I always say just do POSIC shell because every single unit like operating system
|
||
|
|
as a POSIC compatible shell or even a system with BASH, if you run BASH, DASH, DASH, POSICS,
|
||
|
|
I believe, I'm going to check that. Yep, if you run BASH, DASH, DASH, POSICS, it will run in
|
||
|
|
POSICS compatibility mode. You can install BASH if you want on FreeBSD. I typically just use the
|
||
|
|
default shell wherever I'm at. But you know, right, right, POSICS compatible shell scripts.
|
||
|
|
And then your shell scripts will work on Linux. It'll work on FreeBSD. It'll work on
|
||
|
|
something strange like Illumos. Not Plan 9 though. Not Plan 9.
|
||
|
|
Package management. That's the next quick start section. On FreeBSD, there are two main ways
|
||
|
|
of managing software. There are binary packages and ports. Don't mix binary packages and ports.
|
||
|
|
If you don't know what you're doing, it can cause problems. So a brief explanation of ports,
|
||
|
|
ports are like Gen2. You download a port tree. It's a series of recipes to make the software.
|
||
|
|
You end up spending a lot of time watching compiler output, possibly manually troubleshooting
|
||
|
|
dependencies, resolving dependencies. But there are a few programs that help with this.
|
||
|
|
So synth is a program that builds ports, port master is a program that builds ports,
|
||
|
|
and PUDRIARE, PUDRIARE. I never know how to say it. That's useful for creating like a local binary
|
||
|
|
package repository. That's what PUDRIARE is for. It builds all of the ports and then you can
|
||
|
|
serve them as a binary package repository. It's very useful. And then to be more verbose about
|
||
|
|
using the binary package management system. So for example, package install FUBAR,
|
||
|
|
package search FUBAR, package remove FUBAR, package install FUBAR again.
|
||
|
|
Package auto remove, package update, package upgrade. Really similar stuff to like a DNF or an
|
||
|
|
app. The file system, I guess I should probably have titled this hierarchy. But the hierarchy of
|
||
|
|
FUBAR is different than a Linux system. Read the man page on hire. That's man, H-I-E-R.
|
||
|
|
It tells you why things are the way that they are. So the biggest difference on FUBAR
|
||
|
|
is that it's logically organized. On Linux, everything you install ends up in slash bin,
|
||
|
|
which is actually just a simlink to slash user slash bin. And slash S bin is just a simlink
|
||
|
|
to slash user slash S bin. On FreeBSD, the file system is a lot more organized. There's a
|
||
|
|
stronger concept between base operating system and random stuff the user installed from the package
|
||
|
|
management tools. This is useful because of a package breaks, for example, the system still
|
||
|
|
boots. So on FreeBSD, slash bin requires contains everything required to boot the system.
|
||
|
|
Slash bin contains everything required for fundamental administration. Slash user slash bin
|
||
|
|
contains all of the other non-essential binaries that are part of the base system. And then
|
||
|
|
everything in user local is what is installed by the package management system. So user local bin,
|
||
|
|
that would be, for example, where VIM is installed, perhaps where Audacity or Firefox is installed,
|
||
|
|
right? Another thing, user installed programs are configured in slash user slash local slash Etsy.
|
||
|
|
This is a little bit confusing at first, but you get the hang of it when you start to think,
|
||
|
|
user local is where all of the other stuff is. Everything in the root directory is default
|
||
|
|
system. Everything in user local is what I've installed. So, for example, a document root for
|
||
|
|
like Apache on FreeBSD. It's not far dubbed up HT docs. It would be user local far dubbed up HT docs.
|
||
|
|
It gets long, sometimes your prompt gets long, but you get the hang of it after a while,
|
||
|
|
and it starts to make a lot of sense and really becomes enjoyable to use the system that way.
|
||
|
|
Another issue with this logical separation is it can cause confusion when compiling software
|
||
|
|
from source, specifically not from the port system, but like something you download off GitHub,
|
||
|
|
or for example, all of the suckless tools I compile, I have to manually modify the linker options,
|
||
|
|
and sometimes the make file options, so that the linker knows where to look for libraries at.
|
||
|
|
If you know how linker options work, if you know how make files work, a lot of times you can just
|
||
|
|
change, for example, slash user include to slash user local include, and it fixes a lot of things.
|
||
|
|
Things usually just compile. As for actual file system support, apparently I didn't know this,
|
||
|
|
but apparently extended to extend the three and extended four. Now I have read right support
|
||
|
|
using the EXT2FS driver. The last time I looked into extended four support on FreeBSD
|
||
|
|
was probably about half a decade ago. It might have existed then, but I wasn't aware of it.
|
||
|
|
I probably wouldn't try to boot from extended four, honestly, but these things exist for
|
||
|
|
compatibility purposes. The other big file system, UFS, it's not journaled by default,
|
||
|
|
proceed with caution. If you don't know what file system to pick, just pick ZFS, I promise,
|
||
|
|
a lot of the complicated ZFS stuff, including snapshots, you don't even have to be aware of snapshots
|
||
|
|
to use ZFS. You can use it as a very dumb file system if you want. I then have a section called
|
||
|
|
ZFS nonstarter. I'm not an expert on ZFS, but I sort of show you some of the cool things about
|
||
|
|
ZFS in this shell session. So I write ZFS is cool because we can create partitions on a whim, we can
|
||
|
|
create partitions, and ZFS partition is called data set. I think of it as a logical partition,
|
||
|
|
except unlike Linux, LVM, it's a lot more flexible. So we can create data sets, create data sets with
|
||
|
|
a quota, destroy data sets, create and use encrypted data sets, so on and so forth. So ZFS list,
|
||
|
|
list all your data sets, ZFS list dash T snapshot, list all your snapshots,
|
||
|
|
how you create a data set, ZFS create Z root slash the path to your data set. So I create
|
||
|
|
Z root slash crypt. I'm thinking I want to make an encrypted partition. So I set the quota,
|
||
|
|
ZFS set quota equals 5G on Z root slash crypt. I listed it tells you it's only using 96 kilobytes,
|
||
|
|
it has 5 kilobytes available. That is the quota. I then realized I didn't turn encryption on.
|
||
|
|
So I ZFS destroy Z root slash crypt. I then recreate it. ZFS create dash O encryption equals on
|
||
|
|
dash O key location equals prompt dash O key format equals pass phrase Z root slash crypt. It
|
||
|
|
prompts me for a password. I enter it. I then ZFS list Z root slash crypt. It tells me hey,
|
||
|
|
this thing exists now. I make a file called super secret and slash Z root slash crypt,
|
||
|
|
list that file. I get encryption information. I unmount, unload the key, reload the key,
|
||
|
|
so on and so forth. Additionally, you can modify mount options with ZFS. I didn't do this in that
|
||
|
|
example, but I probably wouldn't mount my crypt partition at Z root slash crypt. I'd probably
|
||
|
|
mount it as a sub directory of my home partition. ZFS is really flexible and a lot of the things
|
||
|
|
you can do don't require like modifying your FS tab. It's all done through ZFS. It's really,
|
||
|
|
it's a really cool file system and I need to use it more. You know, I know quite a bit about
|
||
|
|
LVM Linux logical volume management, but that sort of has its own drawbacks compared to ZFS.
|
||
|
|
I really like ZFS. You know, ZFS even does a raid. I only run it. I've only ever ran it on one
|
||
|
|
disc at a time, but you know, the ability to create partitions on the fly, the ability to set quotas
|
||
|
|
on the fly, the ability to change mount points on the fly. It's all really powerful stuff and I'm
|
||
|
|
kind of surprised there's not something like this and Linux already. And I almost wish there
|
||
|
|
was ZFS on BSD, on open BSD because I would just use open BSD forever and ever, but we gave what we
|
||
|
|
can take. So my conclusion here, I really think free BSD is a viable desktop operating system,
|
||
|
|
especially for the types of people who already use Linux in a terminal-centric way. You know,
|
||
|
|
Unix is Unix. I think for anyone who's ever installed like Arch or Gen2, or gone from a Debbie
|
||
|
|
and minimal installation to a graphical installation, a graphical environment, you know, something
|
||
|
|
as big as GNOME or something as small as like open box. I think free BSD is not, it's not really
|
||
|
|
all that difficulty, you know, so sort of demystifying free BSD. It's just a Unix. It's just like
|
||
|
|
a Unix because it is a Unix and a lot of the things you do are familiar because, guess what,
|
||
|
|
X11 is the same everywhere you go. Operating systems or Linux distributions that use WPA
|
||
|
|
Supplicant, same as everything else. You know, the really the big major differences are from
|
||
|
|
a Linux, no GNU, no system D, and maybe a better way of organizing the system where instead of
|
||
|
|
dumping everything into Slash Bin, you instead dump everything into, you know, an Ancillary
|
||
|
|
Directory link. This is the garbage I've installed from the software repositories containment zone,
|
||
|
|
everything else that is actually, you know, I should take care of that's over here. So I have
|
||
|
|
some other stuff. I don't run Firefox inside of a jail, but I have two links on how to run Firefox
|
||
|
|
inside of a jail. Jails are like Cherutes, jails are like Docker containers. The only difference is
|
||
|
|
jail is slightly more secure than a Cherute. And unlike Docker, when you build a jail, it doesn't
|
||
|
|
have the aspect of downloading random stuff off of GitHub and downloading random operating systems
|
||
|
|
off of GitHub and Docker containers off of GitHub. And blindly trusting that the guy who set it
|
||
|
|
up actually knows what he's doing. And then I have a list of free BSD distros that come with a
|
||
|
|
desktop out of the box. Ghost BSD is free BSD with the Matei desktop Hello System. It's free BSD
|
||
|
|
with an Apple like GUI. I believe Hello System is still in development, but I'm kind of curious
|
||
|
|
to see. I think the Apple desktop is called like Aqua or something. I'm kind of curious to see
|
||
|
|
what an Aqua like desktop would be on free BSD, especially considering that large portions of
|
||
|
|
Apple software is pretty much just BSD. Another one, Midnight BSD is free BSD with XFCE and a
|
||
|
|
different package management system. There is also Nomad BSD. It's a live GUI free BSD with
|
||
|
|
open box. I'm probably wrong about this, but the way I think of Nomad BSD, I conceptualize it
|
||
|
|
similar to Puppy Linux. But you know, you can obviously install it on a hard drive and use it
|
||
|
|
as if it was anything other than Puppy Linux, right? But that's all I have on the year of the
|
||
|
|
free BSD desktop. If you have any questions, you can leave a comment or send me an email or record
|
||
|
|
a follow-up show. If you have any complaints, you can do the same. If you have any grievances to
|
||
|
|
air, you can also do the same. If you... I'm trying to think of what else you might want to do.
|
||
|
|
If you want to learn more about free BSD, I will definitely say you should check out the handbook.
|
||
|
|
The handbook is good reading, even if you have no intentions of ever installing or running the
|
||
|
|
system, just because it gives you a really big overview on how to do things with this system,
|
||
|
|
how things are structured. If you're curious, but not committed. For the same reasons, I tell people
|
||
|
|
to read the 9 front FQA, even if they have no intentions of running the system, because it is
|
||
|
|
informative and it gives you a good overview of the system without actually committing to that system.
|
||
|
|
This episode, I've waited till the very end to say it. I'm recording this on free BSD. My USB
|
||
|
|
microphone just works. Unlike the 9 front episodes, I have a plan 9 episodes. You know,
|
||
|
|
where the microphone doesn't work. It just works on free BSD, you know. I'm recording in audacity,
|
||
|
|
so on and so forth. And I'm still looking. Oh, I think one last caveat, I should say this is
|
||
|
|
kind of an aside. So Linux has DRM enabled in the kernel. This means you can watch DRM controlled
|
||
|
|
content in your web browser. Free BSD does not have DRM controlled content in your web browser,
|
||
|
|
or in the kernel for that matter. So for example, you can watch Netflix on Linux. You can't watch
|
||
|
|
Netflix on free BSD. Even though the Netflix servers run on free BSD, but you know, the whole
|
||
|
|
debate on DRM and the kernel, my legitimate response is, why would you ever want to watch Netflix?
|
||
|
|
Right. There's so many things we can do besides just watching. We have so much doing to do in life.
|
||
|
|
Why not do it? And I think with that sort of multimedia caveat, the DRM caveat, I think I'm
|
||
|
|
going to end the show. So if you have any questions, feel free to leave a comment or send me an email.
|
||
|
|
If you get stuck somewhere along the way, trying to install free BSD,
|
||
|
|
for sure, for sure, send me an email or leave a comment and I will try my hardest to help you.
|
||
|
|
Right. That's what open sources all about. The people before me taught me for free. Now it is
|
||
|
|
my responsibility to teach the people after me. All right. We have to pass down this knowledge,
|
||
|
|
pass down these skills, help people where we can and help guide them to the answers and the
|
||
|
|
solutions. And I think that's my favorite aspect about open source software and free software in
|
||
|
|
general is sort of the, you know, passing of the torch before you become too cynical about software.
|
||
|
|
You have a period of time where you tell people all about all the things you've learned and help
|
||
|
|
people along the way. I think also if you do install free BSD, you should record an episode
|
||
|
|
and giving it a review. Your perspective as a person who has never used free BSD before,
|
||
|
|
what you like about it, what you don't like about it, the interesting things you found out about it,
|
||
|
|
maybe your favorite part about it, your least favorite part about it, why you're sticking with
|
||
|
|
free BSD, why you're going back to Linux, why you're considering being a hobbyist computer in any
|
||
|
|
capacity whatsoever when an operating system like macOS or Windows just works. All right. So if you
|
||
|
|
install free BSD, you know, record an episode giving a legitimate review on it. You know, we're so
|
||
|
|
curious about a lot of the new Linux users, but I'm more so curious about the people who have been
|
||
|
|
using Linux and Unix for a long time, trying a different type of Linux or Unix that's just
|
||
|
|
different enough, it might be a little bit uncomfortable. But as I always say, there's a lot of fun
|
||
|
|
in computing. You know, there's still a lot of fun in Linux and a lot of fun in BSD. So again,
|
||
|
|
thanks for listening to Hacker Public Radio. And stay tuned. Eventually, I will record the year of
|
||
|
|
the Open BSD desktop episode. This has been Hacker Public Radio, and that is all I have to say.
|
||
|
|
This has been RC, and I am ending the recording.
|
||
|
|
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 broadcast,
|
||
|
|
you click on our contribute link to find out how easy it leads. Hosting for HBR has been
|
||
|
|
kindly provided by an onsthost.com, the Internet Archive and R-Sync.net. On the Sadois status,
|
||
|
|
today's show is released on our Creative Commons Attribution 4.0 International License.
|