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?
* 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.
+ 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
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.
This is a pretty good overview: https://en.wikipedia.org/wiki/Operating-system-level_virtual...
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.
The more comfortable people are with tools like DTrace, the better they will be able to write and use software.
- 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.
DTrace is not hard, it's essential; and it's significantly easier, than say, awk, which is another crucial tool.
I think only Solaris has full support?
And DTrace in particular is really, really easy to use (the Linux alternatives, not so much).
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.
I dunno how useful that is for web devs, but as a C programmer and perpetual tinkerer - FreeBSD suits my needs very nicely.
My prior post wasn't written as a statement of exclusivity, simply that I prefer the way freebsd does it.
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.
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...
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.
I use ezjail, btw.
- 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.
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.)
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