Hacker News new | past | comments | ask | show | jobs | submit login
You should try FreeBSD (2014) (pascalj.com)
174 points by eatonphil on Nov 20, 2015 | hide | past | favorite | 154 comments

I wonder why this got so many votes to be honest, it's from May 2014 and as far as why one would want to try FreeBSD it is not very detailed. That being said:

I use FreeBSD and (obviously) prefer it, but:

1) ZFSonLinux has made huge steps forward and actually (at least in my opinion) is production ready and rock solid (of course it's not as good as ZFS on FreeBSD though, for example it's lacking some features and of course it's not as proven as of now)

2) Usable containers finally have come to Linux in the form of Docker and everybody is absolutely hyped about it (I would argue though that Jails has more features, is more stable and mature)

The most obvious reason for me to use FreeBSD though is just the difference in philosophy. Don't rapidly make big changes, think everything through, don't surprise users, don't make upgrades that call for massive user intervention, and it's democratically governed and yes, it's a complete OS. Code quality is also better (have you actually looked at what code makes it into the Linux Kernel?), and I would argue therefore security and stability is way better.

Just my 2 cents, nothing wrong with Linux, have used it for years, now I would not want to go back though.

And a small Side Note: No systemd, not to start a flame war, but it is taking over the linux-sphere and I find it's design just horrific

Sorry if I'm too harsh, but saying that ZoL is "rock solid" and "production ready" sounds like a joke to my ears.

ZFS is an extremely complex filesystem, and it took Sun _years_ of internal testing first, and hundreds of angry customers later (sadly, at some point, the only way to improve a product is through real world testing), to reach a milestone where it was really production ready.

I know that on these days of dockers and unicorns, "production ready" has very different meaning than years ago, but still...

Of course you can't compare the trouble Sun originally had in creating ZFS with the difficulty of porting it to Linux when it has been used for years and you can built on stable code and learn by the other implementations. This comparison is quite unfair and lacking in substance. It's not like the ZoL guys had to start from scratch and reverse engineer

It depends of course, I would always choose FreeBSD over Linux when it comes to ZFS, but then again I would always choose a BSD-OS regardless of whether I want to use ZFS or not.

Take it certainly with a grain of salt, but the developers themselves announced ZoL to be production ready in 2013/03[1], Richard Yao (also a developer of ZoL) argued in a blog post in 2014/09[2] that ZoL was stable and production ready and elaborated on this. Some interesting comments also are here[3].

And all this also was quite a while ago, ZoL has been used by users for years now, it's come a long way, I have used it to some extent a while ago and had no bad experiences.

In the end everyone has to decide for themselves what "production ready" really means, and how high the threshold is to deserve that label. But I think that you can reasonably make the argument, that it is...

[1] https://groups.google.com/a/zfsonlinux.org/forum/m/?fromgrou...

[2] https://clusterhq.com/2014/09/11/state-zfs-on-linux/

[3] http://linux.slashdot.org/story/14/09/11/1421201/the-state-o...

Where is ZoL not up to speed compared to FreeBSD / ZFS?

Matt Ahrens, one of the original ZFS authors, has somewhat recently stated that for ZFS the OpenSolaris/Illumos/FreeBSD versions are on par, but Linux and OSX are behind.

I've had issues this year w/ Ubuntu 14.04 machines where the kernel modules would not build, resulting in zpools that could not be imported. I guess that's more of a packaging issue than a code issue.

I periodically have unexpected behavior where my filesystem doesnt mount right and I have to re-mount, or the nfs exports have to be re-exported, etc. I've assumed this was due to incomplete configuration on my part but it's clearly not as brainless to set up as native fs.

Short answer for me: It hasn't been tested as much.

I know a zraid3 FreeBSD/ZFS root array will still boot with two drives failed and one drive acting wonky. Not so sure about Linux.

Are there significant differences in usability between BSD jails and LXC?

There's little technical difference. Both BSD and Linux provide set of kernel-level mechanisms that allow you to run "containers", ie. process trees that are completely isolated from each other and from the host OS. They are roughly comparable, I believe, with mostly minor technical differences.

The huge practical difference right now is that on Linux, Docker and LXC (as in linuxcontainers.org) provide a high-level, fairly opinioned framework and set of infrastructure pieces to build, run and manage containers — and there are no fully equivalent tools on BSD, at least none that are as featureful or mature.

If you want to do containerized deploys on BSD, you'll be writing scripts that set up jails, call rctl, set kernel parameters with sysctl, and so on. There's ezjail [1], but it's nowhere near Docker in terms of scope.

I actually wish there was something on Linux that was less monolithic and better designed than Docker. Its image management is badly designed and annoying to use, and after all this time it still suffers from design flaws such as needing to be the parent of all containers (completely unnecessary given that we have cgroups).

