My desktop comparison of FreeBSD and OpenBSD

Oko said:
For such applications OpenBSD should run significantly slower than FreeBSD considering amount of crypto, security features, pitiful file system, slowness of rthreads, and big giant lock. On another hand PF is about 4 times faster on OpenBSD comparing to "improved multithreaded" version running on FreeBSD.
Click to expand...
Funny thing actually, I found this posted yesterday to @misc. Apparently there has been some performance tweaks made to the kernel, so I'll have to try a snapshot.
 
What also makes OpenBSD a bit of a pain for "desktop usage" for me is that I don't have access to devel/valgrind or libasan for the address sanitizer (for gcc and clang) on that platform.

The tools it does have is malloc.conf (i.e libc malloc debugger), splint and ElectricFence which are pretty good for most stuff but I would really like those extra tools (in particular for stack array checking) :/

Ironically because of this I tend not to write C on OpenBSD and tend to stick to C++ instead (which is luckily what I use at work). But I really admire the skills of the OpenBSD team to write code that they trust without these extra cruches ;)

Edit: I guess OpenBSD also has the Bohem GC which can be used to check for some leaks and errors too but I have not really tried that.

Edit2: I have also had some success with Emscripten on OpenBSD to both provide me with c++11 features with LLVM / clang++ (i.e shared_ptr<T>) but also since it compiles to Javascript I can use web browser profilers and memory error detection. Kinda hacky so I wont add this as a solution ;)
 
gpatrick said:
On daemonforums a new poster had a question in the OpenBSD forum and had this for a reply:
You have to call OpenBSD customer service at 1-800-234-3325.
Click to expand...
The person who posted the reply was rightly admonished by others for his rudeness.
Click to expand...
I thought that answer was pretty appropriate considering the high quality problem description ;) . Have you bothered to check the number §e ?
 
kpedersen said:
What also makes OpenBSD a bit of a pain for "desktop usage" for me is that I don't have access to devel/valgrind or libasan for the address sanitizer (for gcc and clang) on that platform.

The tools it does have is malloc.conf (i.e libc malloc debugger), splint and ElectricFence which are pretty good for most stuff but I would really like those extra tools (in particular for stack array checking) :/

Ironically because of this I tend not to write C on OpenBSD and tend to stick to C++ instead (which is luckily what I use at work). But I really admire the skills of the OpenBSD team to write code that they trust without these extra cruches ;)

Edit: I guess OpenBSD also has the Bohem GC which can be used to check for some leaks and errors too but I have not really tried that.

Edit2: I have also had some success with Emscripten on OpenBSD to both provide me with c++11 features with LLVM / clang++ (i.e shared_ptr<T>) but also since it compiles to Javascript I can use web browser profilers and memory error detection. Kinda hacky so I wont add this as a solution ;)
Click to expand...
You may have explored this already, but OpenBSD's malloc has some extra options that can enabled: http://www.drijf.net/malloc/
 
byuu, thanks for taking time to write this review. It is nice to know there are different gradations of BSD available and I wish each of them best of health in 2015. Gonna try OpenBSD in a VirtualBox.
 
Actually, after posting on the recent HN thread that I found OpenBSD upgrade procedure, as described in FAQ, to be too "manual" and complicated, and advised otherwise by some nice people there, I've got another SSD into my Thinkpad T400 and replicated my FreeBSD 10.1 desktop in OpenBSD 5.6 yesterday. Take all this with a grain of salt:

