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

Well, but as a user I select the one, which runs the software I need. Look at Windows.

Then why didn't you just inquire about that to begin with? Instead of trying to incite a flamewar between two different systems.

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

Like ralphbsz said earlier. You need to specify your particular use case. There are many categories that fall under the "desktop computing" space. For which a lot of software exist in the ports tree.

I'll give you an example. If you're a content creator (which involves lots of video editing and post processing); working with lots of large files and mass media. You'll benefit a lot from built-in ZFS in FreeBSD.
 
Well availability of software is just one criterion. It may or may not be the most important.

In count of software, Linux wins, but:

the count might not matter in some use cases
the count might not reflect quality, but OTOH quality might not matter either, so GNU/Linux can still win, even if it's lower quality
...

So FreeBSD might win in a quality scenario, but when does that quality matter for an advantage or when does it cost less for a practical application?

Is this evidential though? Well it depends on the use case's preferences.

---

And no, this is not a flame thread. It just asks to discuss the current state of things in relation to potential use cases.

One common division is to treat FreeBSD as a server or research OS. Is it enough though?
 
Well availability of software is just one criterion. It may or may not be the most important.

In count of software, Linux wins, but:

the count might not matter in some use cases
the count might not reflect quality
...

This is stated incorrectly in my opinion.

If one is NOT writing their own software, "Does this OS support the applications I need" is typically the most important criteria.

The absolute count of number of available software packages should be irrelevant. If OS-A has 10x the number of packages in OS-B but none of the ones you need are available, then OS-A would be a pretty illogical choice for you.

Typical home user desktop usage is:
email
web browsing
documents
Thats enough to keep grandma/grandpa in touch with the grandkids.
If that's all you're doing who cares how many different programming languages are available for the OS?

Choice of a platform should start with "what applications do I need to run" and work backwards into the esoteric things like ZFS and such.

I agree with Beastie7
 
Choice of a platform should start with "what applications do I need to run" and work backwards into the esoteric things like ZFS and such.
But are the platforms distinct/exclusive? I tend to see a lot of overlap and attempts to run the software of another on another. An overlap is not a strength, but potentially a misallocation of resources and it signifies about trying to gain the properties of another. Why though, and is it a strength?

Also, if it's not clear, then this is dev talk, and not the average home user, although the average home user's use case is also a use case.
 
So running a Windows VM on a FreeBSD host to run a specific windows application is not a strength of FreeBSD?
If one takes the source code for say XFCE, which was arguably developed on Linux, rebuilds it for FreeBSD how is that trying to gain the property of Linux? It is simply making XFCE available on FreeBSD. By the way, take that same source code and build it for OpenBSD, DragonFlyBSD, NetBSD, Illumos and any other Unix-like system out there: are you contending that making the application XFCE available on them is trying to gain the property of Linux on them?

It's not an overlap, it is not a misallocation of resources, it is not trying to gain the "properties" of another.
That is the strength of Open Source software. If one has a need to run a bit of software that is not currently available on your desired platform, you can put in the effort to port it. You need it, you port it, no misallocation.

You seem to be trying to conflate applications with "features" (properties) of the base OS. And even some properties may be worth it: Linux filesystems. Creating *BSD ability to mount and read/write Linux ext filesystems is not trying to gain Linux properties, in fact it makes the *BSD more flexible because the external data can be easily utilized.

Your answers are starting to sound like Deepseek AI generated bits taken from out of context sentences.
 
That is the strength of Open Source software. If one has a need to run a bit of software that is not currently available on your desired platform, you can put in the effort to port it. You need it, you port it, no misallocation.
One could run the software on another platform and simply pipe some things between? Then porting is not needed, and would not necessarily be even useful.

Like using Power BI on Windows, but use scripts to push and fetch data from it.

However, in this case one does not need the port, but good facilities for creating and managing those pipes (through POSIX or what?). Now, if the effort would go towards the port, but not the pipes, even if the pipes would be "more useful", then?
 
One could run the software on another platform and simply pipe some things between? Then porting is not needed, and would not necessarily be even useful.
This was actually very close to the topic of my thesis. You run the old game in a purely software emulator (i.e no KVM) and then forward the graphical calls to the native (accelerated) host (TCP/paravirtual). In this case OpenGL is a protocol.

This can go further with emulator backed remakes, where just the CPU emulator is needed. Quite well discussed in one of Gabriel Gambetta's articles.

However, with a little bit of money, porting is really not that difficult. The two approaches above are rarely needed unless perhaps the source code is lost. As you can see, the FreeBSD ports collection has the majority of software available to it compared to Linux, minus some proprietary scumware. Its kind of "not a problem".
 