[1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/j...

http://doger.io has links to a lot of simple Linux container runners!

I'm working on a simple FreeBSD jail runner: https://github.com/myfreeweb/sandblast The main idea is machine-friendly configuration: your higher level software (PaaS, CI, etc.) produces a JSON config and pipes it to sandblast, which runs a script in the container.

I have a piece of software running in jails on our servers, I wrote a script to assemble the jail (although this could just be expanding a tar file, and copying in the service configuration file), and add to jail.conf, (maybe add to rc.conf.local if you want to autostart). I didn't need to sysctl, or rctl. I also wrote a small rc file (that just calls /usr/sbin/jail -c name to start, and jail -r name to stop)

in jail.conf i just have

  stud {
    path = "/usr/local/jails/jail_name";
    ip4 = "inherit";
    host.hostname = "jail_name.example.net";
    securelevel = 4;
    devfs_ruleset = 10;
    exec.start = "/bin/service --config=/etc/service.conf";
(ok, i also setup a devfs rule, because i had issues with built in ones and various patch levels of FreeBSD -- and my service needs access to /dev/random)

The only non-obvious thing is you need /libexec/ld-elf.so.1 in order to run dynamically linked libraries.

> There's ezjail [1], but ...

There's also the PC-BSD Warden. With it, one generally does not write scripts to "set up jails, call rctl, set kernel parameters with sysctl".

See the PC-BSD 10.1 Handbook chapter 8:

* http://download.pcbsd.org/iso/10.1-RELEASE/amd64/docs/html/c...

BSD Jails were built with security in mind, LXC is now improving the security model as the prominence of Docker has shed light on it.

>I wonder why this got so many votes to be honest Because people love FreeBSD :)

I recently switched my personal box to FreeBSD. I honestly find it significantly easier to manage than Linux, and have greater trust in its reliability merely from its simplicity.

The single biggest thing which stood out for me was PF (from OpenBSD). Anybody who has ever had the grace of managing IPTables on Linux, give PF a go with /etc/pf.conf (docs: https://www.freebsd.org/doc/handbook/firewalls-pf.html, my config: https://github.com/jamescun/infrastructure/blob/master/roles...).

> Anybody who has ever had the grace of managing IPTables on Linux

Nowadays few people manage IPTables directly. Long ago I used to maintain my own convoluted scripts (ipfwadm, ipchains, iptables...) but once I discovered Shorewall I never looked back - multi-interface multi-VLAN rounting setups can now be sanely managed from the comfort of very readable configuration files.

Here's PF from a VPS running FreeBSD (slightly changed): https://gist.github.com/atmosx/1d4bf8ad42d0447cb415

On that note, I'm currently on Debian Stretch which has a Linux 4.2 kernel and consequently great support for nftables (iptables replacement).

I never truly grokked iptables but configuring nftables reminded me of putting up a pf firewall on OSX. In fact, I'd say it was even easier. The docs could be a tad bit better, but the actual format itself is intuitive and easy to understand.

I'd highly recommend it over iptables if one has the chance.

That PF code is from OpenBSD 4.5, released in May 2009. I wonder what fixes and improvements are missing.

Its a fork that has a different development focus. The biggest difference is that the OpenBSD version has an improved config file format, and the the FreeBSD one supports SMP.

Internally it has changed so much you can't consider it to be the same as the OpenBSD pf. It's a permanent fork.

afaik Iptables is more complex but also has more features than PF.

> If your understanding of the server OS does only allow you to copy/paste random strings from Stackoverflow, you might not really enjoy FreeBSD (or anything besides Ubuntu) — but then, why are you operating a server in the first place?

To serve stuff.

(To expand on this -- most people don't use software, they use software to GET STUFF DONE. Very few people want to operate a server. They operate a server because it allows them to do something they want to. If your FreeBSD pitch is "you should want to operate a server," you're already not reaching most of your possible audience.)

That type of viewpoint is hurting our industry. Just blindly doing things is not productive at all. You should learn and understand what it is you are doing before you do it. Just getting shit tonnes of stuff done is not productive at all if you don't understand how or why you are doing it.

Truck drivers actually know how to drive, Crane operators know how to run a crane, and people operating production servers costing businesses time and resources should also act in the best interest of the business.

As another counterpoint, my small business that runs full-stack in AWS and FreeBSD - I am most certainly not perfectly educated in server and network management, and actually excel in software engineering as opposed to server management and configuration.

AWS lets me get shit done. I know enough to get several services running on an EC2 server, and I don't have close to the $100k+ required to hire an excellent network engineer.

That's part of why AWS, GCE, and DO (and their contemporaries) exist. I'm more educated than most at this point, but that's only because of doing when necessary to get things done.

I wasn't trying to imply a person needs to have the entire set of domain knowledge before operating a server, but simply researching about what you are attempting to do before just copy-pasting bash lines into your terminal and not even recognizing how it even works at all.

AWS lets you not have to know a great deal about setting up servers and networks, which is great, because they are very skilled at it when they set it up for you. Then, all you need to research is what you need to do/use to deploy your apps.

Well, being an engineer at a company that provides private cloud services and a long-time programmer, I'd wait to ensure that application stays secure before singing the praises of easy.

While I agree that making things more accessible is great, "really understanding the network" and "security" are more important than ever. The types of things happening now are similar to 15 years ago when "developers" were making Access databases that are still around today and are all sorts of a mess. I've seen companies dump tens or even hundreds of thousands of dollars just to keep them going.

Now, something similar is happening but it's with web-based applications. Much more exposed. If you don't know your stuff you, your company, or most importantly, your customers will eventually get burned.

As a counterpoint. Truck drivers don't need to know how to build a truck nor to crane operators need technical understanding of the materials in the crane's structure.

Crane operators do need to know a lot more than just pushing buttons. If not, cranes tip over, get blown over, and sometimes people die. I've seen it happen.

Truck drivers, not so much. Although, when your truck breaks down in the middle of nowhere during a blizzard and you have a load where you get paid based on timely delivery, I'd bet having some knowledge on the truck's internals would be helpful.

Yes, but I was talking about its usage, not it's construction. Most of the users of FreeBSD know how to operate it, but may not understand OS theory about how the kernel and userland work together.

Understanding everything beforehand is not what I was attempting to communicate, but simply researching and understanding why a stack overflow comment is the answer, before just copy-pasting it into the terminal. Like reading the man pages of the commands to be run before running them.

What you said can be applied to anything: "most people don't use programming languages, they use programming languages to GET STUFF DONE".

If everyone strictly followed this we wouldn't be using any programming languages other than Java or Python.

Using FreeBSD does not preclude you from getting stuff done, but you do need to have an inclination to try out new (for you) things in your machines right now. It takes some critical mass of enthusiastic adopters (not sure what this number is, but it's there) for your statement to start applying to a wider audience. And from this articles perspective, this critical mass needs to know servers well enough.

I like FreeBSD a lot but I found OpenBSD to be even nicer. Mostly because the of the practice they have of including real examples of command usage in UNIX man pages. Sounds like a small reason, but it was quite a boon.

Caveat: This was a while ago. I don't know if FreeBSD has adopted the same practice.

(Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.)

> Many major companies like Google or Netflix use FreeBSD in production.

Erm. Well, the company's so huge that I'm sure there's something with some freebsd in it somewhere, but... not really.

I've worked with freebsd extensively in a past job, where it was used for licensing reasons. I don't agree with this article.

Netflix uses FreeBSD as a major component of its CDN (IIRC, it's the OS on all their CDN nodes).

Yup: https://openconnect.netflix.com/software/

They're actively giving back a lot of their work too: http://v4.freshbsd.org/search?q=netflix

Most of the CDN isn't served by open connect but by real CDN like Akamai.

That used to be the case, but Netflix started building out their own CDN a few years ago and they've migrated away from their legacy providers. Netflix is now serving about a third of US peak time internet traffic from FreeBSD.

Do you have any source for that because I still see Akamai serving the content?

Yahoo used to run largely on FreeBSD, at least up to the mid 2000s. Wonder whether they still use it.

They have mostly moved away from it.

New machines are using RedHat. Some of the older machines still run FreeBSD.

I used FreeBSD for a couple of years but now use Arch (after a fling with Ubuntu in between). Reasons I switched (some of which may have been addressed since):

* building everything from source got old

* lack of support for hardware (Linux has gotten really good at having drivers for hardware)

* ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking

* On the server side, Linux pretty much caught up on performance

* As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly (on the desktop - less of an issue for servers, where FreeBSD has always shined). Linux has reached a point where I use Linux as my primary desktop OS, and it works great. FreeBSD for the desktop feels like a step backwards.

> * building everything from source got old

You....don't have to. You haven't had to for years. Just use pkg instead of ports.

> * lack of support for hardware (Linux has gotten really good at having drivers for hardware)

Other than wireless, FreeBSD's driver support is pretty solid. I have a cutting edge machine (haswell-e, nvidia, ddr4, etc) and not one device is unsupported. In fact, FreeBSD has much less hassle with the audio driver than any Linux distro I've tried.

> * ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking

Well yeah, it's still a different OS. If you need some specific commercial software (source unavailable), you'll probably have to jump through some hoops to get it working.

> * On the server side, Linux pretty much caught up on performance

Sure. But when performance is on par, it's not really a factor anymore. At that point, it's just what is easiest/most enjoyable to manage.

> * As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly

I've never run into this issue. As long as you aren't just trying to run commands from stackoverflow, you should be able to adapt things for the few nuances pretty easily. It's really just about knowing your OS. Again, not necessarily true for commercial software...but the case for most FOSS.

I tried putting BSD on my laptop, but quickly got annoyed by graphics and sound not working and software missing. I know most things work, and most software is available, but I need more than that.

Now I went back to Ubuntu because I'm to lazy to set up Arch. I'm not even using a tiling VM anymore.

While I see great value in BSD as a server OS, Linux is just much more convenient on the desktop, and this leads to a circle where I use what I know, what I use what I know. So I tend to also run Ubuntu on servers because it's one system less to know.

Though still, if I needed to build a file server, or an environment where security is important, I would take a closer look at BSD.

Starting with 10.0 they improved packaging, so you can use FreeBSD in binary-only setup.

As for your other problems, FreeBSD is targeted toward servers so that's where your problems come from. I like FreeBSD a lot and have been using it since version 4.7, but I still prefer to use OpenSuSE for my desktop/laptop.

> * building everything from source got old

No need nowadays.

pkg(1) works out of the box now. It's faster and way simpler than apt-get/yum.

> * lack of support for hardware (Linux has gotten really good at having drivers for hardware)

I recommend sticking with commodity hardware and making sure your chipset is supported before hand.

> * ports of desktop applications were not always available, and the POSIX shim to use Linux applications didnt always work without some hacking

Also happens. If only more applications made themselves POSIX compliant.

Normally though, just patching a few things in /files in the port is enough. Sometimes all it takes to port an app from Linux to FreeBSD is just fixes to makefile/automake/cmake files.

> * On the server side, Linux pretty much caught up on performance

Can you elaborate more on what you mean?

> * As the Linux community has grown, the resources available to Linux users are amazing. FreeBSD feels like Linux used to - always having to hack around and try to research how to make it work and nothing quite working smoothly (on the desktop - less of an issue for servers, where FreeBSD has always shined). Linux has reached a point where I use Linux as my primary desktop OS, and it works great. FreeBSD for the desktop feels like a step backwards.

Some things in FreeBSD are painful. I can use both FreeBSD and linux pretty efficiently and get done what I want.

That said, I have the opposite impression you have. To me, Linux seems like a hack and a step backwards.

For one, since linux as a kernel only covers so much area, distributions are left to curate how many of the design decisions go down.

Put yourself in the shoes of a developer who goes out of his or her way to learn upstart, for instance. You invest a good part of your time into the codebase, with a sense of confidence you're going to be able to utilize this onward in your career and future projects.

Then you find, this system you spent time learning is now obsolete and you have to relearn everything, There's systemd.

Imagine if this were to happen every few years with a new piece of software. You want to know why it feels useless to learn Xorg? Because they're trying to phase it out for mir. Well, mir isn't "done" yet, and even if it was ready, other software has to integrate with it. There is a huge collaboration that has to take place between developers learning how mir works, and keep in mind, they're getting exacerbated having a new system replace the old every couple of years. Then you have to manage the snafu of packaging it and how you engineer a switch like mir into the release.

Linux may seem more bleeding edge than BSD, but this is only a veneer. To developers, it's hell having your investment in learning something dashed away and having your time put into some venture you may or may not agree with.

BSD drastically simplifies these pains for devs. There is something called the "principle of least surprise". As well, freebsd's base system includes tools like rc(8), package management, etc. which in turns gives a vastly more cohesive experience.

I appreciate the work of both systems greatly - but few give a really care to the real reason you see drama over things like systemd. From my view in using BSD, it's like Linux's universe doesn't even care for its' developers time and sacrifice.

For some reason, I can't edit my last paragraph. It submits but doesn't change.

From my view in using BSD, it's like Linux's universe doesn't even care for its' developers time and sacrifice. Distributions lax on standards, throw out the baby with the bath water whenever a new system comes on the block and leaves upstream and vendors to clean up the mess.

Keep in mind - no one can read every developer mailing list for every project, let alone participate when these things turn into politics. You may see things that are critical of the architecture of a new technology, and then opposing criticism that the legacy systems are outdated and hard for new engineers to understand. Both may be valid, but they conceal something deeper, an outsider comes out of nowhere calling the shots and want to rip up a lot of stuff that works.

All I know is that developers who invest their time maintaining these systems get a raw deal. Maybe the new system, be it mir, systemd, etc. really improves the experience and will work out "long term". But developers are already jaded and heard this too many times.

I did.

I like it.

It feels very clean and well engineered, I always manage to break it via updates though (freebsd-upgrade vs ports vs pkg)

Apparently pkg-ng and ports are linked via a central database though now, so that should not be the case any longer.

As for why? I disliked systemd and was told to "evolve or gtfo" so I gtfo since I didn't like the way it was being forced on me and the few gripes I had with it fell onto people who seemed to be acting very defensively. But I digress.

I'm a systems administrator, in my next employment I will be attempting to get into a company that is making use of freebsd ( hopefully by then I'll be breaking it much less often of course :) )

Always read /usr/ports/UPDATING after upgrading your ports tree, before upgrading any ports. This usually has what's going to break and instructions about how to manage. It does seem like it's not updated as often these days though.

Is there an equivalent to Debian's Stable packages?

There are several tiers. Nowadays installing a release version of FreeBSD, packages will get updates quarterly with security updates in between as required. In effect the system is suited for production and very stable by default.

Other tiers include the stable and current branches which track development more closely.

After introduction of pkg (FreeBSD 10.0+), the packages are build weekly.

freebsd-upgrade has been absolutely fool-proof for me. Mixing ports and pkg is not advisable even though they use the same database since versions are often not in sync.

Boot environments on ZFS with beadm provide a brilliant way to protect against catastrophic updates. I don't know of any other popular OS that offers something comparable.

If you boot a Fedora 22/23 machine with root on btrfs, you get something similar, I believe: dnf notifies you of OS upgrades, you click 'yay', the system reboots, makes a snapshot and installs upgrades. If installation fails, the snapshot is rolled back; if it completes successfully, the system reboots again and you're good to go. It's apparently been in since systemd 183: https://wiki.freedesktop.org/www/Software/systemd/SystemUpda...

I sort of hope people are waking up from the rut the industry has been. OSX for dev, Linux for backend services... Even AWS. If I were to start another company today, I'd almost surely be using none of these options to max my productivity.

Right now, OSX has become increasingly hostile to dev and Linux is great at modularizing other features FreeBSD built years ago.

Lately I've been trying to ship software from the newly open sourced and open-er licensed .NET CoreCLR and Mono (via C# & F# respectively) and FreeBSD. The results are surprisingly good, especially with the new native executable compilation target stuff.

And the docker pass-through to FreeBSD jails is hot like the sun. It's like a Docker container with similar constraints but without such severe security issues. That and the new network stack makes containers on FreeBSD pretty compelling, even compared to the 1.9 security work.

And there is that thing where linux is locked in a death roll with itself regarding its initalization system? Freebsd don't have that. And that thing where Apple makes you boot into safe mode and flip an NVRAM bit to actually have root on your box?

Of course, I'm not personally shipping code on iOS, so this discussion is a lot more flexible for me than it might be for many.

If I could find another OS that give me the same ability to do stuff that OS X does, and it was more open and developer/me friendly, I would switch in a heartbeat.

Things that my Mac + OS X gives me, that other I have not found anywhere is includes 10+ hour battery with excellent power-tooling, excellent hardware design that is robust, nice looking and feeling, a desktop environment that works for the most part and lets me work on my software without getting in the way, while still being top notch when it comes to quality of bundled software, graphics and such.

> If I could find another OS that give me the same ability to do stuff that OS X does, and it was more open and developer/me friendly, I would switch in a heartbeat.

I am using Windows 10 on a surface book. There are some minor glitches in a 1st gen product I admit wholeheartedly. Most are fixed for me. I had a defective unit off lot 0 but the replacement and recent driver updates have fixed everything but the "sometimes my mouse goes away" and "sometimes my screen pauses as the driver freaks out". Both are minor and correctible annoyances that are well known.

The Surface book gives me 7-8 hours of battery life doing Clojure development with deploy cycles with casual use, with audio streaming and bluetooth headphones. This eclipses my i7 OSX boxes, current gen, that typically conk out around 5 hours in the same config. The SB has a funny behavior though, it does connected standby like a tablet. It'll hibernate, but the default is after 2 hours of standby. So you need to know that a bit of your battery life is being used there.

I highly recommend the surface book, unless you're an iOS developer. Otherwise, your tools are universal. What I need is there: Docker support is handled via identical (or superior) mechanisms to what we do on OSX; X11 apps are supported about as well; you can get access to the tools you need but PowerShell is actually very whiz-bang and advanced once you see it for what it is; the security model is better than OSX; and honestly I like Win10 better than OSX, which feels incredibly dated by comparison.

This sounds great, except some of us are wary about using an OS with a built-in keylogger and ambient sound recorder.

The ambient sound recorder is disabled by default, but is no different than any other option that does the same.

As for the keylogger, stop spreading FUD. Cortana is nearly identical to every other search including Apple's spotlight. Proxy your traffic and watch each keystroke. Ubuntu's search also does this.

Or were you under the impression that your Siri voice snippets or OK Google or Firefox awesome bar was magically not phoning to a cloud service?

What would you develop on then?

Backend services, maybe micro maybe not. The CLR has really great support for a hybrid async/threadpool model and C# has direct language support. There's a framework called "ServiceStack" which tastes a lot like Jetty that you can use to avoid the ASP.NET-influenced technologies and approach things in a lightweight way.

There is also a developer preview of actual native compilation, which means your deploy story in a container is competitive with Go and startup times for a statically linked binary are great. This means it's actually outperforming Java for containerized deploys (in this specific facet).

Azure and GCE are both really, really good compared to EC2. Hell, GCE is shipping actual Kubernetes support and I want to migrate our entire tech stack to that. Already we've migrated our growing website to it, and as soon as they fix some network performance issues (already fixed in master, but we don't use beta orchestration software in production), we'll flip the switch on that as it elegantly solves some really shitty problems you hit in AWS VPCs.

I like F# a lot, by the way. I can't wait to use it more. It's like OCaml but with a lot of the amenities you expect from the JVM ecosystem (like, for example, the ever-required but poorly supported datetime libraries) and LINQ support, which is pervasive, user-extensible object comprehensions with compiler support. C# doesn't excite me so much, but it has a REPL and it's certainly a more advanced language than Java.

I'm a programmer, not a professional sysadmin, but for my side projects I have to manage my own servers (well, small VMs, but you know what I mean) and for this I definitely prefer BSD.

In fact, I prefer BSD in general over Linux, and while I tried to run it on my main dev laptop, a never ending trickle of minor frustrations with hardware support (suspend/hibernate never worked right, weird issues with docking/undocking (I have a Dell latitude), audio, etc.) eventually forced me back to Ubuntu.

So, for the time being I think I'll stick with Linux for my workstations and BSD for my servers :)

Fortunately AWS and Digital Ocean have great support for FreeBSD!

Indeed, I'm running a couple of FreeBSD droplets on DigitalOcean right now. I just wish they'd get their backup service working for BSD.

Those interested in FreeBSD for their desktop might want to take a look at PC-BSD http://www.pcbsd.org which is a FreeBSD variant geared towards desktop users.

Also, BSD Now http://www.bsdnow.tv and BSDTalk http://bsdtalk.blogspot.com are excellent podcasts for BSD.

Just a word of warning, Jordan Hubbard and Kip Macy work for iXsystems and are pushing for both PC-BSD and FreeNAS to move to NextBSD, which is basically bringing half of OS X into FreeBSD. (Probably inspired by Jordan's days of working at Apple.)

Which many people, including myself, feel is a disastrously bad idea (ex http://blog.darknedgy.net/technology/2015/08/26/0/). It has a lot of similarities to Linux and systemd.

As such, I've switched to recommending people just go with FreeBSD lately. It's a bit of work, but with some helpful guides, you can help people avoid most of the pitfalls (ex http://files.byuu.org/temp/os/freebsd-10.html). And once you learn the basics, you'll be in a great position to administer your system going forward.

Thanks for the shout-out. Thankfully, the FreeBSD Foundation itself doesn't seem particularly receptive to the NextBSD effort (judging from their most recent quarterly status), so there's no danger of it being merged soon.

nice, relaunchd looks interesting and I was not aware of svc from DragonFlyBSD https://www.dragonflybsd.org/cgi/web-man?command=svc&section...

I think its a little premature to worry about NextBSD in the context of PC-BSD. PC-BSD has brought some stuff from OpenBSD over, but I it doesn't sound like they do stuff without proof of working.

I guess Linux has SystemD and the BSDs have NextBSD to be fearful of.

> I guess Linux has SystemD and the BSDs have NextBSD to be fearful of.

Pretty much. But the FreeBSD developers have a history of being much more conservative on these types of changes. But then again, Debian used to as well. So you never know.

I'm all for people experimenting and trying out new types of init systems and the like. I just don't like having them forced upon me when they're clearly not ready for production. I'm also really worried about the lock-in effects. The BSDs are already feeling the pain of software growing dependencies on the unportable systemd (the most egregious was Brasero, a CD-burning tool, recently having an argument over a systemd dependency.) I don't want to see the BSDs repeat the same mistake.

It's enough "fun" dealing with networking idiosyncrasies like SO_NOSIGPIPE vs MSG_NOSIGNAL, kqueue vs epoll; audio idiosyncrasies like OSS vs ALSA; input idiosyncrasies like devd vs udev; etc as it is. Let's not add another one with init system dependencies. Desktop applications have done fine for the past 50 years without init system dependencies, why start now?

I'll watch. LaunchD isn't bad on the OS X boxes we have[1] and I guess coming from NeXTSTEP, Mach isn't something I have a problem with. I will see how it works, but I'm an OpenBSD user these days so I will wait and see what they think.

1) my main complain has already been addressed with the switch from XML

I've actually listened to the BSD Now podcast episode where they discussed NextBSD…

IIRC, launchd is a simple process manager, and it never had anything to do with XML. XML/plists are used in Apple's implementation of launchCTL, the command line client.

http://www.nextbsd.org/welcome-to-ghost/ NextBSD is explicitly a "science project" – they don't want upstream FreeBSD to become NeXTSTEP :)

> IIRC, launchd is a simple process manager, and it never had anything to do with XML.

Everyone thought that, until someone came along and wrote a launchd attempt that put an XML parser into the process #1 program. It was publicized back in 2014.

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/la...

Also, worth mentioning is the excellent FreeNAS http://www.freenas.org/ storage appliance based on FreeBSD & its ZFS capabilities.

Actually, FreeBSD is a great platform to learn about Linux. The more you learn about FreeBSD, the more will you understand Linux.

The only time I will advice not spending time on FreeBSD, is when you have to deal with Java.

Absolutely agree.

A single year of FreeBSD has taught me more than 10 years of Linux about UNIX and by extension made me more proficient with both systems.

Have you tried lately? Java used to be a big issue on FreeBSD, but that hasn't been the case in several years. Now it works as well as any other platform.

What problems did you have with Java on FreeBSD?

I've done Java, Scala, and Clojure development on FreeBSD and had no problems whatsoever.

The issue was that in the past JDK (offered by Sun and Oracle) had no binaries available for FreeBSD (I believe the source was available but was not the same that Sun JDK was built from). If you wanted to run it, you would have to download the Linux version and run it in compatibility mode.

Later FreeBSD get some kind of deal with Sun to provide native Sun JDK for FreeBSD and made them available through http://www.freebsd.org (you can check web archive to see older versions).

Nowadays starting since JDK 7, OpenJDK supposed to be fully compatible with OracleJDK, so it should no longer be a problem anymore.

What issues do you have with Java on FreeBSD? I only just got FreeBSD running on my dev machine, but I've been able to work on (build/run) my Scala projects easily enough.

I definitely think people should give FreeBSD a try. I also think they should give different flavors or linux a try (e.g. Arch Linux). What I don't agree with is using FreeBSD or a non-mainstream OS in production unless you really know what you're doing.

There are many reasons for this, but the most important one is what the article alluded to; there is a plethora of resources for troubleshooting an issue. If you can't install a package like `gfortran` on something like ubuntu, then you can head over to askubuntu and will likely get the solution to your problem.

What I think FreeBSD (or any less widely used OS for that matter) should do is create the right kind of easily searchable support structure that people coming from Ubuntu and CentOS take for granted.

If you read the article closely, it does not point to a canonical support structure. This does not mean there isn't one or for that matter, many. But, what I can decipher is that there isn't a de-facto site that you can get help from.

There is canonical support such as the excellent handbook: https://www.freebsd.org/doc/en/books/handbook/

The forums and mailing lists are also full of very knowledgeable users and developers.

Besides, FreeBSD's Jails eat Docker for lunch as long as you don't need a point and click App store for your containers.

I'm sure many people will tell you that the FreeBSD man pages [0] are an incredible resource and some of the best written man pages out there. From experience, the official handbook [1] was incredibly helpful as well.

That said, the forums are not the most helpful place because there are /so/ many configurations out there and so many "right" ways to do things that it makes finding a working solution incredibly difficult.

[0] https://www.freebsd.org/cgi/man.cgi

[1] https://www.freebsd.org/doc/handbook/

These posts should never be allowed on Fridays. I should be out drinking (or doing what normal people do) on Friday nights, not at home installing another OS.

Just go spin an instance up in the cloud then ;).

Small reason to use Linux--Linux has taken over the embedded market. Hardware vendors (e.g., Broadcom, Intel) offer BSP (board support packages) for Linux but not any of the BSDs.

The BSP in embedded does sort-of what the PC BIOS does. The BSP is the code to bring the microcontroller from cold start to booting something. Booting Linux is supported by large vendors.

Embedded hardware vendors also offer Linux drivers. Not so much anything else.

This is indeed true, systemd was the one thing triggered me to check with BSD again after quite a few years.

Netbsd used to be the embedded BSD flavor, but comparing to linux it's nearly nothing these days. linux thrived in the embedded OS space and pushed aside QNX, OS9, Vxworks, WinCE and NetBSD.

> A really big difference is that FreeBSD is the kernel and userland together.

Can someone explain the significance of this as the author seems to keep glossing over it. What's does he mean by saying they are "together" and what is the advantage of it?

I think what the OP is referring to is that Linux is just the kernel, whereas a full "GNU/Linux" distribution is the GNU userspace utilities (the command line utilities), compilers, etc and other things (not necesarily part of GNU).

The author might be saying that the FreeBSD OS is essentially treated as a single distribution that is both developed, maintained, and packaged cohesively by a single team, as opposed to Linux, where the kernel team (led by Linus) develops the kernel (and maintains/integrates associated parts such as device drivers and filesystems), other devs develop other utilities, and distribution teams pull together everything else (usually either a company such as Canonical or Red Hat, or often a team of volunteers such as with Debian.)

For the latter, it really comes down to a difference in philosophy: because FreeBSD is a single, cohesive unit, there's less room for differing opinions and variety in the mix, which can deliver solid results but with reduced "moving fast and breaking things" that sometimes result in faster innovative leaps that you might see on Linux. (But how much do you enjoy seeing your core infrastructure broken? e.g., this is also why Debian has three tracks - stable, testing, and unstable, to accomodate different levels of risk.)

(Your choice of operating systems may have nothing at all to do with your choice of governance -- but the solid, stable approach could be characterized as conservative and the move fast and break things could be progressive ;) personally, I like both at different times)

The significance is that you have one group building the kernel and userland which allows for implementation and testing of features that cross that boundary. A non-FreeBSD example is the recent work on pledge in OpenBSD. Kernel changes were made in conjunction with changes to a significant part of the userland. That is a minor example, but gives the feel of how having the same set of eyes look to the whole system can be a benefit.

The userland and kernel are developed together by the same group of people/project. So the design is consistent across the system. In Linux the kernel comes from Linus and the kernel development team. The userland usually comes from the GNU core utils team, the distro creator and several other places. This can cause disconnects between how various things in the system work, kernel patches to get a random features to work, etc.

If you download the source of freebsd, the userland tools come together with it, they are developed as a whole with the kernel side of things. Even the clang/llvm compiler will get built by a 'make buildworld'

You have a full working system from source, while with linux you need kernel, binutils, gcc, in different pieces, not developed as a cohesive whole

If you're interested in a video tutorial on how to set up FreeBSD, these are good videos to start: https://vimeo.com/channels/freebsdguides

I recently switched my dev machine (laptop) from Ubuntu to FreeBSD because I wanted the experience. I wrote a post about it[0]. Basically, wifi and graphics were a PITA and I brute forced my way into getting them working.

After getting past those two though, everything else just worked. The simplicity of the system compared to Debian/Ubuntu is just astounding.

I haven't yet gotten into jails or bhyve, but those are the next two things I'm very excited to work toward.

[0] http://blog.eatonphil.com/2015-11-18/two-weeks-of-freebsd---...

I've found that OpenBSD has incredibly complete support for many laptops, going so far as to support Thinkpads with touchscreens and digitizer pens out of the box.

Overall I find FreeBSD's desktop to be more usable, even though OpenBSD has more streamlined configuration in some parts of the system.

I agree! For instance, my wifi card (Centrino 2230) is not supported on FreeBSD 10.2-STABLE but it has been available on OpenBSD for a little while. It is now supported in HEAD but won't be in STABLE until 11.0 next year.

I decided to go with FreeBSD because, from what I read, it seemed like it and 3rd-part packages are kept more up-to-date. As a server-side and front-end developer, this is somewhat more immediately important than "complete security".

Edit: Additionally, jails and bhyve are a big motivator to pick FreeBSD over OpenBSD, personally.

Don't be afraid to run -CURRENT on a laptop! Or even the graphics team's testing branch, which already has Haswell accelerated graphics support: https://github.com/freebsd/freebsd-base-graphics/tree/drm-i9...

About 3rd party packages: FreeBSD ports are always current, binary packages are available as quarterly and current. With OpenBSD, it's all frozen on release, and you basically have to run -CURRENT to get recent packages.

The OpenBSD team is working on a hypervisor too: http://undeadly.org/cgi?action=article&sid=20151101223132

ZFS + jails + DTrace though… :-)

