NetBSD-Advocacy archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

New flyers - need help


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

% Titelseite - enthält Logo und Einleitung

\includegraphics[width=.7\textwidth ]{NetBSD}

\huge \bfseries tips and tricks for NetBSD newcomers

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}.

% Erste Innenseite - zusammen mit zweiter Innenseite das erste, was der Leser 
beim Aufklappen sieht

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.
\section{Generic tips}
        \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, 

        \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{} 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.

% 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.

% Zweite Innenseite, wird mit der ersten Innenseite beim Aufklappen als erstes 

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:

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.

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).

Decentrally organised, there are NetBSD channels in the larg IRC networks 
EFnet, IRCnet and Freenode (the largest one) with the name {\ttfamily #netbsd}.

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
\section{Nützliche Links}
        \item NetBSD website: \url{}

        \item NetBSD guide: \url{}

        \item NetBSD articles: \url{}

        \item NetBSD manpages: \url{}

        \item NetBSD wiki: \url{}\\

        \item Search bugs:\\ \url{}

        \item Report bugs:\\ \url{}\\

        \item Install additional software:\\ 

        \item NetBSD guide -- compile NetBSD:\\ 

        \item NetBSD on flash drive:\\ 

        \item pkgsrc guide: \url{}

        \item pkgsrc make targets:\\ \url{}

        \item development/contribution: \url{}\\

        \item mailinglists: \url{}

        \item mailinglist archives: \url{}

        \item mailinglists on gmane: 
        \item NetBSD-related events:\\ \url{}

        \item IRCNet: \url{}

        \item Freenode: \url{}



% Titelseite - enthält Logo und Einleitung

\includegraphics[width=.7\textwidth ]{NetBSD}
\huge \bfseries NetBSD for newcomers

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}.

% Erste Innenseite - zusammen mit zweiter Innenseite das erste, was der Leser 
beim Aufklappen sieht
\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 

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}.

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
\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.

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 

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.

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 

\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.

% Zweite Innenseite, wird mit der ersten Innenseite beim Aufklappen als erstes 
\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.

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

\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.

        \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 
        \item {\ttfamily vmstat(1)} -- shows information about virtual memory 
        \item {\ttfamily fstat(1)} and {\ttfamily sockstat(1)} -- equivalently 
to lsof, fstat shows informations about open files, and sockstat about open 

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 

\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 

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 

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.


% Title page - contains logo and short description

{\huge \bfseries The NetBSD project}

{\large \scshape ``Of course it runs NetBSD''}

\includegraphics[width=\textwidth ]{NetBSD}

\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.
\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 
\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 

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} would e.g. build the 
toolchain for sparc simply with {\ttfamily -m sparc tools}, and just 
with choosing another target (so {\ttfamily -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.
\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 

NetBSD users are very widespread, that's why there are few user groups, but 
many regional mailing lists ( 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.
\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
\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 
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 

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{}\\
Guide: \url{}\\
Articles: \url{}\\
Mailing lists: \url{}\\
Manpages: \url{}


Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index