1
GETTING MORE HELP

As thick as this book is, it still can’t possibly cover everything you must know about FreeBSD. After all, Unix has been kicking around for close to 50 years, BSD is pushing 40, and FreeBSD is old enough to have its doctorate. Even if you memorize this book, it won’t cover every situation you might encounter. The FreeBSD Project supports a huge variety of information resources, including numerous mailing lists and the FreeBSD website, not to mention the official manual and Handbook. Its users maintain even more documentation on even more sites. The flood of information can be overwhelming in itself, and it can make you want to just email the world and beg for help. But before you send a question to a mailing list or forum, confirm that the information you need isn’t already available.

Why Not Beg for Help?

FreeBSD provides two popular resources for assistance: mailing lists and forums. Many participants on both are very knowledgeable and can answer questions very quickly. But when you send a question to these community support resources, you’re asking tens of thousands of people all over the world to take a moment to read your message. You’re also asking that one or more of them take the time to help you instead of watching a favorite movie, enjoying dinner with their families, or catching up on sleep. Problems arise when these experts answer the same question 10, 50, or even hundreds of times. They become grumpy. Some get downright tetchy.

What makes matters worse is that many of these same people have spent a great deal of time and effort making the answers to most of these questions available elsewhere. If you make it clear that you’ve already searched the resources and your answer really doesn’t appear therein, you’ll probably receive a polite, helpful answer. If you ask a question that’s already been asked several hundred times, however, the expert on that subject just might snap and go ballistic on you. Do your homework, and chances are you’ll get an answer more quickly than a fresh call for assistance could provide.

The FreeBSD Attitude

“Homework? What do you mean? Am I back in school? What do you want, burnt offerings on bended knee?” Yes, you are in school. The information technology business is nothing but lifelong, self-guided learning. Get used to it or get out. Burnt offerings, on the other hand, are difficult to transmit via email and aren’t quite so useful today.

Most commercial software conceals its inner workings. The only access you have to them is through the options presented by the vendor. Even if you want to learn how something works, you probably can’t. When something breaks, you have no choice but to call the vendor and grovel for help. Worse, the people paid to help you frequently know little more than you do.

If you’ve never worked with open source software vendors, FreeBSD’s support mechanism might surprise you. There is no toll-free number to call and no vendor to escalate within. No, you may not speak to a manager and for a good reason: you are the manager. Congratulations on your promotion!

Support Options

That being said, you’re not entirely on your own. The FreeBSD community includes numerous developers, contributors, and users who care very deeply about FreeBSD’s quality, and they’re happy to work with users who are willing to do their share of the labor. FreeBSD provides everything you need: complete access to the source code used to create the system, the tools needed to turn that source code into programs, and the same debuggers used by the developers. Nothing is hidden; you can see the innards, warts and all. You can view FreeBSD’s development history since the beginning, including every change ever made and the reason for it. These tools might be beyond your abilities, but that’s not the Project’s problem. Various community members are even happy to provide guidance as you develop your own skills so you can use those tools yourself. You’ll have lots of help fulfilling your responsibilities.

As a grossly overgeneralized rule, people help those like themselves. If you want to use FreeBSD, you must make the jump from eating what the vendor gives you to learning how to cook. Every member of the FreeBSD user community learned how to use it, and they welcome interested new users with open arms. If you just want to know what to type without really understanding what’s going on behind the scenes, you’ll be better off reading the documentation; the general FreeBSD support community simply isn’t motivated to help those who won’t help themselves or who can’t follow instructions.

If you want to use FreeBSD but have neither the time nor the inclination to learn more, invest in a commercial support contract. It might not be able to put you in touch with FreeBSD’s owner, but at least you’ll have someone to yell at. You’ll find several commercial support providers listed on the FreeBSD website.

It’s also important to remember that the FreeBSD Project maintains only FreeBSD. If you’re having trouble with some other piece of software, a FreeBSD mailing list is not the place to ask for help. FreeBSD developers are generally proficient in a variety of software, but that doesn’t mean they want to help you, say, configure KDE.

The first part of your homework, then, is to learn about the resources available beyond this book. These include the integrated manual, the FreeBSD website, the mailing list archives, and other websites.

Man Pages

Man pages (short for manual pages) are the primordial way of presenting Unix documentation. While man pages have a reputation for being obtuse, difficult, or even incomprehensible, they’re actually quite friendly—for particular users. When man pages were first created, the average system administrator was a C programmer and, as a result, the pages were written by programmers, for programmers. If you can think like a programmer, man pages are perfect for you. I’ve tried thinking like a programmer, but I achieved real success only after remaining awake for two days straight. (Lots of caffeine and a high fever help.)