Man, I definitely am scared to! I haven't quite figured out the environment though. It was such a relief just to get graphics working in the first place. I don't I have the time to put up with volatile nightly builds. But as I said, I have no clue how volatile CURRENT is. But with your suggestion, I'll have to read.

I thought I heard something about OpenBSD wanting a native bhyve replacement. But vmm sounds awesome! Thanks for pointing that out!

If you're not comfortable putting FreeBSD on your desktop - check out pfSense. Find that old PC, slap another NIC in it and make it your router. You get ZFS for free along with other cool networking and FreeBSD stuff.

Does anyone have a source that FreeBSD are used at Google and Netflix today?

I work on the OCA team at Netflix. I can confirm we run FreeBSD on our CDN servers.

I was at Google for several years before Netflix, and I believe that any claims of FreeBSD being used by Google are either outdated or misguided. AFAIK, Google was linux from day 1.

video from AsiaBSDCon 2014 https://www.youtube.com/watch?v=4sZZN8Szh14

interview with Scott Long of Netflix on BSD Now http://www.bsdnow.tv/episodes/2013_12_25-the_gift_of_giving

Netflix has the OpenConnect server/service that is used to bring content closer to the users by caching content at the ISP. It's a FreeBSD box with NginX and Bird BGP

Also WhatsApp

