This is a long posting and doesn't cover the whole story, any more would be a waste of time probably on my point because nobody would read it all. This hopefully will give an insight into OpenBSD but may not necessarily hint at all the appealing aspects of OpenBSD.
Some of the things that I say in here are going to provoke a response from GPL fans. Let it be known that I don't care to be drawn into a heated debate about the rights and wrongs of GPL. That isn't the purpose of this posting. GPL is an important consideration and I try to put the point of how GPL can effect the uptake (or not) of functionality produced in a seemingly free environment. Beyond that I have no concerns.
I like GPL for many reasons but I, and a lot of other folks, don't think it's a suitable free software framework for many things.
In short if you want to discuss the 'rights and wrongs of GPL' please do it on another thread. I may comment if I have the energy left to do so
Many folk ask about OpenBSD on the Zaurus and what they could expect when running OpenBSD on a Zaurus.
There are some short answers which will probably give some people the information that they are after and there are some longer answers which hopefully will give the others what they are after.
The OS - identical to any of the other ports of OpenBSD. 'Out of the box' it will behave exactly as it does if you install it on your i386, Vax, SparcStation or whatever. - This may mean of course you need to do a bit of tweaking to have an appropriate environment for your tastes but the tweaking will be standard across all architectures too
man pages are also available for every user command, this isn't unlike Linux, it's just unlike most Zaurus distributions.
The build environment - identical to any of the other ports of OpenBSD. OpenBSD is in sync across all architectures so it will behave like it does on other architectures. There are a few exceptions to this when you get into using ports (build from source collections of software that come from third parties) in that some ports require a lot of work to make them run on ARM architecture due to inexperience or lack of interest on the part of the developer to make the product as fully portable as possible.
It isn't Linux - Linux is only the Kernel - most people running Linux run GNU/Linux which is the Kernel plus a set of utilities that define the environment, provide the commands and a lot of other things. OpenBSD has its own set of tools that under Linux would be provided by the GNU toolsets. Both OpenBSD and GNU commands give POSIX compliance where standards exist, however, the GNU toolset has extended many commands (for example rm -v (verbose), find -regex (regular expression match)) beyond the core of the POSIX compliance requirement - such extensions will probably not be available in OpenBSD (some others may) so software that aims to be portable should cater for these differences.
Licensing is a BSD license and not a GPL license - There are many differences between BSD licenses and GPL licenses, possibly the most radical is that you can build systems on BSD, customise it (modify Kernel etc. if you like) and distribute it without the need to provide source code. You must adhere to displaying appropriate copy-write messages if a particular module, subsystem or licensing clause requires it but you have that freedom. This makes it appealing for some commercial operations and it is one of the reasons that for example, Apple's DarwinOS can retain binary only components and strict control over their operating system - even imposing their own licensing on top of the BSD license because it is their own product. - Many people hate this about BSD, many people love this about BSD, I am ambivalent, it has some far reaching implications.
Answers related to usability that are of key interest to Zaurus users
It's slower than PDAXROM - PDAXROM and OpenBSD (on the Zaurus) are both built with Software Floating Point, however, PDAXROM uses a vector floating point library which outperforms the library used in OpenBSD on the Zaurus.
On OpenBSD default build uses no xscale optimisation for the bulk of the executables - The Kernel is compiled with -mcpu=xscale but the rest of the distribution is compiled (for compatibility with other ARM architectures) with no optimisations. - It is possible to set some environment variables prior to build that will enable xscale optimisations and you get much better performance when you do this.
QVGA is not yet supported on the X server in OpenBSD - The X server uses facilities provided by the zaurus_lcd driver which currently only implements 640x480 mode. - This is going to make gaming and probably video slower than you want it to be - if that's your main thing then OpenBSD is probably not for you.
Things that you take for granted in Linux such as BlueZ bluetooth, squashfs, cramfs and many other things aren't present in OpenBSD. Bluetooth is a big problem for a lot of folk. At the moment the slickest solution you can have is to get a second SIM card and a CF UTMS/GPRS modem for your dialup stuff.
Linux style /dev/rtc control doesn't exist, which means no APM sleep - lay-persons terms this means that you can't run a PIM application and expect it to wake the device at a certain time, there is no support in the OS for that level of control over the rtc alarms of the system. - It doesn't lend itself to being a PIM based system if you need traditional PIM type environments (it does rock at running Personal Wiki's though if that's what your bag is!).
It runs entirely from hard disk and of the three distributions that do this (OpenZaurus, PDAXROM for SL-C3000 and OpenBSD) it does this the best. It manages the drive handling effectively and rapidly, will suspend and resume cleanly and will flush unwritten data to the drive when the unit resumes if there was a difficulty doing this when the unit was suspended. This is one of the more appealing sides to OpenBSD, the kernel is clean, stable and well behaved - admittedly it doesn't get functionally enhanced too often but the emphasis is always on making it as stable and secure as possible.
It runs entirely from disk as mentioned above and does NOT support inbuilt flash or SD cards yet - supporting inbuilt flash would require jffs2 support and jffs2 support would require writing a BSD licensed (non GPL) driver to support jffs2. SD cards you can connect via USB or via a CF adaptor but the SD slot isn't supported yet. Looking at the comments in the Linux driver source - about how badly implemented the hardware is - I wouldn't be surprised if this never happens.
Now some longer discussions about pertinent issues
GPL and BSD licenses
GPL when strictly enforced (look forward to seeing a lot more of that) imposes a few restrictions on its use. One being anything that directly utilises GPL code (in various ways) becomes GPL too. i.e., Linux being GPL means all Kernel modules written using Linux source code are also GPL forever and must forever adhere to GPL, that license cannot be changed or revoked regardless of the writer's wish and source code must be made available to anyone requiring it should the product be distributed in any way.
GPL consumes other licensing and is contentious in the way that it prohibits the freedom to use its code in some ways. This is by design and I don't wish to debate the higher ideals of GPL, this is just plain fact.
The OpenBSD ethic with regard to what enters the mainstream product states that nothing shall enter the product that converts or makes the licensing ambiguous from a BSD license. Therefore, GPL software cannot enter the Kernel and various other parts of the OS.
Many enhancements to Linux including Bluez, squashfs etc. explicitly state that they are GPL - you cannot therefore take these components and integrate them into BSD without your distribution of BSD taking on a GPL license and being insubmissible back into OpenBSD for general use. Furthermore as a developer that has developed a GPL piece of code you cannot have a change of heart and change the license. It stands.
Many modules, however, state a primary licensing terms which are independent of GPL - stating some of the major clauses of GPL without stating that they will impose GPL license inheritance then go onto say that they may be used within GPL software. This is a nice way for developers to aim at total portability.
The OpenBSD community and the developers
OpenBSD is carefully managed through a core team of developers who implement many changes themselves if bugs or limitations are reported and will vet any submissions of patches for stability, impact and licensing on the product. Changes in OpenBSD therefore happen slower than in Linux.
The distribution is largely favoured by security specialists since the goals of OpenBSD are stability and security. Many systems prevalent in Linux including OpenSSH are developed upon OpenBSD and since the distribution governs how a system should be set up (with which tools, startup, permissions, scripts etc.) OpenBSD can aspire to be 'secure by default'. This is something that cannot be stated of many Linux distributions and there is always an uncertainty when approaching a new Linux distribution as to if this important part of the work has been performed correctly.
More about the Kernel
The Kernel is monolithic - unlike Linux OpenBSD does not have loadable module support, instead all drivers are linked into the Kernel. This can cause a certain amount of bloat if a Kernel aims at supporting a wide range of hardware, such as may be the case with the i386 Kernel; however, it is more secure and offers more stability to avoid the issues associated with dynamic linkage of modules into a running Kernel and it also reduces some of the implementation complexity associated with driver presence particularly during boot (see Linux use of initrd's for module based SCSI drivers where kernel doesn't have SCSI driver linked in).
Focussing on stability, security and maintainability has allowed the developers to make the Kernel sources extremely clean and readable. They are liberally commented and even without these comments are coded with a fairly unambiguous style such that they can be read with a reasonable understanding on the first pass by competent developers.
The benefits of the way this Kernel has been developed are most evident in the ability to rapidly support new architectures and it is a goal to introduce new architectures purely from the standpoint of proving the portability of the Kernel. - this is one of the primary reasons that OpenBSD was ported to the Zaurus.
Instead of using procfs (which is available), system control is performed through a sysctl interface which allows the administrator to fine tune many elements of a running Kernel or to configure those elements for system boot using a file called /etc/sysctl.conf.
The Kernel has some interesting things built into it such as random stack allocation so that rogue software that potentially exploits stack vulnerabilities cannot perform in a predictable way.
The base build system can cross compile for things like the base distribution (Kernel, userland tools, scripts and layout etc.) and XOrg, however, cross compilation is discouraged.
OpenBSD focusses on native build wherever possible for all elements of the operating system or ports.
No effort whatsoever has been made to make the ports system cross compile.
The ports system is a set of scripts and patching tools that build software packages from source and to qualify for inclusion in the ports system the software (patched by the ports system) must be stable, secure and not interfere with OpenBSD licensing as a whole.
The reason that cross compilation is discouraged is that it effects many things in building software.
Firstly cross compilation requires that the software being compiled doesn't have a build environment that prohibits it from being cross compiled or makes it extremely challenging to cross compile. An example may be that the build process builds its own tools to complete the build process and isn't mindful that it is being cross compiled. This may, for example, lead to a component required by the build process being built as an ARM binary that needs to run on the i386 type host that is actually performing the cross compile. This may sound trivial to fix but if you have 16 different architectures to consider in a cross compile matrix and an unknown complexity in each application then it can become prohibitive.
Secondly cross compilation can introduce subtle differences in the binary output. In fact it is true that the binary output for many targets using GCC tools is so radically different between versions of GCC to render the binary output totally unusable for certain purposes. Consider Dan Kegel's information on gcc/binutil/glibc and Linux versions as an indication of sometimes how 'hit and miss' it can be to get a stable build combination for some architectures.
Remove the cross-compiler element and the resulting code generation tends to be less problematic but not completely.
OpenBSD raises the stakes a little with code generation by using the ProPolice extensions that reportedly only work with certain versions of GCC. The GNU team aim to make these work with GCC 4, however, to date they are only stable with GCC 3.3 (possibly other 3.x). ProPolice is aimed at introducing countermeasures to stack smashing code within the compiled code of a product such that a user may reasonably be able to take open source code with minimal analysis and assume that stack smashing exploits will be countered by the compilation environment. This is particularly useful in large projects.
For these reasons and potentially many others OpenBSD favours a native build environment which can be time consuming but as discussed can produce a more predictable output.
OpenBSD is typically at 3 versions at any one time.
OpenBSD -release is the snapshot of a stable working environment that is pushed out every 6 months.
OpenBSD -current is up to the minute CVS commits flaws, claws and all - typically this is what we have been running on the Zaurus because the best developments have come since 3.8.
OpenBSD -stable is what you want to be running in business production environments but paradoxically is the hardest to implement. OpenBSD -stable consists of OpenBSD -release with critical security patches and the easiest way to build this is via CVS by selecting the stable release branch of CVS. This is slightly harder than -current which day by day releases a tarball wrapping all changes.