Current (any month, year?) evidence-supported strengths of FreeBSD over a major Linux like Debian?

I am making this thread, because I found some quite old threads of a similar kind, but nothing that's organized or that discusses the issue at any given time. Having the right keywords also makes searching for this info hopefully easier.

The question for this thread is:

What evidence-supported strengths does FreeBSD have over a major Linux like Debian 12?

I just want to understand the strongest areas where FreeBSD shines over Linux or is at least equivalent.

---


The main motivation for this thread came from this speculation around this other thread:


That is, in order to understand what's a smart way to "connect" the OSes, then one needs to know where their strengths lie, so for most part one can combine the strengths of each OS.

---

I suggest this thread can be used as a standard thread for questioning the status quo at any time (week, month, year, ...) so that new threads about GNU/Linux vs FreeBSD do not need to be created.
 
Last edited:
What evidence-supported strengths does FreeBSD have over a major Linux like Debian 12?
For what use case?

The number of differences between the two is huge. Some of the differences are very significant, in particular the license, and the upgrade/update workflow. But even more importantly, the style and character of the core group of people that make the architectural, design and culture decisions for the two are very different. As examples: Kirk and Linus are very different personalities.

On the other hand, the practical everyday differences between them can be so tiny that you don't even notice. These days, I often have shell windows on three different OSes open at the same time (Debian Linux on an RPi, FreeBSD on a server, Darwin/MacOS on my laptop), and if usually don't know and don't need to know which shell window I'm in, because they all work the same.

So, in what context are you asking the question? Are you distro hopping and want to know what OS to try next on your laptop? Are you trying to decide what base kernel to use for the next generation dishwasher or refrigerator (both Linux and BSD are viable as embedded systems)? Are you a cloud company trying to set up a million machines? Do you need commercial support, because availability and reliability are so important to you that you want to pay for that? Are you an intelligence agency and worried about the security of your systems?

The fact that both of them exist, and are thriving, are are used by people (as an example: I use both, and other OSes) tells you that the answer is not simple.
 
#1 with strongest evidence is the absence of the Linux Foundation. Easily makes FreeBSD more reliable and a stronger choice for computing.
yeah, we have FreeBSD Foundation instead. :rolleyes:

Campy politics do, unfortunately, have an effect on how system components are put together. The FreeBSD camp makes different decisions than the Linux camp. Both camps have perks and downsides, fans and detractors. But even then, politics don't have a very robust and watertight case for being a direct cause-and-effect relationship between dev preferences and quality of end product. Just being an outsider of Linux Foundation is not enough to be a strong competitor to it. FreeBSD Foundation operates in the same space as Linux Foundation, in the sense that both provide some direction, a set of ideals that devs and users can bandwagon around, and both produce ultimately similar end results - a very capable, general-purpose OS available to users free of charge. Which one is a 'stronger choice' - that's debatable.

Design decisions for components underneath all that familiar software that runs on either Linux or BSD - yeah, they are limited by what's available to the dev in a given camp. Metaphorically speaking, there may be just a couple devs in the BSD camp, but their end product has close to the same capabilities as stuff made by 100 devs in the Linux camp. And Linux camp is pretty famous for encouraging distro-hopping.
 
yeah, we have FreeBSD Foundation instead. :rolleyes:

Campy politics do, unfortunately, have an effect on how system components are put together. The FreeBSD camp makes different decisions than the Linux camp. Both camps have perks and downsides, fans and detractors. But even then, politics don't have a very robust and watertight case for being a direct cause-and-effect relationship between dev preferences and quality of end product. Just being an outsider of Linux Foundation is not enough to be a strong competitor to it. FreeBSD Foundation operates in the same space as Linux Foundation, in the sense that both provide some direction, a set of ideals that devs and users can bandwagon around, and both produce ultimately similar end results - a very capable, general-purpose OS available to users free of charge. Which one is a 'stronger choice' - that's debatable.