Yahoo! was using FreeBSD machines in production for many years. They were very stable. Since WhatsApp team came out of Yahoo!, they kept using FreeBSD machines.

And NetApp

I've been using FreeBSD since 1999 or so, and I love it, but not really for a desktop. On a server you can spend a lot of time dialing it in, building from source, etc. and have a rock solid performant server, and in most cases it's worth it.

On the desktop you can get a system that's basically the same as Linux but you will spend more time on updates and building stuff, and it will be harder to configure your hardware. If the philosophical differences between FreeBSD and Linux are important to you, it's worth it. Otherwise I'm not sure there are many advantages that make it worth the hassle.

I have tried PC-BSD but haven't spent enough time with it to make a really solid conclusion about it.

So... what then do you prefer for your desktop?

Depends on the task, and I'm not exactly a typical case. For graphics and video editing I prefer OSX. For .Net specific development, Windows 10 (Which I'm starting to hate). For all other development and casual browsing I use Arch Linux. I spent a full day building it and dialing it in a couple years ago and it works like clockwork today.

Linux has a lot of the pathology that comes with monopoly. Low innovation, features almost entirely copied from other OSes (often poorly and very late). Also my brief experience with a kernel patch for Linux felt very abrasive, defensive, and I didn't make any progress (though part of the issue was fixed in a roundabout way a few months later).

