Code quality of FreeBSD compared to OpenBSD?

Status
Not open for further replies.
I'm currently a Slackware user prepping for making the jump to FreeBSD and wanted some clarity on this topic purely out of interest in coding.

Note: This isn't a 'which is better' debate. I know the two have different philosophies and goals and a comparison is bound to be almost completely subjective. This is more of a discussion about the coding practices of the two according to a few pre-established (relatively) objective standards.

A few years back, when I was a newbie in Linux, a friend/colleague introduced me to the BSDs and told me the reason he preferred OpenBSD over FreeBSD was because of its 'superior code quality'. The points he gave to explain this 'superiority' in code quality were:

1) Accomplishing more in very less lines of code compared to FreeBSD. Therefore, easier for code audits and maintenance.
2) Regular code audits and reviews. Therefore, lesser bugs/security holes.
3) No 'bloatware'

With respect to these three points, how does the code quality of FreeBSD compare to that of OpenBSD? To slightly increase the objectivity of the comparison,

1) FreeBSD has (supposedly) better hardware support and more programs compared to OpenBSD. Do these justify the difference in the number of lines of code between the two?
2) How frequent are code audits in FreeBSD compared to OpenBSD? How quickly are bugs resolved?
3) This is the most subjective of the three. Let's take the definition of bloatware as:

Unwanted software included after a new installation

The goal of FreeBSD is: To provide a stable and fast general purpose operating system that may be used for any purpose without strings attached.

Does the most stripped-down installation of FreeBSD give you any programs/features you can't modify/remove?

To the Mods - Sorry if this forum isn't the right place for this. FreeBSD Development seemed too much of a technical discussion forum than befitting such a general question. I'll move the thread if needed.

Thanks in advance.
 

Unwanted software included after a new installation

The goal of FreeBSD is: To provide a stable and fast general purpose operating system that may be used for any purpose without strings attached.

Does the most stripped-down installation of FreeBSD give you any programs/features you can't modify/remove?

I'm very fresh user of FreeBSD, so I won't tell anything about the code quality, but about the base installation... it's hard to call bloated a system that doesn't even have package manager installed by default.
On FreeBSD you get a minimal system and then you can do mostly anything with it. It's not the case with OpenBSD - here "no bloatware" comes at a price - for example no bluetooth or VirtualBox. It may be OK for certain purposes or people, but for me the latter was a deal breaker. FreeBSD is much more universal system, while OpenBSD is limited by its strict philosophy. It may be a good thing or a bad thing, depending solely on what you want to do.
 
I'm currently a Slackware user prepping for making the jump to FreeBSD and wanted some clarity on this topic purely out of interest in coding.

Note: This isn't a 'which is better' debate. I know the two have different philosophies and goals and a comparison is bound to be almost completely subjective. This is more of a discussion about the coding practices of the two according to a few pre-established (relatively) objective standards.

Could you name those "few pre-established (relatively) objective standards" because i am fully at loss what you are referring to.

A few years back, when I was a newbie in Linux, a friend/colleague introduced me to the BSDs and told me the reason he preferred OpenBSD over FreeBSD was because of its 'superior code quality'. The points he gave to explain this 'superiority' in code quality were:

Superior code quality in relation to what? Even without having studied the relevant codebases extensively i can't help but feel that such a general statement applied broadly to what really is a bit more than 5 lines of code is lacking substance.

1) Accomplishing more in very less lines of code compared to FreeBSD. Therefore, easier for code audits and maintenance.

I think the programmer to willingly do less with more still has to be born so i figure unless there is a substancial underlying skill gap the amount of code needed to archive some functionality will be more or less equal and any kind of noticeable difference in size or complexity is bound to require compromises. Again this seems like a very broad statement to me which makes discussing it in a vacuum somewhat pointless.

2) Regular code audits and reviews. Therefore, lesser bugs/security holes.

While i admit to be not overly familiar with OpenBSD's development cycle this once again doesn't give me much of a base for a discussion as depending on what exactly is meant by "regular code audits and reviews" it could either be very impressive or rather boring and mundane.

3) No 'bloatware'

So what is bloatware? As far as the base distribution is concerned the only thing i could imagine this referring to from the top of my head would be sendmail and while i can see the logic behind this it's still quite reliant on definition. One might as well argue that mail delivery (even or especially in a local context) is not needed therefore "bloat" in general.

With respect to these three points, how does the code quality of FreeBSD compare to that of OpenBSD? To slightly increase the objectivity of the comparison,

