You should try FreeBSD (2014)
blog.pascalj.com
blog.pascalj.com
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
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...
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.
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";
mount.devfs;
exec.system_jail_user;
exec.jail_user=jail_name;
exec.poststart="/usr/local/bin/jail_ipfw";
}
The only non-obvious thing is you need /libexec/ld-elf.so.1 in order to run dynamically linked libraries.
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...
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.
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.
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...
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...
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...).
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
Caveat: This was a while ago. I don't know if FreeBSD has adopted the same practice.
> 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.
They're actively giving back a lot of their work too: http://v4.freshbsd.org/search?q=netflix
* 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.
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.
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.
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.
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.
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.
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 :) )
Other tiers include the stable and current branches which track development more closely.
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.
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.
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.
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.
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.
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?
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 :)
Also, BSD Now http://www.bsdnow.tv and BSDTalk http://bsdtalk.blogspot.com are excellent podcasts for BSD.
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.
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?
1) my main complain has already been addressed with the switch from XML
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 :)
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...
The only time I will advice not spending time on FreeBSD, is when you have to deal with Java.
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.
I've done Java, Scala, and Clojure development on FreeBSD and had no problems whatsoever.
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.
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.
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.
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.
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.
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.
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?
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)
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
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---...
Overall I find FreeBSD's desktop to be more usable, even though OpenBSD has more streamlined configuration in some parts of the system.
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.
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… :-)
I thought I heard something about OpenBSD wanting a native bhyve replacement. But vmm sounds awesome! Thanks for pointing that out!
interview with Scott Long of Netflix on BSD Now http://www.bsdnow.tv/episodes/2013_12_25-the_gift_of_giving
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.
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.
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).
https://www.freebsd.org/doc/en/articles/explaining-bsd/compa...
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.
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.
...games.
Is the syscall emulation layer good enough to run the Steam client and, to pick one at random, Kerbal Space Program?
You need it to run Linux Docker containers on FreeBSD. More on https://wiki.freebsd.org/Docker
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.
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
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
%
rcctl enable ntpd
rcctl disable ntpd
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.
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.
But if you're interested, check out http://teachbsd.org
http://networkfilter.blogspot.com/2014/12/security-openbsd-v...
Is there a way to make CUDA work in freebsd? Would be glad to know.
There is OpenCL though https://wiki.freebsd.org/Graphics/OpenCL for Intel and Radeon.
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).
OpenBSD is definitely more secure out of the box than Linux.
I find the claim hard to believe and would like to see the benchmark if you can dig it out.
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.
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.
I'd be more interested in hearing about everything else.
It will fall further behind still in the near future, as desktop Linux embraces Wayland.
On a server though, it's just fine.