Over the last several years, the skill level required for system administration has dropped; no longer must you be a programmer. Similarly, man pages have become more and more readable. Man pages are not tutorials, however; they explain the behavior of one particular program, not how to achieve a desired effect. While they’re neither friendly nor comforting, they should be your first line of defense. If you send a question to a mailing list without checking the manual, you’re likely to get a terse man whatever in response.

Manual Sections

The FreeBSD manual is divided into nine sections. Roughly speaking, the sections are:

1. General user commands
2. System calls and error numbers
3. C programming libraries
4. Devices and device drivers
5. File formats
6. Game instructions
7. Miscellaneous information
8. System maintenance commands
9. Kernel interfaces

Each man page starts with the name of the command it documents followed by its section number in parentheses, like this: reboot(8). When you see something in this format in other documents, it’s telling you to read that man page in that section of the manual. Almost every topic has a man page. For example, to see the man page for the editor vi, type this command:

$ man vi

In response, you should see the following:

VI(1)      FreeBSD General Commands Manual           VI(1)

NAME
     ex, vi, view - text editors

SYNOPSIS
     ex [-FRrSsv] [-c cmd] [-t tag] [-w size] [file ...]
     vi  [-eFRrS] [-c cmd] [-t tag] [-w size] [file ...]
     view [-eFrS] [-c cmd] [-t tag] [-w size] [file ...]

DESCRIPTION
     vi is a screen-oriented text editor.  ex is a line-oriented text editor.
     ex and vi are different interfaces to the same program, and it is
     possible to switch back and forth during an edit session.  view is the
     equivalent of using the -R (read-only) option of vi.
:

The page starts with the title of the man page (vi) and the section number (1), and then it gives the name of the page. This particular page has three names: ex, vi, and view. Typing man ex or man view would take you to this same page.

Navigating Man Pages

Once you’re in a man page, pressing the spacebar or the PGDN key takes you forward one full screen. If you don’t want to go that far, pressing ENTER or the down arrow scrolls down one line. Typing b or pressing the PGUP key takes you back one screen. To search within a man page, type / followed by the word you’re searching for. You’ll jump down to the first appearance of the word, which will be highlighted. Typing n subsequently takes you to the next occurrence of the word.

This assumes that you’re using the default BSD pager, more(1). If you’re using a different pager, use that pager’s syntax. Of course, if you know so much about Unix that you’ve already set your preferred default pager, you’ve probably skipped this part of the book.

Finding Man Pages

New users often say that they’d be happy to read the man pages if they could find the right one. You can perform basic keyword searches on the man pages with apropos(1) and whatis(1). To search any man page name or description that includes the word you specify, use apropos(1). To match only whole words, use whatis(1). For example, if you’re interested in the vi command, you might try the following:

$ apropos vi
unvis(1) - revert a visual representation of data back to original form
vidcontrol(1) - system console control and configuration utility
vis(1) - display non-printable characters in a visual format
madvise, posix_madvise(2) - give advice about use of memory
posix_fadvise(2) - give advice about use of file data
--snip--

This continues for a total of 581 entries, which is probably far more than you want to look at. Most of these have nothing to do with vi(1), however; the letters vi just appear in the name or description. Device driver is a fairly common term in the manual, so that’s not surprising. On the other hand, whatis(1) gives more useful results in this case.

$ whatis vi
vi, ex, view, nex, nvi, nview(1) - text editors
$

We get only one result, clearly with relevance to vi(1). On other searches, apropos(1) gives better results than whatis(1). Experiment with both and you’ll quickly learn how they fit your style.

The man -k command emulates apropos(1), while man -f emulates whatis(1).

Section Numbers and Man

You might find cases where a single command appears in multiple parts of the manual. For example, every man section has an introductory man page that explains the contents of the section. To specify a section to search for a man page, give the number immediately after the man command.

$ man 3 intro

This pulls up the introduction to section 3 of the manual. I recommend you read the intro pages to each section of the manual, if only to help you understand the breadth and depth of information available.

Man Page Contents

Man pages are divided into sections. While the author can put just about any heading he or she likes into a man page, several are standard. See mdoc(7) for a partial list of these headings as well as other man page standards:

