Theo de Raadt has announced the release of OpenBSD 5.1. The OpenBSD 5.1 release page has a detailed list of all changes and improvements. As always, I would love for someone to write proper items about OpenBSD releases – it’s outside my interests and cursory glances don’t do it justice.
Wonderful OS. It does so many things just the right way, securely. Unfortunately, it has some problems, like:
– broken linux emulation [compat], which renders linux_compat almost unusable. You need to sweat yourself to death to get medium-sized linux projects to work under OpenBSD
– translations of the GUI apps [when LOCALE vars are in use] are not full. You get half english/halt your_lang interface, which is not cool. Of course, the whole localization is actually not there, because OBSD doesn’t support proper localization AFAIK
[and yes – I use OBSD on desktops and embedded devices]
– third party apps are quite often unstable, breaking the whole fun. They seem to crash now and then producing quite huge coredumps [*.core files] in your home directory
– OpenBSD is not the fastest OS on earth, but that’s not a rant. I kinda made peace with it
There are many other things – positive and negative, but I don’t think it’s a good place for such an extensive summary.
I’ve heard on IRC that linux emulation just isn’t a top priority. I kind of get what they are getting at but still it’s a little frustrating.
I like OpenBSD a lot. I’m glad I’m not the only one with those random .core dumps.
I just want having gcc 4.7 ported to it
4.6 is available as a package.
oh great! so I’ll give it a try! thanks!
Actually, OBSD devs are trying to get away from GCC all the way by implementing PCC
yeap, but gcc (actually g++) is the compiler that implements the most of the c++11 features.
I would like to know if clang 3.0 is also available through their packages system.
Clang is available as a port/package. devel/llvm.
Incorrect. PCC was never an adequate choice and won’t be anytime soon.
Well, ‘ulimit -c 0’ seems to disable coredumps, but it’s not exactly an “OpenBSD way of doing things” I suppose …
But if you decide to write an extensive summary (please!), post the link here. While I currently use Linux a lot and Win 7 a bit, I’m really interested in other options as well.
Unfortunately the vast majority of the crashes are due to bugs with the third-party software. OpenBSD introduced a stricter malloc() implementation many years ago as well as some other security related features which exposes poorly behaved third-party software. A good number of bugs that have been fixed with third-party apps tend to show up on Linux quite infrequently and then when run on OpenBSD or through Valgrind they are fully reproducible.
I am developing an open source program and for fun tried to run it in OpenBSD, it crushed with segfault. After using valgrind+memcheck I dicovered that program was reading 1 byte above its allocated memory, in other systems Linux based or Windows’s program wasn’t crashing.
Memory boundaries checking in OpenBSD is superb.
You are absolutely right and I am perfectly aware it is third party software to be blamed.
OBSD’s FAQ makes it clear from the start:
“The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system. Although we strive to keep the quality of the packages collection high, we just do not have enough human resources to ensure the same level of robustness and security.”
I think you might be trapped into an understanding problem here. Allow me to explain:
OpenBSD organizes “additional software” by its ports collection (similar to what the other BSDs do). There is “the OS” (which is OpenBSD) and there is “additional applications”. Those are managed by maintainers and typically ported over from Linux land. Especially in GUI applications you can see that they are quite Linux-centric and may work better “over there”. The internationalisation and localisation is a workiing field for the original developers and port maintainers, not the OpenBSD “OS team”. The OS can only provide “highest level” selection mechanisms, typically by environmental variables and their control mechanisms. Just to mention a few: There is $LANG, and there are $LC_* for a fine-grained control (LC_ALL, LC_MESSAGES, LC_COLLATE or LC_TIME, just to name a few) which control both language and character set, whereas $LANG only controls language and has a “strange priority relationship” to the other ones.
See the FAQ 10.20 “Character sets and localization”:
http://www.openbsd.org/faq/faq10.html#locales
More details can be found in the login.conf manpage:
http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&sektion=5
Much more details about the language control variables (even though taken from FreeBSD):
http://www.freebsd.org/cgi/man.cgi?query=environ&sektion=7
Additional info:
http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html
It’s up to the GUI programs to properly honor the environmental settings (and not overriding them with their own defaults), and it’s up to their developers to implement the translation texts properly.
Believe me – I know enough about the problem of bad, missing and partial translation. In Germany, english error messages and the ability not to select “Deutsch” at the very first step of an OS installation is the main reason to drop powerful and versatile systems like OpenBSD. Note that this also covers Linux! In the past, I always experienced Gnome to have a better translation than KDE, for example. But that has nothing to do with the actual OS they’re running on. People tend to forget this fact.
I’m using english-only Unix and Linux systems myself (primarily FreeBSD, OpenBSD and Solaris), as I prefer the clear english texts over the sloppy, partially wrong and ugly-looking german translations. The only exception I’m willing to admit is OpenOffice. 🙂
You have just learned that those are not developed by the OpenBSD team. 🙂
OpenBSD forces coders to be more careful than other Unix or Linux systems may do. Just as an example, if cc -Wall shows anything, the program should be worked on until no more warnings appear. Especially memory management is (due to security reasons) seen as an important aspect. Sloppy coding, compile warnings and runtime messages sadly seem to be typical. They appear more often on systems software is ported to (e. g. more often on OpenBSD than on native Linux).
Throw better hardware at it – that’s what the “big guys” with the pockets full of money typically do. 🙂
I love OpenBSD and its rock solid simplicity but It’s not an ideal OS for big servers.
IMHO OpenBSD is perfect for embedded solutions, firewalls, log servers and other small footprint and very focused tasks (running on small hardware or VMs).
For bigger generalistic projects FreeBSD and GNU/Linux are better options.
Can you explain your arguments?
Yeap. Support for enterprise hardware (hba and multipath drivers) is very limited in OpenBSD.
OpenBSD I/O performance is bad and SMP isn’t stellar.
PS: I hate to argument against OpenBSD… but you have to use the right tool for the right job.
Very scientific.
Hey, thanks for this great response!
I am aware about most of the things you were kind enough to point out. The only thing I was not actually aware of was the fact that ‘3rd party app'<>’base OS’ communication is the real problem. Thank you for making me a little bit wiser!
True but I can’t even remember the last time I used that. If there’s not a native port the program probably wouldn’t run very well in Linux emulation anyway.
Yes, I have heard that localization is somewhat incomplete in the base system. For GUI apps not in base it is not an OpenBSD problem.
Don’t bother me much though, English is the language of computers. Just deal with it or contribute what is necessary to improve localization.
That’s not really an OpenBSD problem but a problem with the app. Quite a few “portable” programs a written with the mentality that if it works on Linux that’s good enough.
Maybe but I haven’t noticed any real difference between, for example, OpenBSD and Linux. If anything OpenBSD feels faster.
I only use OpenBSD in infrastructure roles though so maybe this is a problem more noticed on the desktop.
On an unrelated note, I think this should be front page news on *OS*news.
Edited 2012-05-04 03:51 UTC
That is one of the greatest problems with generally open source world. It usually takes care about Linux, everything else seems to be forgotten.
There is a noticeable slowdown on the “desktop”. I suspect the main culprits are a) userthreads and b) malloc.
a) Using userthreads means a huge multithreaded program is running on a single cpu core wasting all the threading overhead.
b) OpenBSD malloc is pretty complex and has many features – most importantly ASLR which consumes high quality random numbers on a regular basis. There is no way it could outperform a decent performance-optimized malloc. Huge multithreaded programs tend to allocate and deallocate thousands of objects every millisecond so it ends up adding up.
On the command line, most programs a) use SMP-enabled processes instead of threads and b) are written in C which means all allocations are planned. It is perfectly possible they could outperform an out of the box Linux with many daemons half-idling in the background.
I certainly don’t have any complaint about make -j 6 in /GENERIC.MP.
OpenBSD 5.2 will include SMP-enabled rthreads by default so I expect to see a boost in “desktop” performance. malloc is less likely to improve but memmap is getting reworked, which could lead to a faster implementation.
NOTE: The network stack runs in kernel and thus it won’t scale over 1 core until the kernel itself becomes multithreaded.
Often, when you install a critical 3rd-party package (e.g. a memory hog one), you’ll see some instructions on how to deal with it. In most cases, an
$ ulimit -d 1048576
will solve your problem.
As explained by 0brad0, OpenBSD uses a different allocator, more restrictive, that doesn’t allow crap software.
What I have seen so far, and strangely enough, are that users who recompile kernels to cut some MBs are the ones who generally have GBs of memory. In the same line, users who complain about speed _generally_ have multi-GHz CPUs. Is this the case?
Been using OpenBSD since 2.something. For what I use it for (firewalls, general-purpose servers) it works well for me.
Strong points: emphasis on security, correctness, and general good design. Base system includes userland (like other BSDs, unlike Linux), so your base system won’t generally break due to incompatibility between components. Best open-source firewall system (pf) there is, and other tools (OpenOSPFd and OpenBGPd) can let you replace commercial routers. Easiest-installing OS I’ve used. Complete, correct documentation written by folks who consider it as important as good code. Good wireless card support, at least as a client. Relatively small developer community gives precise focus. Some offshoot projects in wide use my many OS & commercial projects (OpenSSH, tmux).
Not-so-strong: Raw I/O throughput probably not world-beating (though network stack is quite good). Same with SMP implementation. Relatively small developer community means some newer hardware and features slower to be supported than on Linux or FreeBSD. Filesystem size limited by RAM in current implementation (and no “advanced” options like ZFS or HAMMER). Some Linux-oriented 3rd-party software breaks (not OpenBSD’s fault, but something to consider), though “classic” Unix tools and those with portability in mind typically run just fine. Limited virtualization options as host OS. Community can be hostile to those who don’t ask intelligent questions or who don’t RTFM.
I probably left some things out. But bottom line, it’s a high-quality, reliable OS that is the right tool for some (many?) jobs. If I were an open-source developer, I’d test on OpenBSD as a QC measure.
I’d mod you up for writing a really good summary but since we’re not adults here I’m not allowed to.