Pros:
  • Smooth, text-based installation with default automatic partitioning putting everything (root, /usr, /etc, /var, /home and so on) onto its own partition.
  • X works out of the box.
  • "Spartan," intuitive root file system layout, ps ax looks cleaner than on FreeBSD even with the X running. Very cool.
  • Packages-oriented OS. It has ports, however OpenBSD FAQ advises to use packages. Let's face it, if we want a desktop with about a thousand of apps installed, packages would be preferred indeed. OpenBSD's pkg_add works well, however I haven't had a chance to go into dependency inferno with it yet. I didn't see any slowdowns during package installation as the original poster reported, if compared to FreeBSD's pkg.
  • I liked rc.conf defaults are at /etc/rc.conf and you are supposed to edit /etc/rc.conf.local. This simply seems more intuitive to me than having three of them. Although having to set the flags to "" instead of NO to actually enable something seems a little odd.
  • My sysctl.conf had only one entry to make it a functional system.
  • Audio works out of the box, even laptop's volume controls. Didn't have to map volume buttons in dwm to make them work.
  • Despite OpenBSD FAQ is less detailed, if compared to the FreeBSD Handbook, I found it to be really nice along with the manual pages. It does its business and there's no lack of documentation.
  • Very easy to get NICs going by editing /etc/hostname.if files. Wi-Fi up and running in seconds. Way easier than having to deal with wpa_supplicant.conf first time.

Cons:
  • Sluggish performance. Heavy apps take longer to start. chromium and firefox take time to render pages, they eat lots of CPU and lock up for short moments often and this irritated the hell out of me. Everything is taken down a notch, if compared to FreeBSD.
  • OpenBSD is a desktop battery vampire king. Even with apmd running with the -C "keep it cool" flag, it seems it is draining the banks much faster than FreeBSD. With -A, "automatic" setting it loves to spin CPU cooler a lot when I am browsing web pages on the AC power. The laptop is suddenly struggling with Facebook. Nothing of that, of course, happens in FreeBSD.
  • "OpenBSD devs eat their own dogfood," it is said, but suspend and resume actually work better for me on FreeBSD out of the box on this particular laptop. OpenBSD failed to wake up a few times. Perhaps this could have been fixed somehow.
  • Had to edit login.conf to increase memory limits for the staff group, otherwise heavy apps like chromium and thunderbird simply segfault which was very surprising for a newbie like me. (But hey, one needs to do some legwork in FreeBSD to make it seaworthy too.)
  • Extremely poor performance on HTML5 video streaming on YouTube and elsewhere. It is advised to use downloaders like youtube-dl to watch online videos. I've browsed all the forums I could and, as I understood, it is said web browsers are to blame, however the same software works fine on FreeBSD and other OS's.
  • I didn't like user-installed apps put their configs to /etc instead of /usr/local/etc.
  • No wine.

Things to mention, however not particular pros or cons:
  • It was a little bit unclear what to do with firmwares after the first boot. Had to grab 'em manually from the Internet and decompress to /etc/firmware to make Wi-Fi adapter and discrete ATI Radeon work.

Right now I am back to FreeBSD. Poor web browsing experience and unreliable suspend/resume render OpenBSD less desirable for me. I hope this will improve in future. I do sincerely appreciate that system and community exist. The more of these things on this planet, the better. There's definitely a number of OpenBSD features I would love to see implemented in FreeBSD.
 
blackhaz said:
Cons:
  • Sluggish performance. Heavy apps take longer to start. chromium and firefox take time to render pages, they eat lots of CPU and lock up for short moments often and this irritated the hell out of me. Everything is taken down a notch, if compared to FreeBSD.
  • OpenBSD is a desktop battery vampire king. Even with apmd running with the -C "keep it cool" flag, it seems it is draining the banks much faster than FreeBSD. With -A, "automatic" setting it loves to spin CPU cooler a lot when I am browsing web pages on the AC power. The laptop is suddenly struggling with Facebook. Nothing of that, of course, happens in FreeBSD.
  • "OpenBSD devs eat their own dogfood," it is said, but suspend and resume actually work better for me on FreeBSD out of the box on this particular laptop. OpenBSD failed to wake up a few times. Perhaps this could have been fixed somehow.
  • Had to edit login.conf to increase memory limits for the staff group, otherwise heavy apps like chromium and thunderbird simply segfault which was very surprising for a newbie like me. (But hey, one needs to do some legwork in FreeBSD to make it seaworthy too.)
  • Extremely poor performance on HTML5 video streaming on YouTube and elsewhere. It is advised to use downloaders like youtube-dl to watch online videos. I've browsed all the forums I could and, as I understood, it is said web browsers are to blame, however the same software works fine on FreeBSD and other OS's.
  • I didn't like user-installed apps put their configs to /etc instead of /usr/local/etc.
  • No wine.
