Comprehensive and biaised comparison of OpenBSD and FreeBSD Antoine Jacoutot Baptiste Daroussin ajacoutot@ OpenBSD. org bapt@ FreeBSD. org The OpenBSD project The FreeBSD project Abstract AJACOUTOT: Right, so while discussing the re- productive appendix of these horses to know This paper will look at some of the differences between 1 2 which came first... the FreeBSD and OpenBSD operating systems. It is OK who am I kidding here. It was something not intended to be solely technical but will also show like midnight and... the different ”visions” and design decisions that rule BAPT: Actually I think it was more like 2am. the way things are implemented. It is expected to be a AJACOUTOT: Anyway, we were having our 10th subjective view from two BSD developers and does not pint of Heineken in a Pub somewhere... pretend to represent these projects in any way. BAPT: Duvel, it was Duvel. Be careful what you say here, its a beer land! We don’t want it to be a troll talk but rather a casual AJACOUTOT: Right right. So I started complaining and friendly exchange while nicely making fun of that the Duvel didnt taste anything, of course it each other like we would do over a drink. Of course, was our 10th pint so... we shall try and hit where it hurts when that makes BAPT: No no no, I told you cant say things like this. sense. Obviously, we both have our personal subjective Or OK, maybe the last one was Heineken after preferences and we will explain why. Showing some of all. the weaknesses may encourage people to contribute in AJACOUTOT: See! So, as I was saying, the beer did some areas. not have any flavor anymore. And thats when it hit me... Flavor... wait a minute... OMG this Most of the topics discussed here could warrant their is exactly like FreeBSD. You guys dont have own paper and talk and as such some may not get the FLAVORed packages! deep analysis they deserve. [ Trolls must now leave the audience] This is a totally biased talk from two different perspec- tives. ACT I 2 Ports & packages 1 The History behind the story AJACOUTOT: FLAVOR3 is an awesome concept. I AJACOUTOT: Before we begin, let us tell you a lit- am not aware of any other package manager in tle story about how we ended up here today... UNIX land that implements the same function- Once upon a time in the countryside on a sunny ality. afternoon, in the mid-summer time, Bapt and I Basically, it allows providing packages com- were having some herbal tea with... piled with a different set of options. Thats very What was it already, sponge cake? convenient from a dependency point of view BAPT: Absolutely, we were talking about the inter- since according to the options you want, the fi- action between ponies and unicorns. Which nal binary will change as it might end up link- one appeared first etc... ing to different libraries. Just another one of our regular meetings argu- So you want to be able to control that but pro- ing on important philosophical concepts. viding packages compiled with a good set of defaults can be next to impossible sometimes in mind that we do not release a package set, (its hard compromise) and thats where FLA- but the ports tree is a rolling release not tight VORs kick in. For example you can install to a FreeBSD release. Which reminds me, you Sendmail with or without support for SASL guys do not support upgrading packages on a and / or LDAP: there are different (conflict- given release! ing) packages for it (e.g. ”sendmail” versus AJACOUTOT: Actually we do support upgrading ”sendmail–ldap-sasl”). packages on a given release. Its different from subpackages which are just What we do not provide are precompiled split packages. These are typically used when binary packages. So its true that you need you have a software that comes with a huge some kind of a build box where you can amount of data (like audio and graphics for distribute packages updates from. games for example) which rarely change while But theres work in progress in this area and the main binary does each update. I am confident that within a year we will be Instead of having to update the complete set, able to provide binary upgrades for packages you just update one small subpackage. It can on supported releases. also be used for things that ship modules or So keeping your packages up-to-date will just add on components that have a whole lot of be a matter of running ”pkg add -u”. different dependencies. PHP is a good exam- ple. On OpenBSD we compile it with pretty Talking about pkg add(1)4, its important much all options, so the build requirements are to note that a lot of operations are done big but the port only needs to be built once and as different unprivileged users (fetching, since the package is split into multiple ones, extracting etc), we dont really want to go on you only get to install what you need (e.g. php- the Internet as root while you guys still do imap, php-mysql...). not drop privileges when using libfetch(3)5 in BAPT: You really took the wrong example here. pkg(8)6. Care to comment about that? For php we have fine grained split the pack- BAPT: That is not true actually pkg(8) uses cap- ages so you want php with imap? Just pkg in- sicum to sandbox everywhere it is possible. stall php5-imap and done. And pkg(8) also uses unprivileged user to fetch AJACOUTOT: But my point is actually that sub- packages for examples and everywhere it is packages allow you to not have to deal with possible. fine grained packages. If I understand cor- While sandboxing is supported for a long time, rectly how your ports tree works you still need unprivileged users mechanism were added re- to build each PHP module separately one by cently before OpenBSD did it ... by a few days one, while we do it all at once. :) BAPT: Correct, these are not really subpackages AJACOUTOT: Maybe you and Marc (Espie; the and would be nicer with them. For FLAVORs author of OpenBSD pkg add(1)) are sharing a good example could be the OpenLDAP client brains! compiled with or without SASL :) AJACOUTOT: Right. So if I need SASL support in Back to our topic, we also try very hard OpenLDAP on FreeBSD, I assume I need to to provide proper upgrade paths for our users, build it myself right? Thats fine I guess, but but the difference is that we dont have to deal my fear is what will happen when I run ”pkg with legacy / unmaintained wrappers against update && pkg upgrade”? the pkg tools (portmaster7, portupgrade8, BAPT: Bad things... portinstall, portguruwhatever...)ˆ . Our pkg BAPT: So yes it is true that we do not yet have FLA- tools are designed to provide everything one VORs nor subpackages but there is some on- needs for package management without the going work to provides those features in the need for an external helper. Dont forget we ports tree. That work is pretty hard as it breaks have a long tradition of providing proper bi- the design of some tools that are heavily used nary packages over pushing people to compile by users like portmaster and portupgrade and their own. which are barely maintained; meaning we need BAPT: This is also true for FreeBSD now, most of to find an upgrade path which will not break the tools you are speaking about are mostly those. We try to always have an upgrade path to use the ports tree directly as a live system for users and try to avoid hard breakage. Keep rather than using binary packages (which is a 2 usage not supported by OpenBSD right?). This is all very confusing, no support can be AJACOUTOT: Its perfectly supported by OpenBSD. good if you dont understand how it works. We just dont encourage it it because for BAPT: Common that is easy: 99.99% of the cases, it is not needed. Normal Releases which are published from BAPT: But one thing about the FreeBSD ports tree a -STABLE branch were supported by the is that it works on all supported versions of Security Officer for a minimum of 12 months FreeBSD. Ah well... true you only support one after the release, and for sufficient additional version of OpenBSD and only for 6 month. time (if needed) to ensure that there is a newer release for at least 3 months before the older 3 Release model & engineering Normal release expires. Extended Selected releases (normally every AJACOUTOT: You are correct, for packages we second release plus the last release from each only support the current release which at this -STABLE branch) were supported by the time is is 6.0; the operating system itself is sup- Security Officer for a minimum of 24 months ported for two releases. after the release, and for sufficient additional And aside from current/snapshots, our ports time (if needed) to ensure that there is a newer tree is indeed tagged to a specific release. Extended release for at least 3 months before Thats a design decision. We do not want our the older Extended release expires. users to be forced to upgrade to a new major Nah... I agree this is a mess, further more it version of a software on a given release and was causing lots of issue when maintaining we do not want to maintain 4 different versions the ports, as we had to wait for at the very least of the same software to prevent that.