I’ve been using FreeBSD in production on AWS for a few years now and it’s been great, thanks to ZFS, jails and pf.
There are lots of different ways to configure jails, which unfortunately means there are lots of places to get stuck.
I typically deploy to x1.* instances, which have NVMe drives. I create a zpool of all the NVMe drives, and then mount a zfs filesystem on the zpool at /mnt/jails. I run all my services in jails. Each jail gets its own IP address on the host, and services are made available to the outside world using pf rdr rules. Services in jails are allowed to access the outside network using pf nat rules. pf makes it easy to monitor and restrict network activity for each service.
Once you’ve configured a jail, you can snapshot it with zfs, compress the snapshot, archive it and rsync it to other FreeBSD hosts. Once copied to other hosts, starting the jail simply requires registering it in /etc/jail.conf and running `service jail start $JailName`.
I’ve started documenting this and have been thinking hard about how to provide a more generic container interface on top of this implementation. If you’re interested in the shell scripts,
I’ve started posting them here:
> There are lots of different ways to configure jails, which unfortunately means there are lots of places to get stuck.
This is something that annoys me too, do you have any recommandations? Should I learn to setup jails from scratch? Or settle on a single tool like ezjails?
As someone who has just gone through this, I would say from scratch.
ezjails and some of the others really do seem like the definition of leaky abstractions if you expect a nice layer on top. They're more like handy reusable shell functions.
If you learn from scratch (which again, isn't far removed from those helper packages), you'll have a better understanding for when you get stuck.
A honest question: why would one choose FreeBSD with jails over something like CoreOS with rkt for a stateless cloud application? If I am not mistaken, Netflix uses FreeBSD on a bare metal for CDN, but prefers Linux for applications on AWS.
Maturity; an organisation that's been going for 25 years (and maintained backwards compatibility for most of that), a decade or more of documentation/tutorials/... that one can be confident will still work. rkt might offer the same thing but you need a compelling reason to pick something newer and less established.
A good question indeed considering "the cloud" thrives on Linux, and increasingly Docker/Linux containers. What I've seen happening is that there are lots of Docker images installing (parts of) Ubuntu/Debian or Alpine on first startup (coreutils, bash, gawk, package managers and what not). Not saying it's against the letter of GPL, but to me this, if not Docker in general, had always the smell of a GPL-circumvention technique. I'm not a GPL zealot or something; if anything, GPL (except AGPL) hasn't so far prevented concentration in the hands of very few cloud providers, and in becoming Android (largest Linux install base by far) a blatant privacy invasion instrument.
Given that BSD doesn't require you to go through such hoops for a POSIX API, it's a mystery to me why the BSDs aren't more used in the enterprise/SaaS space.
I've honestly never heard of anyone bring up the GPL or GPL-circumvention in the same breath as Docker. I have no idea what hoops you're referring to. In my experience, the biggest reason most people don't use jails is because people don't use or get exposure to FreeBSD.
Nine times out of ten, the servers at your first job or university were centos or ubuntu, and your desktop tower was rhel, fedora, or again, ubuntu. If you're an enthusiast maybe you had an arch, debian, or gentoo install. (shrugs slackware predates me).
Without some degree of exposure or evangelism you'll choose what you've seen work over something you suspect might not. And that rationale applies to a lesser agree to docker vs rkt.
Nothing profound. It just has popular mindshare so it's the default. You'll have to beat the pants off something to overcome that.
> it's a mystery to me why the BSDs aren't more used in the enterprise/SaaS space
There needs to be a name for the fallacy that the technically best solution will always win.
BSDs aren't more popular in commercial spaces because it's too difficult to find engineers with BSD experience, and no pre-existing supporting ecosystem. There needs to be a compelling reason for companies to ignore the conventional unpopularity, which means that using a BSD must solve a specific pain point that's visible and understandable enough to executives to get approval for going outside the mold. I hate to break it to you, but your boss (probably) doesn't appreciate why a POSIX API is even a thing in the first place, let alone how it applies to a business case.
My target use-case is deploying backend servers into minimal jails. The servers are single binaries written in golang and the goal is to minimize the attack-surface as far as possible in case I’ve left something exploitable in the server code.
I use a similar setup to yours and it has been a joy to work with. Your jz scripts are a little different to mine, I think I might borrow some ideas from them!
I am so glad I discovered FreeBSD. I've been running it since '95 and I think 2.2.5. Still detest the awful, bland 3D generated "new" logo and flat variant. Please bring back the original.
It saved me from wasting so much money. I was in the process of giving up on the Amiga and had just bought a top spec dual boot NT/95 machine (2x Pentium II, Adaptec SCSI, SCSI cd writer, Seagate Cheetahs, something very expensive for graphics and sound). It was a pile of shite that was objectively slower and worse than the 040 Amiga at every task I tried. Burn a CD sir? Sure, just don't do anything else at the same time, you must disable screensavers or receive a coaster. Move the mouse? Gosh that's brave sir.
FreeBSD gave something that wasn't brain dead, and actually worked, from that horribly expensive failure. Made a useful home file and printer server. Gave a similar desktop to the Suns at work. I took out a sub with CDROM.com that I kept running until they died. I've had a BSD box as some variation of home NAS/media server ever since.
The Amiga would surprisingly live 5 more years as daily driver (with one of the 10k Cheetahs). Windows 2000 was actually reliable enough to use. When retired that first BSD box had an uptime in years. Oh those simple times before constant security updates! I'd love to have used FreeBSD as the daily driver but software and laptop support was lacking in comparison to Windows (I did try a time or two), and OSX that I leapt to as daily machine when it was released. Thankfully today FreeBSD hardware support is much better.
So from chance discovery to the most reliable platform I'm ever likely to get my hands on. Especially with jails, ZFS etc. I just wish it was a little better known compared to Linux.
I use FreeBSD on servers and desktops since 15 years.
Yes, it takes more time to create your desktop then just install Elementary OS or Ubuntu where someone else made that for You, but once You have your configuration files, its similar experience.
On a new box You just install it, add needed packages and put your configs in the ${HOME} directory, same for FreeBSD, same for Ubuntu.
You will also 'lose' less time later since You will have bulletproof upgrades with ZFS Boot Environments (sysutils/beadm) and a lot more stable environment - no rush changes - no systemd - no ifconfig/ip problem - no netstat/ss problem - etc.
For example, I've never liked IPT and I believe the way you set up pf(.conf) makes a lot more sense and is easier to understand. You can work somewhat around that (and vice versa as well via pfctl) but I prefer PF. YMMV.
Things like ifconfig and ip differ per *NIX which is bloody annoying. The macOS ifconfig and route differ a lot from the Linux one, for example adding a default gateway in Linux and FreeBSD with the route command requires different syntax/argument and just typing route on macOS doesn't yield the current routes (cause logic). As much as there is a learning curve involved, iproute2 is a great solution to simplify. There's even iproute2mac for if you're accustomed to iproute2 on Linux. It is a wrapper for ifconfig/route/etc though advanced arguments don't work.
Systemd has the same problem iproute2 has: a learning curve of an integral part of the OS.
As for snapshots, Windows, macOS, and Nix have that as well.
Personally, I love the macOS desktop (and Mac in general with UNIX under the hood) but something like i3wm would also do the job. And I bet it'd run just as great on FreeBSD.
Can you boot from them and preserve fully working UNMODIFIED system after upgrade? Nope. That is the difference in ZFS Boot Environments.
You can do that with btrfs. You can make a snapshot of the whole filesystem and set a subvolume to boot.
Another approach is taken in Team Silverblue (formerly Fedora Atomic Workstation) [1], which uses OSTree snapshots with package layering. It stores the system as a git-like content-addressed object store. So not only can you boot into any version, you can guarantee that two systems are identical by checking out the same OSTree commits.
I also used Mac OS X (it was called that way before it became macOS) and I also liked it, but I feel on FreeBSD more 'at home'.
And the FreeBSD project actually cares about its UNIX user land. I am not sure if I can say that for Apple anymore. Outdated utilities, missing man pages, dtrace unusable by default due to SIP, etc.
> Outdated utilities, missing man pages, dtrace unusable by default due to SIP, etc.
After checking out macOS for the first time in late 2016, it took me until only recently to realise macOS mostly only supports info pages - not man (but to confuse matters, some man pages for certain things like "man ls" do work). Even something as recent as git only offers info pages in Darwin - I'd love to understand why that is.
I've had to run through the "info info" tutorial a few times because the keyboard shortcuts seem neither compatible with emacs nor Readline and they still feel clunky compared to man pages, but I sort of know my way around them now to not have to frequently Cmd-tab back to Safari and figure out which desktop/workspace I've ended up at and how to get back (fwiw, I favour i3).
As for the outdated utilities, I do think it's a little absurd that brew and brew cask are essential add-ons to fetch what should already be present and "just work" (e.g., coreutils).
> And the FreeBSD project actually cares about its UNIX user land. I am not sure if I can say that for Apple anymore. Outdated utilities, missing man pages, dtrace unusable by default due to SIP, etc.
Apart from Dtrace (which you can of course run in VM) it is just a matter of installing and using Homebrew.
I use Homebrew, but you have to prefix most GNU utilities by 'g', unless you are willing to 'override' Darwin's utilities by having the GNU counterparts earlier in the path.
Besides that, Homebrew does not solve the fact that for a lot of Apple-specific utilities, subsystems, and daemons there are no man pages.
(I do agree that Homebrew is a great project, have been using it pretty much since its inception.)
> I use Homebrew, but you have to prefix most GNU utilities by 'g', unless you are willing to 'override' Darwin's utilities by having the GNU counterparts earlier in the path.
That's typical for *BSD. Examples include gcc vs cc, gmake vs make, and many others.
> something like i3wm would also do the job. And I bet it'd run just as great on FreeBSD.
It does. I use i3 everywhere, and once you've logged in, there's absolutely no difference across any Linux distro or BSD I've tried. Debian, FreeBSD, OpenBSD, Alpine linux... short of actually running `uname`, it's not really possible to tell what the underlying system is.
But also relatively outdated graphics drivers outside the NVIDIA proprietary drivers (yes, I know that there is a branch with Linux DRM drivers). This also means relatively limited support for Wayland, so you have to use X11, which is insecure.
Even though there are proprietary NVIDIA drivers, CUDA is not supported, which excludes most modern machine learning.
[edit: removed some criticism, not nice on a birthday :)]
I really like FreeBSD as a clean, understandable UNIX system, it wish it had more momentum (and thus more hardware support, testing, etc.).
About 7 times more on the Linux side, do not mix X11 into that :)
FreeBSD as every system has its limitations, that is for sure, but as I track its developments of the span of 15 years its just getting better and better, in all aspects - including desktop.
Of course there are 'environments' where its all or nothing like 'mobile', Linux has most of the market here with Android while FreeBSD has nothing.
This was true until drm-next-kmod and drm-stable-kmod ports appeared. Now you have very similar Linux and FreeBSD graphics experience.
Which are, respectively, based on 4.9 and 4.11 in ports. The AMD has made large strides since then. In those kernels, the amdgpu driver barely supported Southern/Sea Islands. These work extremely well with recent kernels (much smoother than the old radeon driver). Vega cards only support graphical output since 4.15.
Wayland is enabled by default since recently.
The FreeBSD website states that Wayland is not ready for general use. Wayland has been 'enabled' in many Linux distributions for years, but it took a long time to remove all the wrinkles.
I wonder: did you actually run a full GNOME desktop on Wayland on FreeBSD for a couple of months?
Linux - Vulnerabilities (2103) - FreeBSD - Vulnerabilities (368)
Linux is far more popular and most likely audited more as a result of that. So, it is not surprising that it has more CVEs. Also, the Linux kernel is a fair bit larger, supports more architecture, and more hardware, which means more surface.
About 7 times more on the Linux side, do not mix X11 into that :)
X11 is a permanent security vulnerability. Every application can read each other application's mouse events, key strokes, and do screen grabs.
> Which are, respectively, based on 4.9 and 4.11 in ports. The AMD has made large strides since then. In those kernels, the amdgpu driver barely supported Southern/Sea Islands. These work extremely well with recent kernels (much smoother than the old radeon driver). Vega cards only support graphical output since 4.15.
Yes, its currently little older, but they catching up ;)
> The FreeBSD website states that Wayland is not ready for general use. Wayland has been 'enabled' in many Linux distributions for years, but it took a long time to remove all the wrinkles.
I haven't used it, so I do not know how mature it is.
> I wonder: did you actually run a full GNOME desktop on Wayland on FreeBSD for a couple of months?
I run 'light' with openbox/tint/dzen and do not prefer Desktop Environments, besides, for me it does not matter if it runs on X11 or on Wayland as the end result is the same, but as I did not used Wayland I will stop with conclusions here.
> Linux is far more popular and most likely audited more as a result of that. So, it is not surprising that it has more CVEs. Also, the Linux kernel is a fair bit larger, supports more architecture, and more hardware, which means more surface.
Microsoft Windows is magnitudes more popular then Linux, yet it has less holes, so its not only popularity.
Microsoft Windows is magnitudes more popular then Linux, yet it has less holes, so its not only popularity.
Since the source is not generally available, it is probably inspected less. Also, a lot of device drivers are provided by third parties, whereas they are included in the Linux kernel.
While other OSes may support 10,000 hardware devices, and FreeBSD only supports 9374 of them, you only need one of those devices and chances are the one popular one you want to use works on FreeBSD, too.
Honestly though, systemd is actually a good thing. We write a single .service that works everywhere and takes care of ulimit, private tmp, cgroups/slices, etc, etc.
Deprecating good old tools by rewriting them over and over again with new bugs and not covering full features of the original instead of improving the well tested tools.
This is often used as a the reasoning behind the succes of Linux. But the AT&T lawsuit was already settled in 1994. I first installed FreeBSD in 1996, long after the settlement, and FreeBSD was a better more polished system with ports, good documentation, etc. Remember that in Linux-land Slackware was the most popular distribution, RPM did not exist yet, and SUSE had just rebased their distribution from Slackware to Jurix. At the time, FreeBSD and BSD/OS were also quite popular for servers (web, mail, DNS, etc.).
The AT&T lawsuit may have been a factor, but I think a more plausible explanation is that the Linux ecosystem just moved faster by having short incremental release cycles, where FreeBSD only branched from -CURRENT every few years. So, you in FreeBSD-land you basically had to choose between something that is unstable or something that is old.
Another factor (I think) is that the Linux ecosystem marketed itself better. FreeBSD was a non-profit project (even though Walnut Creek supported them), Linux had a lot of commercial vendors (Red Hat, SUSE, Caldera) that were actively pushing boxes to book stores, etc.
It was more complex than most people realize and it was unclear for some time where it left the open source BSDs: Were we covered or not ?
One way or the other, we got sent back to "Start" (Do not collect...), and had to spend a number of months to get from Net/2 (once it were ready) to a working system.
And it didn't really help either that the 386BSD people felt we stole their thunder, that caused some low-level frictioon and copyright uncertainties.
But I think the biggest reason FreeBSD "did not become Linux" is that we didn't want it to.
We were all UNIX veterans, we wanted something stable, reliable and fast - hence the tagline "FreeBSD - The power to serve"
Linux back then, less so now, was a paradise for hackers and experimenters, people wrote 60% of a device driver for all sorts of crappy hardware and had endless fun with it.
I used a car comparison a lot in those days: Linux is an open GTI, FreeBSD is a 18-wheeler truck. The GTI is no good for haulin' - the truck is no fun for cruzin'
Amongst other differences, that gave Linux a much bigger mindshare in universities and dorm rooms, but then, as now, people get to a certain age and just want things to work.
That window was a very small one from the late 1980's to the very early 1990's Id say 1993 max. SCO Xenix occupied that commodity UNIX on i386, but Minix386 started to fill that void, even though it was basically forbidden. Linux changed all of that as there was no insane licensing once version 0.12 was introduced ( https://web.archive.org/web/20070819045030/http://www.kernel... ), with TCP/IP being added shortly afterwards in 1992. Linux was not obscure at the time at all, when new versions were released getting the latest kernel source from prep.ai.mit.edu was an insane waiting in line task..
Just as in the same time period we saw the rise & fall of OS/2, and the emergence of Windows NT. The hacker free market was open for grabs, but Minix's licensing failed, BSD was caught up in a lawsuit, and NT was anything but free. Solaris was going to stay a SYSV secret, and Mach needed 32v + BSD + SYSV licensing so no joe kid on the street could get access.
Why settle for Unix v6 photocopied Lions notes on the PDP-11 when you could spend a few days downloading SLS onto disks and boot into Linux?
1994 was far far too late. Even for AT&T's UnixWare to make a dent. SCO just ended up blowing their brains out partnering with IBM on that project Monterrey to bring SYSV to 64bits, just as Apple wasted their company way with fantasies of IBM & Pink/Taligent. Even IBM did it to themselves porting OS/2 to L4, thinking that OS/2 on a Microkernel was going to compete with Microsoft's implementation of a microkernel.
Most people and small businesses I know around that period using FreeBSD switched to Linux and started giving Linux a serious try in case FreeBSD was completed banned.
Your post contradicted itself. First you claim the lawsuit isn't the cause, then you say it "may have been a factor". The truth is, it was the main reason.
We'd probably still be using Debian (which does have a kFreeBSD distribution, or at least did prior to systemd ruining everything). The GNU userland is genuinely more user-friendly (even on BSD I tend to use gnu ls, tar, make, ...), and the bazaar "distribution" model (where a "linux distribution" is an assemblage of packages from any number of different projects) works better than the BSD cathedral.
I'm glad that BSD's have their own ls, tar, make and friends. Color that will not go away even with TERM=vt100? Seriously? Give me a BSD userland any time!
There is irony in your "off by default" statement when it comes to GNU toolsets. ECMA48 colour and italics support is on by default in GNU troff, which should not come as a surprise as GNU troff was begun over a decade after ECMA48 was first published and the idea of multiple colours was fairly normalized and widespread at that point. Linux distributors and FreeBSD people later went to significant lengths to turn it off, with extra flags and macros.
The BSD userland is genuinely more user-friendly - I strongly prefer software with functionality I might actually need, as opposed to every pointless thing somebody could imagine. ;-)
But here's another FreeBSD's advantage: it gives you the choice. Just do "pkg install coreutils", change your $PATH and voila: GNU tools.
> The BSD userland is genuinely more user-friendly - I strongly prefer software with functionality I might actually need
I see your point, but quite frankly I like the fact that in some cases I need something outside the usual use case and most times gnu grep (and other gnu utilities) have me covered and I don't have to go crazy fiddling with stuff.
Actually I think we would all using Aix, Solaris, HP-UX, Tru64, DG/UX, .... instead, given the amount of contributions that BSD has gotten back throughout all these years.
While you're here, have you donated[0][1] yet? :)
You may or may not be aware, but FreeBSD runs your movies on Netflix, your games on PlayStation, your files on FreeNAS and ZFS, your friends on WhatsApp and OpenBSD runs everywhere else as OpenSSH. ;)
So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps the foundations keep their non-profit status.
Also, you CAN be the change, if you specify what you'd like your donation to be used for (like more secure defaults for the OS or towards code review and bugs fixing).
I pointed out the problems with this boilerplate spiel that you keep posting over and over to Hacker News, 5 months ago, ironically in a thread where you triggered exactly the same side-discussion yet again. I see that you have not changed the boilerplate.
So you don't agree that every time that you post this boilerplate, to discussion after discussion on Hacker News, people repetitively re-hash the same old arguments, even though it happened in the several instances that I pointed to 5 months ago, happened in that discussion itself, and has now happened in this discussion?
I don't. I consider this to be educational effort, to discuss these arguments with people and to change their mind on that, so that next time they won't bring them up and they'd educate their peers on the matters.
In addition to the other replies already, I'd like to point out that this spiel has practically swayed me in the opposite direction to clicking those links and I don't feel any more educated than I was yesterday.
I'd be interested to know if this type of advertising works on anyone - it just doesn't seem like an effective strategy at all.
Maybe time to change your copypasta that you keep spamming these threads with, because here comes the inevitable questions that you never seem to provide an answer to:
If they rely on FreeBSD so much, why are Netflix and Facebook and Sony not paying FreeBSD enough to make it financially independent?
Why should I donate, if these giant billion dollar corporations are going to just leech off my donation?
Sure they do. There's a donor list at https://www.freebsdfoundation.org/donors/ (click on "2017"; most companies donate rather late in the year); Netflix is listed in the "$25,000 - $49,999" category.
I think you are missing the point here: neither you, me nor FreeBSD Foundation or FreeBSD Project are responsible for Netflix or Sony or any other company financial contributions, I see this argument as completely missed. However, FreeBSD Project and Foundation and you and me are responsible for making all of this possible for _anyone_, from big business, to startups, to take some code and turn it into a great business. For nothing, if they consider this ethics, or for something, if they feel like returning the gift. I donate so that you could take it and make world better with your product, for free, if needs be.
Paying Netflix or not won't keep the lights on for FreeSBD, no matter how you think about it. Donating to FreeBSD Foundation directly contributes to that AND to the future Netflixes for them to provide valuable services to you.
You are still missing the point - you are not supposed to contribute based on what someone does or does not. You are supposed to contribute based on the fact that the project makes it possible for _anyone_ to do what they do thanks to the code being available free and without any commitments. That's why we contribute, because we see value in that. You can take the code, build Netflix v2.0 and donate all the profits to FreeBSD. Or none, you're completely free - that is the idea behind BSD (it would be very nice if you would, though ;)
It's you who is missing the point. If Netflix et al paid their fair share, you would not have to spam every HN thread with this copypasta, and you would not have to be here trying to convince me to subsidize WhatsApp. I sure hope you spend as much time pestering the corporations that leech off community donations as you do defending your HN spam.
Maybe with a better license that didn't enable such freeloading on the part of these gargantuan corporations, FreeBSD wouldn't need to go begging for donations from private citizens.
Problem is, any license that wouldn't enable such "freeloading" would not be Open Source. And as it turns out being Open Source is pretty important to FreeBSD community.
For some reason you insist on your actions towards party A being dependant on actions of party B, with whom party A has absolutely no connection. I think at this point we should agree that we disagree and part our ways in peace :)
FreeBSD was my first real introduction to Unix and, even though I don't use it anymore, I'm still very fond of it.
This was about 15 or 16 years ago, I think. That was back when hardware support, both in Linux and in FreeBSD (and in most other free operating systems) was very flaky, and FreeBSD was the only one that I could get my network card and RAID controller to reliably work on. I ran Linux for a while, but unreliably and with out-of-tree drivers running over strange Frankenkernels. One sleepless, outrageously hot summer night, I tried FreeBSD (4.1, I think? Or 5.0?) and it remained on my hard drive for a pretty long time.
I learned to properly use Emacs on it, after outgrowing NEdit and SciTE. I learned how to write portable (hah...) Unix code, learned about SSH and kqueue and ACPI and firewalls. I learned to use patch and wrote my first open source program from scratch, whose source code has been thankfully buried forever but for a summer or so, I wrote the worst Windows desktop clone you have ever seen (that was back when Qt 3 could deliver us from STL and everyone wrote their own window manager for fun and it had real artwork, not boring, flat themes).
I also learned ksh, having learned that bash is not the only shell in this world. I learned about OSS and could not quite stomach Alsa ever since.
I learned about the ports system and that was a whole new world for me and I'd spend days tinkering with programs I didn't really need, just for the fun of it.
I mostly lurked on the mailing lists. I was thankfully past my script kiddie period and was comfortable admitting I didn't know much about programming and system administration, so I was a little intimidated; I joined discussions rarely, and under a pseudonym, but I read the public mailing lists religiously, and learned a lot from them.
Unfortunately, using FreeBSD on a desktop today is a little harder for me, now that portability is considered more of a stone-age concept for old farts who haven't yet installed Arch Linux on their laptops. It's certainly possible (I toyed with 11.1 a little and it's great) but it requires a little more tinkering than I have time for. Admittedly, that's mostly my fault; I chose a career path (embedded systems) that involves weird FPGAs and microcontrollers and the Linux bandwagon, so the little free time I have is spent getting up to date with stuff like Wayland. Sometimes I tell to myself I'm going to get a long vacation and work on something useful for OpenBSD or FreeBSD and maybe work my way into a job (or a consulting gig, and then another, and then another...) where I can use one of them, but then real life kicks in and I'm back to the Land of Useless Manpages.
I've long lost touch with FreeBSD development and don't know too much about what's happened lately. I've heard that the project has made a number of questionable choices in terms of development, and something about the security team being slow, but I really don't know too much on the subject, so it didn't get a chance to change my opiniong of this project. Granted, I don't know if this is true anymore -- but back then, I thought FreeBSD's pragmatism and clean approach to engineering was something to strive for, and I'm pretty disappointed that it hasn't become more popular in the open source world.
Happy birthday, FreeBSD! Here's for another 25 years of quality software.
> That was back when hardware support, both in Linux and in FreeBSD (and in most other free operating systems) was very flaky, and FreeBSD was the only one that I could get my network card and RAID controller to reliably work on.
Same here. I was a student working as a part-time employee in a IT-department and whenever machines were deemed too expensive to fix, I would harvest the parts which still seemed to be good... which I eventually managed to assembly into a full working server. And on a student-economy, a free server like that was a big deal.
There was only one catch: I couldn't get it to boot. Neither Linux nor Windows.
So the department Unix-guru asked me why I didn't try FreeBSD, something he was somewhat fond of. "It's like Linux, but different" he said.
I was a bit confused, but thought it was worth a shot, and what do you know? FreeBSD not only booted the machine, but kept it running nicely for over half a decade.
In effect, FreeBSD gave me a free server when I could afford hardware the least. That's not something you forget :)
I later learned that the mainboard had a serious chipset-failure (which was probably caused Linux and Windows to fail), but FreeBSD seemingly managed to work around that and just kept on running. As far as I can recall, this most has been the most stable server I've ever run.
These days I have a hard time letting go of the impression that FreeBSD is made of better stuff than other OSes, and has been engineered from the core and up to be more reliable.
Despite that I almost exclusively use Linux now (because it's more plug'n'play but IMO more flaky). I still have fond feelings for FreeBSD in my heart though.
I wish I had time to setup a working FreeBSD laptop, but with small 2 kids and a wife... Those times seems long gone.
Anyhow: Hopefully FreeBSD will still be around when I have time for that. Here's to another 25 years!
> Unfortunately, using FreeBSD on a desktop today is a little harder for me, now that portability is considered more of a stone-age concept for old farts who haven't yet installed Arch Linux on their laptops.
It is impressive how Linux changed from being yet another UNIX clone to being UNIX in most people minds, to the point many say Linux when they actually mean UNIX.
I find it even more impressive how the mentality changed. When Linux was still the underdog everyone cried that you should think about Linux, don't develop for Windows only and so on. Now? "Eh, you run FreeBSD? Your problem. Use Linux."
> I've heard that the project has made a number of questionable choices in terms of development, and something about the security team being slow, but I really don't know too much on the subject, so it didn't get a chance to change my opiniong of this project.
Yeah, I remember reading that. It was a little horrifying to read but, in my experience, stuff that's written in an inflamatory tone is about 50% less dangerous than it seems.
Inflammatory tone or not doesn't change the fact that FreeBSD does some "interesting" choices, even if they choose to "keep running" instead of "keep secure" (OpenBSD-like). Note that OpenBSD devs have always been doomsday apostles,... and they've been right to (privsep, SSH, SSL, now pledge, etc.).
They have, and broadly speaking I certainly agree with how they choose to engineer their software, to an even higher degree than (whatever I still know about how) the FreeBSD team choose to engineer their software.
(FWIW, that's why I actually run OpenBSD on the few non-Linux machines that I use :-) )
However, it seems to me like this is one of those cases where there's more than one way to skin a cat. FreeBSD is missing a lot of useful hardening features, such as ASLR (yay, it's 2003 again!), and has made a couple of "interesting" security choices, but judging by the number and scale of FreeBSD deployments, it seems like there are convincing ways to work around these problems in practice. That document suggests there's a lot of work involved in working around them reliably; again, the number and scale of deployments would suggest that the trade-off is considered reasonable by a lot of people.
FreeBSD lives on in various ways thanks to certain brilliant software *BSD has which Linux has not. For example, FreeNAS, OPNSense/PFSense just to name two.
There's also NetBSD which is ported on a lot of architectures. Though Linux is also strong in that field, traditionally NetBSD was. Its the project OpenBSD derived from (Theo got kicked out of NetBSD).
There are lots of different ways to configure jails, which unfortunately means there are lots of places to get stuck.
I typically deploy to x1.* instances, which have NVMe drives. I create a zpool of all the NVMe drives, and then mount a zfs filesystem on the zpool at /mnt/jails. I run all my services in jails. Each jail gets its own IP address on the host, and services are made available to the outside world using pf rdr rules. Services in jails are allowed to access the outside network using pf nat rules. pf makes it easy to monitor and restrict network activity for each service.
Once you’ve configured a jail, you can snapshot it with zfs, compress the snapshot, archive it and rsync it to other FreeBSD hosts. Once copied to other hosts, starting the jail simply requires registering it in /etc/jail.conf and running `service jail start $JailName`.
I’ve started documenting this and have been thinking hard about how to provide a more generic container interface on top of this implementation. If you’re interested in the shell scripts, I’ve started posting them here:
https://github.com/cieplak/jz