Design decisions for components underneath all that familiar software that runs on either Linux or BSD - yeah, they are limited by what's available to the dev in a given camp. Metaphorically speaking, there may be just a couple devs in the BSD camp, but their end product has close to the same capabilities as stuff made by 100 devs in the Linux camp. And Linux camp is pretty famous for encouraging distro-hopping.
I only meant that FreeBSD is a better system by virtue of not being related to the Linux Foundation.

EDIT: Your post did remind me of #2 The absence of Linus Torvalds. There are many more obviously but these two are excellent evidence supported strengths.
 
More about the Linux Foundation. IMHO what happened WRT bcachefs during the 6.13 release cycle is pretty hard to believe. I understand that the dev is probably not the best person to work with but to block him and his contributions to the kernel for an entire release cycle and thus deliberatly ship a kernel release with known bugs that could already be fixed because of a "code of conduct" issue is just insane.
 
Formerly, the FreeBSD Myths pages used to have
*BSD is better than (insert other system)
This is user opinion only.
(insert some other system) is better than *BSD
This is user opinion only.
It's not there anymore, but I am always reminded about something someone wrote in a thread about mutt vs pine, before pine became alpine.
People will pull out all sorts of technical reasons to support what is, in the end, an emotional decision.

FreeBSD appeals to some people, and not to others. It does some things better than Linux, but with others, such as wireless, it doesn't.
 
Formerly, the FreeBSD Myths pages used to have

It's not there anymore, but I am always reminded about something someone wrote in a thread about mutt vs pine, before pine became alpine.
People will pull out all sorts of technical reasons to support what is, in the end, an emotional decision.

FreeBSD appeals to some people, and not to others. It does some things better than Linux, but with others, such as wireless, it doesn't.
It would be a scientific project but it should be possible to set up a trial&error scheme to get a linux and BSD kernel to boot from the same volume. This will initially be very large and redundant, but things can be made uniform to a certain level. For example, both can have the same native filesystem implemented but the same binary executable format is another thing.
 
I only meant that FreeBSD is a better system by virtue of not being related to the Linux Foundation.

EDIT: Your post did remind me of #2 The absence of Linus Torvalds. There are many more obviously but these two are excellent evidence supported strengths.
Y'know... even if you're not a fan of how Linux Foundation functions, that doesn't change the fact that FreeBSD has most of GNU userland and toolchain available in ports, and Linux kernel has a lot of code that was derived from BSD in the first place.

It's just pure luck that BSD is even a comparable competitor to Linux. There's smart people in both camps... Linus is the guy who came up with git in the first place - and guess what, git is the official tool that FreeBSD devs use for development.
 
Linus is the guy who came up with git in the first place - and guess what, git is the official tool that FreeBSD devs use for development.
I don't think that anyone can dispute Linus' capabilities as programmer and kernel developer. And I'm sure that LibreQuest wasn't thinking at it when he wrote his post.
 
Y'know... even if you're not a fan of how Linux Foundation functions, that doesn't change the fact that FreeBSD has most of GNU userland and toolchain available in ports, and Linux kernel has a lot of code that was derived from BSD in the first place.

It's just pure luck that BSD is even a comparable competitor to Linux. There's smart people in both camps... Linus is the guy who came up with git in the first place - and guess what, git is the official tool that FreeBSD devs use for development.
Vanilla Linux is not GNU. If you want a GNU Linux you have to mod the kernel. So Linux and GNU are not the same thing. :/ <-- EDIT this doesn't have much meaning. lol What I mean is that Linux isn't not a FSF approved kernel it's also not part of GNU but can be used with GNU. I'm not sure what happened to my brain when I posted that. lol

https://www.gnu.org/gnu/incorrect-quotation.en.html

From the FSF

https://www.gnu.org/distros/common-distros.en.html

Final EDIT here. I have no issue with GNU software and I use GNU on all of my systems. However, I have no Linux on any of my systems.
 