• NAME gives the name(s) of a program or utility. Some programs have multiple names—for example, the vi(1) text editor is also available as ex(1) and view(1).
• SYNOPSIS lists the possible command line options and their arguments, or how a library call is accessed. If I’m already familiar with a program but just can’t remember the option I’m looking for, I find that this header is sufficient to remind me of what I need.
• DESCRIPTION contains a brief description of the program, library, or feature. The contents of this section vary widely depending on the topic, as programs, files, and libraries all have very different documentation requirements.
• OPTIONS gives a program’s command line options and their effects.
• BUGS describes known problems with the code and can frequently save a lot of headaches. How many times have you wrestled with a computer problem only to learn that it doesn’t work the way you’d expect under those circumstances? The goal of the BUGS section is to save you time by describing known errors and other weirdnesses.¹
• EXAMPLES gives sample uses of the program. Many programs are very complicated, and a couple samples of how they’re used clarify more than any list of options possibly can.
• HISTORY shows when the command or code was added to the system and, if it is not original to FreeBSD, where it was drawn from.
• SEE ALSO is traditionally the last section of a man page. Remember that Unix is like a language and the system is an interrelated whole. Like duct tape, the SEE ALSO links hold everything together.

If you don’t have access to the manual pages at the moment, many websites offer them. Among them is the main FreeBSD website.

FreeBSD.org