If you use freebsd/openbsd/dragonflybsd you are supporting a more innovative group of people, and will have a much more pleasant experience if you need something fixed in the kernel (I had an issue with the freebsd kernel as well, and they acknowledged and fixed it).

I prefer the "Comparing BSD and Linux" article by Greg Lehey. He clearly prefers BSD and thinks that the BSDs are more elegant OSs than GNU/Linux. Nevertheless, he admits that some users may prefer GNU/Linux for various reasons, and we are left to make our own decisions as to the aesthetics of the various unixes.


I like FreeBSD a lot more than Linux at the administration level. I ran it as my desktop for a few years.

The big problem: all the software I wanted to run assumed the whole world was GNU/Linux. So I ended up running lots of Linux binaries under emulation.

(yes, I could have compiled everything from ports. But the time I spent 3 days compiling OpenOffice to discover the port was known-broken put me off that a bit ...)

Then I discovered Ubuntu and in particular synaptic and the Debian repos and had a "holy shit, this gets it right" moment. Haven't looked back.

Honest question: has FreeBSD become more automation friendly? i.e. putting all the configuration in /etc/rc.conf may be nice for a systems administrator manually editing things, but makes it hard for installation scripts which configure the system incrementally (e.g. Ansible). One thing I like about Linux is support for /etc/foo.d directories instead of /etc/foo.conf. Or is this not a problem in practice?

