Current 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?
 
Back
Top