I thought there does not exist a guarantee that a port (without doing a nearly full rewrite) is even feasible, judging from:


Nor do I think it's trivial to recognize how much effort a port needs. Sometimes it's just changing some file paths, lines in makefiles and maybe compiler flags. However, what if the source code has a lot of references to things that don't exist on the target system?

And if so, then the systems are from some point onwards distinct in practice, since there's a significant porting cost.
 
For end user like me, FreeBSD Handbook and this forum are the biggest strengths of FreeBSD ;-)
Those resources allow me to learn about and get help with implementing FreeBSD in my computer. Moreover, at the basic level, I have better understanding how FreeBSD works compared to various Linux OS distributions, including Debian.

Linux strength comes from multi-billion dollars IT industry that supports and influences, financially and politically, Linux Foundation and millions of developers of software applications for Linux based Operating Systems.
 
However, what if the source code has a lot of references to things that don't exist on the target system?
Then I would identify something vaguely similar (i.e OpenAL instead of FMOD); I would create a small "shim" layer to make the OpenAL API present itself as enough FMOD which the original source code consumes and then on to the next.

And if so, then the systems are from some point onwards distinct in practice, since there's a significant porting cost.
Usually, for i.e games, it would be a few thousand bucks and a month of time to the right contractor to port to almost any platform. I don't think it is too significant (which is why many people in the open-source community do this for free in their own time).

Drivers are more problematic. Which is why no operating system today has anything close to perfect coverage of available hardware.
 
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).

I posted more like that in the "why did you choose FreeBSD" thread.

I really "like" how systemd'ism has screwed up the OOM kill behavior.
 
Generally a code base is already ~80% portable. So you only need to read 20% and the surrounding areas.

Its easy to know which bits because... well, they don't compile ;)
I just don't believe it's that simple. Rather, I think of a scenario, where the compiler errors are not helpful, a lot of the code has to be understood for porting and the original author hasn't thought about porting. Possibly too, the source code is not documented.
 
Also, a lot of the basic points are covered in:


which I had not come across.

The document raises some further questions regarding the "current strengths" such as whether the amount of software is a deciding factor (which it is not). Also, how much of that software is more than small scripts? How much of it is software that would not even be under a BSD license such as programs related to research projects?

Based on technical merit only, the document seems conclusive in saying that FreeBSD is technically superior. However, the source is FreeBSD's documentation. Also, in what sense is it evidence-based? It was already said that Linux has a different model of development.

The hardware support as a difference seems a bit open-ended. I have not found a conclusive source for it, but I have heard that for the most part the hardware support is the same. Linux only shines on some more rare pieces of hardware. For mainstream computing there's little to no difference, esp. when paying attention to selecting suitable hardware components.

The license is a matter of preference really.

---

The reason the question asks for "current" is that it's a bit expected that some things will change over time.

However,

will some not?
 
Is the development model:

GNU/Linux: chaotic, unorganized, a collection of random projects
vs
FreeBSD: organized, strict, a coherent collection

A strength or a weakness?

In particular, why does Linux get more funding, regardless of a supposedly flawed development model and even a bad license?

Are there examples of the Linux model in FreeBSD?
 
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.
I somehow foresaw that kind of thread coming up again.
Regarding linux, I liked it before systemD, pulseaudio, and pipewire became a thing.
But if you ask me now, whether I would move back, or even considering using linux ever again, I would say no, and there are reasons for that.

1) SystemD:
I would recommend reading that thread among others, or at least part of it, since it describes the attitude of systemD developers and their concern for the userbase.
According to CVEs systemD is very much vulnerable, and has some severe security risks.
My personal experience with systemD is that it deleted my /home partition, and encryption headers beyond any reasoning, I could understand.

2) Pulseaudio:
I liked Alsa, and it worked almost out of the box for me, but I needed per app audio control later on so, I switched to pulseaudio.
I never got it to run without crackling, almost spending 2 weeks on it.
Latency problems were also severe for me, but at least I could fix them.
The overhead caused by running an audio server on top of an audio server was also not excusable for me.

3) Pipewire:
A low level framework for audio, I believe.
Spending about 3 weeks on it, I really liked the customizability, and the easy setup of parametric equalization.
However, same problem, the audio crackled.
Again extending ALSA would probably be better, instead of throwing another audio server alternative which depends on either an audio server like ALSA, or jack, or pulse, which also depends on ALSA.

4) Linus strange behaviour regarding the linux ecosystem:
-> Signing a CoC created by Coraline Ada Ehmke with its quirks.
-> Throwing out kernel driver maintainer only because they have a certain ethnicity.
Who is going to maintain these drivers now after the person in response are no more?

