% dmesg > /tmp/dmesg.out
FreeBSD FTP server. You may also want to Search the FAQ.
As is usual with FAQs, this document aims to cover the most frequently asked questions concerning the FreeBSD mailing lists (and of course answer them!). Although originally intended to reduce bandwidth and avoid the same old questions being asked over and over again, FAQs have become recognized as valuable information resources.
This document attempts to represent a community consensus, and as such it can never really be authoritative. However, if you find technical errors within this document, or have suggestions about items that should be added, please either submit a PR, or email the FreeBSD documentation project mailing list. Thanks.
The FreeBSD mailing lists serve as the primary communication channels for the FreeBSD community, covering many different topic areas and communities of interest.
This depends on charter of each individual list. Some lists are more oriented to developers; some are more oriented towards the FreeBSD community as a whole. Please see this list for the current summary.
Again, this depends on charter of each individual list. Please read the charter of a mailing list before you post to it, and respect it when you post. This will help everyone to have a better experience with the lists.
If after reading the above lists, you still do not know which mailing list to post a question to, you will probably want to post to freebsd-questions (but see below, first).
Also note that the mailing lists have traditionally been open to postings from non-subscribers. This has been a deliberate choice, to help make joining the FreeBSD community an easier process, and to encourage open sharing of ideas. However, due to past abuse by some individuals, certain lists now have a policy where postings from non-subscribers must be manually screened to ensure that they are appropriate.
You can use the Mailman web interface to subscribe to any of the public lists.
You can use the same interface as above; or, you can follow the instructions that are at the bottom of every mailing list message that is sent.
Please do not send unsubscribe messages directly to the public lists themselves. First, this will not accomplish your goal, and second, it will irritate the existing subscribers, and you will probably get flamed. This is a classical mistake when using mailing lists; please try to avoid it.
Yes. Threaded archives are available here.
Yes. See the Mailman web interface.
Participation in the mailing lists, like participation in any community, requires a common basis for communication. Please make only appropriate postings, and follow common rules of etiquette.
You have already taken the most important step by reading this document. However, if you are new to FreeBSD, you may first need to familiarize yourself with the software, and all the social history around it, by reading the numerous books and articles that are available. Items of particular interest include the FreeBSD Frequently Asked Questions (FAQ) document, the FreeBSD Handbook, and the articles How to get best results from the FreeBSD-questions mailing list, Explaining BSD, and FreeBSD First Steps.
It is always considered bad form to ask a question that is already answered in the above documents. This is not because the volunteers who work on this project are particularly mean people, but after a certain number of times answering the same questions over and over again, frustration begins to set in. This is particularly true if there is an existing answer to the question that is already available. Always keep in mind that almost all of the work done on FreeBSD is done by volunteers, and that we are only human.
Postings must be in accordance with the charter of the mailing list.
Personal attacks are discouraged. As good net-citizens, we should try to hold ourselves to high standards of behavior.
Spam is not allowed, ever. The mailing lists are actively processed to ban offenders to this rule.
Please wrap lines at 75 characters, since not everyone uses fancy GUI mail reading programs.
Please respect the fact that bandwidth is not infinite. Not everyone reads email through high-speed connections, so if your posting involves something like the content of config.log or an extensive stack trace, please consider putting that information up on a website somewhere and just provide a URL to it. Remember, too, that these postings will be archived indefinitely, so huge postings will simply inflate the size of the archives long after their purpose has expired.
Format your message so that it is legible, and PLEASE DO NOT SHOUT!!!!!. Do not underestimate the effect that a poorly formatted mail message has, and not just on the FreeBSD mailing lists. Your mail message is all that people see of you, and if it is poorly formatted, badly spelled, full of errors, and/or has lots of exclamation points, it will give people a poor impression of you.
Please use an appropriate human language for a particular mailing list. Many non-English mailing lists are available.
For the ones that are not, we do appreciate that many people do not speak English as their first language, and we try to make allowances for that. It is considered particularly poor form to criticize non-native speakers for spelling or grammatical errors. FreeBSD has an excellent track record in this regard; please, help us to uphold that tradition.
Please use a standards-compliant Mail User Agent (MUA). A lot of badly formatted messages come from bad mailers or badly configured mailers. The following mailers are known to send out badly formatted messages without you finding out about them:
Try not to use MIME: a lot of people use mailers which do not get on very well with MIME.
Make sure your time and time zone are set correctly. This may seem a little silly, since your message still gets there, but many of the people on these mailing lists get several hundred messages a day. They frequently sort the incoming messages by subject and by date, and if your message does not come before the first answer, they may assume that they missed it and not bother to look.
A lot of the information you need to supply is the output of programs, such as dmesg(8), or console messages, which usually appear in /var/log/messages. Do not try to copy this information by typing it in again; not only it is a real pain, but you are bound to make a mistake. To send log file contents, either make a copy of the file and use an editor to trim the information to what is relevant, or cut and paste into your message. For the output of programs like
dmesg, redirect the output to a file and include that. For example,
% dmesg > /tmp/dmesg.out
This redirects the information to the file /tmp/dmesg.out.
When using cut-and-paste, please be aware that some such operations badly mangle their messages. This is of particular concern when posting contents of Makefiles, where
tab is a significant character. This is a very common, and very annoying, problem with submissions to the Problem Reports database. Makefiles with tabs changed to either spaces, or the annoying
=3B escape sequence, create a great deal of aggravation for committers.
Please include relevant text from the original message. Trim it to the minimum, but do not overdo it. It should still be possible for somebody who did not read the original message to understand what you are talking about.
This is especially important for postings of the type "yes, I see this too", where the initial posting was dozens or hundreds of lines.
Use some technique to identify which text came from the original message, and which text you add. A common convention is to prepend “>” to the original message. Leaving white space after the “>” and leaving empty lines between your text and the original text both make the result more readable.
Please ensure that the attributions of the text you are quoting is correct. People can become offended if you attribute words to them that they themselves did not write.
Please do not
top post. By this, we mean that if you are replying to a message, please put your replies after the text that you copy in your reply.
A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?
(Thanks to Randy Bush for the joke.)
Participation in the mailing lists, like participation in any community, requires a common basis for communication. Many of the mailing lists presuppose a knowledge of the Project’s history. In particular, there are certain topics that seem to regularly occur to newcomers to the community. It is the responsibility of each poster to ensure that their postings do not fall into one of these categories. By doing so, you will help the mailing lists to stay on-topic, and probably save yourself being flamed in the process.
The best method to avoid this is to familiarize yourself with the mailing list archives, to help yourself understand the background of what has gone before. In this, the mailing list search interface is invaluable. (If that method does not yield useful results, please supplement it with a search with your favorite major search engine).
By familiarizing yourself with the archives, not only will you learn what topics have been discussed before, but also how discussion tends to proceed on that list, who the participants are, and who the target audience is. These are always good things to know before you post to any mailing list, not just a FreeBSD mailing list.
There is no doubt that the archives are quite extensive, and some questions recur more often than others, sometimes as followups where the subject line no longer accurately reflects the new content. Nevertheless, the burden is on you, the poster, to do your homework to help avoid these recurring topics.
bikeshed is a small outdoor shelter into which one may store one’s two-wheeled form of transportation. However, in FreeBSD parlance, the term refers to topics that are simple enough that (nearly) anyone can offer an opinion about, and often (nearly) everyone does. The genesis of this term is explained in more detail in this document. You simply must have a working knowledge of this concept before posting to any FreeBSD mailing list.
More generally, a bikeshed is a topic that will tend to generate immediate meta-discussions and flames if you have not read up on their past history.
Please help us to keep the mailing lists as useful for as many people as possible by avoiding bikesheds whenever you can. Thanks.
Original author of most of the material on mailing list etiquette, taken from the article on How to get best results from the FreeBSD-questions mailing list.
Creation of the rough draft of this FAQ.