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!"
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?
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.
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.
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.
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.
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
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).
>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.
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.
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.
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.
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.
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).
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?
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.
> “ 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'.
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.
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.
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.
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?
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 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.
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.
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.
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 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.
138 comments
[ 1.5 ms ] story [ 248 ms ] threadThe 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!"
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?
Juniper's boxes all used to run a FreeBSD derivative. But even they have introduced Linux based products.
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 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.
eg:
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.
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.
Yes, it keeps userland code honest if you follow the published API and not a specific behaviour. See for example the fsync() saga on Linux:
* https://lwn.net/Articles/752063/
* https://news.ycombinator.com/item?id=19238121
* https://news.ycombinator.com/item?id=19119991
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.
Dave Cutler(Windows NT) too found the DEC support to be a safety test for cleanliness.
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.
You can infer others if you look at the historical sponsor pages: https://freebsdfoundation.org/our-donors/donors/
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.
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.
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.
PlayStation OS is basically the FreeBSD kernel and a custom userspace tailored to the console.
...though I guess you could also argue that people felt like they had more stake in GPL than BSD-licensed code.
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).
(References)
https://marc.info/?l=freebsd-commits-all https://marc.info/?l=freebsd-hackers https://marc.info/?l=freebsd-current
>In my UNIX circles that I run around in, no one talks about FreeBSD.
There's a reason why the "BSD is dying" copypasta <https://everything2.com/title/BSD+is+dying> was born 25 years ago!
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.
I heard that somewhere many years ago, but it may be false.
Can somebody elaborate on FreeBSD's "success"?
Being available alongside Linux distributions as official supported OS on major cloud vendors.
Maybe the contributions to upstream could be better, but that is the choice they decided to make.
Isn't that thanks to its license? They literally can be used in closed source software without a word of credit.
* https://www.freshsource.org/commits.php
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.
There's a lot of weird reasons why you'd use FreeBSD in storage appliances that I have mixed feelings about.
3,975 commits.
This is not true of any of the "acceptable licenses" listed by FreeBSD.
https://www.freebsd.org/internal/software-license/
See: the clauses saying "must reproduce/retain the above copyright".
Yeah, you will see the copyright if you are working at the company. Outsiders would never know it's a fork.
Netflix uses FreeBSD in production on parts of its infrastructure.
Those two alone are pretty nice success stories.
And in addition to those are countless other companies quietly running FreeBSD on their servers.
https://en.wikipedia.org/wiki/List_of_products_based_on_Free...
see e.g. https://youtu.be/Ec4NgWRE8ik?t=700
https://news.ycombinator.com/item?id=27109219
https://news.ycombinator.com/item?id=17534593
Of course nextstep borrowed some userland from FreeBSD and I think this is where the confusion originates. The actual kernel is totally different though.
And the kernel space for both absolutely have a lot of BSD code, more than the Mach or IO/Kit portions last time I checked.
Regarding OS-X/macOS:
(source: https://developer.apple.com/library/archive/documentation/Da...)Some portions of the OS-X/macOS kernel are based on FreeBSD however:
(source: https://developer.apple.com/library/archive/documentation/Da...)As the above states:
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.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 would really like to buy a new edition of "The Design and Evolution of FreeBSD", if it ever happens.
It’s a nice book. I bought it years ago.
I haven’t finished reading it yet, as it is a lot of pages and quite heaving reading.
But I like it a lot. And I will continue to read it.
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).
https://www.mckusick.com/courses/
Thanks for the link.
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.
https://www.dragonflybsd.org
Announcement:
https://lists.freebsd.org/pipermail/freebsd-current/2003-Jul...
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).
The FreeBSD community is carefully watching progress across many forks and cherry-picking / importing a lot of the cream.
E.g., there's active exploration of bringing the Hammer2 filesystem from DragonflyBSD to OpenBSD.
https://github.com/kusumi/openbsd_hammer2
They’re all under the same profile so I think everyone is sharing?
https://people.freebsd.org/~kris/scaling/dfly.html
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.
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.
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
https://www.phoronix.com/review/bsd-linux-eo2021
Matt Dillon announced DragonFly BSD nearly 20 years ago on July,16 2003
FreeBSD 8.0-RELEASE was announced Nov 25, 2009
You’re talking about events that took place over 13.5 years ago.
On the benchmarks:
Where are the Apache, NginX, PostgreSQL and Redis benchmarks?
Where are the measurements of network performance?
>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
But FreeBSD took the mainstream approach.
https://www.dragonflybsd.org/performance/
https://www.dragonflybsd.org/performance/ Has one from 2012 and an update 2018 with a Threadripper 2990WX, though there is no comparison chart..
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'.
[0] https://www.phoronix.com/review/corei9-freebsd13-dfly6
* 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.
I think the BSD ecosystem was harmed more by the SCO lawsuit, and the rise of Linux than by the Dragonfly/FreeBSD split.
SCO brought lawsuits against IBM (Linux) in 2003.
https://en.m.wikipedia.org/wiki/SCO_Group,_Inc._v._Internati....
USL brought lawsuit against BSD in 1992.
https://en.m.wikipedia.org/wiki/UNIX_System_Laboratories,_In....
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:
... but on DragonflyBSD its not possible as there is no GEOM ... so the only thing you can do is to: ... 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 ...
Regards, vermaden
>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.
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
https://github.com/microsoft/vscode/issues/87268
Anyone is free to have an opinion, including not paying any attention to idiots and intolerants.
- Company admits to using FreeBSD.
- Christian groups who are shareholders complain at the execs
- FreeBSD is no longer used at the company.
CockroachDB has a similar naming problem, though that tends to be the execs themselves objecting.
30 years ago it wasn't divisive nor a niche opinionated choice. Kinda the obvious choice. But I guess some people really want it to be [2].
[1] https://en.wikipedia.org/wiki/BSD_Daemon [2] https://www.ign.com/articles/someone-complained-to-ad-standa...
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.
> Don't feed egregious comments by replying; flag them instead.
Frankly, your wall of text is less helpful to the discussion here than the comment you're replying to.
Note: I have no opinion on what you and the other commenter are talking about.
(not in a snarky way, I want the story!)
It's described a bit here.
FreeBSD is far more of a general OS, NetBSD is more known for its minimalism and extreme breadth of hardware support. It can run on almost anything.
But in terms of usage numbers I'm pretty sure FreeBSD trumps it.
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?
Curious to hear your feedback of FreeBSD v5-8. Since many consider those releases (years) very bumpy.
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"?
This part of FreeBSD history in Japan is also very interesting to read.
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 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.
Leadership ugh culture argh.
Makes me want to retch.
How about get some users?
"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.