I really don't know what kind of answer you are expecting here. This is something that would need to be discussed in detail. Trying to distill it down to a generic answer pretty much has to be inaccurate by definition.

1) FreeBSD has (supposedly) better hardware support and more programs compared to OpenBSD. Do these justify the difference in the number of lines of code between the two?

This is as subjective as it gets. I mean would you actually use a system where your hardware doesn't work just because it has less code?

2) How frequent are code audits in FreeBSD compared to OpenBSD? How quickly are bugs resolved?

While i can't give you a real answer to the first part i'd guess as long as "audit" is to be defined as payed external audit of the full base code it won't happen all that often which likely is the case for pretty much every other open source project too. The second part is extremely vague once again. A "bug" can be a lot of things and you can't really compare a typo on some man page with something allowing remote code execution. Sure you could calculate some general average but what's the point?

3) This is the most subjective of the three. Let's take the definition of bloatware as:

Unwanted software included after a new installation

The goal of FreeBSD is: To provide a stable and fast general purpose operating system that may be used for any purpose without strings attached.

Does the most stripped-down installation of FreeBSD give you any programs/features you can't modify/remove?

Yes and likely quite a lot of them. Let's start with the boot loader. Removing it has a high chance of rendering your system non bootable... Oh, that isn't the answer you were looking for? Well, then how about: No. This is open source which means you can obviously change anything you want to change. Also not the right answer? Well, then maybe the question didn't make all that much sense.

All in all it seems to me like you are looking for a simple answer like "A is stricly better than B". Those usually don't exist in the real world.
 
2) How frequent are code audits in FreeBSD compared to OpenBSD? How quickly are bugs resolved?
1) FreeBSD has (supposedly) better hardware support and more programs compared to OpenBSD. Do these justify the difference in the number of lines of code between the two?
ignoratio elenchi
3) This is the most subjective of the three. Let's take the definition of bloatware as:
 
This is the sort of comparison I would expect on a Linux forum and not a BSD forum. Both BSDs have excellent, knowledgeable contributors and "code quality" does not need to be a question asked. "Bloatware" especially is insulting at best.

FreeBSD is a professional operating system for professionals and strong computer enthusiasts. You won't have such Linux type issues here or on OpenBSD. Your friend is ill-advised and shows lack of knowledge and experience.
 
Could you name those "few pre-established (relatively) objective standards" because i am fully at loss what you are referring to.



Superior code quality in relation to what? Even without having studied the relevant codebases extensively i can't help but feel that such a general statement applied broadly to what really is a bit more than 5 lines of code is lacking substance.



I think the programmer to willingly do less with more still has to be born so i figure unless there is a substancial underlying skill gap the amount of code needed to archive some functionality will be more or less equal and any kind of noticeable difference in size or complexity is bound to require compromises. Again this seems like a very broad statement to me which makes discussing it in a vacuum somewhat pointless.



While i admit to be not overly familiar with OpenBSD's development cycle this once again doesn't give me much of a base for a discussion as depending on what exactly is meant by "regular code audits and reviews" it could either be very impressive or rather boring and mundane.



So what is bloatware? As far as the base distribution is concerned the only thing i could imagine this referring to from the top of my head would be sendmail and while i can see the logic behind this it's still quite reliant on definition. One might as well argue that mail delivery (even or especially in a local context) is not needed therefore "bloat" in general.



I really don't know what kind of answer you are expecting here. This is something that would need to be discussed in detail. Trying to distill it down to a generic answer pretty much has to be inaccurate by definition.



This is as subjective as it gets. I mean would you actually use a system where your hardware doesn't work just because it has less code?



While i can't give you a real answer to the first part i'd guess as long as "audit" is to be defined as payed external audit of the full base code it won't happen all that often which likely is the case for pretty much every other open source project too. The second part is extremely vague once again. A "bug" can be a lot of things and you can't really compare a typo on some man page with something allowing remote code execution. Sure you could calculate some general average but what's the point?



Yes and likely quite a lot of them. Let's start with the boot loader. Removing it has a high chance of rendering your system non bootable... Oh, that isn't the answer you were looking for? Well, then how about: No. This is open source which means you can obviously change anything you want to change. Also not the right answer? Well, then maybe the question didn't make all that much sense.

All in all it seems to me like you are looking for a simple answer like "A is stricly better than B". Those usually don't exist in the real world.

Here I was, congratulating myself on asking 'clear' and 'objective' questions. Thanks for showing me just how unanswerable my questions are...

Will keep these points in mind when I talk to my friend the next time... 😬
 
This is the sort of comparison I would expect on a Linux forum and not a BSD forum. Both BSDs have excellent, knowledgeable contributors and "code quality" does not need to be a question asked. "Bloatware" especially is insulting at best.

FreeBSD is a professional operating system for professionals and strong computer enthusiasts. You won't have such Linux type issues here or on OpenBSD. Your friend is ill-advised and shows lack of knowledge and experience.
Okay, I promise my next post on this forum will only be after installing and experiencing FreeBSD...😅
 
A few years back, when I was a newbie in Linux, a friend/colleague introduced me to the BSDs and told me the reason he preferred OpenBSD over FreeBSD was because of its 'superior code quality'. The points he gave to explain this 'superiority' in code quality were:

1) Accomplishing more in very less lines of code compared to FreeBSD. Therefore, easier for code audits and maintenance.
2) Regular code audits and reviews. Therefore, lesser bugs/security holes.
OpenBSD keeps that marketing schtick of "Only two remote holes in a heck of a long time" which holds as much truth as a glass is full of water with holes in the bottom.

They always tout their rigorous and complete audits, but has anyone ever actually seen the results, or what they're using? I believe that is all closed.

As for one specific example of a remote hole is OpenSMTPD which was vulnerable for two years before it was found. Of course, the reasoning they give that it isn't a remote exploit, and it that allows their tag line to hold is that if OpenSMTPD was used in the default installation, there was no exploit. One presumably uses it because it is "secure," and has been audited, and they can use it for its purpose. If you purchase a toaster and someone tells you that model may catch fire if you put toast in it, but it won't catch fire if you don't, then it is a toaster without any vulnerabilities? You bought the toaster to make toast. Who wants a toaster that sits on a counter you can't use?

And if they do rigorous and complete audits, then how did a vulnerability to allow root access go unnoticed for over two years?

I could postulate that NetBSD code correctness is better than FreeBSD and OpenBSD because it runs on everything, even the faulty toaster.

Use what you prefer and meets your needs. I use both OpenBSD (mail) and FreeBSD (firewall, httpd); and used NetBSD in the past.
 
But seriously … FreeBSD aims to provide a base system that is as small as possible, giving you only the most important tools. For example, Perl and BIND were part of the base system in the past, but have been removed (in favor of ports), precisely because it makes more sense to install them from ports or packages if necessary instead of “bloating” the base system.

If you want to remove other components from the base system that you don’t need, then that’s not difficult. Have a look at the src.conf(5) manual page. For example, if you don’t want to have the ee(1) editor (even though it’s very small), set WITHOUT_EE=yes in /etc/src.conf and rebuild the base system. However, as a consequence, you cannot perform binary updates anymore (e.g. using the freebsd-update(8) tool), because that would always install a complete base system again.

By the way, I have a stripped-down version of FreeBSD running on a small SBC with 128 MB RAM and a 48 MB (not GB!) flash card. I use it as an mp3 player mostly.
 
But seriously … FreeBSD aims to provide a base system that is as small as possible, giving you only the most important tools.
While this may have been true at one point I am not so sure it is still the case.
For example we have bhyve in base. Is it essential? All the ZFS stuff in base and growing. Is it essential?
Three firewalls in base. Is that necessary?

Here is my src.conf for minimal system. Combined with kernconf cleanup I do make minimal builds.
Floppy disk module enabled in GENERIC kernconf? Really? SCSI disk controller modules included by default.
Only recently with the addition of iflib did the really old network modules get a cleanup.

You have offered great advice but I disagree with you on the minimal base. FreeBSD 12 grew by over 100 megabytes and the FreeBSD CDROM installer disc image no longer fits on a CDROM. Not even with overburn.
 
While this may have been true at one point I am not so sure it is still the case.
For example we have bhyve in base. Is it essential? All the ZFS stuff in base and growing. Is it essential?
Three firewalls in base. Is that necessary?
Well, bhyve is tightly integrated with the kernel, so it makes sense to ship it with the base system. ZFS is used by many FreeBSD users (probably more than UFS), so it makes sense to include the tools that most users will need.

About the firewalls, yes, I agree. At least one of them should go, In my opinion. I would keep IPFW because it is the “native” firewall and has some features that the others don’t have. And maybe PF, too, because it’s fairly portable and well maintained, and it’s a huge plus if you have to maintain both FreeBSD and OpenBSD machines, for example.

One of the things that was often mentioned in such discussions is sendmail. Do we need sendmail in base? It could be argued that it should be moved to the ports collection. On the other hand, we need at least some kind of mail delivery support in base, so things like cron jobs and the periodic script outputs work out of the box, which is essential. And sendmail is comparatively small – replacing it with a slimmer delivery agent won’t really save much space (DragonFly BSD did that, but for other reasons). Also, there are people who’d like to keep it for sentimental reasons, because sendmail was part of BSD 1, developed at Berkeley 40 years ago. These people were already severely hurt by the removal of BIND which had a similar history. Personally I’m not one of those who want to keep stuff just because of historical reasons. For today’s users, only technical reasons should matter.

Bottom line: I agree that the base system is not minimal, but it’s a good compromise. And thanks to the src.conf(5) + “make world” framework you can make a minimal system that fits your needs perfectly. There is no one-size-fits-all.
 
1) Accomplishing more in very less lines of code compared to FreeBSD. Therefore, easier for code audits and maintenance.
For the same functionality, does it have fewer lines? Is there any measurement of that? I doubt it.

2) Regular code audits and reviews. Therefore, lesser bugs/security holes.
I used to talk regular to a (volunteer) OpenBSD developer. I was very impressed by their culture of audits, code quality, and looking over one's shoulder. The idea in coding for OpenBSD is: code so will that code reviews and audits are guaranteed to find NOTHING. In particular, make sure that your code has no security vulnerabilities, and think through attack surface and penetration aspects all the time. In my opinion (of having been paid money to develop software for the last ~25 years), the best predictor of quality of the finished product is the attitude and culture of the developers, so I would expect this culture to lead to a product that reflects the stability and security aspect.

But: that was 10-15 years ago, mid to late 2000s. I don't know how much has changed since. And it is one anecdotal sample, not an accurate study.

3) No 'bloatware'
One man's bloatware is another mans vitally important functionality. I have no idea how you define bloatware; usually the definition is "aspects of an operating system that I don't like."

The sensible question to ask is: What is your intended usage of the OS? Does the packaging of the OS and the available features (whether delivered as part of base or as an optional add-on) match your needs? Do unneeded features cause you problems?
 
FreeBSD doesn't fit on a CD anymore. But file size shouldn't be relevant for the sake of file size. I bet that trying to contain everything in a small size adds additional work for developers.

FreeBSD has additional programs in base, but they're by no means bloat. FreeBSD is like fully loaded instead.

I read that Sendmail isn't secure, but it's not replaced in base by drop-in Postfix because of the license. DragonflyBSD's and OpenBSD's have secure MTA's, but may be limited in protocols they use.

I heard that they started improving IPF again. Before what I didn't like is the similarity in names, and that it caused confusion when I tried to learn about the differences of 3 different firewalls. When I read about them, an author may have confused some of them. A rationale was that a firewall was ready to use for those coming from NetBSD or OpenBSD.

There's features that I don't use like virtualization in base. They're functional without having excessive useless code, but not everyone uses them.

When something that's good is taken out of base, it does negatively affect the projects associated with them. Many projects deserve to have the support provided from simply being in base. On the other hand, there has to be a half-way point between being in base and being in ports. Ports doesn't offer their projects what being in base does.

From a user's viewpoint, when something goes to ports, quality control lacks in respect to dependencies. There's quality in much of port maintenance, but ports is a huge pool with little defined separation from a lot that isn't quality controlled. There's quality control in base that doesn't exist in ports, as ports is a separate entity than base.

When I tried slimming down src.conf, it has caused some broken functionalities needed for the ports tree, when it hasn't happened in previous FreeBSD releases. For graphics components and the toolchain. I used to take a legacy named graphics feature out of src.conf and make.conf, and it didn't affect builds and functionality at all. When advanced drivers and features started being integrated into those legacy options in make and src, removing those options broke builds or functionalities. It's similar for the toolchain and compilers. I didn't see the point in having 2 compilers in a system, one in base, when it was going to be overriden by a program's demand requiring the newest compiler. Before, I could build FreeBSD base repeatedly, by specifying the use of ports' compiler and toolchain. Then, they change the default options. Leaving out an option in src.conf, then allows a build, but after two times, a dependency needed is left out, that's needed for a next build. I want no more than 2 compilers to be used, rather than 3. The latest ports should only require 1 additional llvm utilities, and not always require the latest compiler with it. If a new whole compiler from ports is going to be always needed, for a newest toolchain utility, why is a fully featured compiler and toolchain needed in base.

Now I use the whole binary for base updates, and only customize and compile the kernel. I use an additional PF firewall to block out cleartext network services, instead of removing them through src.conf. It's too much to recompile for removing these few features, when I no longer do it for other features.

OpenBSD has benefits, but it lacks a lot of functionality for graphics, devices and other more advanced features. Why not Minix over OpenBSD for reliability and even fewer features? For wanting a completely trimmed down BSD distribution, that may not be usable with most FreeBSD ports: http://www.minibsd.org/.

The only operating systems that can compete with FreeBSD in both quality and functionality are ones associated with Apple, or are based on FreeBSD.

I don't know this for certain, but I get the impression that OpenBSD bloats and complicates their documentation, from what has once been described as simple and practical, to keep users they see as unwanted out. It's not a case of lack of documentation, because that requires a lot of effort. It's a case of disintegrating and muddied documentation. As for what other projects do with software bloat for other reasons.
 
But seriously … FreeBSD aims to provide a base system that is as small as possible, giving you only the most important tools.

I really wish the developers would take this approach with the desktop. Shipping X.org, and a decent Display/Window Manager would be perfect. Leave all other setup, configuration, and customizability stuff to the user.

I read the developers intend to ship DRM (and subsequent drivers) in base anyway; so it'd make sense do to this.
 
I really wish the developers would take this approach with the desktop. Shipping X.org, and a decent Display/Window Manager would be perfect. Leave all other setup, configuration, and customizability stuff to the user.

I read the developers intend to ship DRM (and subsequent drivers) in base anyway; so it'd make sense do to this.

Xorg in base would benefit me personally (in many ways) however, I suspect the vast majority of FreeBSD installs do not need Xorg so it would be a little short sighted (and selfish) for me to push that agenda to include it in base.

And then XDM and TWM are pretty much part of Xorg so a display manager and window manager comes for free. of course they won't be the ones that *I* would want to use but again I cannot be selfish and expect everyone to cater for my needs can I?

So ultimately I would vote that they stay out for now... (begrudgingly ;)) and instead leave "setup, configuration, and customizability stuff to the user".

One man's bloatware is another mans vitally important functionality. I have no idea how you define bloatware; usually the definition is "aspects of an operating system that I don't like."

"Bloatware" is certainly becoming a problem in other operating systems. And it isn't really "functionality" based, more how it is implemented. For example I personally have no need for a mail server, and yet sendmail can exist on my system because it is fairly small. If I found that it was replaced with something that is many times larger and full of fragile dependencies just to get 1 extra feature, I would be concerned.

So I would define bloatware as "aspect of an operating system that is incorrect and should be replaced with something correct".

Heck if the entirety of the Windows GUI system was rolled up into a single 1MB binary, I wouldn't even call that bloatware because it doesn't actively go against me if I decide not to use it (minus the inevitable MS license).
 
The only way the base can be slim, is if they have distribution sets, similar to what was in the old FreeBSD installation cd's, that can be chosen from. Program sets that can be chosen from that are of the quality of base, but not exactly ports. Like extended base, that doesn't come on the basic install CD.

If Xorg is in the base, then that leaves a rationale for the alternative of Wayland, and both are heavy. It also means more work (for developers and maintainers) to include components that come with them. Not everyone uses a graphical desktop, for it to make sense in a minimal base for all. Other programs, not everyone uses either, but they're important to those who use them.
 
Meh, that's right. I forgot it comes with it's own DM/WM. Well, they can at least put that crap in the installer or something. I'm lazy.
 
The only way the base can be slim, is if they have distribution sets, similar to what was in the old FreeBSD installation cd's, that can be chosen from. Program sets that can be chosen from that are of the quality of base, but not exactly ports. Like extended base, that doesn't come on the basic install CD.
I'd vote for selecting a type of distribution again. It has been a few years since I installed NetBSD, but they had some options; OpenBSD allows you to select which distributions you want; OpenSUSE allows you to select a type of installation.
 
I cant comment on the so called code quality, but FreeBSD is aimed at a wider user base so inevitably will have more included code to accommodate that. I see there is moves to shrink down the default kernel, which is a long time coming and glad it is happening.
 
Please stop irritate FreeBSD marketdevs OK?

Now the "facts":
majority of FreeBSD developers don't run FreeBSD as a desktop system.
They use Mac OS and only virtually use FreeBSD.

Contrary, most OpenBSD developers run OpenBSD as a desktop daily.
For development too.
Not just stable branch but CURRENT.

Need more code quality validation?
 
Status
Not open for further replies.
Back
Top