Guest post by I’ve been a big fan of FreeBSD since I first acquired 4.4 on 4 CDs. By that point, I had already spent a lot of time in Linux, but I was always put off by its instability and inconsistency. Once I had FreeBSD installed, it felt like a dream. Everything worked the way it was supposed to, and the consistency of its design meant even older documentation would be mostly applicable without having to figure out how my system was different. There is a reason why in the early days of the Internet, a huge portion of servers ran FreeBSD.
But, that was a while ago. Since then, Linux has matured greatly and has garnered a lot of momentum, becoming the dominant Unix platform. FreeBSD certainly hasn’t stood still, however. The FreeBSD team has kept current with hardware support, new features, and a modern, performant design.
As far as hardware support, it is extremely well supported on i386 and amd64 architectures, which are considered Tier-1 platforms.. PowerPC, Sparc64, ARM, and ia64 architectures are considered Tier-2. This means that those systems are not supported by the security team, and security patches must be ported to the individual architectures by their respective teams. Additionally, new features added to Tier-1 should be workable on Tier-2 platforms, but implementation isn’t required before integration into the main source tree. Tier-2 systems shouldn’t be considered broken – they generally work quite well, even in production environments. Sparc64 is perhaps the best supported of the Tier-2 platforms.
I don’t really have access to a wide range of hardware at all – my Dell laptop is the only thing I can really tinker with, so most of this review was conducted in VMware, which fully supports FreeBSD. I would actually prefer FreeBSD, but for two minor problems. First, at least on my laptop, FreeBSD may not properly throttle back the CPU when it gets too hot, so tasks that really hits my laptop hard cause an overheat alarm and the FreeBSD will shut itself off. This has only happened once, and it did shut-off gracefully. The other one isn’t so minor: My laptop has hybrid graphics (IntelHD and NVidia). There is no way, supported or unsupported, to use the NVidia graphics. This is fine 90% of the time, but for that 10%, I’d really miss it.
Finally, FreeBSD might be the most prominent of the BSDs, but it certainly isn’t the only one. In the upcoming weeks, I will be doing more of these covering some of the other BSDs.
Installation and Configuration
For a long time, FreeBSD used the venerable sysinstall, a text-based installation system. It wasn’t pretty, but it worked well. Recently, they switched to bsdinstall, a text-based installation system which isn’t pretty, but works well. It has lost some features while gaining others, but it is a much more flexible design, and will ultimately be significant improvement. The install process is currently simpler, but bsdinstall offers greater levels of scriptability and customization, if your environment requires it.
The install process itself is fairly straight forward, but there are definite benefits to being familiar with FreeBSD. They steps consist of configuring your network, partitioning the disk, and choosing your distribution components from a total of five options. After this, the root password is set, and a users can be added. One thing that it doesn’t tell you is that if you want to be able to su into the root account, the user needs to be a part of the group wheel.
Another area of potential trouble that the installer doesn’t alert you to is that if you are sharing a disk with another OS, the FreeBSD bootloader won’t be installed. After copying files, and before rebooting, the opportunity is given to drop to a shell for further configuration. A single command is all that is needed to install the bootloader in this situation. Unfortunately, there is no immediate help given on how to do this, or that it even needs to be done, but information on what to do is located in the FreeBSD Handbook. Again, it is very helpful to have prior experience with FreeBSD to fix this.
Overall, the installation is quick, taking only about 10 minutes or so from a USB stick to a hard disk. When it’s done, it boots to a console login prompt. Some further configuration may be needed. This may involve adding extra users if required, and configuring additional network adapters, as only one is configured during the install.
After configuring the base system, the next thing you’ll want to do is update the system and install the ports tree. The system can be updated with the FreeBSD-update command. This will install the latest security patches. FreeBSD differs from most Linux distributions, in that updating the system provides only security updates, and not feature-updates. New feature are rolled into new releases, which happen on a roughly annual basis. If you need to customize your system, you can download the latest source and rebuild the the kernel or the whole system, depending on your needs. The source tree and the FreeBSD Handbook have much documentation on this process. On my laptop, with 8GB of RAM and a 2.2GHz quad-core Sandy Bridge processor, make -j10 buildworld (which builds the entire system) takes about 45 minutes to complete.
For additional software, the ports tree is one of FreeBSD’s strong points. There are more than 24,000 ports available. A simple make install will build and install an application and all of it’s dependencies. It will prompt you to set configuration options if needed, and will even create package files if instructed. If you need to use another system to grab the package files, you can even generate a shell script that will automatically fetch the needed files for you. There are also a whole suite of port management tools to ease the processes of updating and upgrading software.
For regular package management, FreeBSD falls flat initially. It’s package tools are rather antiquated, and lack many features. For example, there is no built-in way to upgrade a package automatically – it has to be uninstalled and reinstalled manually. There are ports available to streamline certain package tasks, however. For example, you can use bsdadminscripts from the ports tree. This provides tools to automatically upgrade packages without having to build them via ports. However, the bsdadminscripts package still utilizes the regular package tools, and because of that is limited in what it can manage. There is a much superior option available, however, that modernizes FreeBSD package management.
Available in FreeBSD 9.1 (but not yet ready) is pkgng, the precursor to the next package system due to arrive in FreeBSD 10.0. This tool adds significant functionality and makes package management much simpler. Tools are included to convert your package database from the old system to the new. Currently, the only packages available from the FreeBSD servers via pkgng is pkgng itself. However, the folks behind PC-BSD have setup a pkgng repository with instructions on how to use it with FreeBSD, and this is what I recommend you do. If you have newer Intel graphics, this is necessary if you don’t want to build Xorg yourself, since PC-BSD defaults to a new version built with KMS support. Most packages available in ports should be available, and ports can be integrated into pkgng, using that for package installation rather than the old method. Using pkgng to install a group of packages performs significantly faster, as well. Again, I strongly recommend you use this setup.
One of the great features of FreeBSD is native ZFS support. All the needed tools are included out of the box, and all that is needed to be done is to add zfs_enable="YES" to /etc/rc.conf. This will allow your ZFS pools and datasets to be automatically mounted at boot. If you plan on using Jails (as I am in this review), I would strongly recommend ZFS to host your jails on. ZFS’s snapshot and copy-on-write features make it an excellent choice for managing your jails efficiently.
It isn’t necessary to use ZFS for the rest of the system. In fact, bsdinstall doesn’t handle ZFS too well beyond basic zpool creation. However, if you are set on using ZFS from top to bottom, it is possible and not at all difficult if you’re comfortable with the console. I won’t cover that here, but there is an excellent guide for having ZFS as root. If that guide doesn’t quite fit for your needs, there are plenty more.
Jails and Virtualization
Jails are one of FreeBSD’s flagship features. They provide advanced features compared to traditional chroot environments, without the security problems traditional chroots have had. Processes within a jail cannot see processes that exist outside of the jail. Additionally, each jail has it’s own IP addresses and hostname. Like any OS-level virtualization option, the kernel is shared, so you can only run FreeBSD-built software within a jail. However, unlike true virtualization solutions, there is absolutely no performance hit. Networking and disk I/O operate at full speed.
There are three ways to install a jail. First, you can use bsdinstall, the same install program that installs the base system, to install from an installation disk. Alternatively, you can download the source for FreeBSD, compile it, and install into a jail location.
Finally, you can use ezjail, available via the ports tree. This the most widely used and easiest to use solution. If you use ezjail, it conserves disk space by using FreeBSD’s nullfs feature to create a duplicate userland without copying files. Additionally, ezjail will take full advantage of ZFS features, using it’s own native snapshot and copy-on-write to also avoid duplication of the userland.
Using ZFS with ezjail is simple. Just create a new zpool mounted at /usr/jails, then change a handful of ZFS-related settings in /usr/local/etc/ezjail.conf. This file is well documented within the file, and there is also a man page with more detail.
Using ezjail, creating a basejail is as easy as running ezjail-admin install. All subsequent jails are based on the basejail, but it is possible to create other flavors if you are running multiple jails with common features. Options are available to include the ports tree, man pages, choose where to download the base system, or choose the release version you wish to use. You could potentially even install a significantly older FreeBSD release in a jail. This hasn’t been well tested, but there is no real reason why it shouldn’t work. It is even possible to install the Debian/kFreeBSD userland inside a jail, as well as something seemingly crazy, but still useful: CentOS 5.5 in a jail.
I created three jails on my test installation: A publicly accessible web server running Dokuwiki, a server to handle dhcp and dns for an internal network, and a Samba server providing shared storage. In a situation such as this, if the publicly facing web server was compromised, the rest of the system would remain protected.
While the security offered is potent, it isn’t automatic or 100% complete. There are a number of well documented and well understood situations where a privileged user within a jail can team up with an unprivileged user on the host to and get privileged access on the host. Care must also be taken when creating devfs rule sets for jails. By default, only a very limited selection of devices are accessible within a jail, but many services require greater access to certain devices. As an example, dhcp needs access to packet filter devices, and the OpenSSH server needs /dev/random. If a device node is exposed to the jail in an insecure way, such as write access given when only read access is needed, and that jail is compromised, the misconfiguration might be leveraged to cause havoc.
FreeBSD Jails have been around since the 4.x series, and while mature, until recently it has lacked a key feature round in Solaris Zones and Linux OpenVS: The ability to impose resource limits on per-jail basis. New with 9.x is Hierarchical Resource Limits. This system allows an administrator to place various limits on jails, and have triggers for each limit that can log events, execute scripts, or deny resources. Triggers can be set for various counters, such as memory usage, stack size, process count, or others. Currently, CPU rate and I/O limiting isn’t implemented, but CPU rate limiting is coming for 10.x.
If jails isn’t enough to meet your needs, and you need to virtualize your whole system, FreeBSD makes great guest OS. The best option is to run it under VMware, as it is officially supported by VMware, and has been for several years. FreeBSD is also supported under Amazon’s EC2 service, and tools are available to create instances to run under Microsoft’s Azure service.
If you want to virtualize FreeBSD on your desktop, FreeBSD’s support of both VMware and Virtualbox guest additions is complete, with accelerated graphics, automatic cursor grabbing and ungrabbing, and shared folders. It also runs under Parallels Desktop for OSX, and both VirtualPC and Hyper-V for Windows.
If you wish to virtualize another OS on your FreeBSD system, your options are rather limited. Currently, only Virtualbox runs, and that is without USB support, since that requires a closed-source, proprietary driver that isn’t available for FreeBSD. Aside from the lack of USB support, Virtualbox is stable and runs as expected.
FreeBSD on the Desktop
It doesn’t happen automatically, but FreeBSD can be made into a fine desktop. If you are a KDE user, the story couldn’t be much better. The latest KDE version is always available via ports, since with each release the KDE team keeps an eye towards FreeBSD compatibility. Installation, whether via ports or packages, presents a KDE desktop, with the only modification being the initial background image.
Gnome is a different story. Gnome 2 is available in the Ports tree, but Gnome 3 is not. Most of the Gnome developers don’t seem to interesting in supporting anything other than Linux. There is third-party repository available at www.pkgdemon.com that provides a method to build Gnome 3 inside of the ports tree, as well as Cinnamon if you prefer an updated Gnome 2 desktop. I am not a Gnome fan, so I did not attempt this.
Some things are important to know about running Xorg on FreeBSD. First, the packaged Xorg (as well as the default configuration when building from ports) includes hald and dbus, but those services are not enabled by default, so when you launch X, your mouse and keyboard won’t work. To enable them, hald_enable="yes" and dbus_enable="yes" need to be added to the /etc/rc.conf file.
Second, and more importantly, video support is somewhat limited. Currently, Kernel Mode Setting is only partially implemented. IntelHD graphics requiring KMS work with some caveats (Such as, no text console after the kernel module is loaded, and a kernel panic when unloading the module), but AMD Radeon chipsets are not. Pre-KMS drivers do work, with 3D acceleration when available, and NVidia graphics are fully supported by NVidia’s proprietary driver. This driver actually works very well and is well supported. It has been available for 10 years, and provides the necessary libraries for running OpenGL applications under Linux emulation. Performance should be good (It was awesome in the past, rivaling Windows XP and besting Linux by 50%), but I unfortunately cannot test the current versions, as my laptop is an uses NVidia’s Optimus, and I can only use the IntelHD graphics under FreeBSD.
There are some other issues with FreeBSD as a desktop to be aware of. A weird quirk of FreeBSD package management is that the default package repository doesn’t get updated; all the packages are the same version as what is found in the ports tree included with that particular release. Besides the RELEASE branch, there is also STABLE and CURRENT. The STABLE branch is updated along with the standard ports tree, and there is typically about a week or so of lag time between the port being updated and the corresponding package being available. If you want the cutting-edge branch, you can switch to CURRENT, which provides the absolute latest, untested packages. Currently, CURRENT and STABLE are identical, but this isn’t always the case.
Also, even when the packagesite is correctly set, it might not find existing packages. This occurs because, when you do something like pkg_add -r firefox, it will look at a path normally ending in Latest/firefox.tbz, which is a symlink to ../All/firefox-##.##.tbz (Depending on the version). The symlink might be pointing to an older version that is no longer there. Using the full path to the correct package will fix this issue, or you can wait for the symlinks to be updated. Of course, using PC-BSD’s package repository with the new package manager doesn’t have these issues. I can’t understate how helpful this is.
Obviously, FreeBSD has a ways to go to be as smooth on the desktop as newer Linux distributions, but if you are willing to put up with these relatively minor problems, it does make a fast, stable desktop. Adobe’s Flash player is available via the Ports tree (It uses Linux emulation and a shim to provide it to native browsers). There are also plenty of kernel tunables to optimize your system for desktop usage (There is a good guide available here), and ALSA and PulseAudio emulation is available when applications don’t support OSS.
Final Thoughts and the Future of FreeBSD
FreeBSD is a complete and well-engineered system. While much of what they do involves less fanfare than Linux, they have a strong and active development and user community. They have kept pace with technology and still maintain a powerful system with modern features, and have done so mostly without anything feeling tacked on. The consistency of the system is why I prefer it over Linux – significant changes can rarely, if ever, be described as disruptive. But, changes still are made.
Slated for FreeBSD 10 are a number of improvements, many incremental. Virtual Private Systems, or VPS, is a new OS-level virtualization technology that will offer true virtualization of kernel resources, even providing live migration between hosts. The BSD Hypervisor is also nearing completion, which will turn FreeBSD into a type-2 hypervisor. KMS is also being expanded upon, with AMD graphics slated for support, and many other more incremental changes are coming, but there is a major change looming on the horizon.
Very important from a technological standpoint as well as a philosophical standpoint is removal of GPL from the base system. There are some environments where the GPL is not appreciated or allowed (such as certain embedded scenarios), and these changes allow FreeBSD to fit into those environments. It is also important for the FreeBSD project, as it helps to strengthen the identity of the project and the license. FreeBSD 10 is slated to be released the 18th of November, and the team is very good about hitting their target dates.
There is still plenty of development going on the BSD world, and as I alluded to at the top, this is meant to be the first of several articles on BSD that I’ll be writing in the coming weeks, time allowing. OpenBSD and NetBSD are of course on my list, as are a half dozen or so other smaller or more specialized BSD projects. So, stay tuned!
David Hutchinson is a student of both Networking and Computer Science, and an all-around science and technology enthusiest.
There were many nice features, such as the ports collection and the stability was unmatched for a time. It was kind of awesome to have a book that was definitive in the documentation of the system in a way that linux never could match as it changed way too frequently.
I think the lack of a decent threading library and rapid improvement in Linux fueled by corporate funding kind of tilted the momentum in Linux’s favor.
That’s not to say that FreeBSD is terrible to use today, but it doesn’t meet my personal/professional performance requirements on a server or a desktop.
Lack of a decent threading library? Do you have any source?
I don’t know BSD that well, but threading on UNIX systems had lots of problems in the beginning.
Operating systems like BeOS, OS/2, Windows among others, have as scheduling unit, threads, whereas the UNIX model uses processes.
So the whole transition to support threads on UNIX systems, had each system apply its own solution, before pthreads became integrated across UNIX systems.
http://jeremy.zawodny.com/blog/archives/000203.html
This is what I ran up against back in the day. Obviously things are different now with threading on FreeBSD, but there are so many packages that are built with only linux in mind. FreeBSD is used in many different high performance situations, and actually I do use it in a few of those too.
I plan on this being the first in a series of all the BSD’s. I’m thinking of tackling NetBSD next – I’ve got it running on emulated Sparc64 hardware (via QEmu), and might be doing some work on real hardware, too. If there’s anything anybody wants to see specifically regarding NetBSD, reply to this comment.
Also, by the time I’m near the end of the series, FreeBSD 10 will be out, and with the enhancements coming to KMS, as well as laptop support in general, I’ll definitely be talking about the new features entirely on real hardware.
Maybe I’ll use FreeBSD 10’s new hypervisor, BHyVe, to cover Debian GNU/kFreeBSD.
Edited 2013-09-25 23:55 UTC
Thanks for the article. I’m also looking forward to a series on netbsd, openbsd, dragonfly .. and maybe pc-bsd which isn’t really different just made for desktops.
If I can make a humble request for the article series:
* I’d like real facts. We keep hearing lots of opinions on “stability”, “high volume traffic”, “low memory footprint”, “bad concurrent performance”. Things have moved on since 2002. I’d like to see a proper set of tests done to back such claims up – what do we mean by “stability”, .. the last set of tests I saw were probably a decade ago http://bulk.fefe.de/scalability/
Tests could include things people care about today like latency under io load, etc.
* rather than focus just on user-facing features, maybe talk about the internal engineering of these systems. These systems actually do have engineering principles that they are built to and evolve around. Perhaps a critique of whether such lofty goals are a worth it – the relative free-for-all in Linux seems tr have paid off, or has it? Does the human intensive code auditing of openbsd have value if 3rd party apps are badly done? Should netbsd be the true core bsd from which drivers are then reimplemented elsewhere?
I don’t mean to detract from your good work – it’s great – just saying what I’d personally like to see.
Honestly – for a good bunch of serious users, the installation is done once, boot up times are kinda less important on long-running servers….. the focus is more on what these systems are like in operation … threading performance, latency, resilience to failure, ease of upgrading and management ….
I will be sure to include some more info on internals and now the different BSDs are put together, and how they differ from each other.
Since FreeBSD has an excellent system architecture handbook (http://www.freebsd.org/doc/en/books/arch-handbook/), I’ll touch on it more when I come back around when 10 is out.
I am looking forward to the rest of the series, exactly as you have planned it.
I don’t get as much time for researching things as I should, so articles like this are a big help to me!
Although I no longer use it much, I’ll always have a soft spot for FreeBSD. It’s served me well over the years on both desktop and servers.
I’m already deeply vested in linux, but I’m considering trying out BSD for my server hosting environments. There are several features that I want which linux doesn’t give me directly:
ZFS – obviously.
Union mounts – Sometimes it’s exactly what’s needed and it’s so annoying that it’s not available in mainline due to the linux head honchos refusing to incorporate any overlay fs into the kernel (ie aufs or unionfs)
Secure root jails – while I’m very pleased to have linux containers in mainline (ie lxc-*), the virtualization has been incomplete for a long time. Not that the missing pieces are important for functionality, but the lack of secure containment kills it for me (/proc/sysrq-trigger,dmesg,hard coded uid==0, etc).
One thing that’s holding me back with FreeBSD is the lack of full virtualization (KVM), although I hear that may be coming in v10.
I’ve found that Linux generally has excellent hardware support on servers, but I don’t know where BSD stands (Ie network drivers & raid controllers like the LSI megaraid used in dell poweredge servers).
I’m pretty sure the controllers that Dell uses in their Poweredge servers are suported – Dell’s PERC H700 and H800 series use the LSI SAS2108, which is supported by the MPS driver.
Network drivers should be supported, as well.
(http://tinyurl.com/ppmjqdm)
The full HCL can be seen here:
http://www.freebsd.org/releases/9.1R/hardware.html
Well, GNU/Linux has a lot of hardware drivers but all these drivers are quality drivers? And do you really need that exotic controller on you mission critical server?
Yes, Linux has some 150.000+ drivers and a couple of 100 drivers released every week. There are only so many Linux developers, so they will never be able to update all of them when Torvalds changes the API in the kernel. That is one of the reasons Linux is unstable, unless you are very restrictive with what software you install. If you are on a Long Term Cycle distro, like LTS, and you want to install some kind of software that uses new libraries, you need to upgrade your libraries too. Which forces you to upgrade other software on your system so they can use the new libraries too. etc. This triggers a chain reaction so you have upgraded your entire system. Ergo, LTS does not work. You can only use LTS if you install old software, or, if you hack the software so it uses your old libraries.
So, no, most Linux drivers does not work. When Torvalds upgrades the kernel and changes the API, drivers does stop working. So of these 150.000+ drivers, I wonder how many of them are up to date? Maybe 5%? 95% of the drivers does not work?
http://www.osnews.com/permalink?561858
“…You have 150,000+ drivers for Linux, with a couple of hundred new devices released WEEKLY..how many Linux kernel devs are there again? if you pumped them full of speed and made them work 24/7/365 the numbers won’t add up, the devs simply cannot keep up…which is of course one of the reasons to HAVE a stable ABI in the first place, so that the kernel devs can work on the kernel while the OEMs can concentrate on drivers…”
Ah, but OEMs are evil, remember? They make hardware and accompanying drivers for profit, when they should be donating every waking hour to support Linux and giving their time for free. </sarcasm>
If you hadn’t picked it up yet, I agree 100% with you concerning the ABI as well as the API. It’s attitude that prevents this from happening; the pervasive entitlement complex that has made its way into most corners of the Linux community.
Kebabbert,
“So, no, most Linux drivers does not work. When Torvalds upgrades the kernel and changes the API, drivers does stop working. So of these 150.000+ drivers, I wonder how many of them are up to date? Maybe 5%? 95% of the drivers does not work?”
Has this actually affected you or are you just trying to paint linux more negatively than it is? Trust me I want a stable ABI/API as well, however in practice I’ve found long term linux driver support to be simply amazing. If you pull out an old device that used to work with linux, it’s more likely to still work under linux than under windows.
I cannot complain about the device support itself, but I have gripes with how drivers all mashed up into a huge bloated kernel tree. There’s no simple way to determine what one needs to select in the kernel, it’s very discouraging. The drivers are pretty good, but the management of them is absolutely horrid and I end up compiling way more than I need because I just don’t know what drivers I’ll need. I’d rather see all of these drivers stripped out of the kernel source and separated into more manageable projects (using a stable API/ABI).
Thinking off the cuff, ideally a standardized userspace framework would take care of managing device drivers transparently as needed in the way which makes the most sense for the particular linux distro (downloading drivers from a repo/compiling from source/install from disk/notifying the user). This way one could compile a simple kernel up front and the drivers could be managed separately and only compiled as they’re needed.
To rope this back to the article’s topic, can someone illustrate the BSD driver code&binary management? Does the model differ much compared to linux?
Hi, I think you will find interesting the arch-handbook you can find here: http://www.freebsd.org/doc/en/books/arch-handbook/.
Happy reading.
He’s just pissed at Linux for some reason and brings up this tired old “Linux isn’t stable” harangue like a broken record.
Alfman,
Every once in a while in forums, I read about people having unstable Linux systems. I tried to help a friend with Ubuntu who got problems after upgrading the kernel. After that, I recommended against upgrading the kernel. If it works, why upgrade? Just because Ubuntu says so?
I think the Linux driver model is broken. Actually I am not the only one saying this, as you maybe noticed. If you think about it, I think you will understand why the driver model is less optimal. It could be better, dont you agree?
No, there are hundreds of new devices every week. Didn’t you read what you yourself quoted?
Most new devices does not need a new driver anyway since a) many of them are just “clones” of existing devices and b) one driver usually handles many devices.
Really. I can’t even remember the last time I encountered a driver that didn’t work.
What does “up to date” really mean though. If it’s an old(er) device a stable driver doesn’t need to be constantly updated.
I don’t have them either because I am careful about how I buy my hardware because I might want to run something on there other than Windows. Every laptop I buy is Intel based everything, every desktop-ish bit of kit is intel + nvidia (nvidia have the better drivers and if I don’t need 3d VESA will suffice).
It is a lot a hell better than 10 years ago, but there are still times when something is either supported poorly or there are problems with it.
I do however that a lot of the driver problems have been solved by things becoming more commodity because the hardware manufacturer developers are just going to say “just use the standard spec”.
Edited 2013-09-26 20:07 UTC
True but that goes for any OS.
Kebabbert, you look like a parrot.
You said the same thing(with other words) about kernel API breakage :
here – http://www.osnews.com/permalink?573118
here – http://www.osnews.com/permalink?566906
One does not need to be too much dramatic. Things dont break so easy as you sad.
Back to the topic, the thing i miss on FreeBSD is the lack of Dogfeeding on Notebooks/ACPI related things, and that’s why my notebook uses OpenBSD…
@Soulbender, @Risthel
So both of you dont agree that the Linux driver model could be better? You never see any threads about people having problems after upgrading the kernel?
When anyone, me, or bassbeast or anyone else, point out all the problems with Linux drivers – we get called ugly names, “parrot”, “idiot”, etc. Is it not acceptable that people thinks the Linux driver model is not good, and could be done better? Linux can not have flaws? The source code is far from good?
The whole idea of how the Linux kernel works is that you have to GPL your code.
You have to play by their rules or f–k off. That is their decision and they want people to play by their rules.
Some people think that is justified. You and I don’t believe that is okay.
For me it is against the spirit of something which is open source, but I don’t believe anything that is GPL is in the spirit of sharing and giving something away.
If I give my work away it will be under a license that allows the person to do anything they want with it.
Edited 2013-09-26 19:59 UTC
I have never said it couldn’t be better but I don’t agree that it’s fundamentally broken and that Linux isn’t stable.
You’re free to think whatever you want and I’m free to disagree. You may notice a distinct lack of thought police at your door.
Oh, it has flaws alright but so does every OS.
I wouldn’t know, I haven’t look at it much but I’m sure it’s better than what either of us could do.
@Kebabbert
I did not said that Linux driver model is the best, not either is “good enough” to all the situations. You are just painting Linux way worst than it is.
This is a cicle that NEEDS to end. People grow up, but it seems that still needs to be tied to old misconcepts(or exagerate some of them) painting the other technology as the worst. Linux users making Windows technology the bad/ugly, and BSD users annoying Linux around.
For things that really matter, you only buy them that already have linux support. Like the aforementioned dell server, most major hardware vendors have their gear certified to run linux. They aren’t unstable at all.
davidone,
“Well, GNU/Linux has a lot of hardware drivers but all these drivers are quality drivers?”
Mileage varies. Drivers that are problematic (in my experience) have been for the desktop (video/sound) or those for consumer devices that are added to the machine without researching linux compatibility (I was given a doxie scanner as a gift, but company behind it has said they would never support linux or release the specs, they’ve pulled the statement due to criticism but their policy is effectively unchanged).
On the other hand for a server I think you’d be hard pressed to find a server that linux doesn’t work with even if you buy it at random. Some of the userspace components may be trickier to get without manufacturer support (ie raid monitoring/management).
“And do you really need that exotic controller on you mission critical server?”
Raid controllers are not really exotic on performance servers, and yes we do need it if we don’t want to give up features like battery backup write back caching and hotswap, RAID offloading. With this you can commit transactions at tremendously high speeds even with RAID6. The backplanes in servers are often hardwired for the raid controller so you cannot really bypass them.
Don’t confuse this with the “soft” raid that comes with low/mid machines.
I agree with you: I cannot buy a server if I don’t find it’s fully supported by freebsd (drivers and so on): I think every sysadmin should do so for every operating system.
Raid controllers aren’t exotic on servers, I agree.
The problem is when you have a server with an exotic controller onboard
I use only LSI/Perc and Areca ones.
Yersterday I read a news item about Whatsapp processing 31 billion messages each day (wft!).
From the comments on this article I understood that their services are written in Erlang and their servers run FreeBSD. Seems FreeBSD made a good case in such a high traffic envrironment.
More info:
http://vimeo.com/44312354
(I provided this link without verifying, since I cannot view this video here. So don’t blame me if it is some weird cat movie ;-))
Well, if you are interested in FreeBSD in *nice* production environments, please take a look at: https://signup.netflix.com/openconnect/software or sony/playstation4 platform (here probably because of BSD license
)
I’d really like someone to explain why freebsd is better for such workloads than linux.
I keep hearing it is better for “high volume traffic” – but why exactly?
The biggest “stability” or “workload” issue we’ve come across comparing our FreeBSD systems to our Debian Linux systems: if a process spins out-of-control on Linux, spiking load averages over 20, there’s nothing you can do but power-cycle the box. On FreeBSD, you can still SSH in, kill the process, and carry on.
We run into this 2-3 times a month. For some reason we haven’t been able to track down yet, BIND9 will peg the CPU at 100% and we’re unable to login to the Linux box over the network. Have to phone the school and ask someone to power-cycle the box.
On the FreeBSD systems (ZFS storage boxes), even when I do stupid things that run it out of RAM or CPU spikes or I deadlock the storage pool, I can still login via SSH and fix things.
This is a common occurrence on various mailing lists/forums I’m on as well. Once a process spins out of control on Linux, you’re locked out; a similar situation on FreeBSD is usually fixable.
Thanks – I appreciate a real world example to illustrate the differences between Linux and FreeBSD.
Just install memlockd on Linux, and you’ll never run into problems anymore when ssh’ing your servers.
Never heard of it. I’ll add it to my list of interesting things to read about in the future.
Thanks for the tip.
Interestingly enough in our organization we’ve had the opposite issue.
Some FreeBSD boxes have processes that die every now and then (ldap,sshd. etc and even bind) rendering them inaccessible from the network. Someone with console access can restart those services no problem, and things get back to normal. Whereas linux boxes (workstations mainly) tend to be accessible through the network,even when their console is locked up by some nasty process.
Still, freebsd + zfs makes a fantastic file server. I’d actually be interested in seeing performance benchmarks between llvc and gcc FreeBSD systems.
Be it on FreeBSD or Linux or any other *nix, if you have this problem you should use monit (or similar) to make sure those critical services are always running and responding.
That said, I have never had sshd crash on either BSD or Linux.
Logging in to or even using Linux systems with ridiculous load averages is a problem that got solved with “the patch that does wonders” included in 2.6.38.
I created a “fork-bomb” that created 200 instances of itself, all of them using all CPU time that are allowed to use. The load average moves asymptotically towards 200 and logging in/out of the system via SSH is more or less as fast as if the system was idle.
I did this over SSH:
$ cat /proc/loadavg
199.67 144.58 67.66 2/145 3769
$ pkill forkbomb
# wait for some time
$ cat /proc/loadavg
0.00 9.76 28.43 1/144 3984
I can even do this on a virtualized Linux environment running on a dual core laptop without any problem. The only thing you need is a kernel at or last version 2.6.38.
Edit:
Here some comments from users about the patch (@Phoronix)
http://www.phoronix.com/scan.php?page=article&item=linux_2637_video…
Edited 2013-09-27 07:49 UTC
Ah, most of our servers are still running 2.6.32 (mostly Debian 5; in the process of being upgraded to Debian 7).
Thanks for the good update on what’s going on in BSD world. I use Linux and the commercial Unixes (AIX, HP/UX, Solaris) so it’s nice to know what’s happening on the other side of the fence.
I’ve tried PC-BSD several times on home PCs, but have had little luck with it. PC-BSD is a noble effort but the developer team is so small that bugs don’t seem to get fixed very fast. I hope to get time enough to try FreeBSD sometime.
Cheers.
I moved from FreeBSD to PC-BSD on my home desktop/server with 9.0. It wasn’t pretty, and I messed up a lot of things before I learned “The PC-BSD Way”. Tried using PBIs and ran out of disk space. Tried using PC-BSD tools and messed up the boot process. Tried a bunch of different things and gave up in frustration. Turns out I was trying too hard to be clever instead of just going with the flow.
Then I restarted from scratch with PC-BSD 9.1, avoided PBIs completely, switched to the rolling release based on 9-STABLE (which actually switches the install to TrueOS instead of PC-BSD), migrated to a full ZFS-on-root setup, and started using pkgNG for everything. Things have been extremely smooth, and very “Ubuntu-like”, in that there’s no compiling of anything, anywhere.
“freebsd-update fetch install” once a month keeps the OS up-to-date. Using Boot Environments with ZFS even makes it an almost fool-proof process (clone new BE, boot into new BE, do the upgrade, test, make new BE default or revert to old BE).
“pkg update; pkg upgrade” every two weeks keeps all the software up-to-date.
It’s actually fun to use the computer upstairs again.
It was getting very brittle and finicky there for a bit (mixing ports and packages; mixing binary and source OS updates; trying to be “too smart”, etc).
I really did enjoy reading the article. Being a FreeBSD user myself since v4.0, I think you did a great job describing what FreeBSD is and how you’ve eyperienced the current release.
I noticed a few inaccuracies which I’d like to comment on; also allow me to add some words regarding statements I find notable.
“As far as hardware support, it is extremely well supported on i386 and amd64 architectures, which are considered Tier-1 platforms.”
There are new restrictions, especially regarding peripherials that violate existing standards. Especially in case of mobile hardware (laptops for example) this can be significant. Intending to use FreeBSD on such a device usually involves research prior to the act of purchasing, and maybe getting hands dirty after purchasing. It still can be worth investing the work.
“First, at least on my laptop, FreeBSD may not properly throttle back the CPU when it gets too hot, so tasks that really hits my laptop hard cause an overheat alarm and the FreeBSD will shut itself off.”
This can be the case of improper ACPI implementation. You could add “device coretemp” and “device cpufreq” to the kernel config and make sure you have loaded the appropriate ACPI module. There’s also powerd in the base OS.
“The install process is currently simpler, but bsdinstall offers greater levels of scriptability and customization, if your environment requires it.”
If you need to do something “non-standard” (like dedicated disk layout), you can still easily drop to a command line shell. In case you really want to do “something strange”, you know how to do that with CLI tools.
“The install process itself is fairly straight forward, but there are definite benefits to being familiar with FreeBSD.”
A good idea is to have a printed copy of the relevant handbook sections, or make them available via WWW on a second machine. Someone entirely new to the FreeBSD operating system will definitely benefit from the excellent documentation. Things not mentioned by the installer (e. g. usage of “su root” requires “wheel” group membership, or how to install bootcode for a boot manager) is covered there.
“After configuring the base system, the next thing you’ll want to do is update the system and install the ports tree.”
A working ports tree can be obtained during installation from the media. Of course that tree is dated exactly like the OS, so if you want more recent entries, updating the ports tree is needed via Internet.
“The system can be updated with the FreeBSD-update command.”
The command is “freebsd-update” (all lower case).
“FreeBSD differs from most Linux distributions, in that updating the system provides only security updates, and not feature-updates.”
The main difference is that FreeBSD does provide a consistent operating system “as a unit”, maintained by the FreeBSD team, whereas Linux “base systems” are a composition from packages just as the creators of the distribution decide. The FreeBSD OS consists of a kernel, userland tools and libraries (called “world”), and the source code. All those parts can be subject to freebsd-update. Every other software (coming from the ports collection) does technically not belong to FreeBSD (as “the operating system FreeBSD”).
“New feature are rolled into new releases, which happen on a roughly annual basis. If you need to customize your system, you can download the latest source and rebuild the the kernel or the whole system, depending on your needs.”
It’s worth mentioning that world and kernel should always be in sync version-wise. Still it is possible to change kernel configurations without requring a rebuild of the world.
“The source tree and the FreeBSD Handbook have much documentation on this process. On my laptop, with 8GB of RAM and a 2.2GHz quad-core Sandy Bridge processor, make -j10 buildworld (which builds the entire system) takes about 45 minutes to complete.”
“A simple make install will build and install an application and all of it’s dependencies.”
And its dependencies.
“It will prompt you to set configuration options if needed, and will even create package files if instructed.”
The ports collection offers even more functionality. It’s a whole consistent framework to fetch, install, update, remove, search and patch software. There are management tools, for example portmaster, that can optimize those processes.
“For regular package management, FreeBSD falls flat initially. It’s package tools are rather antiquated, and lack many features. For example, there is no built-in way to upgrade a package automatically – it has to be uninstalled and reinstalled manually.”
In combination with an updated ports tree, portmaster can do this (using -P and -PP options to use precompiled packages instead of compiling stuff from source). The new pkg tool (pkgng) intend to solve the problems of binary updating. It can already be used (with few limitations).
“Using pkgng to install a group of packages performs significantly faster, as well. Again, I strongly recommend you use this setup.”
Compiling from source is only needed in few specific cases, for example when no package is available for a specific combination of options you want to enable or disable (packages are built with the default options), or if you need to apply specific optimization to gain performance. A good example is mplayer if you want it to be as complete as it can be.
“If you want to virtualize FreeBSD on your desktop, FreeBSD’s support of both VMware and Virtualbox guest additions is complete, with accelerated graphics, automatic cursor grabbing and ungrabbing, and shared folders.”
In this case, check out VirtuelBSD – this is a preinstalled and preconfigured VM image that does not require any installation and can be used for “trying out” the system.
“It doesn’t happen automatically, but FreeBSD can be made into a fine desktop.”
I can confirm this, as I’m using FreeBSD exclusively on the desktop since version 4.0.
“Gnome is a different story. Gnome 2 is available in the Ports tree, but Gnome 3 is not. Most of the Gnome developers don’t seem to interesting in supporting anything other than Linux.”
Similar opinions have been around regarding Xfce which also seems to rely on OS-specific things that are provided in Linux, but not in FreeBSD, so it could be less functional here.
“Some things are important to know about running Xorg on FreeBSD. First, the packaged Xorg (as well as the default configuration when building from ports) includes hald and dbus, but those services are not enabled by default, so when you launch X, your mouse and keyboard won’t work.”
I always thought at least HAL would already be considered obsoleted in Linux…?
“To enable them, hald_enable=”yes” and dbus_enable=”yes” need to be added to the /etc/rc.conf file.”
Or disable them when building X if you don’t require those things for your desktop.
“Pre-KMS drivers do work, with 3D acceleration when available, and NVidia graphics are fully supported by NVidia’s proprietary driver. This driver actually works very well and is well supported. It has been available for 10 years, and provides the necessary libraries for running OpenGL applications under Linux emulation.”
The built-in “ati” driver of X.org (and even of XFree86) did provide very good 3D performance for the older Radeon GPU series. With current ATI cards, it doesn’t seem to be that easy. However, I’m currently using a nVidia card and the binary driver was easy to install, and it has good 3D boom.
“There are some other issues with FreeBSD as a desktop to be aware of. A weird quirk of FreeBSD package management is that the default package repository doesn’t get updated; all the packages are the same version as what is found in the ports tree included with that particular release.”
There is an environmental variable $PACKAGESITE that you can set to either
— cont. —
“There are some other issues with FreeBSD as a desktop to be aware of. A weird quirk of FreeBSD package management is that the default package repository doesn’t get updated; all the packages are the same version as what is found in the ports tree included with that particular release.”
There is an environmental variable $PACKAGESITE that you can set to either use the RELEASE packages (those that work with the system as-is from the installation media) or the current packages (which get updated regularly). See “man pkg_add” for details.
“Besides the RELEASE branch, there is also STABLE and CURRENT. The STABLE branch is updated along with the standard ports tree, and there is typically about a week or so of lag time between the port being updated and the corresponding package being available. If you want the cutting-edge branch, you can switch to CURRENT, which provides the absolute latest, untested packages. Currently, CURRENT and STABLE are identical, but this isn’t always the case.”
That’s not fully correct. Allow me to explain:
The tags RELEASE, STABLE and CURRENT (HEAD) have nothing to do with the ports tree pre se. They refer to the operating system (which is, as I explained, maintained independently). The RELEASE branch contains the OS as it is delivered on the installation media, and you can follow the security updates (indicated as patchlevels, e. g. 9.1-RELEASE-p2 as the 2nd patchlevel of 9.1). The CURRENT branch is where the active development takes place. Understand it like this: It is a development branch. Experimental features can appear and disappear, and it may not even compile today, but will do so tomorrow. From this branch, STABLE is created with the “confirmed” and tested features that will go in the next release (e. g. 9-STABLE or 9.2-STABLE to say “this is the STABLE branch after 9.2-RELEASE). Security-critical development will be backported to the RELEASE security branch (and maybe older branches that are to receive security updates).
You should not expect CURRENT to always work. If you want the most current “fully usable” version, use STABLE instead. Continuously update the sources and the ports tree. Following STABLE (or CURRENT) cannot be done using freebsd-upadte (as it only follows the RELEASE security branches), but an update is only a “make update” command away.
The ports tree, on the other side, is “continuously moving”, it’s “always STABLE” and contains the most current ports. It can be binarily updated with the portsnap command.
Using tools like SVN (previously CVS) you can, of course, obtain ports trees for specific dates, just as you can for the OS.
“Adobe’s Flash player is available via the Ports tree (It uses Linux emulation and a shim to provide it to native browsers).”
There is no Linux emulation in the meaning of “Linux emulation”, instead it’s an ABI, an alternative binary interface that “routes” Linux calls to the respective FreeBSD calls.
“The consistency of the system is why I prefer it over Linux – significant changes can rarely, if ever, be described as disruptive. But, changes still are made.”
It’s not really fair to compare FreeBSD to Linux in that way. When we say Linux, we usually mean “the many different distributions of Linux”, while FreeBSD means “the FreeBSD”. That’s why FreeBSD has the opportunity to provide a centralized means of documentation (instead of leaving that task to the users, scattered across the web in forums, wikis and user pages), plus there is a friendly, professional and helpful participating on the mailing lists. As there is “only one OS”, things don’t have to be discussed for any imaginable implementation and variation.
Among developers, FreeBSD is impressive regarding the quality of its documentation. Nearly everything in the system (binaries, configuration files, kernel interfaces, library calls, maintenance procedures, protocols and device drivers) have a manual page with carefully crafted information. Even some quality ports follow this approach and provide excellent off-line documentation (which can be significant under certain circumstances). The FreeBSD Handbook and the FAQ are also locally available and can be output in text, HTML, or various printable formats. The source code is also very tidy and of high quality, it answers the questions that the manpages cannot answers – this is a feature especially appealing to programmers. The system’s directory hierarchy, even though containing many “historical idioms” and therefore maybe looking “outdated” from a “modern” point of view, is easily usable; file locations can be “predicted” and the logic behind the patterns is of course described in “man hier”. Details matter, and as soon as you know why something is there, it becomes obvious why it is a good idea that it is there.
Of course, many of those advantages are way too “low level” to make any significant point in how FreeBSD is a good desktop OS or not. I can only speak from my individual experiences that I would not want to trade FreeBSD as my primary (because exclusive) desktop OS for anything else. Sure, there are things that don’t work as I’d like to (or stopped working), but for a professional, secure, easy, powerful and versatile OS that I’m granted the honor to use it for free I won’t complain too much.
The naming for the FreeBSD branches is a bit confusing right now as there are 3 separate naming conventions in use: -CURRENT/-STABLE/-RELEASE, RELENG_X/RELENG_X_Y both from the CVS days; base/head, base/stable, base/releng from the SVN switchover.
-CURRENT (aka base/head in svn terms) is where the most development occurs. This will become the next major (x.0) release of FreeBSD, at which point a new -STABLE branch is created.
-STABLE (aka base/stable/X in svn terms, where X is one of 8, 9, or soon 10) is the development tree for a specific major version of FreeBSD. Currently, there are 2 stable trees under development (for FreeBSD 8.x and 9.x) and a third will be created shortly (for FreeBSD 10.x). Most development that occurs here is merging features from -CURRENT/head, although some new features are developed directly in here. All minor releases (8.1 through 8.4; 9.1 through 9.2) are created from the -STABLE branch for that major version.
-RELEASE (aka base/releng/X.Y in svn terms) is really two separate things: a specific release as distributed on CDs which never changes (this is more commonly known as -RELEASE); a security branch that gets security updates as needed (this is more commonly known as -RELENG).
For an outsider, or someone who used FreeBSD a few years ago and just coming back to it, it’s confusing as hell.
In another year or so, when 8.x is no longer supported and all CVS-related terms are gone, it will be much easier to understand. Do you want head (devel), stable (devel), or releng (user release)? 
It’s also extremely confusing right now as there are two separate packaging systems in use (pkg_* and pkgNG) with different releases supporting different package tools. Thankfully, there will be proper pkgNG repos for 9.2 and 10.0 and all releases going forward, so one can easily ignore the old pkg_* tools starting now. Again, in another year or two, when 9.x is no longer support, it will be much simpler as pkg_* will be gone.
Edited 2013-09-26 23:06 UTC
#/# find /var/db/pkg -type d -name “p5*” | xargs -J % find -type f -name “+CONTENTS” -exec grep -H “5.12” {} \; | grep pm | gtr -s \/ “\n” | grep p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % && yell || yell
…………………………
I sort of dread the disappearance of +CONTENTS (etc) with the new packaging system (if I understand pkg(ng) fully enough); the seperate directory-as-its-database is much more forgiving to workarounds (pkg won’t install conflicts? with v9, one can temporarily mv the old /var/db/pkg directory maybe, move it back…) not to mention the CLI above. It took all of a couple minutes to almost fully upgrade perl 5.12.x to 5.14.4 … One could say “can’t do that in… [other operating system] ” and maybe not, if the new pkg(ng) does not have equivalent easily-crafted (pipes, etc) tools.
….
Otherwise, reading the first few posts in this thread (when there were just a few yesterday), I re-read them to discern that they were, in fact, generally positive.
Heh. I sometimes mess that up on the command line, too.
Thanks for all that info. Some is new to me, some I left out ’cause the article was getting kinda long.
Any day of the week, any of the BSDs will beat Linux to hell. It still outperforms it for gaming, for video card support (nvidia anyway, since they’re involved in the development and part of the kernel), has much more stability and is two entire security levels higher out of the box than any decent linux distro (and windows). And no constant kernel updates every 2 weeks to address gaping security holes that shouldn’t have been there in the first place.
The future of gaming is BSD, not linux. Most games perform way better in FreeBSD than linux. The fact is, FreeBSD is still and will remain better than linux, for a long time.
Thanks for posting this… as per my previous posts, I’m really keen to understand this in a verifiable way.
Please can I trouble you to be more specific so that I can also experience the benefits you’ve mentioned:
1. gaming performance – which games, which OS, which settings, which hardware/drivers
2. security – how can I test “2 security levels”? What do I need to do to compare and test? What should I configure? How should I run a test?
3. stability – what test do I need to run to compare the stability you’ve mentioned? Is it a test of uptime? Is it a test of kernel or core library bugs under varied load?
4. kernel updates – is there a way to check the other hypothesis isn’t true: that the linux kernel not more security holes but more fixes, whereas bsd has the same (or more) but but less fixes?
Thanks – I am genuinely not messing here, I just want to get to the objective facts in a testable way.