Hi, some time ago, we made German flyers because the current ones were fairly outdated (as well as the International ones). They are intended for the 'switcher' from Linux to NetBSD. Anyway, here's a translation. As you can see, I'm no native speaker nor much into the system, so I'd like to see these flyers corrected. Regards, Julian PS: No PDFs attached, they would be too large (about 100KB each). You need the NetBSD logo from the website for compiling, then called "NetBSD.png". You can find the pdf versions on http://komkon2.de/nbflyer/en-wickelfalz.pdf http://komkon2.de/nbflyer/en-wechsel.pdf http://komkon2.de/nbflyer/en-tipps.pdf
\documentclass[notumble,nofoldmark]{leaflet}
\usepackage[nenglish]{babel}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{hyperref}
\begin{document}
% Titelseite - enthält Logo und Einleitung
\vspace*{\fill}
\begin{center}
\includegraphics[width=.7\textwidth ]{NetBSD}
\huge \bfseries tips and tricks for NetBSD newcomers
\end{center}
Nowadays there are only few people who start using Unix by using a shell. Most
people install their operating system with a graphical installer, in most cases
GNU/Linux, the most-widespread unix.
This introduction is made for people who already used Linux, who know about its
internals and the principals of the system, and provides a few tips and tricks
how to switch to NetBSD, and what you have to consider when switching.
Just to stay clear: In the following text, we shall use the term \emph{Linux}
equivalently to the term \emph{GNU/Linux}.
\vspace*{\fill}
% Erste Innenseite - zusammen mit zweiter Innenseite das erste, was der Leser
beim Aufklappen sieht
\newpage
\section{Documentation}
\subsection{Notation}
In the Linux world you will rarely see a notation not only referring to its
name, but also to its manpage category. In the BSD world, it is usual to do
exactly that by appending the category number in brackets after the name.
Thus, when people would usually say \emph{Just use sh!}, you'd \emph{translate}
it to \emph{Just use sh(1)!} when they want you to use the shell.
In the same way, as packages in the BSD world are organized in categories, you
will mostly see references to the category prepended to the name, e.g. you'll
be told to install {\ttfamily www/firefox} instead of just \emph{firefox},
where {\ttfamily www} is the pkgsrc-category of firefox (see below).
This notation helps ommitting ambigous descriptions, and you usually can
determine whether you are talking about a kernel driver, a userland tool,
configuration file or a library by just looking at the category the object is
meant to be in.
\subsection{The guide}
As all other BSDs, NetBSD has a central handbook, called \emph{the NetBSD
Guide}. This guide can be seen as \emph{the} reference for the system,
containing a description of all important subsystems, introductions on how to
use them (e.g. hard disk encryption), and should be your first start if you
have a problem.
\subsection{The articles}
Of course there are several articles and howtos about specific NetBSD topics.
Though there is not \emph{the} central list with \emph{all} articles, you can
find many of them, especially the official ones, on the NetBSD website.
You should not only have a look at the website itself, but also at the
installation instructions for your specific platform, often containing
solutions for very specific problems you only have with that single machine.
For less static informations, also have a look at the NetBSD wiki.
% Dritte Innenseite - zusammen mit vierter Innenseite zur Vertiefung.
\newpage
\section{Generic tips}
\begin{itemize}
\item The configuration in NetBSD is mostly the same as with Linux or
any other Unix. All configuration files of the base system are in {\ttfamily
/etc}, and the ones of additional packaed software in {\ttfamily /usr/pkg/etc}.
The default values are often in {\ttfamily /etc/default} (not to be
confused with Debian using them for real configuration by the user). Data saved
here is usually overwritten by the configuration files of the user.s
\item {\ttfamily sysctl(7)} is an interface to set various parameters
of the kernel, mostly equivalent to Linux' procfs. Though Linux also has a
command {\ttfamily sysctl} doing the same work, in Linux it is only another
interface to procs.
sysctl in NetBSD in generally tidier and contains descriptions of the
options and parameters. With the tool {\ttfamily sysctl(8)} you can show and
set these values (and show descriptions).
An exact description of some important sysctls can be found in the
{\ttfamily sysctl(7)} manpage. Having a look here might even help experienced
users fine-tune their kernel parameters.
\item Not only for configuration, but also for showing system
information (as the processor model, system version, installed memory, etc.),
sysctl is sufficient.
With {\ttfamily sysctl -a} you can show all sysctl parameters currently
in use, with {\ttfamily sysctl -d OPTION} you can see the description of a
single parameter.
\item A useful equivalent to Linux' lspci is {\ttfamily pcictl(8)}.
With {\ttfamily pcictl /dev/pci0 list} you can see a list of all PCI devices on
the first PCI bus (on modern x86, usually the only one).
\item To see informations the kernel printed out while booting (but are
now lost due to dmesg being spammed by something else), you should have a look
at {\ttfamily /var/run/dmesg.boot}. Here all the informations from the boot,
e.g. your processor model, found devices on your system, are listed.
When you report a hardware problem it is always helpful to append the
dmesg of your system.
\item The NetBSD Guide has several chapters about building your system
from sources, which is with NetBSD especially easy compared to all other
platforms and operating systems. You can build NetBSD on nearly any Unix and
any platform for any platform, cross-compile them all without hassle, so you
don't have to use your weak old machine for building their own current system.
\item NetBSD calls most of its devices after its producer, as is the
classical Unix way. You'll notice that especially when having a look at the
network interfaces. Instead of being called eth0, eth1, etc., they're called
by their driver, e.g. wm0. The wd0 for PATA hard disks has its origins here,
too.
\item If you have a NetBSD CD, but want to install your system from
USB, you can use the tool {\ttfamily sysutils/mkmemstick}. Being used upon a
NetBSD CD image it will create a ready-to-boot image to be dd'ed to your USB
flash drive.
\item Equivalently to Linux' logrotate, under NetBSD you have
{\ttfamily newsyslog(8)}, being configured in {\tfamily /etc/newsyslog.conf}.
It is activated by default.
\item To understand where you will get best help for your problems, or
where to start when encountering a problem, it is useful to understand the
organsation and development model of NetBSD. We just want to stress this here,
on \url{netbsd.org/contrib} you will find more about this topic.
\item NetBSD sends daily mails. You should read them from time to time,
they contain informations about e.g. security holes, hard disk failures and
other important informations.
\item You should always, when you have a computer with an internet
connection, modify your {\ttfamily /etc/daily.conf} to contain the line
{\ttfamily fetch\_pkg\_vulnerabilities=YES}, which downloads a list of security
issues every day and compares it to your installed packages.
\end{itemize}
% Vierte Innenseite, gleichwertig zur dritten Innenseite
% Die dritte Seite floatet einfach über auf die vierte. Es werden ohnehin
immer beide gleichzeitig gesehen (die eine verdeckt die andere), daher kann man
das so machen.
%\newpage
% Zweite Innenseite, wird mit der ersten Innenseite beim Aufklappen als erstes
gesehen
\newpage
\section{Community/Bugreports}
When the documentation doesn't help anymore, you should ask in the community or
report a bug. There are several methods to do so, the fastest ones being
described here:
\subsection{Mailinglists}
Mostly all of the NetBSD communication is done via mailing lists. You can
subscribe to them (most of them don't have too much traffic, and nearly no dumb
traffic anyway) or read all the archives in the web or in the usenet.
\subsection{Announcements}
For security holes and general informations like new releases, there is the
list \emph{netbsd-announce}. There is very few traffic on this list (about one
per month), and really only the really important things. You should subscribe
to this list if you use NetBSD anywhere.
\subsection{Bug Reports}
If you encounter a problem, you can fill a PR (problem report) about this.
First you should have a look at the PR database, if there was somebody else who
already reported it and perhaps found a workaround. If the bug wasn't already
reported, you can simply report it with the web formular or with the NetBSD
tool {\ttfamily send-pr(1)} (being in the base distribution).
\subsection{IRC}
Decentrally organised, there are NetBSD channels in the larg IRC networks
EFnet, IRCnet and Freenode (the largest one) with the name {\ttfamily #netbsd}.
\subsection{Events}
NetBSD is represented on many events in the Open Source scene. If you want to
get in touch with other NetBSD people, watch out for NetBSD booths or go to the
special BSD events, where NetBSD is always represented.
% Rückseite, ist gedacht für Adressen oder abschlie�ende Informationen
\newpage
\section{Nützliche Links}
%{\small
\begin{itemize}
\item NetBSD website: \url{netbsd.org}
\item NetBSD guide: \url{netbsd.org/docs/guide/en}
\item NetBSD articles: \url{netbsd.org/docs}
\item NetBSD manpages: \url{man.netbsd.org}
\item NetBSD wiki: \url{wiki.netbsd.org}\\
\item Search bugs:\\ \url{netbsd.org/support/query-pr.html}
\item Report bugs:\\ \url{netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd}\\
\item Install additional software:\\
\url{netbsd.org/docs/guide/en/chap-boot.html#chap-boot-pkgsrc}
\item NetBSD guide -- compile NetBSD:\\
\url{netbsd.org/docs/guide/en/part-compile.html}
\item NetBSD on flash drive:\\
\url{www.bsdnexus.com/NetBSD_onastick/install_guide.php}
\item pkgsrc guide: \url{netbsd.org/docs/pkgsrc}
\item pkgsrc make targets:\\ \url{wiki.netbsd.org/pkgsrc/targets}
\item development/contribution: \url{netbsd.org/contrib}\\
\item mailinglists: \url{netbsd.org/mailinglists}
\item mailinglist archives: \url{mail-index.netbsd.org}
\item mailinglists on gmane:
\url{dir.gmane.org/index.php?prefix=gmane.os.netbsd}\\
\item NetBSD-related events:\\ \url{netbsd.org/gallery/events.html}
\item IRCNet: \url{ircnet.org}
\item Freenode: \url{freenode.net}
\end{itemize}
%}
\end{document}
\documentclass[notumble,nofoldmark]{leaflet}
%\documentclass{article}
\usepackage[nenglish]{babel}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{hyperref}
\begin{document}
% Titelseite - enthält Logo und Einleitung
\vspace*{\fill}
\begin{center}
\includegraphics[width=.7\textwidth ]{NetBSD}
\huge \bfseries NetBSD for newcomers
\end{center}
Nowadays there are only few people who start using Unix by using a shell. Most
people install their operating system with a graphical installer, in most cases
GNU/Linux, the most-widespread unix.
This introduction is made for people who already used Linux, who know about its
internals and the principals of the system, and provides a few tips and tricks
how to switch to NetBSD, and what you have to consider when switching.
Just to stay clear: In the following text, we shall use the term \emph{Linux}
equivalently to the term \emph{GNU/Linux}.
\vspace*{\fill}
% Erste Innenseite - zusammen mit zweiter Innenseite das erste, was der Leser
beim Aufklappen sieht
\newpage
\section{start scripts, init}
One of the greatest historical differences between BSD and the rest of the unix
world was its init system {\ttfamily init(8)}, the first application being run
by the kernel. It reads its configuration from the file {\ttfamily rc.conf(5)},
which is mostly the (de)activation of services (usually by {\ttfamily
servicename=YES}, e.g. {\ttfamily sshd=YES}).
In {\ttfamily /etc/rc.d} there are the rc scripts (equivalently to Linux'
{\ttfamily /etc/init.d}). Out of these, init builds a list of dependencies and
the order in which the services will be started.
Starting/stopping is as it is in Linux, just with the different path. So
{\ttfamily /etc/rc.d/sshd start} starts your sshd, analogous to {\ttfamily
start} there are the options {\ttfamily stop}, {\ttfamily status}, {\ttfamily
restart}.
If a service is not activated in your rc.conf, you have to prepend the action
by a {\ttfamily one}. So if you e.g. don't have {\ttfamily sshd=YES} in your
rc.conf, but you want to start your sshd once, you can do that wiht {\ttfamily
/etc/rc.d/sshd onestart}.
\section{Networking}
The networking of NetBSD is configured in the {\ttfamily rc.conf} as well, with
the keyword {\ttfamily ifconfig\_IFNAME}, where IFNAME is the interface name.
{\ttfamily defaultroute} sets your default gateway to its value, and {\ttfamily
hostname} specifies the hostname. Additional IP addresses can be specified with
{\ttfamily ifconfig\_IFNAME\_alias}. To get a thorough description, please see
the manpage {\ttfamily rc.conf(5)}.
To configure your network manually, you use {\ttfamily ifconfig(8)}, whose
differences to Linux' ifconfig are marginally. Additionally, it also has the
functionality of Linux 'iwconfig with some extra options.
Routes are set with {\ttfamily route(8)} as in Linux, but you should be careful
-- the BSD route varies greatly from its Linux brother. Much of its work can be
done with the tool {\ttfamily netstat(1)} as well, which in turn behaves mostly
like its Linux counterpart.
% Dritte Innenseite - zusammen mit vierter Innenseite zur Vertiefung
\newpage
\section{Package management}
When installing additional software on NetBSD, you have two possibilities:
Either you install binary packages from a repository, or compile them yourself.
Both ways are equivalent, the binary packages are just built in a standard way
pkgsrc would do it for you.
Additionally to this text, a short look on the according chapter in the NetBSD
guide is advisable. There is even a whole \emph{pkgsrc Guide}, explaining the
details of the package management.
\subsection{pkgsrc}
The system for managing source packages in NetBSD is called {\ttfamily pkgsrc}.
It originated in FreeBSDs \emph{ports}, but separated a long time ago and
nowadays is a neary platform- and machine-independent package management, which
can be used on many different Unixes and architectures, even as an unprivileged
user.
Usually, the pkgsrc sources are in {\ttfamily /usr/pkgsrc}, installing packages
to {\ttfamily /usr/pkg}, though both paths can be customized. In the
installation path, you have a structure close to the one in {\ttfamily /}: You
have {\ttfamily bin/}, {\ttfamily sbin/}, {\ttfamily etc/}, etc.
pkgsrc installs no packages outside its installation path. Thus, you have to
configure all additional software in {\ttfamily /usr/pkg/etc}. If you installed
a service, you can either copy its rc script from {\ttfamily
/usr/pkg/share/examples/rc.d} to {\ttfamily /etc/rc.d} or modify your rc
configuration to have this path as its {\ttfamily rc\_directory} as well.
pkgsrc is separated into categories like \emph{www}, \emph{chat}, \emph{mail},
etc., each of the names self-complaining, and inside these categories, you find
the packages.
To install a package, go into its directory (e.g. {\ttfamily misc/bsdstats}),
and then call {\ttfamily make install} to compile and install the package.
To search for a package, you can use {\ttfamily find(1)} ({\ttfamily cd
/usr/pkgsrc; find . -maxdepth 2 -name PKGNAME} if you are only search for the
package name, or simply {\ttfamily grep(1)}).
Each package directory contains the file {\ttfamily DESCR} with a description
of the package. So if you want to do a full-text search, you could do that by
{\ttfamily cd /usr/pkgsrc; grep STRING */*/DESCR}.
After installing a package, you should also clean up its working files by
typing {\ttfamily make clean clean-depends}. If you should ever have forgotten
that, you can also run these commands from the pkgsrc directory or from a
category directory, cleaning all subdirectories from your current point.
\subsection{Binary packages}
The package management itself (as pkgsrc is just the package source) consists
of the tools {\ttfamily pkg\_info(1)}, {\ttfamily pkg\_add(1)}, {\ttfamily
pkg\_admin(1)}, {\ttfamily pkg\_delete(1)} and {\ttfamily pkg\_create(1)}.
pkg\_add and pkg\_delete (de)install the package given to them as a parameter,
where you have to specify the whole name (including the version) for
pkg\_delete. pkg\_info lists all packages or prints informations about a
specific package (e.g. contained files, description, version, dependencies,
etc.). pkg\_admin has more generic tasks for the administration of the packages
and their database (in {\ttfamily /var/db/pkg}) and checking security issues.
\subsection{mk.conf}
pkgsrc is configured by the file {\ttfamily mk.conf(5)}. This files does not
exist by default, you have to create it. To see which options you can set to
configure a package, type in {\ttfamily make show-options} from a package
directory.
\subsection{Other tools}
There are several other tools simplifying package management. You can just
browse the pkgsrc category {\ttfamily pkgtools}, especially for tools like
{\ttfamily nih}, {\ttfamily pkg\_chk}, {\ttfamily pkgin}.
% Vierte Innenseite, gleichwertig zur dritten Innenseite
% Die dritte Seite floatet einfach über auf die vierte. Es werden ohnehin
immer beide gleichzeitig gesehen (die eine verdeckt die andere), daher kann man
das so machen. Das Paketmanagement muss irgendwo zwei Seiten Platz haben.
% Eigentlich hätten wir das Paketmanagement natürlich wichtiger, aber das ist
schwer zu machen, ohne sich dabei auf eine Seite zu beschränken.
%\newpage
% Zweite Innenseite, wird mit der ersten Innenseite beim Aufklappen als erstes
gesehen
\newpage
\section{Hard disks / block devices}
Unix was originally programmed for platforms different to Intel's x86, so it
traditionally had a \emph{disk label} instead of a Master Boot Record (MBR).
NetBSD still refers to these roots, and some platforms (e.g. sparc) still use
this disk label natively, and no mbr. Because of this tradition, there are
several differences when addressing block devices and partitions.
\subsection{Partitioning}
Though often you want to use {\ttfamily gpt(8)} for larger disks, you still
often encounter {\ttfamily disklabel(8)} being used on a disk.
You edit the disk label of a hard disk with the tool {\ttfamily disklabel(5)}.
You can directly write the disk label to the whole disk, if you don't want to
boot from it except the platform supports that (as sparc), or you can embed it
in a native partition of your platform (mostly MBR).
In this case, you create an MBR partition first, called \emph{slice}, and
inside a partition of this slice, you create a disk label. Such a disk label
contains up to 16 partitions, being enumerated with \emph{a}--\emph{n}.
Partition \emph{c} perhaps \emph{d} have a special meaning: \emph{c} will be
used for addressing the slice the disk label lies in, or in case of a
non-embedded disk label, the whole disk. \emph{d} then, if you have an embedded
disk label, addressed the whole hard disk.
\subsection{Raw Devices}
NetBSD distinguishes the abstraction layer you use the devices with, depending
on the device nodes you use. Each block device (in the following, say
{\ttfamily /dev/sd0} is either raw as a character device (with DMA)
addressable, then with an \emph{r} before (thus {\ttfamily /dev/rsd0}), or as a
block device with its usual name.
Thus you should always use the block device for mounting and such work, but for
operations under the file system you should use the raw device (e.g. to zero
out the disk by {\ttfamily dd of=/dev/rsd0d} instead of {\ttfamily rsd0} or
{\ttfamily sd0d}).
% Rückseite, ist gedacht für Adressen oder abschlie�ende Informationen
\newpage
\section{Monitoring}
\subsection{Monitoring tools}
NetBSD has several very powerful monitoring tools in its base distribution,
which Linux only has with its hard-to-use unified sar.
\begin{itemize}
\item {\ttfamily sysstat(1)} -- shows an overview of all possible data.
You can also rotate between some of them, or only show specific subsystems
\item {\ttfamily iostat(8)} -- shows statistics about I/O of hard
disks, terminals and CPU
\item {\ttfamily netstat(1)} -- shows several networking-related
informations, as open ports, routing tables, mostly equivalent to the Linux
version
\item {\ttfamily vmstat(1)} -- shows information about virtual memory
usage
\item {\ttfamily fstat(1)} and {\ttfamily sockstat(1)} -- equivalently
to lsof, fstat shows informations about open files, and sockstat about open
sockes
\end{itemize}
Though you can call all tools without parameters or option, you really should
have a look at its manpage, defining several options to customize the
monitoring.
\subsection{Periodic mails}
The standard contrab from NetBSD has three entries: {\ttfamily daily},
{\ttfamily weekly} and {\ttfamily monthly}, being called as often as their name
says.
They write mails and logs about memory and disk usage, system warnings,
security issues, login accounting, etc. You can configure them over their files
{\ttfamily daily.conf(5)}, {\ttfamily weekly.conf(5)} and {\ttfamily
monthly.conf(5)} respectively, to say which checks they shall do and what to
show.
You should at least have a short look at these mails, if you do not have any
other monitoring, as they might contain important informations about e.g. hard
disk failures in raid systems, critical security holes, etc. Especially if you
have a computer with an internet connection, this is recommendable.
\end{document}
\documentclass[notumble,nofoldmark]{leaflet}
\usepackage[nenglish]{babel}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{hyperref}
\begin{document}
% Title page - contains logo and short description
\vspace{4cm}
\begin{center}
{\huge \bfseries The NetBSD project}
{\large \scshape ``Of course it runs NetBSD''}
\vspace{1cm}
\includegraphics[width=\textwidth ]{NetBSD}
\vspace{1cm}
\end{center}
\subsection{What is NetBSD?}
NetBSD is one of the oldest, still active free Unixes. Different to Linux,
NetBSD has its roots in the original Unix from Bell Labs, and its origin in an
academic environment, which it left 1993 for an open environment; but this
professional direction has been preserved till today.
``Of course it runs NetBSD'' -- NetBSD is very vigilant about the cleanness and
portability of its code. It is running on many platforms other operating
systems abandoned years ago, no matter if it's a small HP Jornada palmtop or a
40kg DEC Alpha server -- on all these machines you can run an actual NetBSD
with actual software.
But especially for modern platforms NetBSD is well suited, being a modern, but
classical universal Unix, being useful as a desktop or server operating system.
% First inner side - together with the second one being the first page the
reader sees when unfolding the flyer.
\newpage
\subsection{NetBSD is continuity}
Compared to Linux, but also in comparison with other BSDs NetBSD is a very
\emph{conservative} operating system, not in the sense of being underdeveloped,
but in choosing its developments thoughtfully. NetBSD is like no other free
Unix following classical unix traditions and principles, resulting in a very
uniform handling.
Where other operating systems often try to implement as many features as
possible into every program they use, NetBSD is suspicious of these features
being reasonable and non-redundant, and not breaking the system's stability by
adopting unfinished software.
But even implemented features won't rot around without further maintenance, but
can also be abandoned after a while when they did not prove their usefulness,
open up security holes or their implementation is faulty or redundant.
NetBSD claims the entitlement of running on every hardware platform, but even
when only using a recent x86 system, you profit from that. Because of that, the
code is written with a great stress on its cleanness and potability and always
well documented.
But this does not slow development down, it just makes it possible to use
modern features on old computers, or even implement them without being forced
to handle code that would be hardware-specific on other OSs. Just recently a
new firewall -- {\ttfamily npf} -- was developed, to overcome the disadvantages
of existing firewalls, unique userland virtualisation technics like {\ttfamily
rump}, and Lua being imported into the kernel make not only the most recent
computers, but even old forgotten machines competetive against the market
leaders with modern servers.
Especially the uniformity of kernel and userland demarcate NetBSD from Linux.
Where GNU/Linux is a combination of many small parts (e.g. GNU), a kernel, and
several companies delivering third party modules, NetBSD's parts all come from
the same team, ensuring the components work together and are all handled the
same way.
% Third inner page - together with fourth side used for digging more into the
topic.
\newpage
\subsection{For all platforms}
NetBSD's Slogan is ``Of course it runs NetBSD'', and that points out the
greatest dogma of NetBSD. Even when Linux supports many different platforms,
there's no uniform distribution for them. For many platforms you need a
specific distribution, each of them being different.
% 11 - 57
NetBSD provides a uniform operating system with uniform userland (it's the
same), uniform package management and actual development on more than 10
architectures and more than 55 platforms. You won't get a stripped-down version
of NetBSD on an older platform, but always the whole complete system without
limitations.
Especially for this reason NetBSD is often used in embedded computers: Porting
NetBSD to a new platform is in many cases only the adjustment of a few drivers,
or the platform is even there already. And if there is a new platform, NetBSD's
separation makes it as easy as possible to only have to implement the
hardware-specific code and no other subsystems.
Additionally, NetBSD provides paravirtualisation with Xen, being host, but also
client system, bringing you the possibility of running other operating systems
as clients or being a client system on another host machine, too.
\subsection{Simple possibility for crosscompiling}
NetBSD runs on many very old platforms, which are too weak to compile greater
amounts of code in finite time. That's why NetBSD developed a very mature and
comfortable system to crosscompile the whole operating system, or just the
crosscompiling toolchain itself.
Generally, you can compile on nearly every Unix (including MacOSX) and and
every platform NetBSD and toolschains for every supported platform, even as
unprivileged user. The script {\ttfamily build.sh} would e.g. build the
toolchain for sparc simply with {\ttfamily build.sh -m sparc tools}, and just
with choosing another target (so {\ttfamily build.sh -m sparc distribution})
you can just switch to compiling the whole operating systems, without being
required to spend any more work on it.
% Fourth inner page, equal to the third inner page.
\newpage
\subsection{Active community}
NetBSD has a very active, but relatively centrally organised community.
The NetBSD Foundation does not only provide the websites and infrastructure for
the development and distribution of NetBSD, but also the mailing lists for
communication of the NetBSD users. Most of the communication of the community
is done over these lists, so you reach most of the users with a mail to these
lists, getting fast help.
Furthermore, NetBSD has channels (#netbsd) in the great IRC networks (the most
active ones being IRCNet and Freenode) where you can get in touch directly and
more private with other NetBSD users, and get help 24 hours around the clock.
On the mailing lists, but also in IRC you will often meet developers, so you
sometimes have the person responsible for your problem directly reading your
message.
NetBSD users are very widespread, that's why there are few user groups, but
many regional mailing lists (regional-LANG%NetBSD.org@localhost) provide help
in your mother tongue. Alternatively, you will find NetBSD booths on every
great Open Source Event (like Froscon) to ask for help or to get informations
about the current status of NetBSD developments.
\subsection{Simple participation}
The NetBSD community is a very tight one, where beginners will get in touch
with developers very fast. Code proposals will be discussed and worked on (i.e.
being imported to NetBSD or the problems will be fixed otherwise) very fast.
If you want to help developing NetBSD, you will get in touch with developers
via mailing lists or IRC very fast, which have an overview of the current
development and can give proposals what could be worked on, or even offer their
help themselves, if you get stuck with development.
Of course you do not have to write code to participate. There is much important
work to be done without having great technical knowledge, mostly documentation.
% Second inner page, being the first thing to be seen together with the first
inner page.
\newpage
\subsection{A complete operating system}
NetBSD uses the package manager {\ttfamily pkgsrc}, which does not only work on
nearly every Unix/Linux platform, but also serving NetBSD always with the most
recent packages. DragonflyBSD and MirOS did even adopted pkgsrc as their main
source for third party packages, thus enlargening the user and developer base
of pkgsrc.
You can configure NetBSD to be as minimal as possible, eating only a few
megabytes, but you can install as much software as you want. Especially on
firewall solutions, NetBSD provides more than all the other free Unixes. Other
security features like {\ttfamily veriexec}, allowing only execution of
registered binaries, make NetBSD not only for severs, but also for embedded
environments optimal.
No matter if you want a KDE, Gnome or Xfce desktop, you will find them all in
an actual version for NetBSD. Nearly every Open Source software is available
for NetBSD, and even if it is not provided, you can still use the interal
emulation for FreeBSD or Linux or many other systems. There is no significant
speed impact, as you do not have virtualisation, but only translations of
syscalls and maybe some special libraries in between.
Of course you don't have to compile all packages yourself, on old computers
that would take a large amount of time, anyway. You can simply use on of the
numerous repositories and install binary packages easily with the command
{\ttfamily pkg\_add} within seconds (or minutes, depending on the package
size). All dependencies and conflicts will be solved automatically or be shown
to the user, respectively, and are solvable with a few operations.
NetBSD gives you control ove rall the licences of your used packages. While the
base system contains only BSD licenced code, you can configure in your
configuration file for additional software / compiling {\ttfamily mk.conf}
precisely which licences you want to use and which ones you want to deny.
% Back matter, useful for some finishing informations or addresses
\newpage
\subsection{Complete documentation}
NetBSD has, as many other BSDs too, a very good and complete documentation.
On the one hand, there is the central (free) NetBSD guide. The guide contains
detailed instructions on how to install and configure NetBSD to run on your
system, how to install additional software, and all the generic administration
stuff. But there's also deeper information about all important subsystems, e.g.
on how to use software RAIDs, bluetooth, or hard disk encryption.
On the other hand, NetBSD is nearly completely covered with manpages. For every
program, for every kernel driver, there is a manpage that describes its usage,
sense and functionality. With all this documentation, NetBSD fits well
specially for developers, which want to find information fast and locally, but
not have to search endlessly online for documentation. Just recently, there was
a new apropos programmed in a GSoC project that improves manpage searching even
further.
But also in comparison with Linux manpages, the BSD manpages are often more
complete and more detailed.
But also for beginners, NetBSD is usable. The system gives you all
possibilities of solving problems yourself by learning about the system, not by
having to search the web because there's no documentation delivered with the
system.
Also for non-NetBSD users the documentation is often very useful. The basic
mechanisms of Unix (e.g. of a vfs) are detailed very precisely, and the NetBSD
installation notes for older platforms are often used by vintage computing
people as references, too.
\subsection{Entry points for documentation}
Website: \url{http://netbsd.org/}\\
Guide: \url{http://netbsd.org/docs/guide/en/}\\
Articles: \url{http://netbsd.org/docs/}\\
Mailing lists: \url{http://netbsd.org/mailinglists/}\\
Manpages: \url{http://man.netbsd.org/}
\end{document}
Attachment:
signature.asc
Description: PGP signature