Well, there is a lot of software out there that was developed on Linux, but nobody bothered to port or package it for FreeBSD. Source code is available via Github, it's just a matter of having someone with time, interest, and skill to get it to compile on FreeBSD.

One example is Karp, I played with it via KDE's src builder tool... and it works fine on FreeBSD.

Another is Beelzebub, which I have not tried - but there are similar projects in ports. Yeah, you have to set up the compiler toolchain properly on FreeBSD, and that task takes talent. For someone who knows what they're doing, it doesn't really matter if they're using Linux or BSD as the basic OS for productive development. Latest versions of git are available for both, and that's just the start.

Every project has to make decisions about what they support and what they ignore, and what kind of reasoning leads to a given decision.
 
... but to block him and his contributions to the kernel ... because of a "code of conduct" issue is just insane.
Maybe it is. Maybe it is the only sane and safe answer. Having a kernel developer who is out of control, introduces bad code into the kernel regularly, and is immune to being taught to not do that, would also be insane. In the case of BcacheFS I don't know enough about the details and personalities involved to make judgement what is right or wrong.

People will pull out all sorts of technical reasons to support what is, in the end, an emotional decision.
Or a financial, or political, or unmeasurable technical decision. For example: What would the estimated cost of lawsuits over license issues be? How high is the risk that our solution will not be future proof, and we'll need to switch again soon? How likely is it that some politics issue (such as immigration, code coming from the "wrong" country, ...) will derail our plan? These are issues that are real, but hard to measure.

It would be a scientific project but it should be possible to set up a trial&error scheme to get a linux and BSD kernel to boot from the same volume.
Even easier: If the OP knew exactly what their workload was (for example in batch computing: run this particular workload on this particular hardware), it would be difficult but possible to measure the performance of the two OSes. After suitable tuning. But this is very difficult, and full of assumptions. For example: With OS A I would invest another $10K into memory, while OS B would benefit from instead using that money for faster disks. Does that change the tradeoff?

I don't think that anyone can dispute Linus' capabilities as programmer and kernel developer.
His capabilities in that respect are frequently disputed. I won't think there is a consensus whether he's a great, good, decent or awful coder or software engineer. There are many viewpoints on this, and it is a question of viewpoint. But that's also no longer relevant; today he's the manager of a very large and complex operation, and interpersonal skills are what is needed now. And again, that's an area where the opinions on Linus' work diverge greatly.
 
More about the Linux Foundation. IMHO what happened WRT bcachefs during the 6.13 release cycle is pretty hard to believe. I understand that the dev is probably not the best person to work with but to block him and his contributions to the kernel for an entire release cycle and thus deliberatly ship a kernel release with known bugs that could already be fixed because of a "code of conduct" issue is just insane.
Sorry, but I personally see 'code of conduct' as something pretty important, especially on a big project like Linux kernel. There is some truth to the old adage that "Managing programmers is like herding cats". On a big project, people do need to be on the same page about what to do, and to what end their efforts should go. Just being able to cooperate with each other and being open to learning from each other, and being able to have a civil, productive, informative conversations with each other - that goes a LONG way towards having a higher quality product.

You can have somebody capable of solving a complex bug, but if the dev is not someone you can work productively with, what would it take to work with that kind of person in spite of such shortcomings? The bug will be eventually solved or rendered irrelevant by progress elsewhere in the project.

And what protection do you have against sabotage? University of Minnesota debacle was not that long ago, or the xz patches. And who can forget how a disgruntled programmer broke the Internet by merely unpublishing a key .npm module?
 
Maybe it is. Maybe it is the only sane and safe answer. Having a kernel developer who is out of control, introduces bad code into the kernel regularly, and is immune to being taught to not do that, would also be insane. In the case of BcacheFS I don't know enough about the details and personalities involved to make judgement what is right or wrong.
In this case we're talking about bugs that were already in the kernel. I don't trust this particular developer and I will never use his filesystem on any of my systems but in general I think that bug fixing should come first, ahead of anything, especially when user data is at stake.
 