In our new "cloud native" systems we are ending up with a number of single-purpose VMs in AWS or GCP. So being able to run a minimal OS image with OpenBSD has it's attraction. At this point, it's easier to use CentOS or Ubuntu due to application compatibility.

I suppose the next logical step is Docker or NixOS.

Dealing with /etc/rc.conf isn't any harder than dealing with /etc/fstab, /etc/master.passwd, /etc/ttys, or any of the other text-files-with-specific-defined-formats databases. There's no reason to think that one only edits them manually. One manipulates the account database with tools such as "pw useradd" and suchlike. One can manipulate /etc/rc.conf{,.local} and its replacements with tools too.

The OpenBSD people have a while back (http://www.openbsd.org/plus56.html) explicitly re-defined /etc/rc.conf{,.local} to be a database of name=value pairs (rather than a shell script with arbitrary content), precisely so that it can be manipulated and parsed by programs other than shells. They have the rcctl tool (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...) which is explicitly designed to let one do things like

  rcctl enable ntpd

  rcctl disable ntpd
to enable and disable the ntpd service.

Whilst FreeBSD has yet to catch up with the formality, the existence of tools such as sysrc (https://www.freebsd.org/cgi/man.cgi?query=sysrc) mean that treating FreeBSD /etc/rc.conf{,.local} (and indeed other files that can be manipulated with sysrc such as /boot/loader.conf) as a similar database file is a growing idiom, FreeNAS becoming the exception and not the rule in this regard.

Services managed on FreeBSD through nosh (http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...) have the advantage that they can use the daemontools envdir mechanism, which separates configuration variables for separate services quite simply and easily. This is a long-standing and well-understood mechanism, which has been around for approaching two decades at this point and which one can find widely discussed and documented. nosh has a mechanism for importing /etc/rc.conf{,.local}, moreover.

In nosh there is also an rcctl shim that maps both to this envdir mechanism and to the native service management. So one can do the same rcctl things such as

  %rcctl get ntpd flags
  -p /var/run/ntpd.pid -f /var/db/ntpd.drift
which can read (and with the concomitant "rcctl set" modify, of course) the variables in a conventionally-placed envdir, and

  rcctl enable ntpd

  rcctl disable ntpd
which will make the appropriate service bundle modifications to enable and disable the service.

I've read about the FreeBSD Linux emulation layer, but don't know that much about it. What exactly does it provide besides emulation of Linux system calls? How reliable is it in practice?

This was ten years ago, I have no idea what it's like in 2015. It's a syscall emulator and a pile of libs from Red Hat. It was reasonably reliable. X font rendering was awful. But then, Linux at the time wasn't much better; Ubuntu had only just started on the process of making the Linux desktop less annoying.

It is maintained. epoll support is coming to the linuxulator in FreeBSD 11.

But you don't need it really. All the usual desktop software is available natively. Firefox, Thunderbird, Chromium, LibreOffice, Transmission, VLC, GIMP, darktable, ioquake3 :-)

You don't need to compile anything (if you don't want to, say, use LibreSSL everywhere), pkgng is excellent.

> But you don't need it really.

You need it to run Linux Docker containers on FreeBSD. More on https://wiki.freebsd.org/Docker

I don't think that's a good idea. I don't want to run Linux anything ;-)

> But you don't need it really.


Is the syscall emulation layer good enough to run the Steam client and, to pick one at random, Kerbal Space Program?

I expect almost any laptop I buy will work (with minimal tinkering) with any flavor of Linux I use, but something tells me that is not the case with BSD. Are they all running it on a virtual machine? Or is there a lot more people writing drivers for BSD than I imagined?

The BSDs seem like they have a lot of what I love about Slackware, only more so. I'd really like to try installing one, and might do so on an old laptop this weekend.

Not sure which operating systems are still pushing the enveloppe but I get the impression that these system designs are congealing.

BSD and Solaris were different enough to create real competition, if only friendly. Now it seems that momentum of linux has turned it into the only real option for doing "serious" things, unless you need the license freedom of BSD for an embedded device.

That's an impression a lot of people have been getting and it's very unfortunate. It doesn't help that OS isn't really taught anymore.

But if you're interested, check out http://teachbsd.org

I tried 10.0, and I had a few really irritating problems. My connection didn't stay up well with freebsd, and freebsd-update was not behaving robustly in the face of that. And pkg was frequently having problems with upgrades to itself where you had to follow the lists to know when to do something carefully by hand rather than letting the tool do its thing.

FreeBSD was my first and longest-standing OS love.

How's FreeBSD doing in the exploit mitigation department? Last I checked, they didn't even have ASLR.


I'm not sure I'd place much faith in ASLR these days. Bittau's Blind Return Oriented Programming (BROP) http://www.scs.stanford.edu/brop/ makes that only a speedbump, not a real obstacle, for any server that suffers from a stack overflow vulnerability and respawns after a crash. Basically, you can read the return address off the stack a byte at a time by detecting the difference between a crash (you got the overflowed byte wrong) and no-crash (you got the overflowed byte correct). Doesn't take long to recover the return address, and hence find the text location. Their paper is a really fun read!

We all know that exploit mitigations aren't perfect. But to not even bother using them... that's just ridiculous. There are plenty of scenarios where ASLR helps prevent exploitation. And the fact that FreeBSD doesn't even have it is pretty damning.

I didn't say not to bother; I just said the protection provided by ASLR is weaker, even on 64-bit systems, than most of us believed a couple of years ago.

It's the FreeBSD folks that didn't bother. Not you.

HardenedBSD has ASLR, they're working on upstreaming it to FreeBSD.

HardenedBSD http://hardenedbsd.org/ has completed a fork of FreeBSD with ASLR.

I have freebsd in one of my VMs and like it very much. One reason I am reluctant to move it as my primary OS is the lack of CUDA support (this might be an nvidia thing and not the fault of freebsd devs). But still it's seems to be a blocker.

Is there a way to make CUDA work in freebsd? Would be glad to know.

No. NVIDIA hasn't ported CUDA to FreeBSD.

There is OpenCL though https://wiki.freebsd.org/Graphics/OpenCL for Intel and Radeon.

> Many major companies like Google or Netflix use FreeBSD in production.

Citation needed on that Google part. It seems unlikely to be true on any meaningful scale. (That is, when writing a FreeBSD advocacy article, maybe you should not be using the largest Linux user in the world as the FreeBSD example).

This got me curious, and I installed one of the official Vagrant images[1]. However they don't seem to come with ZFS as default file system...?

[1] https://vagrantcloud.com/freebsd

I expect that for general development use, FreeBSD in a VM performs better with UFS than it does with ZFS, especially in low memory VMs. That is probably why the vagrant images don't use it by default. You might need to just create a FreeBSD VM from the normal FreeBSD installer if you wish to experiment with ZFS on FreeBSD.

As far as I know, FreeBSD is more secure than most of the out of the box Linux versions(not considering jails). Does anyone know an article that illustrates this?

There is HardenedBSD http://hardenedbsd.org/, which is working on filling gaps between OpenBSD and FreeBSD security.

OpenBSD is definitely more secure out of the box than Linux.

I've heard the opposite. Although it's comparing to OpenBSD in this case, here's a good graphic that shows the exploit mitigations that FreeBSD provides by default: http://networkfilter.blogspot.com/2014/12/security-openbsd-v...

Not sure what the author's sources are, but Google does not use FreeBSD in production.

They used to long ago

I really wanted to try FreeBSD because of ZFS. Then I've seen benchmarks of ZFS between FreeBSD and ZFS on Linux on Ubuntu. Ubuntu was nearly double the speed in the benchmarks. I was sold to Ubuntu. Simple.

There is a lot that can go wrong benchmarking filesystems, especially one like ZFS that relies heavily on its caches being filled.

I find the claim hard to believe and would like to see the benchmark if you can dig it out.

"There are lies, damned lies, and benchmarks"

Did you compare performance on your own workloads?

We test ZoL with each major release, and while stability has improved significantly, it becomes apparent that ZFS can have wide performance differences depending on configuration and use case.

This is true with all ZFS implementations, but with ZFS on Linux not being native there are even more variables.

#1 selling point missing from the article( though they hinted at it with a nod to /etc/rc.conf ):

It's not infected with systemd.

Edit: Downvotes? This is a selling point, with all major linux distros leaving very little choice for those who dislike systemd.

Three replies, and two of them gripe about Systemd.

I'd be more interested in hearing about everything else.

If they were serious they would be griping about laptop compatability, making me think they arent using it all

I can't even stick with using Linux. No way will I manage a BSD.

There's a very great difference between using BSD on the desktop vs. using it on a server. FreeBSD is years behind Linux in desktop support in terms of GPU drivers (still no haswell graphics support), desktop environment slickness and audio latency etc.

It will fall further behind still in the near future, as desktop Linux embraces Wayland.

On a server though, it's just fine.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact