[HN Gopher] Back to FreeBSD: Part 1
___________________________________________________________________
Back to FreeBSD: Part 1
Author : enz
Score : 137 points
Date : 2026-02-22 07:16 UTC (8 hours ago)
(HTM) web link (hypha.pub)
(TXT) w3m dump (hypha.pub)
| nesarkvechnep wrote:
| I'm always going to like articles introducing people to FreeBSD.
| palata wrote:
| Nice article!
|
| > To solve the distribution and isolation problem, Linux
| engineers built a set of kernel primitives (namespaces, cgroups,
| seccomp) and then, in a very Linux fashion, built an entire
| ecosystem of abstractions on top to "simplify" things: [...]
| Somehow we ended up with an overengineered mess of leaky
| abstractions
|
| Not sure I like the value judgement here. I think it's more of a
| consequence of Linux' success. I am convinced that if it was
| reversed (Linux was niche and *BSD the norm), then a ton of
| abstractions would come, and the average user would "use an
| overengineered mess" because they don't know better (or don't
| care or don't have a need to care).
|
| Not that I like it when people ship their binary in a 6G docker
| image. But I don't think it's fair to put that on "those Linux
| engineers".
| realusername wrote:
| I don't think it's necessarily true, compare the BSD utils to
| the GNU utils and the style difference is very visible.
|
| On the other hand, I don't think the comparison between jails
| and docker is fair. What made Docker popular is the reusability
| of the containers, certainty not the sandboxing which in the
| early days was very leaky.
| NooneAtAll3 wrote:
| what do you mean by reusability?
| maxloh wrote:
| For example, you can build a Python image, and reuse it on
| every Python apps you have.
| fragmede wrote:
| And for the whole world, too. I don't need to build my
| own local stripped down version of Alpine Linux with
| python, somebody's already dike that for me.
| shevy-java wrote:
| > compare the BSD utils to the GNU utils and the style
| difference is very visible.
|
| Well, what style difference exactly? GNU utils tend to be
| more verbose. Other than that, what is the difference in
| style?
| jacquesm wrote:
| I don't agree with that. FreeBSD has more of an engineering
| than a hacking mentality and it shows in the various
| architectural choices.
|
| And containers really are a VM-light, so you might as well use
| the real thing, in fact, VMWare for a long time thought that
| their images would be a container like thing and many larger
| installations used them as such.
| lifeisstillgood wrote:
| I ran a whole company on top of FreeBSD back in the day (2005
| ish). It was great, and ran all my personal pcs the same way
| (hell, refusing to install windows to try out this bitcoin idea
| is even now a good idea).
|
| But somehow Linux still took over my personal and professional
| life.
|
| Going back seems nice but there need to be a compelling reason
| -docker is _fine_ , the costs don't add up any more. I do t have
| a real logical argument beyond that.
| dijit wrote:
| Yeah, I have a similar situation; FreeBSD is a great operating
| system, but the sheer amount of investment in Linux makes all
| the warts semi-tolerable.
|
| I'm sure some people have a sunk-cost feeling with Linux and
| will get defensive of this, but ironically _this was exactly
| the argument I had heard 20 years ago_ - and I was defensive
| about it myself then.. This has only become more true though.
|
| It's really hard to argue against Linux when even
| architecturally poor decisions are papered over by sheer force
| of will and investment; so in a day-to-day context Linux is
| often the happy path even though the UX of FreeBSD is more
| consistent over time.
| flipped wrote:
| Never understood why satoshi was a prime windows user.
| earthscienceman wrote:
| I know this comment is effectively a side tangent on a side
| tangent. but that was always the strangest thing to me as
| well. I remember in 2012 when I was debating fiddling around
| with Bitcoin. that was one of the things that turned me off.
| I was sure that there was no way something as brilliant as
| this was supposed to be was developed by windows user.
|
| Which surely says something about all these ideological
| purity tests
| dijit wrote:
| Windows developers (like sysadmins) are of two kinds in my
| experience.
|
| People who don't understand shit about how the system
| behaves and are comfortable with that. "I install a
| package, I hit the button, it works"
|
| .. and
|
| People who understand very _deeply_ how computers work, and
| genuinely enjoy features of the NT Kernel, like IOCP and
| the performance counters they offer to userland.
|
| What's weird to me is that the competence is bimodal;
| you're either in the first camp or the second. With Linux
| (+BSD/Solaris etc;) it's a lot more of a spectrum.
|
| I've never understood exactly why this is, but it's
| consistent. There's no "middle-good" Windows developer.
| salvesefu wrote:
| Probably bc, Windows users _live_ in walled knowledge
| domains that tend to reinforce levels of competence (or
| lack of competence).
|
| Gamers tend to be somewhere in the middle though.
| anthk wrote:
| Unix is easier to understand than the NT mess and
| everything it's in the open and documented, so you can
| achieve a good level of knowledge in the middle. OTOH in
| order to understand NT deeply you must be a reverse
| engineer. Also, on the other side, crazy experts under
| Wine (both ways, Unix and NT) OpenBSD and 9front do exist
| on par of these NT wizards. It just happen with Unix/9f
| you climb an almost flat slope (more in the second) due
| to the crazy simple design, while with NT the knowledge
| it's damn expensive to earn.
|
| With 9front you OFC need expertise on par of NT but
| without far less efforth. The books (9intro), the papers,
| CSP for concurrency... it's all there, there's no magic,
| you don't need ollyDBG or an NT object explorer to
| understand OLE and COM for instance.
|
| RE 9front? Maybe on issues while debugging, because the
| rest it's at /sys/src, and if something happens you just
| point Acid under Acme to go straight to the offending
| source line. The man pages cover everything. Drivers are
| 200x smaller and more understandable than both NT and
| Unix. Meanwhile to do that under NT you must almost be
| able to design an ISA by yourself and some trivial
| compiler/interpreter/OS for it, because there's no open
| code for anything. And no, Wine is not a reference, but a
| reimplementation.
| adrian_b wrote:
| In the early years after 2000, FreeBSD 4 had a much better
| performance and reliability in any networking or storage
| applications in comparison with the contemporaneous Linux and
| Windows XP/Windows 2000.
|
| However, in 2003 Intel introduced CPUs with SMT and in 2005 AMD
| introduced multi-core CPUs.
|
| These multi-threaded and/or multi-core CPUs quickly replaced
| the single-threaded CPUs, especially in servers, where the
| FreeBSD stronghold was.
|
| FreeBSD 4 could not handle multiple threads. In the following
| years Linux and Windows have been developed immediately to take
| advantage of multiple threads and cores, while FreeBSD has
| required many years for this, a time during it has become much
| less used than before, because new users were choosing Linux
| and some of the old users were also switching to Linux for
| their new computers that were not supported by FreeBSD.
|
| Eventually FreeBSD has become decent again from the PoV of
| performance, but it has never been again in a top position and
| it lacks native device drivers for many of the hardware devices
| that are supported by Linux, due to much fewer developers able
| to do the necessary reverse engineering work or the porting
| work for the case when some company provides Linux device
| drivers for their hardware.
|
| For the last 3 decades, I have been using continuously both
| FreeBSD and Linux. I use Linux on my desktop PCs and laptops,
| and in some computational servers where I need software support
| not available for FreeBSD, e.g. NVIDIA CUDA (NVIDIA provides
| FreeBSD device drivers for graphic applications, but not CUDA).
| I continue to use FreeBSD for many servers that implement
| various kinds of networking or storage functions, due to
| exceptional reliability and simplicity of management.
| matheus-rr wrote:
| The jails vs containers framing is interesting but I think it
| misses why Docker actually won. It wasn't the isolation tech. It
| was the ecosystem: Dockerfiles as executable documentation, a
| public registry, and compose for local dev. You could pull an
| image and have something running in 30 seconds without
| understanding anything about cgroups or namespaces.
|
| FreeBSD jails were technically solid years before Docker existed,
| but the onboarding story was rough. You needed to understand the
| FreeBSD base system first. Docker let you skip all of that.
|
| That said, I've been seeing more people question the container
| stack complexity recently. Especially for smaller deployments
| where a jail or even a plain VM with good config management would
| be simpler and more debuggable. The pendulum might be swinging
| back a bit for certain use cases.
| sthuck wrote:
| I don't think article misses it, it's exactly the point it
| makes
| torstenvl wrote:
| > _Jails solve the isolation problem beautifully, but they don
| 't have a native answer to shipping. That gap is real, and it's
| one of the main reasons the ecosystem around jails feels
| underdeveloped compared to Docker's world._
|
| The link literally uses the term ecosystem. Several times
| actually.
| steve1977 wrote:
| > You could pull an image and have something running in 30
| seconds without understanding anything
|
| Fixed that for you ;)
| steve1977 wrote:
| Maybe FreeBSD doesn't want a jails "ecosystem"?
| wolvoleo wrote:
| Jails were never going to 'win' because they're only on an OS
| with 0.1% marketshare.
|
| But it's not a competition. FreeBSD does its thing and Linux
| does another. That's why I use FreeBSD.
| aswanson wrote:
| What is your use case for BSD?
| chuckadams wrote:
| Docker's client/server design also allowed for things like
| Docker Desktop, which made the integration seamless with non-
| linux systems. Jails have nothing like that, so the only system
| that will ever run jails is FreeBSD. Also, I'm not up to speed
| enough to know, but do jails even have a concept of container
| images?
| user3939382 wrote:
| You can also run Linux containers on FreeBSD
|
| https://youtu.be/HV-wUUzRCMo
| KronisLV wrote:
| > the container stack complexity
|
| I'm using either Docker Compose or Docker Swarm without
| Kubernetes, and there's not that much of it, to be honest. My
| "ingress" is just an Apache2 container that's bound to 80/443
| and my storage is either volumes or bind mounts, with no need
| for more complexity there.
|
| > The jails vs containers framing is interesting but I think it
| misses why Docker actually won. It wasn't the isolation tech.
| It was the ecosystem: Dockerfiles as executable documentation,
| a public registry, and compose for local dev. You could pull an
| image and have something running in 30 seconds without
| understanding anything about cgroups or namespaces.
|
| So where's Jailsfiles? Where's Jail Hub (maybe naming needs a
| bit of work)? Where's Jail Desktop or Jail Compose or Jail
| Swarm or Jailbernetes?
|
| It feels like either the people behind the various BSDs don't
| care much for what allowed Docker to win, or they're unable to
| compete with it, which is a shame, because it'd probably be
| somewhere between a single and double digit percent userbase
| growth if they decided to do it and got it right. They already
| have some of the foundational tech, so why not the UX and the
| rest of it?
| jacquesm wrote:
| > I'm using either Docker Compose or Docker Swarm without
| Kubernetes, and there's not that much of it, to be honest.
|
| On the outside. But that's a lot of complexity hidden from
| view there, easily a couple of million lines of code on top
| of the code that you wrote.
| NooneAtAll3 wrote:
| "failed to verify your browser"
| m132 wrote:
| Getting the same thing, "Failed to verify your browser. Code
| 11". Some noise about WebGL in the browser console,
| getExtension() invoked on a null reference. LibreWolf on Linux
| + resist fingerprinting.
|
| Maybe opting for a better-written WAF could boost the reach?
| flipped wrote:
| Is there any technical writeup which explains _how_ the isolation
| exactly works, on containers and VMs? I have always heard the
| high level arguments of weak isolation, same kernel, etc but
| never the implementation details.
| flipped wrote:
| Anyone looking to use jails might find BastileBSD helpful. It's a
| nice and modern jail manager.
| paul_h wrote:
| I was looking at TrueNAS CORE to see if it was a viable way to
| bsd-jail Linux containers. I'm really only doing this to get
| some protection from supply chain attacks given I'm fairly
| promiscuous at git-clone-and-run-a-build. Before that I was
| aiming for the same with Bastille and had got to the give up
| stage because it felt too fiddly to set up. This was a year
| ago. Maybe its better now
| user3939382 wrote:
| I switched my startup's whole infra to FreeBSD a couple months
| ago. Found a use after free bug that Linux's memory management
| was just fine with in Gnome XSLT lib that FreeBSD properly
| refused. Other than that smooth sailing, jails work great.
|
| After IBM destroyed CentOS, all the Xorg politics nonsense, the
| list goes on with Linux, not interested. I just want something
| quiet and boring and stable and correctly designed. NetBSD would
| be my first choice but they don't get the $ they need for
| drivers.
| manuelabeledo wrote:
| You don't need to follow the news cycle to use an operating
| system.
| user3939382 wrote:
| I do follow the news cycle and if I'm hearing about a
| software package in it, something is wrong with the people
| making the software and I don't trust them. Software is an
| engineering discussion or at least it's supposed to be.
| Here's my community guidelines: everyone be nice and
| respectful engage in good faith and focus on the math. Being
| social is fine so long that it doesn't become a diversion
| from the engineering discussion. We're talking about code not
| a philosophical treatise. There are civil ways to settle
| disagreements. I'm so sick to death of the politics.
| ajross wrote:
| > all the Xorg politics nonsense
|
| Uh... Xorg is packaged by FreeBSD too...
|
| Really the whole theme that (from the article) "FreeBSD ships
| as a complete, coherent OS" is belied by this kind of nonsense.
| No, it's not. Or, sure, it is, but in exactly the same way that
| Debian or whatever is. It's a big soup of some local software
| and a huge ton of upstream dependencies curated for shipment
| together. Just like a Linux distro.
|
| And, obviously, _almost all those upstream dependences are
| exactly the same_. Yet somehow the BSD folks think there 's
| some magic to the ports stuff that the Linux folks don't
| understand. Well, there isn't. And honestly to the extent
| there's a delta in packaging sophistication, the Linux folks
| tend to be ahead (c.f. Nix, for example).
| rednb wrote:
| The key thing is that on freebsd you do not risk bricking
| your system by installing a port. Even though this guarantee
| has become less true with PkgBase
| ajross wrote:
| > The key thing is that on freebsd you do not risk bricking
| your system by installing a port
|
| What specifically are you trying to cite here? Which
| package can I install on Debian or Fedora or whatever that
| "bricks the system"? Genuinely curious to know.
| rednb wrote:
| I was referring to the need to be careful to not
| modify/update packages also used by the base system.
| Since all packages are treated the same on Linux, you
| often can't tell which package can put you in trouble if
| you update it along with the dependencies it drags with
| it.
|
| This kind of problem happens frequently when users add
| repositories such as Packman on Linux providing
| dependencies versions different from the ones used by the
| base system of the distro.
|
| Experienced people know how to avoid these mistakes, but
| this whole class of problem does not exist on FreeBSD.
| user3939382 wrote:
| > a huge ton of upstream dependencies
|
| I think you missed the point in my original comment. I
| explained I moved my platform with all dependencies and had 1
| bug which was actually a silent bug in Linux.
|
| In other words, it works. Your particular stack might have a
| different snag profile but if I can move my giant complex app
| there, yours is worth a shot.
|
| FreeBSD is more complete than you make out. They also have
| hard working ports maintainers.
| rednb wrote:
| Done the same since 2018 circa, never looked back.
|
| For a while even used it on the desktop, but was too much
| trouble due to specific tools we need that weren't supported
| properly. so we're using Linux on the desktop.
|
| FreeBSD is stable, lightweight, gets out of the way, and
| without drama.
| jmclnx wrote:
| >but they don't have a native answer to shipping
|
| I am not quite sure what this means. I had a jail a few years ago
| and I remember there was a utility to "back" the jail up so you
| could put it on another system. Are there constraints with that
| utility. It seemed to work, maybe I am forgetting something ?
|
| In any case I still think Jails are much better than the things
| Linux has. To me, it is creating a jail that is more difficult.
| There were ports that made it easier, I used one of them, but
| that port was abandoned at some point. I think it was "ezjail".
| efortis wrote:
| A two-server networking setup with VNET Jails:
|
| https://ericfortis.com/blog/freebsd-jails-network-setup
| shevy-java wrote:
| > FreeBSD is worth a brief aside here, because it differs from
| Linux in a fundamental way. Linux is a kernel. What most people
| call "Linux" is actually that kernel combined with a GNU
| userland, a package ecosystem, and a set of choices that vary
| from distro to distro -- Ubuntu, Fedora, and Arch are all running
| the same kernel but are meaningfully different systems
| underneath.
|
| It is not incorrect but ... do people really care about that
| distinction?
|
| Because in most situations I know of, when people refer to Linux,
| they almost never refer to the linux kernel. They refer to the
| whole operating system stack, which is typically put down via a
| distribution. So, Fedora, Gentoo, Arch, and so forth, are all
| "kind of" Linux. Barely anyone refers to the linux kernel if you
| look at all the discussions on the world wide web.
|
| > FreeBSD ships as a complete, coherent OS
|
| The BSDs often promote that aka "Linux is chaos, we are coherent
| and consistent operating system following intelligent design".
| Well ... this is the rise of worse is better, repeated:
| https://dreamsongs.com/WorseIsBetter.html
|
| It is a great analogy that works on so many levels. Broken down
| to Linux versus the BSDs, I think 500 out of 500 top
| supercomputers running Linux kind of show which philosophy is
| better. The one that works better. That does not mean the BSDs
| are useless, but I am getting tired of the promo used by the BSD
| as "we are order, Linux is chaos". I compare this more to Lego
| building blocks. With Linux there is a stronger focus on having
| building blocks available. You can build up things. You have
| projects such as LFS/BLFS (Linux from scratch). The BSDs do not
| have something comparable. Which operating system is the better
| tinker OS? Which community created git? (Ok ok that was Linus so
| not really a community per se, but it originated from Linux and
| perhaps that was not an accident either.)
|
| > FreeBSD pioneered the practical implementation of what we now
| call containers.
|
| Ok great. Many modern programming languages learned from older
| languages; many of these older languages are dead now. You need
| to keep on innovating. Why is BSD so dead set on the past?
|
| > FreeBSD reached that third stage in 2000. Linux wouldn't get
| there until 2008 with LXC.
|
| Dumdedum ... it kind of sounds as if the FreeBSD guys are sad
| that Linux went on to dominate. It reminds me of NetBSD aka "we
| work on every toaster in the world". Then suddenly on a mailing
| list many years ago "wait a moment ... Linux now works on more
| toasters than we do". The BSDs don't seem to understand how
| momentum can be dominating.
|
| > Technical superiority doesn't win ecosystem wars. Linux won
| through a combination of fast decisions, the viral GPL licence,
| and strong enterprise backing from Red Hat and IBM. Then Google,
| Facebook, and Amazon happened -- hungry for datacenters,
| developing tools to manage growing infrastructure at scale. They
| set the direction for the entire industry.
|
| Ok that flat out is incorrect. First - GPL worked well for the
| linux kernel, that is true. But the ecosystem includes many BSD-
| licences programs too, on Linux. So that explanation fails
| already here. LLVM has Apache License 2.0 which I kind of feel is
| a mix between GPL and BSD (not quite true but this is how I
| remember it).
|
| Then the claim is Linux won because of Red Hat. I actually find
| Red Hat annoying and I am glad to not depend on it. Linux is way
| bigger than Red Hat. IBM? I don't see what IBM did for Linux
| really. So that explanation also does not work.
|
| Google, Facebook, and Amazon - well, they profited from Linux.
| They didn't really ENABLE Linux. They would not have used Linux
| if Linux would have been useless. So that part came afterwards.
|
| So none of those explanations really work well here.
|
| > Linux rapidly went from "the free OS for people who can't
| afford commercial licences" to "the only acceptable OS for
| servers".
|
| That is true but not for the claims made, e. g. "because of
| Google". The more important question is: why did the BSDs fail?
|
| > To solve the distribution and isolation problem, Linux
| engineers built a set of kernel primitives (namespaces, cgroups,
| seccomp) and then, in a very Linux fashion, built an entire
| ecosystem of abstractions on top to "simplify" things
|
| No, that is also incorrect. cgroups are also very different to
| seccomp and the latter is even maintained independently:
| https://github.com/seccomp/libseccomp/releases
|
| > Somehow we ended up with an overengineered mess of leaky
| abstractions for cloud-based, vendor-locked infrastructure.
|
| Wait a moment - he cites Docker. That's owned by a private
| company. What does this have to do with Linux? If company xyz
| does something based on FreeBSD, we would then say company xyz is
| responsible for FreeBSD failing or not failing? How does that
| work?
|
| > And this complexity has quietly reshaped how the industry
| thinks about deploying software. Today, if you want to run an
| application in a larger system, the implicit assumption is that
| you containerise it with Docker and orchestrate it with
| Kubernetes.
|
| Personally I find all this abstraction crap. With all their
| failures, though, things such as docker kind of present a
| "download this one file, then it will work fine". And that is
| kind of true. I saw that in in-campus use for life science
| faculty clusters and what not. It simplifies things for the admin
| there. People give a similar rationale for systemd. Personally I
| don't think systemd should exist, but there are people who
| benefit from it - that simply is a factual statement.
|
| All in all this is a very strange point of view from FreeBSD
| folks. At the least the NetBSD folks back then on the mailing
| list acknowledged the situation and then tried to find
| alternative strategies and in some ways succeeded (although I am
| not sure whether NetBSD right now runs on more toasters than
| Linux does - anyone has updated statistics for that?).
| assimpleaspossi wrote:
| >>I think 500 out of 500 top supercomputers running Linux kind
| of show which philosophy is better.
|
| Or is it because it's what they're used to. I saw this argument
| elsewhere where the respondent went on to show that the users
| were Linux specialists and that's why Linux was used.
| razighter777 wrote:
| I frequently see freeBSD jails as a highlighted feature, lauding
| their simplicity and ease of use. While I do admire them, there
| are benefits to the container approach used commonly on linux.
| (and maybe soon freebsd will better support OCI).
|
| First it's important to clarify "containers" are not an
| abstraction in the linux kernel. Containers are really an
| illusion achieved by use of a combination of user/pid/networking
| namespaces, bind mounts, and process isolation primitives through
| a userspace application(s) (podman/docker + a container runtime).
|
| OCI container tooling is much easier to use, and follows the
| "cattle not pets" philosophy, and when you're deploying on
| multiple systems, and want easy updates, reproducibility, and
| mature tooling, you use OCI containers, not LXC or freebsd jails.
| FreeBSD jails can't hold a candle to the ease of use and
| developer experience OCI tooling offers.
|
| > To solve the distribution and isolation problem, Linux
| engineers built a set of kernel primitives (namespaces, cgroups,
| seccomp) and then, in a very Linux fashion, built an entire
| ecosystem of abstractions on top to "simplify" things.
|
| This was an intentional design decision, and not a bad one!
| cgroups, namespaces, and seccomp are used extensively outside of
| the container abstraction. (See flatpak, systemd resource slices,
| firejail). By not tieing process isolation to the container
| abstraction, we can let non-container applications benefit from
| them. We also get a wide breadth of container runtime choices.
| Melatonic wrote:
| Jails have been around a long time in comparison
|
| I still see FreeBSD as being great for things like networking
| devices and storage controllers. You can apply a lot of the
| "cattle vs pets" design one level above that using VMs and
| orchestration tools.
| znpy wrote:
| > lauding their simplicity and ease of use
|
| Spawning a linux container is much simpler and faster than
| spawning a freebsd jail.
|
| I don't know why i keep hearing about jails being better, they
| clearly aren't.
| mono442 wrote:
| > FreeBSD reached that third stage in 2000. Linux wouldn't get
| there until 2008 with LXC.
|
| OpenVZ and Linux vserver are older than LXC and were commonly
| used, though they required a patched kernel.
| reconnecting wrote:
| _Failed to verify your browser Code 99_
|
| Is it really so necessary to put Vercel Security Checkpoint that
| apparently not working here?
___________________________________________________________________
(page generated 2026-02-22 16:00 UTC)