Ask HN: Does FreeBSD Have a Future?
I know that historically FreeBSD has been superior to Linux in certain networking (firewalls, CDNs) and filesystem (TrueNAS) tasks and is the basis for commercial products from Juniper and in-house CDNs at Netflix and elsewhere, but isn't it only a matter of time before these capabilities are implemented at feature and performance parity in Linux and the only reason to select FreeBSD is the ability to close-source everything you're doing? Aren't there Linux-based firewalls on par with pfSense/Opnsense or NAS products on par with TrueNAS yet?
22 コメント
Yes ... and the future is bright.
I have been using FreeBSD for almost two decades now (and still use it) both privately and professionally. I stared at 'dark' 5.x times with problematic SMP implementation and DragonflyBSD split.
These back then in 2004-2005 were the 'dark times' for FreeBSD.
Since then all things improved or been reworked.
Besides ZFS inclusion many great things happened in FreeBSD that are not available anywhere else like:
- GEOM Storage Framework
- Jails with VNET or Netgraph networking
- Bhyve virtualization/hypervisor written from scratch and ported to macOS and Illumos
- new LUA based loader(8) with support for ZFS Boot Environments - beadm(8)/bectl(8)
- TLS in kernel (Netflix)
- imported DTrace for better troubleshooting and looking for performance improvements
- Capsicum sandboxing Security framework
- 33000+ available packages in pkg(8) repository
- support for new/latest GPUs
- boot speed improved from 28 to 8 seconds: https://youtu.be/10XRCiBtyhA
- import of pf(8) OpenBSD firewall
- ported to ARM64 and POWER64 architectures
- move from M:N to 1:1 threading model in SMP
- new bsdinstall(8) installer and bsdconfig(8) companion
- sendmail(8) removed for dma(8) from DragonflyBSD
- ... and I definitely do not remember tons of other stuff (almost two decades)
Not to mention BSD license that gives you ABSOLUTE freedom and not just a glimpse of it.
Some of these features I described here:
- https://vermaden.wordpress.com/2020/09/07/quare-freebsd/
Regards.
I have been using FreeBSD for almost two decades now (and still use it) both privately and professionally. I stared at 'dark' 5.x times with problematic SMP implementation and DragonflyBSD split.
These back then in 2004-2005 were the 'dark times' for FreeBSD.
Since then all things improved or been reworked.
Besides ZFS inclusion many great things happened in FreeBSD that are not available anywhere else like:
- GEOM Storage Framework
- Jails with VNET or Netgraph networking
- Bhyve virtualization/hypervisor written from scratch and ported to macOS and Illumos
- new LUA based loader(8) with support for ZFS Boot Environments - beadm(8)/bectl(8)
- TLS in kernel (Netflix)
- imported DTrace for better troubleshooting and looking for performance improvements
- Capsicum sandboxing Security framework
- 33000+ available packages in pkg(8) repository
- support for new/latest GPUs
- boot speed improved from 28 to 8 seconds: https://youtu.be/10XRCiBtyhA
- import of pf(8) OpenBSD firewall
- ported to ARM64 and POWER64 architectures
- move from M:N to 1:1 threading model in SMP
- new bsdinstall(8) installer and bsdconfig(8) companion
- sendmail(8) removed for dma(8) from DragonflyBSD
- ... and I definitely do not remember tons of other stuff (almost two decades)
Not to mention BSD license that gives you ABSOLUTE freedom and not just a glimpse of it.
Some of these features I described here:
- https://vermaden.wordpress.com/2020/09/07/quare-freebsd/
Regards.
Yes FreeBSD has, but there are things that the team around project must clean, more about security.
https://news.ycombinator.com/item?id=32506675
About that 'lesson...'
sendmail(8)
- still in FreeBSD 13.x base but no longer in FreeBSD 14.x base (removed)
- FreeBSD 14.x will use dma(8) from DragonflyBSD instead
ntpd(8)
- its in FreeBSD base system so ntpd(8) bugs translate to FreeBSD bugs
- they can change that to chronyd(8) so they will have chronyd(8) bugs instead
openssl(8)
- same as with ntpd(8)
- not a lot of software is ready to move to libressl(8) - HardenedBSD (security oriented fork of FreeBSD) moved to libressl(8) some time ago but they went back because patching 'all the world software was taking too much time'.
portsnap(8)
- is now deprecated - gitup(8) or git(8) can be used to update FreeBSD Ports tree
A lot of complaints are not that FreeBSD is insecure - but that some things are not enabled by default - this is not a security hole.
Anyone can enable SWAP encryption (in installer) or enable basic firewall config (after install). Not everyone needs that.
FreeBSD is like a framework with available options - you enable/use what you like and thats it.
For example why FreeBSD would dump TCP Wrappers features when it works properly? A lot of people rely on that (older configs/automations/...)
FreeBSD does not dump older features 'just like that' because now they are not fancy.
FreeBSD is not OpenBSD.
OpenBSD tries to enable each possible security mechanism by default - yet they still have security holes sometimes (like all software).
Not to mention that a lot of important stuff does not work on OpenBSD. WINE? Nvidia drivers? Bluetooth? Netflix? Virtualization of Windows or Linux? Any secure filesystem with checksums like ZFS? Running Linux binaries?
Yes you can be secure when almost nothing is available - but I believe that is not the right path.
I respect OpenBSD attitude and path - but I could not use it daily as it does not have features I need and use daily.
Hope that helps.
sendmail(8)
- still in FreeBSD 13.x base but no longer in FreeBSD 14.x base (removed)
- FreeBSD 14.x will use dma(8) from DragonflyBSD instead
ntpd(8)
- its in FreeBSD base system so ntpd(8) bugs translate to FreeBSD bugs
- they can change that to chronyd(8) so they will have chronyd(8) bugs instead
openssl(8)
- same as with ntpd(8)
- not a lot of software is ready to move to libressl(8) - HardenedBSD (security oriented fork of FreeBSD) moved to libressl(8) some time ago but they went back because patching 'all the world software was taking too much time'.
portsnap(8)
- is now deprecated - gitup(8) or git(8) can be used to update FreeBSD Ports tree
A lot of complaints are not that FreeBSD is insecure - but that some things are not enabled by default - this is not a security hole.
Anyone can enable SWAP encryption (in installer) or enable basic firewall config (after install). Not everyone needs that.
FreeBSD is like a framework with available options - you enable/use what you like and thats it.
For example why FreeBSD would dump TCP Wrappers features when it works properly? A lot of people rely on that (older configs/automations/...)
FreeBSD does not dump older features 'just like that' because now they are not fancy.
FreeBSD is not OpenBSD.
OpenBSD tries to enable each possible security mechanism by default - yet they still have security holes sometimes (like all software).
Not to mention that a lot of important stuff does not work on OpenBSD. WINE? Nvidia drivers? Bluetooth? Netflix? Virtualization of Windows or Linux? Any secure filesystem with checksums like ZFS? Running Linux binaries?
Yes you can be secure when almost nothing is available - but I believe that is not the right path.
I respect OpenBSD attitude and path - but I could not use it daily as it does not have features I need and use daily.
Hope that helps.
The FreeBSD Foundation and FreeBSD Project members have been investing in and working on improving FreeBSD security for at least the last several years. Much of that "FreeBSD – A Lesson in Poor Defaults" blog post is outdated/incorrect/conjecture.
One of the things I've learned in my 2.5 decades in this industry is that products/platforms which have a long history of defying gravity will generally continue to do so. Generally, the longer something has been out and about, the longer you can expect it to continue to be out and about.
There are exceptions to this, but they generally occur slowly (e.g. Perl, PHP) and the trendline is obvious for years, and it only asymptotically approaches obsolescence.
OpenBSD and FreeBSD, afaik&afaict, are not on such a trendline at all. Which isn't to say they are immune from ever entering such a trend! But they'd be starting from a relatively steady state, despite what (probably false) intuitions about the supremacy of other options might seem to dictate.
I would predict we'll be having this conversation again and again, long into the future, as we've been already having this conversation for about twenty years.
And the answer will still be: BSD is just fine.
There are exceptions to this, but they generally occur slowly (e.g. Perl, PHP) and the trendline is obvious for years, and it only asymptotically approaches obsolescence.
OpenBSD and FreeBSD, afaik&afaict, are not on such a trendline at all. Which isn't to say they are immune from ever entering such a trend! But they'd be starting from a relatively steady state, despite what (probably false) intuitions about the supremacy of other options might seem to dictate.
I would predict we'll be having this conversation again and again, long into the future, as we've been already having this conversation for about twenty years.
And the answer will still be: BSD is just fine.
As far as the road towards feature parity goes, it seems that Linux is mostly evolving technical solutions rather than replicating them. Dtrace on Linux is a big project being superseded by eBPF[0] - its the primary example that comes to mind. As a counterpoint, OpenBSD's pledge has been re-implemented on Linux using bpf & seccomp[1].
I still value BSDs as they are developed as complete operating systems rather than as cobbled-together distributions. Users benefit from a more cohesive experience on BSD vs. Linux.
>and the only reason to select FreeBSD is the ability to close-source everything you're doing?
I'd love to have a GPL-licensed BSD operating system. Ideally new features would be prototyped in BSD-licensed BSDs and eventually make it into a stable GPL-licensed version. (I know it sounds crazy...) I don't want to get my hopes up, but the people behind the Hyperbola BSD project have been working on it for some years now[2].
[0] https://news.ycombinator.com/item?id=22987696
[1] https://justine.lol/pledge/
[2] https://www.hyperbola.info/news/hyperbolabsd-is-an-operating...
I still value BSDs as they are developed as complete operating systems rather than as cobbled-together distributions. Users benefit from a more cohesive experience on BSD vs. Linux.
>and the only reason to select FreeBSD is the ability to close-source everything you're doing?
I'd love to have a GPL-licensed BSD operating system. Ideally new features would be prototyped in BSD-licensed BSDs and eventually make it into a stable GPL-licensed version. (I know it sounds crazy...) I don't want to get my hopes up, but the people behind the Hyperbola BSD project have been working on it for some years now[2].
[0] https://news.ycombinator.com/item?id=22987696
[1] https://justine.lol/pledge/
[2] https://www.hyperbola.info/news/hyperbolabsd-is-an-operating...
> I'd love to have a GPL-licensed BSD operating system. Ideally new features would be prototyped in BSD-licensed BSDs and eventually make it into a stable GPL-licensed version. (I know it sounds crazy...)
Why? What does a GPL license let you do that you can't do with a BSD license?
If the base is BSD licensed, why would commercial users not use the base rather than the GPL one?
Why? What does a GPL license let you do that you can't do with a BSD license?
If the base is BSD licensed, why would commercial users not use the base rather than the GPL one?
>If the base is BSD licensed, why would commercial users not use the base rather than the GPL one?
Non-copyleft licences are not a universal business need for commercial users. See Red Hat, Suse, and Canonical for examples. BSD licences are also GPL compatible, so for whoever feels the need to contribute open source BSD licensed code, there is also a one-way street for redistributing it under the GPL. I believe this is an advantage that GPL projects & their username can leverage.
>Why? What does a GPL license let you do that you can't do with a BSD license?
I believe that bad people should not have access to good software. Bad people are incentivized to do sneaky things, and therefore, they avoid GPL licensed software because it legally binds them to be open and honest about their code/intentions. Take what happened with MINIX and Intel ME for example. MINIX has a permissive license that Intel exploited in ways that I'd bet most people here agree are net a negative. If MINIX had been GPL licensed, then Intel would have just chosen an alternative for Management Engine, but at least the options available (i.e., attack surface) would have been reduced.
I even support the SSPL. I don't care if it doesn't meet the pure definition of "open source" because what matters more to me is that it prevents large companies from abusing those who do most of the work supporting FOSS.
I believe that a successful GPL-licenced BSD is possible, and I'd take delight in knowing that big tech companies would be disincentivized to used it for some surveillance capitalism product i.e. Google's plans for Fuchsia.
[0] https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...
Non-copyleft licences are not a universal business need for commercial users. See Red Hat, Suse, and Canonical for examples. BSD licences are also GPL compatible, so for whoever feels the need to contribute open source BSD licensed code, there is also a one-way street for redistributing it under the GPL. I believe this is an advantage that GPL projects & their username can leverage.
>Why? What does a GPL license let you do that you can't do with a BSD license?
I believe that bad people should not have access to good software. Bad people are incentivized to do sneaky things, and therefore, they avoid GPL licensed software because it legally binds them to be open and honest about their code/intentions. Take what happened with MINIX and Intel ME for example. MINIX has a permissive license that Intel exploited in ways that I'd bet most people here agree are net a negative. If MINIX had been GPL licensed, then Intel would have just chosen an alternative for Management Engine, but at least the options available (i.e., attack surface) would have been reduced.
I even support the SSPL. I don't care if it doesn't meet the pure definition of "open source" because what matters more to me is that it prevents large companies from abusing those who do most of the work supporting FOSS.
I believe that a successful GPL-licenced BSD is possible, and I'd take delight in knowing that big tech companies would be disincentivized to used it for some surveillance capitalism product i.e. Google's plans for Fuchsia.
[0] https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...
> I believe that a successful GPL-licenced BSD is possible, and I'd take delight in knowing that big tech companies would be disincentivized to used it for some surveillance capitalism product i.e. Google's plans for Fuchsia.
I guess I understand that, although it doesn't match my philosophy; but as described where HEAD is BSD and release branches (or similar) are GPL, it just doesn't seem compelling. Release changes aren't nothing, but most of the stuff happens in HEAD, so...
If you really want BSD ancestors encumbered by GPL or whatever, you've got to do more of a hard fork and add something compelling after the fork.
On philosophy re MINIX etc. If I'm writing software and releasing it to the world, I want people to use it. If I think I've got the best OS, why wouldn't I want people to be able to use it in their products? I want the world to have better products, and that means embedded computers running embedded operating systems should run my OS.
I guess I understand that, although it doesn't match my philosophy; but as described where HEAD is BSD and release branches (or similar) are GPL, it just doesn't seem compelling. Release changes aren't nothing, but most of the stuff happens in HEAD, so...
If you really want BSD ancestors encumbered by GPL or whatever, you've got to do more of a hard fork and add something compelling after the fork.
On philosophy re MINIX etc. If I'm writing software and releasing it to the world, I want people to use it. If I think I've got the best OS, why wouldn't I want people to be able to use it in their products? I want the world to have better products, and that means embedded computers running embedded operating systems should run my OS.
> the only reason to select FreeBSD is the ability to close-source everything you're doing?
I doubt that's the reason, since you can certainly develop closed-source applications for Linux.
I'm moving to BSD specifically so I can stop using Linux, because I dislike the development direction that Linux is on.
I doubt that's the reason, since you can certainly develop closed-source applications for Linux.
I'm moving to BSD specifically so I can stop using Linux, because I dislike the development direction that Linux is on.
"I'm moving to BSD specifically so I can stop using Linux, because I dislike the development direction that Linux is on."
I would love to learn more about that!
I would love to learn more about that!
Netcraft has been confirming the death of FreeBSD for decades now. It works and continues to work. It might not work forever, but why not use the (subjective) best tool while you can?
Linux is unlikely to implement a low churn kernel and userland; unless something comes up and the contributor count drops a lot. When I left a company that was kind of sort of stuck on running applications compiled for FreeBSD 4 to one running much more current versions, it was no big deal: everything worked better but the user experience is the same. Otoh, half of the Linux systems I use for work now use ip, the other use ifconfig, sometimes netstat, sometimes ss, etc.
Linux is unlikely to implement a low churn kernel and userland; unless something comes up and the contributor count drops a lot. When I left a company that was kind of sort of stuck on running applications compiled for FreeBSD 4 to one running much more current versions, it was no big deal: everything worked better but the user experience is the same. Otoh, half of the Linux systems I use for work now use ip, the other use ifconfig, sometimes netstat, sometimes ss, etc.
It's always hard to predict the future. People using CentOS have probably had more more scares then the ones using FreeBSD. CentOS had its main maintainer gone missing, the CentOS stream thing and now the RHEL closing thing.
If AT&T couldn't kill *BSD, I think it'll take something like an asteroid wiping out civilization to take it out.
https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
when the average age of committers was in the 50s, then maybe the cry is exaggeration, but what about 70s ?
Linux has the opposite problem of BSD.
Linux has a collaborative unified kernel and a fragmented distro and package manager ecosystem.
BSD has unified distros with userspace, package manager, and fragmented kernels NetBSD, FreeBSD, OpenBSD, MacOS etc.
I would love to know what it would take to get unified a BSD kernel and singular base distro.
I like the idea of having a BSD type OS that is not ruled by an oligarchy or big industry like Linux appears to be.
Sadly a BSD desktop/laptop user experience has way too many gaps on modern hardware to be useable. Linux is an easy choice today and has most cutting edge features supported.
Linux has a collaborative unified kernel and a fragmented distro and package manager ecosystem.
BSD has unified distros with userspace, package manager, and fragmented kernels NetBSD, FreeBSD, OpenBSD, MacOS etc.
I would love to know what it would take to get unified a BSD kernel and singular base distro.
I like the idea of having a BSD type OS that is not ruled by an oligarchy or big industry like Linux appears to be.
Sadly a BSD desktop/laptop user experience has way too many gaps on modern hardware to be useable. Linux is an easy choice today and has most cutting edge features supported.
Fun fact about Juniper devices - a lot of them actually run Linux VMs on top of the FreeBSD base.