I have been using FreeBSD for the last 2 years on a 2015 Intel MacBook Pro, and I have been a long-time Linux user.
Things I appreciate about FreeBSD:
- init system (with real PIDs).
- FreeBSD documentation.
- installation experience (fast and hassle-free).
- stability, consistency and low memory usage.
- DWM / XFCE works great.
- ease of configuring PF
However, there are some main impediments that prevents me from using it as my daily driver:
- WiFi drivers don't work unless it's a ThinkPad I think (specifically Broadcom 4360 on old Macbooks), I bought a Realtek USB WiFi adapter, which works but with reduced performance.
- There are sketchy sound driver issues with the laptop speakers, resulting in tinny sound.
- Bluetooth doesn't work at all, although my BOSS system shows up on hcinquiry.
I like FreeBSD's init system too, but what do you mean about PIDs?
> WiFi drivers don't work unless it's a ThinkPad I think
That's not it; FreeBSD works fine with the wifi in my Dell. I grant that the driver coverage is probably more spotty than Linux, but it's just on a per-device (card/chipset) basis.
Didn't it used to be the case that a lot of FreeBSD devs used OSX while OpenBSD devs used OpenBSD and this dogfooding produced better device driver support on OpenBSD?
I heard that somewhere many years ago, but it may be false.
Yes that's absolutely true. And sad. What did FreeBSD do now? They are trying to create an environment to run Linux WiFi drivers. It's so hard to get documentation and support to develop a WiFi driver, less and less people want to do it.
Agree with the documentation, its rock solid and NOOB friendly. 7 years ago I had to rebuild and restore an embedded server for a client and with no BSD experience at all it took me a few hours and has been working flawlessly since.
Really wish there wasn't a split between FreeBSD & Matt Dillon 20-years ago, since DragonflyBSD is so strong and yet FreeBSD hasn't benefited from it's innovations.
They'd truly would be better together than apart.
Can only imagine how much stronger the BSD ecosystem would be overall today, if the past 20-years these teams had been together.
EDIT: "stronger together" meaning, FreeBSD would benefit from the technology innovations, architecture simplicity and performance that DragonflyBSD brings ... and DragonflyBSD benefiting from the larger install base that FreeBSD has (and it's brand recognition).
Complexity management is key in any project. Lots of successful forks reduce total complexity. NetBSD and OpenBSD are excellent examples — one could argue that their goals and innovations (in portability and security) would also be useful in the «mainline» FreeBSD, but that would explode complexity.
The FreeBSD community is carefully watching progress across many forks and cherry-picking / importing a lot of the cream.
I’m not sure what to make of it, but amusingly your link says “OpenBSD version of netbsd_hammer2”, which itself says “NetBSD version of freebsd_hammer2”, which in turn says “FreeBSD version of openbsd_hammer2”.
They’re all under the same profile so I think everyone is sharing?
I also would prefer that this split would not had place and that DragonflyBSD would never start ... but yet it happened ... so what?
Recently (as a seasoned FreeBSD user/sysadmin) I tried DragonflyBSD to check how it went ... and it lacks a LOT of things that FreeBSD has - like for example the GEOM framework.
On FreeBSD its quite easy to list block devices like:
FreeBSD # geom disk list
... but on DragonflyBSD its not possible as there is no GEOM ... so the only thing you can do is to:
DFBSD # camcontrol devlist
... but its far from usable and its very limited.
On FreeBSD I was able to write lsblk(8) Linux replacement ... I would not be able to do that on DragonflyBSD.
Yes - its a pity that such a talented person such as Matt Dillon left FreeBSD project - but DragonflyBSD is not a better replacement also ...
I think it's fair to say that DragonFlyBSD has diverged with vastly different goals to FreeBSD. It's a good thing it's able to do what it sets out to do. It's not trying to replace FreeBSD.
> “ From what I recall, the FreeBSD team made the right call at the time.”
I’m not so sure.
Given how unstable FreeBSD 5 (intro of new SMP) was, until it finally stabilized multiple years later at v8.0 - I’m not sure others would have that same sentiment.
And seeing how DragonflyBSD performance is standing up to FreeBSD (and best’ing it times) even though they have a radically smaller developer community (and no corporate support) - it does challenge the topic of who was right.
I do think objectively, people would state that DragonflyBSD chose a clean/simpler architecture that’s easier to understand
>Where are the Apache, NginX, PostgreSQL and Redis benchmarks?
>Where are the measurements of network performance?
You'd have to ask Larabel about that. But given that Dragonfly can seemingly trade blows with FreeBSD *18 years later* does seem to suggest there's some merits to their design
Oh.. here is a benchmark [0] from 2021, Dragonfly performs comparably with Ubuntu and FreeBSD 13 on an intel core i9 of some type. I have no idea whether these benchmarks reflect real world performance. I also don't know where and how much Dragonfly is used in 'production'.
It was all truly unfortunate. But sometimes there are no clear right answers - but you have to make a choice between multiple bad options. When doing nothing isn't an option either then you have to make a call as to what you think the least terrible outcome will be and history will be the judge as to whether you were right.
Similar issues contributed to there being multiple *BSDs. It's never that simple of course, but it was certainly a part of it. Technical/ideology and Personality all play a part.
You've gotta be careful giving vikings a commit bit.
Your best bet for information is probably the mailing list archives. To be a bit reductive, Matt had strong opinions about SMP and threading and got his commit bit yanked. As a result he forked FreeBSD (4?) to create DragonFlyBSD. It's not so far off of how we ended up with OpenBSD really. Or as Linus put it, Theo is… difficult.
Honestly, I think these forced forks are good. They're a a perfectly natural result of getting a bunch of smart, opinionated people in a group together. They've given some incredibly smart people a much bigger sandbox to play in. As a result we've got things like openssh and hammer.
Not necessarily in disagreement, but some points to consider:
* The nice thing about free software is that FreeBSD can benefit from Dragonfly's innovations!
* Dragonfly certainly would benefit from FreeBSD's (relatively) large userbase; but it could also be hurt, because FreeBSD's larger userbase would be more demanding of the kind of stability that could slow down innovation.
* ...and, likewise, FreeBSD might suffer if all those innovations harm the OS' reputation for robustness and stability.
Not to be mean, but I started using Linux in 1992 (yes that early on,
from the usenet posting), and I seem to recall hearing a lot more about
FreeBSD or the *BSDs about 30 years ago than I do now.
In my UNIX circles that I run around in, no one talks about FreeBSD. Honestly
asking (yes, I guess I did not read the article) is most of its success
on the commercial side? I think it is used in NAS boxes and routers/switches a lot, right?
There are plenty of companies that may not use the full BSD stack but pull bits and pieces of code as needed. Microsoft is known to have built off BSD networking code for Windows.
>Microsoft is known to have built off BSD networking code for Windows.
30+ years ago, when everyone was basing their TCP stacks on the BSD implementation. That was one of the reasons that the infamous 64k+ "ping of death" affected more than just Windows in 1998.
The stack was re-written for Vista/Longhorn more than 20 years ago.
My point being that the GP question was about FreeBSD's success today and the Windows TCP stack is not a good candidate to illustrate that.
I did some experiments to find out what is the bare minimum I would need for remote work (VPN+RDP). It turns out it would be possible, albeit a bit slow, on a Pi B (512MB of RAM) using OpenBSD or FreeBSD. The latter was a bit faster.
With Raspbian, I would need more memory (1GB did the job).
On the negative side, there aren't as many packages for the BSDs on ARM.
Anyway, it got me interested enough to buy an x86 laptop just to run FreeBSD.
Going by volumes of commits and posts on most mailing list, it has been in a long slow decline since probably early-mid 00's. I'll leave others to speculate on the reasons, but it is a pity. I'm a Linux user and developer and hardly meddled with the BSDs, but I think competition in the open source OS space is a great benefit. I certainly remember the competition used to spur ideas and development in days past.
One thing that has amazed me is that despite the weight of development and investment in Linux far outstripping FreeBSD since around that time if not earlier, FreeBSD still managed to hold its own in performance, at least in some workloads and situations. Is there something about the people, community, methodologies, or technology that provide advantages to help achieve this? It would have been nice to know what could have been with a more even split of resources.
Although I will say in my experience by far the most capable people have been those with passion who would have been working on a project as a hobby anyway (if not so many hours), and often the best results come from those people attacking problems that interest or concern them as opposed to ones that go through committees and executives and project managers, etc. The latter often serve to crapify things in the long run by being driven by short-term and selfish thinking (not necessarily by any one developer or person, just the nature of the whole beast). Linux kernel has been doing as well as can be expected in avoiding that corporate crapification, but it certainly is not immune. I could easily believe the average developer-hour invested in FreeBSD has a far greater value to the project in general than that in Linux (yes I'm aware many FreeBSD developers do get paid to work on it, and many Linux ones don't).
Its secret to 'survival' is more appropriate. This article has a lot of fluff.
eg:
Specifically, companies needing redundancy
require more than one operating system, since any single operating system may fall
victim to a failure that could take out the
entire company’s infrastructure
What sort of argument is this.
We need multiple political parties. Therefore, our existence is important even if we secure insignificant votes?
Or does he mean BSD license vs GPL? In which case, I agree with his idea of diversified choices.
It's the same reason why porting to obscure CPUs can be useful: DEC Alpha was never popular, but supporting it kind of forced Linux to be 64-bit clean in some ways, so when amd64 came along there was already a bunch of infrastructure in place.
And having 'external parties' that are not part of the same 'tribal structures' and same zeitgeist / group think can allow for experimenting of ideas.
> It's the same reason why porting to obscure CPUs can be useful: DEC Alpha was never popular, but supporting it kind of forced Linux to be 64-bit clean in some ways, so when amd64 came along there was already a bunch of infrastructure in place.
Nitpick (and you didn't necessarily imply otherwise), but x86-64 was a latecomer to 64-bit ports in Linux. SPARC I think was next after Alpha, and MIPS, PARISC, IA64, PowerPC at least all came before x86-64 was merged.
Wasn't the Alpha port the first chip it was ported to back in the 1990's? I know the Amiga people did their own thing but I don't think it was ever properly merged back upstream
Wasn't there some kind of issue with a leap second sending machines (Linux machines?) off the deep end years ago (and all about the same time)? Conceptually, if you're running a mix of OSs, then there's much less chance of something undiscovered wiping out your entire infrastructure.
There was a story I heard that when working on the avionics for one of their planes, Boeing mandated three separate CPU architectures, with the code developed by three different, isolated, teams, using three different toolsets (languages and runtimes) to minimize the risk of some Unknown Unknown commonality taking them all out. Dunno what actually happened. Could be completely folklore.
I think the statement is poorly worded. Perhaps a better formulation is that a monoculture carries a special kind of risk (it also holds benefits to a business of course). Same is true in politics where having a strong ruling party and an enfeebled opposition is not healthy. You need some external energy into the system to keep it on its toes.
>Not to be mean, but I started using Linux in 1992 (yes that early on, from the usenet posting), and I seem to recall hearing a lot more about FreeBSD or the *BSDs about 30 years ago than I do now.
>In my UNIX circles that I run around in, no one talks about FreeBSD.
This downgrade is quite sad. Too many of the enterprise grade network devices rely on linux.
At least the FreeBSD Junos still runs on the devices on top of KVM. I just can't understand why they didn't go for jails/bhyve or illumos zones instead.
> This downgrade is quite sad. Too many of the enterprise grade network devices rely on linux.
This is in no way a downgrade. Juniper just read the writing on the wall. Arista boxes ran Linux from day one and have a much better reputation for stability than virtually any other vendor.
It still doesn't change the fact that putting all eggs to one penguin-shaped basket give me the heebie-jeebies. Monoculturization is never a good thing, yet everyone seems to run towards it with a glee on linux.
At least I can put money where my mouth is and continue budgeting for Juniper as long as they support FreeBSD.
The viewer is emblematic of FreeBSD itself, in a way.
"The major browsers have implemented rich native viewers for this industry-standard format now, that work on any OS, including ours. So what we will do is this: we will invent our own format and our own reader, done differently, with different controls. We will only have the time and manpower to implement, oh, maybe 10% of the features, but that doesn't matter."
"Hey! Why are people complaining about it? It works for us!"
I would echo the "I wish the split hadn't happened" voices but I suspect that the magic number of variants of an OS are around 3-5 and thats kind-of where we sit.
It always was (to some extend) a set: Bell vs Berkely vs Digital vs Sun vs "the rest" with things taken from each, and added back. Getopt, NFS, mods to the TCP/IP stack, ideas about virtual disks and filestores.
I may misunderstand, but I think there are "more" variants of Linux, but probably close to this magic number of really significant distros.
I drove FreeBSD as a desktop on multiple machines for decades. I now live in OSX but I continue to operate FreeBSD for research nodes on Dell, but with more debian in the mix now than before.
I'd love to try FreeBSD on RPi4 but what i read suggests it still has some issues in the uBoot and install area. I drive a 4 disk ZFS node through a jmicron USB-SATA bridge card, I need to be sure that will work before I can move but having adopted ZFS on Ubuntu the good thing is, ZFS variants apart, I SHOULD be able to do this transition without dataloss, assuming the controller chip works.
Up in server land I've migrated between Debian and FreeBSD for ZFS filestores multiple times. Its really easy.
I love FreeBSD and have been running it as a primary OS in my home and in my work since the late 90s. Unfortunately, there's some long-standing bugs that seem to have no traction to be resolved around booting from USB storage that impacted me in my home and some systems had to be rebuilt on Linux, making me not Linux-free at home for the first time in over a decade. I love FreeBSD and I hope it has another 30 years of success.
This is so nice to see. Glad that FreeBSD is still alive after all these years. I guess I can share my story :)
I played with some early versions of FreeBSD and OpenBSD but, at the time, I was still a Linux newbie so I wasn't comfortable with them. Disk I/O on FreeBSD 3.x was super-slow compared to Linux out of the box... because I didn't know what "soft updates" were and how enabling them would have resolved all my issues.
It wasn't until FreeBSD 4.0 that I had learned enough Unix to make the jump, and that became my primary desktop for a while. Soon after, I switched to NetBSD (1.5.2), which I used as my only OS for various years, and I became an avid contributor to the project. I ported and maintained Gnome 2.x, and then developed things like tmpfs and the NetBSD testing framework.
But... Mac OS X came along, I jumped ship to an iBook, and without being exposed to the BSDs on a daily basis via a desktop environment, I slowly lost the interest to continue using and contributing to them. I always said back then that having a strong desktop story was super-important to capture developers, and I think it still is. And I wasn't the only case. Mac OS X "stole" many BSD developers because it /was/ almost-BSD-but-with-a-great-UI.
So I had left, until recently. I had kept a VM around all these years mostly as a curiosity, but just over a year ago, I set up (again) a home server on a "bargain" ThinkStation I found, mostly to act as a NAS and to run VMs on. My obvious choice was FreeBSD (I still "believe in" the BSDs), and ZFS and bhyve have delivered rock-solid and extremely pleasant experiences. Every time I type some zfs or vm commands, I'm amazed by how well the thing works.
I used to favor NetBSD due to its minimalism and its portability, which in turn meant it had a neat internal design (which is what "wowed" me). But by then, it's true that FreeBSD was already the "easy to use" FreeBSD with the most active contributor base, although it was stuck on i386. I think this ease of use continues to this day, and FreeBSD has seen a lot of improvements to its internal design to make it portable. FreeBSD is less daunting to the beginner user _and_ developer, and I think the latter is also critical to run an open source projects these days because, to gain new contributors, you have to meet them where they are. FreeBSD's adoption of "common" tools, such as Git, Phabricator or Bugzilla (even if not "ideal" by some standards) has helped.
I guess I should spend the time to write a full retrospective, but that will do for today, hehe.
I've been an erstwhile FreeBSD user since v2.x (ca. December 1996),
running FreeBSD on my own machines since v4.x (ca 2001), and started
using it as my primary laptop/desktop daily driver since v5.3 (ca.
November 2004). Prior to that, SunOS/Solaris was my drug of choice.
In the past, I would update the OS and ports religiously, sometimes
rebuilding world and packages on a weekly basis. I've never once
experienced any bumpiness between v5.x and v8.x (or any other version,
but see my comments on v13 below). The OS has always been rock solid.
I have occasionally experienced some package issues, usually when
upgrading a port that had lagging dependencies -- some packages written
in PHP come readily to mind. The number of times this has happened is
more than 2 and less than 6, and in each of those cases, using
portdowngrade and waiting it out a few weeks did the trick.
Apart from OS-independent hardware issues, the only real FreeBSD issue
that I've ever encountered was in the v12->v13 upgrade. If you were
running ZFS, there was a gpart bootcode command you needed to run as
part of the upgrade process, which I sometimes forgot to do, which
caused the post-upgrade reboot to hang. Normally this wouldn't be a big
deal, you just insert the rescue CD and run the command and be on your
way 2 minutes later; but at that time I had a number of my servers
running on a VPS provider that didn't allow you to mount your own ISO,
so I had to wipe the machine and reinstall the OS from scratch and
restore stuff from backups. I don't really count this as a FreeBSD issue
per se, just an obtuse service provider. (I've since moved most of my
digital properties oceans away from that company.)
Nowadays I upgrade the OS and packages far less frequently. I upgrade
the OS with every minor release and also if there are any security
issues that affect me. I upgrade the packages every couple of months, or
if there is a bugfix that affects me, or if I need a new feature only
available in a newer release.
Since I started using it, there have been a number of developments that
have made my FreeBSD life so much better: cperciva's portsnap and
freebsd-update, pkg-ng, and of course the biggest one: ZFS. All of these
allow me to maintain and upgrade the systems very easily.
I stick with FreeBSD because of its consistency and ease of use, so I'd
be curious to know what you mean by "bumpy"?
I've been running FreeBSD since the 2.x days. I worked at an early ISP where we used it for DNS, mail, and NNTP. Eventually I started running it at home.
Yes! It was so huge in the ISP space back then because trying to run something like NNTP on Linux at the time was just not a great experience for customers. Indy ISPs aren't really a thing these days I guess, but back then it was a really strong market for FreeBSD.
In case you haven't already, you might want to check out the McKusick courses (available as videos). They're not cheap though, maybe you can find pirated copies.
I was fortunate enough to see some back in the VHS days when someone in a local LUG convinced their employer to buy them as a way to support FreeBSD and give the team something to watch together (and recruit from the LUGs via hosted viewings no doubt).
There isn't much special secret sauce that Netflix has at the OS layer of things, so there's not much reason for them to keep the patches in-house (and then have to maintain as the public source rolls forward). Other vendors that give back are Dell EMC Isilon (keeping their OneFS code private), Juniper, Netgate, etc.
Sony is unique in that it was a one-time fork, and now that the product is out there's not much churn in things.
Most vendors have learned that keeping things in-house just causes pain down the road when you have to re-base with the latest FreeBSD release.
If you're fine with violating the license, then there is nothing stopping you from closing the source to GPL licensed software without a word of credit. I'm not sure what your point is.
The Nintendo Switch is based on FreeBSD as well. Also Juniper Networks and several other enterprise networking equipment manufacturers make extensive use of FreeBSD in their products.
With heavy use in Netflix's CDN resulting in something like more than 15% of internet traffic being delivered by FreeBSD, that's some kind of success I imagine.
Yeah I hear this statement a lot too but macos is based on nextstep much more than it was on FreeBSD.
Of course nextstep borrowed some userland from FreeBSD and I think this is where the confusion originates. The actual kernel is totally different though.
The fundamental services and primitives of the OS X kernel
are based on Mach 3.0. Apple has modified and extended
Mach to better meet OS X functional and performance goals.
It is correct to say some parts of OS-X/macOS are based on FreeBSD, but not to the point of making an unconditional assertion. As to user-land utilities, many are the same as found in a FreeBSD distribution.
A little more.. Apple hired Jordan K. Hubbard, the FreeBSD co-founder, back in 2001 to work in the Core OS Engineering Department. His role at that time was manager, BSD technology at Apple, overseeing the BSD Technology Base for Darwin, the UNIX-based core of Mac OS X.
I remember a very early release of Darwin, was interested at the time to see if it would eventually become a standalone product, but it never did. I assume there was a lack of corporate support, much like how Google is now trying to slowly close AOSP via removing core pieces like the dialer.
"I find FreeBSD's self-congratulatory nature quite off-putting, as well as the issues with its leadership and culture. It makes me feel nauseated. Perhaps focusing on attracting more users should be a priority."
Save it on disk, fsync twice :D and use it next time.
A free software project doesn't have to be ubiquitous, or even popular, to be a success. Things like usability, usefulness, technical excellence, beauty, community activity, contributor-friendliness, and longevity are all legitimate software successes, each in their own right.
Never mind the veracity of the reasoning you gave— why are we even looking for reasons to discount and dismiss a beloved, storied, ongoing F/OSS project like FreeBSD?
was it really constructive for this pioneering tech to choose the actual "devil" as a logo? then the move to shiny plastic look for the logo? long-standing public divisions with no end.. niche opinionated choices sure, but dont be surprised at the results.
Is anyone actually offended by a mascot based on a joke about "Unix daemon"? Do they just not get the joke or are they really that sensitive? I imagine it's the same sort of person that opposes table top games like Dungeons & Dragons and shares out Chick tracts (often highly offensive and rude, ostensibly Christian, cartoon tracts denouncing Catholics, Jews, and Muslims, in particular, as well as other groups; we had someone leaving them in our office for a while).
>I just got a call from the owner of a hotel for which we provide hotspot service. She says that a guest spotted the "Powered by FreeBSD" logo at the bottom of the login page, and was offended; the guest was convinced that either we or the hotel management "worshipped the Devil" and refused to stay at the hotel unless the logo was removed.
If you really search for it, you will always find someone offended by anything.
Only a few years ago there was this German guy that bullied VS Code into removing their cutesy Santa hat which doesn't even have any religious context, it's originally a coca cola thing :')
Anyway, having ubiquitous usage is not a goal of FreeBSD. People are free not to use it if they don't feel like it. I guess there's not much overlap in people being offended by penguins and those offended by daemons so I might have another suggestion :P
It's not a devil but a daemon and I don't think this has ever caused people to not use it.
I mean beastie is super cute and wears green sneakers. You'd have to be really hardcore religious like Amish to take that seriously and they abhor computers anyway :)
I like the new logo too. It's just a ball with two cones really.
Things I appreciate about FreeBSD:
- init system (with real PIDs).
- FreeBSD documentation.
- installation experience (fast and hassle-free).
- stability, consistency and low memory usage.
- DWM / XFCE works great.
- ease of configuring PF
However, there are some main impediments that prevents me from using it as my daily driver:
- WiFi drivers don't work unless it's a ThinkPad I think (specifically Broadcom 4360 on old Macbooks), I bought a Realtek USB WiFi adapter, which works but with reduced performance.
- There are sketchy sound driver issues with the laptop speakers, resulting in tinny sound.
- Bluetooth doesn't work at all, although my BOSS system shows up on hcinquiry.