Of course it runs ... NetBSD A software developers insight of the world's most portable OS Foreword This article is my personal account on NetBSD and is not meant to be a completly non-biased insight into differences of various operating systems nor is it meant to discourage from trying out and using them. Also, this isn't meant for hard core users but as a simple guide on how things work. Introduction NetBSD, a system derieved from the original Berkeley Software Distribution, is one of the most versatile operating systems currently available. It runs on most hardware you can stick the name "computer" on, and also on hardware you have to think twice before calling it that. NetBSD is NOT meant to support all hardware a single architecture can offer but instead focuses on running on as many architectures in their default configuration as possible. NetBSD: Grandfather of portable systems NetBSD is, so to speak, the real grandfather of portability. Well, there have been many systems before NetBSD that have been ported from their native architecture to other hardware, but NetBSD has transformed that necessity to a fine art. Just like FreeBSD, NetBSD started as an i386-only system, but while FreeBSD developers focused on supporting all Intel-PC hardware, NetBSD developers have choosen to get the system running on all kind of hardware. "Why?" you may ask. Good question. The answer is simple and complex at the same time, depending on which way you're looking at it: The simple part: There's a lot of older hardware out there that isn't supported any more by their original developers but is still of value. It could be used for various purposes like servers, low-workload workstations and so on. Thats where NetBSD comes in and tries to fill that gap. The complex part: There's also a quite big bunch of exotic hardware that IS currently supported by their original producers. But most often this systems have their own way of doing things (think API's, developer tools, graphical user interfaces etc). Very often, the development tools and specifications are also closed source and/or only commericially available and do run on few if not a single operating system - forcing you to use that system(s) if you want to develop for the target platform. This happens most often on embedded devices; but also happened many times on end-user desktop machines and servers in the past. Also, using propritary APIs (Application programmers interface), running your software on that system often calls for rewriting big chunks of your source code. So it's only reasonable to run a system with a highly developed hardware abstraction layer (HAL) that makes your code fairly system independant. Of course, there are certain limitations. Even a higly developed HAL can't change the fact that an architecure for example does not have graphical capabilities. But by using the systems libraries, the program may not even have to be aware of that fact, because the system may be able to tunnel the graphical output to another computer that CAN display graphics. Of course, without the program even knowing that it's happening. NetBSD: Kernel, Base and Packages There are three parts of the NetBSD system in a quick overview: *) Kernel The kernel is the most basic part of the system, consiting of the most fundamental hardware abstraction: It handles IO requests and transfers data between real devices and and their abstractes counter-parts known as "special files" or "device files". It also manages things like multi-threading, multi-processor, audio-subsystems, network (with network-cards and other means of transfering data) and so on. It does it in a way to hide most of the hardware complexities from the programs running on that systems through (mostly) hardware-independant APIs. *) Base system The base system is always developed in sync which the kernel, and is also shipped in a fitting version to the kernel. This is in direct opposition to the Linux systems, where kernel and everything else is developed seperatly and only occasionally "made to fit". Think of the base system as the basic libraries and basic tools have two basic purposes: Hide most of the architecture dependant features of the APIs from the userspace applications. There ARE APIs like device files and most if not all of the graphical systems that are completly related to the system they are running on. The reason why that incompatibilities are not handled by the kernel itself are quite simple: The kernel would become to bloated, slow and hard to maintain. Also, the base system (in cooperation with the kernel) tries to compensate for features that are simply missing like the mentioned graphical capabilities by substituting other system defaults and patched X libraries that do not need any hardware and driver support to compile on the system. In contrary, they are only featuring the parts needed to access the graphical system over the network. The second purpose of the base system is to enable the user to compile the system itself, run the most basic services like remote access, and finally, compile additional software from the Package-distribution. *) Packages - additional software for NetBSD Once the base system is up and running, most likely additional software is needed to run the wanted services. This is where NetBSD's "pkgsrc" package managment system comes to help. The pkgsrc distribution is a central place for all hardware independant software that isn't a "must" for running the OS. From simple mp3-libraries to the always too-complex-to-be-bugfree fantastic window-managers like KDE and Gnome, it's all there. Just enter the directory of that software, take "make install" and pkgsrc download and compiles that software, including all of it's dependencies. There are also some hardware dependand software packages in pkgsrc like the bochs emulator, but they are quite a few. Most of the abstraction layers are buried deep in the kernel and the base system.