[xhrpost]

As a web developer who knows enough Linux to do minimum dev-ops, could anyone recommend some things worth playing around with in FreeBSD? Like "do this and see how easy it is vs Ubuntu!". Or are the gains more long term like better stability?

[atmosx]

Yes. From my experience:

* PF (default on OpenBSD, a fork exists on FreeBSD) configuration is way more human-readable than iptables. Makes a lot easier to create custom complex rulesets.

* Documentation is much cleaner on FreeBSD (or OpenBSD) compared to GNU/Linux. Again helps you deploy complex solutions easily.

* The upgrade process (using ports or pkg) is well documented, easy to execute[1].

* ZFS makes FreeBSD a very solid file server

So, other than specific software, a clean approach on how start/stop services, where goes what, etc. I don't see any other reason for someone to switch from Linux to BSD.

However, given my experience ruby (I'm a ruby programmer) under-performs on FreeBSD VPSs compared to Linux VPSs while on bare metal doesn't. There are reports citing NetBSD as fastest ruby bare-metal OS. But again, differences shouldn't be all that much between BSD and Linux deployments in bare metal to justify a switch on VPSs though, if deploy ruby apps, I'd say stick with Linux.

[1] Hm. It's easy to execute if you are not afraid to read some extra documentation. But once you get the hand of it, it's really a breeze, never had serious issues with FreeBSD in ~3 years.

[oscargrouch]

+ Dtrace

+ Jails

+ Capsicum [1]

+ Netmap [2]

+ Most performing network stack

+ Resource Management (pretty low memory usage)

+ The userspace tools come with the source (no GNU/Linux duality)

+ Clang/LLVM as default compiler stack

[1] - https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4

[2] - https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4

[thiagowfx]

I never understood the main differences between jails and chroots. Would you be willing to explain?

[bespoke_engnr]

FreeBSD jails are like a really mature, full-featured version of LXC as opposed to "just a chroot". In addition to being chroot that provides real filesystem isolation without many of the security issues of a Linux chroot, it also has CPU and memory limits, disk quotas, network isolation, root privilege isolation, all the magical ZFS goodness (provided you're running the jail on ZFS). It's really, really nice.

This is a pretty good overview: https://en.wikipedia.org/wiki/Operating-system-level_virtual...

[rhizome]

Chroots only lock you to a particular part of the filesystem. Jails add process and network resource restrictions.

[vbit]

Running ps in a jail will show the processes in the jail only.

Processes in the jail will only see network interfaces and other devices that have been explicitly exposed to the jail.

As others have said, it's like a vm with no virtualization overhead. You can set up jails with the entire Freebsd fs hierarchy so it runs like another host with its own users. Note that even the root user in a jail is not the same as the real root user. You can then use pkg to install packages within the jail too.

[thelibrarian]

chroot (often referred to as a "chroot jail") limits a process to a certain subset of the filesystem - e.g. you could limit a httpd process so that it can only see /var/www, and it would not be able to see anything outside that, so if there was a security compromise of the web server, an attacker would not be able see anything outside that folder tree.

A FreeBSD jail is a like a lightweight virtual machine, and is very similar to a Docker container in Linux (though it has been around for about a decade longer than Docker). It provides isolation for processes etc., but uses less resources than a full virtual machine. It is limited in that it has to be the same operating system as the host.

[TylerE]

The best thing about FBSD is that it mostly works the same way it did a decade ago. It's a lean, mature, core that isn't subject to flavor-of-the-month changes to core systems.

[pyvpx]

the PF available on FreeBSD is woefully out of date. If you use FreeBSD regularly and don't mess with pf, learn ipfw. it is quite powerful and much more performant.

[rufugee]

I'm surprised this is the case, since pfsense is a very capable FW built upon the pf version on FreeBSD. I've been running it for years with nary a problem. Would you say the outdated version of pf puts people running pfsense at risk?

[atmosx]

Everything he said is true and I know this for sure. But I like PF so much and even the stripped down version of FreeBSD feels awesomely good. You're in no danger what-so-ever. OpenBSD's version of PF has loads of advanced features and way better performance but you'll only notice these things if you need an (very?) advanced configuration.

[joshbaptiste]

Dtrace alone will turn you from a developer to a Developer + Systems admin + practical OS engineer, you will understand how your stack is performing within various lower levels of the operating system and be able to tune the hell out of your stack from bottom up.

[Thaxll]

Come on, 0.1% of the people need Dtrace...

[woodman]

0.1% of people in the world? That seems a little high. 0.1% of people who describe themselves as *-dev? That seems really low. Also, how do you define "need"? Dtrace isn't just for tracing functions down to the kernel level, and I can imagine all sorts of things that a web dev would find useful in dtrace. Just google "ruby dtrace".

[4ad]

If you do any kind of programming or system administration, you need DTrace (or some lame Linux equivalent). It really pains me to see that people reject it because it's "too advanced" for them, or such nonsense. Dynamic tracing is the one technique that will enrich your life as an IT professional more than absolutely anything else ever did.

And DTrace in particular is really, really easy to use (the Linux alternatives, not so much).

[atmosx]

Yeah that said, Dtrace on FreeBSD sucks. The DSL is hard and many ready-to-run scripts don't run at all.

Other than Dtrace... Tools like dtruss & co are not as clean as strace, that's the feeling I've got when I had to trace some calls.

[duggan]

If it's more widely available, more developers will reach for it.

The more comfortable people are with tools like DTrace, the better they will be able to write and use software.

[sneak]

Everyone needs to know all of the things. Just because it's a pain to get now doesn't mean people wouldn't use it if it were there. Remember when monitor mode meant patching drivers and running a weirdo kernel? It's like that.

[Thaxll]

Two things here:

- If you use Dtrace to troubleshoot a problem it's way beyond your scope of knowledge as a web developer. Dtrace is too deep and very specific to certain problems that you will never see because your regular nginx + php works fine in all cases.

- Not everyone wants and should be good at everything.

Just be good at what your doing well, I'm not saying that one shouldn't be curious but Dtrace isn't "an excuse" to install *BSD as a web dev.

[4ad]

If you don't use DTrace to debug php, you're missing a lot: http://php.net/manual/en/features.dtrace.dtrace.php. Same for python and ruby and node.js. All these have DTrace support.

DTrace is not hard, it's essential; and it's significantly easier, than say, awk, which is another crucial tool.

[bitroliest]

Under OSX it seems that DTrace support is incomplete thanks to OSX' dtrace implementation [1]. [1] https://github.com/joyent/node/issues/3617

I think only Solaris has full support?

[bsg75]

Its interesting to some of us: http://www.postgresql.org/docs/9.4/static/dynamic-trace.html

[juliangoldsmith]

But that doesn't mean it's only useful to 0.1% of people.

[woodman]

I switched from CentOS to FreeBSD as my daily driver a little over a year ago, for the ports tree. I needed a bleeding edge version of valgrind, but my ~/bin and ~/lib were already pretty unwieldy - so that is what caused the switch. That and ZFS. But I've found a couple of other things that I really like: the documentation is awesome, and config files are where you'd expect them to be. Being able to tune system internals online with sysctl is really awesome as well. Wanna change the lowest possible C-state one cpu3? sysctl hw.acpi.cpu.3.cx_lowest=C3.

I dunno how useful that is for web devs, but as a C programmer and perpetual tinkerer - FreeBSD suits my needs very nicely.

[icebraining]

Linux has sysctl as well, and other parameters can be set by writing to the right files in /sys. For example, the maximum c-state can be set by writing to /sys/module/processor/parameters/max_cstate (if you have support enabled in the kernel).

[woodman]

The linux sysctl is a wrapper for kernel state represented in the file system, freebsd sysctl is direct to kernel. So that is nice, everything in one place. Before my switch to freebsd, I had been a linux user since 2000 - and while I was aware of the existence of sysctl, I don't remember seeing it used very often. It was much more common to see direct interaction with stuff in /proc (rockectraid, never again). Why is that? Is it an issue with standardizing driver interaction or what?

My prior post wasn't written as a statement of exclusivity, simply that I prefer the way freebsd does it.

[caf]

The /proc/sys/ and sysctl(2) methods are really just down to which syscall is used to talk to the kernel - either way it's just reading or writing a kernel-side data structure, there's no fundamental difference there.

The /proc/sys/ pseudo-filesystem interface has the advantage that it's discoverable. The sysctl(2) interface requires userspace to have knowledge of a swag of hardcoded ID numbers identifying each node in the sysctl tree.

[woodman]

I haven't poked through the code, but the linux man page isn't encouraging: "use the /proc/sys interface instead" [0]

Compare that to the freebsd man page [1]

[0] http://man7.org/linux/man-pages/man2/sysctl.2.html#NOTES

[1] https://www.freebsd.org/cgi/man.cgi?query=sysctl&sektion=3&m...

[caf]

I think perhaps we might be talking at cross-purposes here.

My point is that when you call write(2) under Linux on a file descriptor derived from opening a /proc/sys pseudo-file you are talking directly to the kernel code responsible for updating the sysctl variables in the same way as you are when you call sysctl(2) under FreeBSD.

The /proc/sys files aren't real files - they're just a way of representing the sysctl variables in the existing file namespace.

[romaniv]

IMO, just having something of the quality of FreeBSD's handbook (https://www.freebsd.org/doc/handbook/) is a significant point to consider. It is the best piece of documentation for a system I have ever read.

[gtrubetskoy]

When bored, you can run `make world` (it recompiles the kernel and every binary on the system).

[vbit]

As a developer you might find jails useful. I use them to create multiple isolated 'virtual machines' on the same machine. In each one I can install a different set of packages and I like the my base system in clean. With zfs, I also snapshot each jail before major changes so rollback is easy. Try this and see how easy, well-integrated it is as opposed to something similar on linux.

I use ezjail, btw.

[xenophonf]

My reasons for using FreeBSD are a little more philosophical:

- I want to have a stable base O/S to which I can always easily return.

- I want to be able to customize installed packages in an easily scalable way.

- I want a server O/S to be simple to maintain, relative to Windows or Solaris.

- I want the goddamned documentation installed.

During development it's difficult to get RHEL or Ubuntu back to a known-good set of base packages without fiddling a lot with the package manager. It's better nowadays with package groups and autoremoval supported in both yum and APT, but with FreeBSD, you can always punt, do "pkg delete -a && rm -rf /usr/local" (or "pkg_delete" in the before time), and start over. The base configuration is also pretty simple and centralized, with most of what you need in /etc/rc.conf or /etc/periodic.conf.

pkgng + poudriere + a suitable web server makes custom package management really, really easy. I haven't tackled Spacewalk or similar tools for Linux, but even building locally customized versions of packages on RHEL or Ubuntu is a moderately complicated process compared to the FreeBSD Ports Tree. On RHEL or Ubuntu, you typically have to install the developer tools, hunt down the source RPMs/DEBs, edit the package definition, run rpmbuild/debuild, and install the resulting RPM. Compare that to the FreeBSD Ports Tree, where you run one command to download/update your copy of the package definitions, add whatever package-specific knobs you need to /etc/make.conf, and run "cd /usr/ports/category/packagename && make install" (the compilers and everything come built into the base system).

I'm not going to start an argument about the relative merits of init systems, as systemd (Linux), SMF (Solaris), and SCM (Windows) all have their merits, but I personally like the simplicity of configuring everything through /etc/rc.conf on FreeBSD. It's definitely old school, but then I cut my teeth on NeXTSTEP, SunOS 4, and Slackware Linux, so rc-style init scripts feel pretty natural to me.

As for documentation, I cannot tell you how many times I've wanted to run "man something" only to find out I need to install the -doc package. (Also, I cannot tell you how many times I've wanted to compile something, only to find out I need to install the -dev package.) Compared to Linux, FreeBSD has superior documentation. Even kernel bits get manual pages, and not just syscalls in section 2, but kernel interfaces and modules in section 4.

Of course I use both FreeBSD and Linux to great effect at home and at work, as well as Windows and Solaris. I just _like_ FreeBSD better.

[_delirium]

> On RHEL or Ubuntu, you typically have to install the developer tools, hunt down the source RPMs/DEBs...

Nitpick, but on Debian/Ubuntu this is a lot more simple than you make it sound:

    apt-get source xxx     # download the source package for 'xxx'
    apt-get build-dep xxx  # install everything needed to build it

[xenophonf]

I didn't know about that! Thanks! I'd be surprised if yum didn't support something similar, but whenever I've had to build custom RPMs, it's been the old manual srpm download way. That said, on top of my to-do list is getting Spacewalk up and running, so that I can maintain my own package repository for RHEL/CentOS/Amazon Linux similar to what I do with Poudriere for FreeBSD.

[Florin_Andrei]

> I cut my teeth on NeXTSTEP, SunOS 4, and Slackware Linux

That's the real reason. Everything else is rationalization added later.

(Don't get me wrong, I've also started on Slackware. But sometimes you need to break old habits to learn something new.)

[xenophonf]

Well, I won't pretend to be unbiased, but don't worry - I'm on good terms with a wide variety of operating systems and O/S distributions. ;)

[felixgallo]

by this logic, everyone should move all software to node.js, and any complaints are rationalization, because it's newer than C.

[namidark]

Jails are awesome

[bsg75]

I asked a related question from the database developer perspective just yesterday: https://news.ycombinator.com/item?id=8884125

[josegonzalez]

You probably mean "knows enough Linux to do minimum ops".