Click to expand...
Anybody who knows anything about security will put lack of Wine as a feature not a Cons :) As of your other complains OpenBSD has never been about "performance" but rather about security, stability, and correctness. However as a long term OpenBSD user I have to notice that web-browsers are becoming serious problem on OpenBSD. They leak memory left and right and it seems that with every release the choice is smaller and they work worse and worse. I remember running Opera via Linux emulation on PIII with old slow 512 MB of RAM just couple of years ago and not having any issues.

I am having regular Firefox freezes now on my desktop with 16 GB of RAM and 8 cores which uses its own Unbound. For me the most usable browser on OpenBSD is NetSurf these days with dillo coming close behind. If dillo actually had just a decent CSS rendering I would use it full time to browse Internet.



blackhaz said:
Things to mention, however not particular pros or cons:
  • It was a little bit unclear what to do with firmwares after the first boot. Had to grab 'em manually from the Internet and decompress to /etc/firmware to make Wi-Fi adapter and discrete ATI Radeon work.
Click to expand...

If you are connected to the Internet after first boot system automatically parses your hardware, checks if you need firmware (for example for WiFI) and installs it for you. No action is needed on your part.
 
Oko said:
If you are connected to the Internet after first boot system automatically parses your hardware
Click to expand...
In fact /etc/rc.firsttime does this and is deleted after its execution.
This script is one line long: /usr/sbin/fw_update -v , you can rerun this command if needed.
To add to the pros/cons discussion, I noticed OpenBSD's packages have, in general, better default configuration and work out of the box. But, mostly because of a lack of resources, there are fewer of them.
 
formateur_fou said:
To add to the pros/cons discussion, I noticed OpenBSD's packages have, in general, better default configuration and work out of the box. But, mostly because of a lack of resources, there are fewer of them.
Click to expand...
The lack of packages on OpenBSD was often used in the past as an argument against OpenBSD. For the most part that is just a false argument and people should not be discouraged to use OpenBSD just because they have fear that their favorite application is not ported. I will try to explain little bit.

Things to remember is that Xenocara is the part of the base so those 2000-3000 FreeBSD XOrg related ports are irrelevant for the process of comparison. Another thing is that OpenBSD developers are merciless when it comes to pruning staled, unmaintained packages or packages with security holes (wireshark is an example). Also OpenBSD ports tree no longer contains web-related packages which contain just php or html files which can be easily installed by downloading tar balls and opening them in the root of the web server. MTier due to its unique position as a OpenBSD desktop consulting company is sponsoring many desktop oriented packages. Typically things like CUPS, sane-backends, Ghostscript and various other printer drivers are updated as soon as upstream updates them. TeXLive consist of four big packages unlike FreeBSD ports.

All of above being said. OpenBSD does objectively have fewer packages than FreeBSD. Sometimes packages do really get staled because of the lack of resources. Numpy, scipy, and matplotlib were stalled and there were no Python 3.4 flavors until recent work of Daniel Dickman which still didn't hit official repositories. So things happen but overall one would be hard press to find important application which is not ported to OpenBSD.

For power user I also suggest looking at the dpb (Distributed Ports Build) as well as how packages are signed.
 
Oko said:
Also OpenBSD ports tree no longer contains web-related packages which contain just php or html files which can be easily installed by downloading tar balls and opening them in the root of the web server.
Click to expand...

FreeBSD packages have checksums, which provides some security over just unpacking a tarball. Packaged software can also be tested for corruption and for known problems in installed packages with pkg-audit(8).

Well, I'm sure OpenBSD packages have the same thing, but the point is that packages do offer serious advantages over non-packaged software.
 
wblock@ said:
FreeBSD packages have checksums.
Click to expand...
OpenBSD packages not only have checksums but they are also signed for the past year or more. Mark Espie who is the author of OpenBSD packaging wrote papers on package signing so I invite people to read. For the record I really like what FreeBSD has done with with its binary packages since the time of 5.xxx and 6.1 when I used to run FreeBSD on my desktops.
 
kpedersen said:
What also makes OpenBSD a bit of a pain for "desktop usage" for me is that I don't have access to devel/valgrind or libasan for the address sanitizer (for gcc and clang) on that platform.
Click to expand...
In the interest of keeping this thread up to date… uebayasi@ ported valgrind to OpenBSD last month. The package will be available for the 5.7 release in May, and it’s on the mirrors right now for snapshot users.

I appreciate when people mention specific packages they’re missing instead of just saying “there aren’t enough packages available.” That way, if it becomes available someone can point it out, and sometimes developers can gauge the level of interest in a potential port while they’re browsing forums like this.
 
I am continuing to run OpenBSD as my do-it-all desktop - so far 20 days. A few things to consider in addition to my original post:

Cons:
- No virtualization (yes, I know what Theo said). No VirtualBox.
- No freebsd-update equivalent. If you want to patch your kernel after security advisory, grab the kernel source and recompile. I think there is a third party binary patch effort but this kind of compromises the whole enterprise AFAIAC.
- Yes, older software in ports. Qt is still 4, for example. Sometimes I feel lonely.
- GUI performance hit under load is more severe than I thought initially.
- No Linux compatibility layer. It was just forgotten at some point.

Pros:
- Marvelous "Absolute OpenBSD" book by Michal W. Lucas.
- The "no tweaks" approach. The less custom mods, the better. In this regards, OpenBSD doesn't feel like a bag of Lego bricks.
- Could get the laptop battery life to be comparable with what I get on FreeBSD. Running apmd with no flags turned out to be the best option.

So many parts of it are dear to me but as a general purpose desktop user I found certain downsides of the OpenBSD approach to be critical. Yet it is a pleasure experience learning both BSDs. Will probably keep swapping drives for some time more in this laptop...
 
blackhaz said:
I am continuing to run OpenBSD as my do-it-all desktop - so far 20 days. A few things to consider in addition to my original post:

Cons:
- No virtualization (yes, I know what Theo said). No VirtualBox.
- No freebsd-update equivalent. If you want to patch your kernel after security advisory, grab the kernel source and recompile. I think there is a third party binary patch effort but this kind of compromises the whole enterprise AFAIAC.
- Yes, older software in ports. Qt is still 4, for example. Sometimes I feel lonely.
- GUI performance hit under load is more severe than I thought initially.
- No Linux compatibility layer. It was just forgotten at some point.

Pros:
- Marvelous "Absolute OpenBSD" book by Michal W. Lucas.
- The "no tweaks" approach. The less custom mods, the better. In this regards, OpenBSD doesn't feel like a bag of Lego bricks.
- Could get the laptop battery life to be comparable with what I get on FreeBSD. Running apmd with no flags turned out to be the best option.

So many parts of it are dear to me but as a general purpose desktop user I found certain downsides of the OpenBSD approach to be critical. Yet it is a pleasure experience learning both BSDs. Will probably keep swapping drives for some time more in this laptop...
Click to expand...

You nailed it! Though, there are more cons than pros but to Theo, those are standards. And because there is no easy way to keep the system up-to-date or upgrade it (including packages) I switched from RELEASE to CURRENT, so from time to time I can sync and rebuild.
 
TeamBlackFox said:
Dealbreaker for me on using OpenBSD on the desktop is the lack of Nvidia support. I won't use AMD or Intel, the former for piss poor drivers, the latter because their GPUs are as slow as frozen molasses.
Click to expand...

Understood. OpenBSD does not support Nvidia. For me Intel graphics work well enough on Linux, FreeBSD, and OpenBSD.
 
Also in OpenBSD when I used USB, sooner or later the whole system would hardlock like it was 1995 o.0.
 
TeamBlackFox said:
Well, in my use case, I like to use a system with discrete graphics, and I know a lot of people who work at Nvidia. From what they told me, the reason they don't release a lot of code to the public is because they don't want AMD to understand how their graphics driver code ties to their graphics card. According to one of the engineers I talk to who worked first for SGI then Nvidia later on, he says that AMD's and Intel's graphics chips aren't well engineered because they don't spend as much time optimizing the kernel level code, because he has looked at the open source drivers they released. He also criticized the overuse of microcode by AMD.
Click to expand...
It's also worth remembering that NVIDIA absorbed a lot of the old 3dfx employees after they went belly up. That's actually why I went with NVIDIA, I was a big 3dfx Voodoo guy before that. From what I've read, those graphics cards wars of the 90's made a real impression on them and really fueled their desire to protect trade secrets. I understand why open source purists don't like their approach, but I still want to game while using a UNIX-like OS, and it's hard to beat the quality of their driver and hardware. Having said that, I've played with Nouveau and it's getting very good on Linux with Kepler cards, I wish DragonFlyBSD and OpenBSD had the manpower to port that driver over (I know DragonFly submitted it as a GSoC project). I never really experimented with it when it was available in the UMS era on FreeBSD, but it would be nice to have an option for people with older NVIDIA hardware who can't afford to ugrade as well.
 
I'm not an open source purist, I just don't want to be entirely dependent on a vendor for drivers. Vendors can and do drop support, at which point the users are either stuck with an end-of-life version of the operating system, or must try to come up with reverse-engineered drivers. There are open drivers for Radeon and Intel GPUs, so I use those.
 
wblock@ said:
I'm not an open source purist, I just don't want to be entirely dependent on a vendor for drivers. Vendors can and do drop support, at which point the users are either stuck with an end-of-life version of the operating system, or must try to come up with reverse-engineered drivers. There are open drivers for Radeon and Intel GPUs, so I use those.
Click to expand...
I respect that point of view as well, but NVIDIA have had a policy of dropping cards after about 5 years for awhile now (after discontinuing the old nv driver), so it always amazes me when someone is shocked that it happens. I think the problem lies more with the average consumer who buys a laptop/desktop at a big box store or on Amazon without doing research than the average customer buying a discrete graphics card, though the irony is that NVIDIA will probably drop your old eMachine's integrated graphics before they drop a GTX 550 Ti.

EDIT: I should say that many cards end up being supported far longer than 5 years - http://www.tomshardware.com/news/nvidia-eol-graphics-card,26304.html I was just giving a worst case scenario.
 
retrogamer said:
I respect that point of view as well, but NVIDIA have had a policy of dropping cards after about 5 years for awhile now (after discontinuing the old nv driver), so it always amazes me when someone is shocked that it happens.
Click to expand...

Well, I knew they weren't going to support my cards forever, but its a shock when you do a pkg upgrade and you're left with just console ... to try and buy a new card from a dot-com? ;) Well, its actually switch to different driver package. My work machine has an NVIDIA Quadro X1400, so its using nvidia-driver-304. Which I discovered still get's updates (was about to submit a patch bring it from 304.88 to 304.123, but just as I got it to build cleanly using 'poudriere testport'....the maintainer's update appears.) More recently, my home machine has an NVIDIA Quadro X1700. is now left behind to use nvidia-driver-340.

Which wouldn't be that bad, except that various linux-c6-* ports depend on nvidia-driver which causes a conflict now. I'm debating whether I want to mess around in the ports framework to resolve this, by doing something like DEFAULT_VERSIONS= nvidia-driver=340 or if it should be something along the lines of what mail/sendmail did. There are other ports that depend on this, but there used to be two slave ports mail/sendmail-sasl and mail/sendmail-ldap. Each port conflicts with the other two, and my reason for install ports sendmail was to get tls/smtps support so I had mail/sendmail-sasl installed. At one point there was a define I could put in make.conf to specify what to depend on, but not all ports used it. But, once it converted the problem went away. Now to wait and see if they do the same to print/enscript-{pagesize}. letter is the master port, with letterdj and a4 as slaves. But, seems most ports that depend on it use -a4. Thought some other port used to have this issue, that resolved things by using libpaper and having its config file set to a4 or letter by installing the corresponding package. But, so far I've shied away from (submitting) patches that touch multiple ports or the framework.