Sorry, but I personally see 'code of conduct' as something pretty important, especially on a big project like Linux kernel. There is some truth to the old adage that "Managing programmers is like herding cats". On a big project, people do need to be on the same page about what to do, and to what end their efforts should go. Just being able to cooperate with each other and being open to learning from each other, and being able to have a civil, productive, informative conversations with each other - that goes a LONG way towards having a higher quality product.

You can have somebody capable of solving a complex bug, but if the dev is not someone you can work productively with, what would it take to work with that kind of person in spite of such shortcomings? The bug will be eventually solved or rendered irrelevant by progress elsewhere in the project.

And what protection do you have against sabotage? University of Minnesota debacle was not that long ago, or the xz patches. And who can forget how a disgruntled programmer broke the Internet by merely unpublishing a key .npm module?
Thanks for your answer, I tend to agree with most of what you say but please see also my answer on the post just above this one.
 
In this case we're talking about bugs that were already in the kernel. I don't trust this particular developer and I will never use his filesystem on any of my systems but in general I think that bug fixing should come first, ahead of anything, especially when user data is at stake.
In the case of BcacheFS, the correct bug fix would be to completely remove it from the kernel, at least until it stabilizes. There is a reason I wrote "... introduces bad code into the kernel regularly, and is immune to being taught to not do that ..." above.
 
In the case of BcacheFS, the correct bug fix would be to completely remove it from the kernel, at least until it stabilizes. There is a reason I wrote "... introduces bad code into the kernel regularly, and is immune to being taught to not do that ..." above.
100% agree, it should have never been merged in the first place IMHO.
 
You want verifiable Linux mayhem? I give you mayhem.

So the plain Linux install runs and doesn't automatically suspend. When you install KDE it suddenly starts suspending automatically. WTF is that? The best way to turn this off is not to directly tell it to not suspend on idle, but to mask the systemd event for suspension. So it still tries to suspend but the systemd mechanism has been intentionally broken. WTF is that?

Now it gets better: after a regular update of the OS (Mint) it suspends again. WTF is that?
 
Yes sure. However, e.g. the above issue is not enough to make me or someone switch to FreeBSD for general desktop tasks (for some robust ones, maybe). The strengths of a Linux still outweigh the weaknesses in that use case. For example, FreeCAD on FreeBSD does not offer any tangible benefit over FreeCAD on Debian. I am also currently using Matlab over VMware Horizon and e.g. that program is very usable in such way, and I don't really need more than the application instance. Porting FreeCAD or Matlab to Linuxulator or whatever would not achieve any benefit.

I have clarified the starting post a bit to give a motive for positing the question.
 
You should really take a step back and understand the fundamental differences between FreeBSD and GNU/Linux; there's a huge gap in your knowledge there. This whole comparison is moot.

Software support is a matter of corporate sponsorship and crowdsourcing. FreeBSD is not responsible for that.

FreeBSD does not offer any tangible benefit over FreeCAD on Debian. I am also currently using Matlab over VMware Horizon and e.g. that program is very usable in such way, and I don't really need more than the application instance. Porting FreeCAD or Matlab to Linuxulator or whatever would not achieve any benefit.

That is until you need to debug any sort of error/fault in the application and/or system, or restore application state before some data from it was corrupted, or transfer that data across the planet. Once you start delving into desktop administration is where FreeBSD outshines Linux. If we're talking "desktop tasks" (whatever that means). There are no strengths to Linux; it's just a huge hodgepodge of random s**t.
 
Software support is a matter of corporate sponsorship and crowdsourcing. FreeBSD is not responsible for that.
Well, but as a user I select the one, which runs the software I need. Look at Windows.

Potentially also, if it does not run the software that I need, then do the other benefits compensate for that?

There are no strengths to Linux; it's just a huge hodgepodge of random s**t.

Yes, one can view it this way, but one can also view it like:

GNU/Linux reflects a model of how open source software in the real world exists: unclean, random, chaotically expanding, incomplete, sometimes stable.
 
Back
Top