An operating system should serve the user, and not work against the user.
 
An operating system should serve the user, and not work against the user.
What's Wayland doing? That's all mainstream Linux is using, where it's apparently tolerably to have higher and inconsistent mouse/cursor latency.

I'm skeptical of anyone claiming non-Windows to be faster for gaming (which have been flowing around the same 8+ year period of Wayland), and even question Valve with Steam Deck a bit. Why exactly are end-users tolerating it?
 
What's Wayland doing? That's all mainstream Linux is using, where it's apparently tolerably to have higher and inconsistent mouse/cursor latency.

I'm skeptical of anyone claiming non-Windows to be faster for gaming (which have been flowing around the same 8+ year period of Wayland), and even question Valve with Steam Deck a bit. Why exactly are end-users tolerating it?
I was setting up a Linux system for my cousin last year and took the opportunity to benchmark a few game titles and synthetic tests in a Wayland vs Wayland performance on Linux vs FreeBSD. FreeBSD outperformed Linux at time in my tests. I was using an RX 5700 XT for the tests. The Linux distro was glorious eggrolls Nobara.
 
Is the development model:

GNU/Linux: chaotic, unorganized, a collection of random projects
vs
FreeBSD: organized, strict, a coherent collection
That description has a small grain of truth in it, but is massively exaggerated. A large fraction of all Linux development today is done by corporations (more accurately, by software engineers who are paid by corporations to work on Linux, not as their personal hobby). That development is not chaotic, not unorganized, and not random. It costs a lot of money, and is very goal oriented (because it is expensive).

But ultimately, the development model is irrelevant. The strengths and weaknesses of the resulting artifact are what matters. And clearly computer users (the people who make the decision what OS to install) are voting with their feet.

In particular, why does Linux get more funding, ...
Maybe 90% or more of all servers in the world run Linux; in supercomputers, that figure is 100%. The hyperscalers and cloud companies overwhelmingly or solely run Linux. The only other operating system that shows up on servers with some regularity is Windows. FreeBSD is in the single digit percent of servers, or lower. In commercial desktop/laptop computing (commercial meaning an employer pays for the computer and OS, and it is used on the job), the dominant operating systems are Windows, MacOS, ChromeOS, and Linux (roughly in that order); again FreeBSD is at most single digit percent. To a large extent, FreeBSD today is an OS for hobbyists. That should answer the question of why Linux gets more funding: it is deployed about 100x more frequently, in particular in places where money is earned using the computer.
 
What's Wayland doing? That's all mainstream Linux is using, where it's apparently tolerably to have higher and inconsistent mouse/cursor latency.

I'm skeptical of anyone claiming non-Windows to be faster for gaming (which have been flowing around the same 8+ year period of Wayland), and even question Valve with Steam Deck a bit. Why exactly are end-users tolerating it?
I am not so much against Wayland with XWayland as it was effective for me on Void Linux with the Nvidia driver version 555.58.02.
It handled freesync2 and multi monitors together with sway very well.
The only downside I experienced was after some amount of time (roughly 30 minutes), Ryujinx, Yuzu, and Wine-Proton-GE reported that they lost the GPU device on vulkan.
These applications however only worked with XWayland.
On FreeBSD XWayland does absolutely not work on my Nvidia RTX 4090, no matter what driver version I use, and it does not change, even if I disable the GSP firmware although it is recommended to do so to get XWayland working on Nvidia.

X11 on the contrary works very well.
I set it up exactly the same way, I did back then on Void Linux, but with the exception that it works in multi monitor mode without having any tearing, even with different refresh rates between the two screens.

As for Windows, it depends.
Games can appear to run in fullspeed, even the FPS counter can tell so, but stuttering still occur due to Windows DWMs forced v-sync option.
I believe there are ways to override it, though.
My personal experience is that 30 FPS games like Zelda Twilight Princess run very smooth on Linux and FreeBSD rather than they do on Windows.

As for a benchmark of a game running on Windows, Linux, and FreeBSD, I only could find this one.
Here is also a youtube channel of a FreeBSD user called Alexander88207, who is using an AMD GPU to show how some games perform on FreeBSD.
As far as I know, Nvidia GPUs are better supported on FreeBSD due to Nvidia providing native drivers.
But, I can only try out Wine on FreeBSD, as I have not done it, yet, and upload some videos as an example.
 
Amen!
And very well. We can only hope that Xorg will be a core component of FreeBSD for a LONG time. And not wayland.
I do not think it will go away in any foreseeable future.
As long as people, although now in single digit numbers, are working on Xorg, and Wayland developers are continuing to maintain XWayland, Xorg should continue to live on.
 
Back
Top