That said...the reason I was visiting the forums today....is that I'm trying to find out what I might run into if I were to replace my NVIDIA Quadro X1700 with an AMD card... either an HD4670 or a V5700, it appears both use the same chipset, though the HD4670 clocks a bit faster and has more memory, while V5700 has faster memory?

The motivation is that I've been having weird system freezes, only when I'm doing something on desktop while its busy. Pretty much is always I click on a web page. Chromium seems to like pushing GPU around (it had gotten back on work system with 304.88, which lead to discovery that there had been later point releases with the latest, at the time, being 304.123 -- the latest now is 304.125, wonder what's changed and when I'll get around to upgrading to it....probably as soon as successfully get all currently installed ports to rebuild and finish the upgrade from 9.2 to 9.3.) I have watchdog enabled, so eventually the system reboots. Though its not just chromium that is causing it to freeze, though I did find that timing-wise, both www/firefox and mail/thunderbird are being built at the same time in poudriere, where if no jobs number is set, it'll default to ncpu (which is worse than when it gets to building chromium, where not set a jobs parameter makes it do ncpu+2 if ncpu > 2, else just +1. And, things are probably a bit worse since I have -pipe set in CFLAGS. I have quad core i7 with HT enabled, and I usually run poudriere with 3 parallel jobs. With testport is let it do 8, to get the dependencies out of the way faster :D

Wonder where the Radeon HD 5450 that originally came with work machine is...perhaps after I get upgraded, to 9.3, it'll be jump to 10.1? VT-switching is something that I do more of at work....and back when I first got things working with that card.. found that VT-switch == reboot. Wish I could like remap VT-switch to screen lock....since the goal is to do something quickly that meets security policies.

Will have to see about building a 10.1 poudriere server first...

The Dreamer
 
Well, I've had some pretty basic experience with OpenBSD, then I've also been running FreeBSD as my desktop OS both at home and at work for the last several years -- this to my utter satisfaction, I must add.

OpenBSD: smooth installation process and all that's related to it. Why, you can even have the bsd.rd kernel file and boot it from any media, that will launch the installation or the shell. They also have some other helpful files ready for download, like CD boot file in case you want to make a bootable CD for purposes other than installation/rescue.

I was also able to create a bootable USB flash drive (4G) from which i run OpenBSD with / /usr /home mounted read-only and /dev /var /tmp as tmpfs. Not sure such configuration would be supported by FreeBSD, but I never tried either. Also, some wifi drivers are present in OpenBSD which are not in FreeBSD... or am I mistaken? But this is all related to its suitability for network server usage.

With FreeBSD the installation process is simple as well, but in a different sense... And it has ZFS, which was decisive factor of my preference in favor of FreeBSD over OpenBSD.
Maybe HAMMER fs is also good, but the docs from the dragonfly bsd left me with the feeling that the installation process is not as straightforward there, and that less ports would be available. Neither could I find a lot of information on that. And I don't have enough time to do all the testing...

Also, as a BASIC desktop system on my laptop OpenBSD proved to be very easy to install, configure and make it a running system.
Good out of the box support for Intel processor graphics, it also comes by default with FVWM2 WM with a good config file, which is pretty much all I need from a desktop system. All the rest I needed for a desktop was easily installed via packages, and these happened to work, unlike FreeBSD packages with which I'd had a bit less of luck...

And these I've mentioned are not pros or cons in my opinion, they are just differences depending on the target use intended for each OS. I feel that both OS's do a good job. I'm still running FreeBSD on the 3 computers I'm using, and OpenBSD as my network gateway in the office. OpenBSD folks say it's slower just like a massive safe door is slower than a normal apartment door... I don't mind that, neither do I feel that on my small server.

CONCLUSION: I really appreciate we have this variety. Learning both OS's is enriching and I really love both for the high quality OS's that they are...
 
You must log in or register to reply here.
Back
Top