The FreeBSD website (http://www.freebsd.org/) contains a variety of information about general FreeBSD administration, installation, and management. The most useful portions are the Handbook, the FAQ, and the mailing list archives, but you’ll also find a wide number of articles on dozens of topics. In addition to documents about FreeBSD, the website contains a great deal of information about the FreeBSD Project’s internal management and the status of various parts of the Project.

Web Documents

The FreeBSD documentation is divided into articles and books. The difference between the two is highly arbitrary: as a rule, books are longer than articles and cover broader topics, while articles are short and focus on a single topic. The two books that should most interest new users are the Handbook and the Frequently Asked Questions (FAQ).

The Handbook is the FreeBSD Project’s tutorial-style manual. It is continuously updated, describes how to perform basic system tasks, and is an excellent reference when you’re first starting a project. I deliberately chose not to include some topics in this book because they have adequate coverage in the Handbook.

The FAQ is designed to provide quick answers to the questions most frequently asked on the FreeBSD mailing lists. Some of the answers aren’t suitable for inclusion in the Handbook, while others just point to the proper Handbook chapter or article.

Several other books cover a variety of topics, such as The FreeBSD Developers’ Handbook, The Porter’s Handbook, and The FreeBSD Architecture Handbook.

Of the 50 or so articles available, some are kept only for historical reasons (such as the original BSD 4.4 documentation), while others discuss the subtleties of specific parts of the system, such as serial ports or building filtering bridges.

On the other hand, the official documentation is also pruned. The Handbook and FAQ cover the current FreeBSD releases, and the documentation team mercilessly prunes obsolete information. If you want to know exactly what works with current FreeBSD, go to the Handbook.

These documents are very formal, and they require preparation. As such, they always lag a bit behind the real world. When a new feature is first rolled out, the appropriate Handbook entry might not appear for weeks or months. If the web documentation seems out of date, your best resource for up-to-the-minute answers is the mailing list archive.

The Mailing List Archives

Unless you’re really on the bleeding edge, someone has probably struggled with your problem before and posted a question about it to the mailing lists. After all, the archives go back to 1994 and contain millions of messages. The only problem is that there are millions of pieces of email, any one of which might contain the answer you seek. While the FreeBSD.org website has its own search engine, you can also use any other search engine that indexes https://lists.FreeBSD.org/.

When reviewing the mailing list archives, be sure to check the date. The mailing list is forever. A discussion of hardware problems from 1995 might help you feel that you’re part of a long history of sysadmins that have struggled with cruddy mainboards,² but it probably won’t help you solve the issue with your brand new server. These ancient messages are basically undead documentation, rising from the grave to give you false hope. They’re part of the Project’s history, though, and won’t be purged.

The Forums

Like many other open source projects, FreeBSD has an online forum, https://forums.FreeBSD.org/. A forum is much like a mailing list designed for the web, except that quite a few of us old geezers don’t much care for them. You can find many good discussions and instructions on the forums, however, and they’re a valuable information source.

Many people have also posted lengthy tutorials on the forums. Forum-based tutorials should properly go in the Handbook or an official article, but nobody’s done the work to move them over yet. Read the discussion about such tutorials before following them; people will often point out errors or exceptions, or comment that the whole tutorial is obsolete with a newer version of FreeBSD. If you want to get involved in FreeBSD, converting these tutorials into official documentation would be a great place to start.

The forums have less of a problem with truly old information, but only because they became official in 2009. When the forums reach a quarter-century old, they’ll have the same amount of undead documents. By then, though, an even more whiz-bang discussion system will have come along—or maybe, just maybe, we’ll have a better way of indexing and retrieving useful information from online discussions.

Other Websites

FreeBSD’s users have built a plethora of websites that you might check for answers, help, education, products, and general hobnobbing. Almost every aggregation site such as lobste.rs and Reddit has a FreeBSD section, where you can get links to new posts and articles. Following those links takes you to a whole world of blogs. Also, many hosting companies include extensive FreeBSD tutorials. While these are meant for the company’s customers, they’re most often perfectly useful for everyone.

One of the most popular FreeBSD sites is FreshPorts, https://www.FreshPorts.org/. FreshPorts tracks changes to FreeBSD. Originally, it tracked changes to add-on software available via the Ports system (which I’ll discuss in Chapter 16), but it quickly expanded to cover changes to the base system, the documentation, the website, and more. If you’re looking to see how FreeBSD has changed, start with FreshPorts.

The FreeBSD Journal (https://www.freebsdfoundation.org/journal/) is a project of the FreeBSD Foundation. It’s a commercial project, but your subscription fees go directly to the Foundation. Journal articles are reviewed by some of the most experienced FreeBSD developers and users, so the articles can be considered authoritative. Though as an editorial board member, I’m biased.

The FreeBSD Foundation (https://www.freebsdfoundation.org/) supports FreeBSD development, and I’d encourage everyone to throw a few bucks their way. I find pages like the project list useful. This lists all of the development projects that the FreeBSD Foundation has financially supported and their current state. Looking through it when writing this paragraph, I learned that FreeBSD has added wireless mesh support and multipath TCP. I don’t need either of these right now, but who knows what will happen next week?

Look around, and you’ll find your own favorites.

Using FreeBSD Problem-Solving Resources

Okay, let’s investigate a common question with FreeBSD resources. People have asked about FreeBSD’s cryptographic support for decades, so let’s figure out some definitive answers about what cryptographic functions it does and does not support.

Cryptography is a complicated topic, and searching for information on it is complicated by the different ways it’s referred to. It might show up as “cryptography,” “cryptographic,” the informal “crypto,” or related words, like “encrypt.” We’ll try any and all of these.

Checking the Handbook and FAQ

Skimming the Handbook’s table of contents brings up entries for “Encrypting Disk Partitions” and “Encrypting Swap,” which certainly seem relevant. The FAQ points to these topics as well. That’s a start. Those entries will guide you to appropriate man pages, which will lead you to more man pages.

Checking the Man Pages

Let’s query the man pages for cryptography, using both apropos and whatis.

$ apropos cryptography
krb5_allow_weak_crypto, krb5_cksumtype_to_enctype...
crypto, cryptodev(4) - user-mode access to hardware-accelerated cryptography

This is only two entries, but the first entry is extremely long. Anything that starts with krb5 is related to Kerberos authentication, which is a critical feature for large networks and does involve cryptography, so that’s relevant. The second entry is kind of interesting, though: there’s a man page for crypto(4) and cryptodev(4). (Both words point to the same man page in section 4, so the number only appears in one search result.) Let’s look at the man page.

$ man crypto
crypto(3)                  OpenSSL                 crypto(3)

NAME
       crypto - OpenSSL cryptographic library

SYNOPSIS
DESCRIPTION
       The OpenSSL crypto library implements a wide range of cryptographic
       algorithms used in various Internet standards. The services provided by
       this library are used by the OpenSSL implementations of SSL, TLS and
       S/MIME, and they have also been used to implement SSH, OpenPGP, and
       other cryptographic standards.

OVERVIEW
       libcrypto consists of a number of sub-libraries that implement the
       individual algorithms.
--snip--

Hang on—OpenSSL is not a cryptographic device. Something obviously isn’t right. Look closely at this man page; it’s from section 3 of the manual, the C Libraries section. You need to search the manual for other entries containing crypto. Let’s try the more specific whatis(1) search.

$ whatis crypto
crypto, cryptodev(4) - user-mode access to hardware-accelerated cryptography
crypto(7) - OpenCrypto algorithms
crypto, crypto_dispatch, crypto_done, crypto_freereq, crypto_freesession, crypto_get_driverid, crypto_getreq, crypto_kdispatch, crypto_kdone, crypto_kregister, crypto_newsession, crypto_register, crypto_unblock, crypto_unregister, crypto_unregister_all, crypto_find_driver(9) - API for cryptographic services in the kernel

Bingo! We have three crypto man pages: one in section 4, section 7, and section 9. This gives us information about the interface for programs accessing hardware cryptographic features, a list of supported algorithms, and a description of the kernel’s cryptographic services. Reading these will give you a good grounding in FreeBSD’s cryptography support. The SEE ALSO links in each will steer you to more information. You can now fill your brain with crypto.

Mailing Lists Archives and Forums

While the mailing lists and forums are different platforms, you search them both in similar ways. You could use the FreeBSD website search engine to search the mailing list archives, but I prefer either Google or DuckDuckGo. A search for crypto site:lists.FreeBSD.org spits out a whole bunch of results, as does crypto site:forums.FreeBSD.org.

The problem with using these sorts of discussions for general orientation on a topic is that folks plunge into nitty-gritty details. You won’t get an overview of cryptography, but you’ll find details on this algorithm used with that hardware acceleration on that version of FreeBSD. You can get a very detailed answer if you craft a very detailed search.

Using Your Answer

Any answer you get for a question will make certain assumptions. If you’re talking about cryptography, the discussion assumes you know why crypto is important, how plaintext differs from ciphertext, and what keys are. This is fairly typical of the level of expertise required for basic problems. If you get an answer that is beyond your comprehension, you need to do the research to understand it. While an experienced developer or system administrator is probably not going to be interested in explaining public key encryption, he or she might be willing to point you to a web page that explains them if you ask nicely. Always remember that people have been asking that question in relation to FreeBSD since 1994 and in relation to Unix for close to half a century.

Asking for Help

When you finally decide to ask for help, do so in a way that allows people to actually provide the assistance you need. No matter whether you prefer email or a forum, you must include all the information you have at your disposal. There’s a lot of suggested information to include, and you might think you can skip some or all of it. If you slack off and fail to provide all the necessary information, though, one of the following things will happen:

• Your question will be ignored.
• You’ll receive a barrage of email asking you to gather this information.

On the other hand, if you actually want help solving your problem, include the following pieces of information in your message:

• A complete problem description. A message like How do I make my cable modem work? only generates a multitude of questions: What do you want your modem to do? What kind of modem is it? What are the symptoms? What happens when you try to use it? How are you trying to use it?
• The output of uname -a. This gives the operating system version and platform.
• Any error output. Be as complete as possible, and include any messages from the console or from your logs, especially /var/log/messages and any application-specific logs. Messages about hardware problems should include a copy of /var/run/dmesg.boot.

It’s much better to start with a message like “My cable modem won’t connect to my ISP. The modem is a BastardCorp v.90 model BOFH667. My OS is version 12.2 on a quad-core Opteron. Here’s the contents of /var/log/messages and /var/run/dmesg.boot from when I try to connect. When I manually run dhclient, I get these messages.” You’ll skip a whole round of discussions with a message like this, and you’ll get better results more quickly.

Composing Your Message

First, be polite. People often say things online that they wouldn’t dream of saying to someone’s face. These lists are staffed by volunteers who are answering your message out of sheer kindness. Before you click that Send or Submit button, ask yourself, Would I be late for my dream date to answer this message? The fierce attitude that is occasionally necessary when working with corporate telephone-based support only makes these knowledgeable people delete your emails unread or flat-out block your account on the forum. Their world doesn’t have to include surly jerks. Screaming until someone helps you is a valuable skill when dealing with commercial software support, but it will actively hurt your ability to get support from any open source project.

No matter whether you choose the forums or email, stay on topic. If you’re having a problem with X.org, check the X.org website. If your window manager isn’t working, ask the people responsible for the window manager. Asking the FreeBSD folks to help you with your Java Application Server configuration is like complaining to industrial machinery salespeople about your fast-food lunch. They might have an extra ketchup packet, but it’s not really their problem. On the other hand, if you want your FreeBSD system to no longer start the mail system at boot time, that’s a FreeBSD issue.³

Sending Email

FreeBSD developers tend to use mailing lists, not the forums. This means that the mailing lists can get you attention from people who know more about the system, but it also means that you need to follow the etiquette for that environment.

Send plaintext email, not HTML. Many FreeBSD developers read their email with a text-only email program, such as Mutt. Such programs are very powerful tools for handling large amounts of email, but they do not display HTML messages without contortions. To see for yourself what this is like, install /usr/ports/mail/mutt and read some HTML email with it. If you’re using a graphic mail client, such as Microsoft Outlook, either send your email in plaintext or make sure that your messages include both a plaintext and an HTML version. All mail clients can do this; it’s just a question of discovering where your GUI hides the buttons. What’s more, be sure to wrap your text at 72 characters. Sending HTML-only email or email without decent line-wrapping is an invitation to have your email discarded unread.

Harsh? Not at all, once you understand whom you’re writing to. Most email clients are poorly suited to handling thousands of messages a day, scattered across dozens of mailing lists, each containing a score of simultaneous conversations. The most popular email clients make reading email easy, but they do not make it efficient; when you get that much email, efficiency is far more important than ease. As most people on those mailing lists are in a similar situation, plaintext mail is very much the standard for them.

Top-posting replies to an email is discouraged. Make any comments inline with the discussion to retain context.

On a similar note, most email attachments are unnecessary. You do not need to use OpenPGP on messages sent to a public mailing list, and those business-card attachments just demonstrate that you aren’t a system administrator. Don’t use a long email signature. The standard for email signatures is four lines. That’s it—four lines, each no longer than 72 characters.⁴ Long ASCII art signatures are definitely out.

When you’ve composed your nicely detailed and polite question, send it to [email protected]. Yes, there are other FreeBSD mailing lists, some of which are probably dedicated to what you’re having trouble with. As a new user, however, your question is almost certainly best suited to the general questions mailing list. I’ve lurked on many of the other mailing lists for a decade now and have yet to see a new user ask a question on any of them that wouldn’t have been better served by FreeBSD-questions. Generally, the questioner is referred back to FreeBSD-questions anyway. If your question needs to be asked elsewhere, someone will tell you.

This goes back to the first point about politeness. Sending a message to the architectural mailing list asking about what architectures FreeBSD runs on is only going to annoy the people who are trying to work on architectural issues. You might get an answer, but you won’t make any friends. Conversely, the people on FreeBSD-questions are there because they’re volunteering to help people just like you. They want to hear your intelligent, well-researched, well-documented questions. Quite a few are FreeBSD developers, and some are even Core members. Others are slightly more experienced users who have transcended what you’re going through now and actively want to give you a hand up.

Forum Posting

The forums have a different population than the mailing lists. Some developers hang out there, but not as many as on the mailing lists. The people on the forums are actively interested in helping you with your problems, though.

Forums are somewhat easier than the mailing lists. You can post only in formats the website supports. There are no concerns about top-posting versus inline posting or unreadable HTML. This ease is part of their popularity. If you get deeper into FreeBSD, though, you’ll eventually want to join mailing lists.

But no matter which venue you choose, politeness is vital.

Responding to Email

Your answer might be a brief note with a URL or even just two words: man such-and-such. If that’s what you get, that’s where you need to go. Don’t ask for more details until you’ve actually studied that resource. If you have a question about the contents of the reference you’re given, or if you’re confused by the reference, treat it as another problem. Narrow down the source of your confusion, be specific, and ask about that. Man pages and tutorials are not perfect, and some parts appear contradictory or mutually exclusive until you understand them.

Finally, follow through. If someone asks you for more information, provide it. If you don’t know how to provide it, learn how. If you develop a bad reputation, nobody will want to help you.

The Internet Is Forever

Those of us who were on the internet back in the ’80s remember when we treated it as a private playground. We could say whatever we wanted, to whomever we wanted. After all, it was purely ephemeral. Nobody was keeping this stuff; like CB radio, you could be a total jackass and get away with it.

All those early Usenet discussions? Yeah, Google recovered them and put them online. Our beliefs were the exact opposite of true.

Potential employers, potential dates, even family members might scan the internet for your postings to mailing lists or message boards, trying to learn what sort of person you are. I’ve rejected hiring more than one person based on their postings to mailing lists and discussion boards. I want to work with a system administrator who sends polite, professional messages to support forums, not childish and incoherent rants without sufficient detail to offer any sort of guidance. And I’d think a lot less of my in-laws if I stumbled across a message from one of them on some message board where they acted like fools. FreeBSD discussions are widely archived; choose your words well, because they will haunt you for decades.

Now that you know how to get more help when things go wrong, let’s install FreeBSD.