OpenBSD / GhostBSD / FreeBSD

Hi ralphbsz, I knew this would summon you. ;)
I used XFS before switching to FreeBSD. It is sad that it got dropped from kernel, but cost/benefit was too high. Before, I have nothing but praise for it. A lot more solid than extX in that time I would say. UFS2 the same. Extremely fast and robust.
 
Indeed, XFS was very good in its time, as were its competitors. To understand why, we need to go a little bit back in history. In the 90s, there were lots of commercial Unix variants, each major computer manufacturer had one: AIX, Irix, Tru64 (changed names a few times, I knew it as Ultrix), Solaris = SunOS, HP-UX. The vendors competed on the quality and features of their OS. That means that each of those vendors also had engineering groups building file systems. IBM's version was called JFS, for journaling file system, and came out of Austin (Texas). In those days, using journals or log structures was the hot idea (after Margo Seltzer's PhD thesis out of Berkeley), so everyone wanted one. As I worked at IBM, I used JFS heavily, and it has fine performance for reasonable workloads (in particular databases and integration of blobs with databases), and it was awesomely reliable (that shows the IBM heritage). I don't know very much about Digital's file system AdvFS, other than that it contained lots of ideas from the VAX ODS-2 file system (duh, it used the same people), and it had clustering built in (again inherited from the VAX), and was developed in Massachusetts. HP outsourced the file system to Veritas, and I used VxFS for a while when I worked there; also quite pleasant to use. In those days, there was a lot of development going on in file systems, each of the large Unix vendors competed on the strength of their offering, and the use of journaling (for crash resilience) and logging (for performance) was something the companies talked about in their advertising. Yes, in those days the industry newspaper had ads for file systems!

Because I work in storage systems and in Silicon Valley, I ended up knowing lots of the people in this business. But my personal connection with XFS is a complete coincidence and has nothing to do with work. We live in a small neighborhood in the hills about 45 minutes from the core of Silicon Valley, and one of our neighbors is an older gentleman (I think he's in his mid-80s now). About 20 years ago, we had dinner at his house on the occasion of the birthday of his twin kids (they're about the same age as our son), and one of the guests was his older brother. Turns out the brother worked at Silicon Graphics, where he was ... wait for it ... one of the architects of XFS!
 
Was that the spritefs paper? I think I still have that around somewhere.
Also as always a pleasure to get some historical context. Sometimes I wonder how I would have fared there. Well, mayhaps I'd be living under a bridge now...
 
To the original topic:

GhostBSD now is closer to FreeBSD than it was three years ago. TrueOS (and so, OpenRC) no longer in use, and so on.

FreeBSD will become more like GhostBSD, with PkgBase on the roadmap for this year.




FreeBSD has a culture of keeping -CURRENT as stable as possible.

I am ever impressed by this.



Tangential, a couple of XFS-related topics (one not yet resolved):


 
Was that the spritefs paper? I think I still have that around somewhere.
Exactly, I actually had a slightly hard time finding it online a moment ago, because it doesn't contain "Sprite" in the title. It is Margo Seltzer / Keith Bostic (wife and husband), Kirk McKusick and Carl Staelin: "An Implementation of a Log-structured File Systetm for UNIX", in the Usenix ATC 93.

Well, mayhaps I'd be living under a bridge now...
Given the insanity that the Silicon Valley real estate market has become, half of senior engineers are living under bridges. Actually, that's a joke, but not too far away from the truth. At the height of various booms (99, 2007, before Covid) some well-paid engineers were living in their cars, or buying small camper vans (RVs), because they couldn't afford apartments. It's sad (not funny) to see someone with a good degree who works for a fine employer and drives a nice BMW, but then has to sleep in that BMW.
 
Security is a side effect that happens automatically if you care about code correctness.
I'd quibble with that. I'd say that code correctness makes it a bit easier to tighten up security holes, but security is not an accident or a side effect.

I'd also like to make an claim (based on an educated guess) that just about everything that OpenBSD's packages have, FreeBSD's ports tree has it, as well. And yes, that covers security-related apps like OpenSSH / LibreSSH, and encryption libs. It's still up to OP to configure the stuff properly on both, but OpenBSD will probably offer something that's pre-configured.

OpenBSD won't offer a pre-configured KDE, but they will offer a pre-configured LibreSSH server. On OpenBSD, KDE will be a few versions behind what's offered on FreeBSD. But on OpenBSD, you're gonna have bleeding-edge LibreSSH that has been patched against CVE's released just yesterday. No, I won't provide links, the point of my claim is to give OP an idea of the kind of priority that OpenBSD gives to security. :p
 
FreeBSD can be substantially faster, and not even in abstract many-cores examples. A basic read(2) system call is twice as fast than OpenBSD. OpenBSD never got an optimized gettimeofday(2) like FreeBSD and Linux have, resulting in 10x the time. pthread_mutex_trylock is 70% slower on OpenBSD. Many system calls are about the same time, but some very frequently used ones are much more optimized on FreeBSD.

I do not know what the situation with networking system calls is.
 
Updating OpenBSD was also a hassle - I am not sure if this is still true, but there was no binary option, so you've had to re-compile everything or rely on a third party to compile the updates for you. I guess with modern CPUs performance isn't a big deal these days, and many people don't need Windows emulation, and for them, I guess, OpenBSD can be a wonderful home.
Regarding your quote blackhaz. OpenBSD can now be updated with binary security patches using the command # syspatch. Compiling security updates is thankfully a thing of the past. You can compile applications using ports in OpenBSD. I prefer using packages.
 
Regarding your quote blackhaz. OpenBSD can now be updated with binary security patches using the command # syspatch. Compiling security updates is thankfully a thing of the past. You can compile applications using ports in OpenBSD. I prefer using packages.

+1
... and also, there are some differences between OpenBSD and FreeBSD, from a typical end-user point of view, and how he's using the system. For example:


* Using packages instead of building from ports:
The OpenBSD ports team considers packages to be the goal of their porting work, not the ports themselves. In general, you are advised to use packages over building an application from ports.
OpenBSD.org | FAQ15


* Using GENERIC kernel instead of a CUSTOM kernel:
Some other operating systems encourage you to customize your kernel for your machine. OpenBSD users are encouraged to simply use the standard GENERIC kernel provided and tested by the developers.
OpenBSD.org | FAQ1


* To change the kernel configuration via boot_config(8) and config(8) instead of compiling a CUSTOM kernel:
There are three ways to customize a kernel:
* temporary boot-time configuration using boot_config(8)
* permanent modification of a compiled kernel using config(8)
* compilation of a custom kernel
OpenBSD.org | FAQ5
 
Does FreeBSD encourage building ports, or using custom kernels? It allows it, but is there a documented push towards it?
 
Does FreeBSD encourage building ports, or using custom kernels? It allows it, but is there a documented push towards it?
The handbook tries to give a basic explanation of options you have. The explanations are meant to give enough information to decide if, for example, you want ports or packages. You can get as deep in as you want, but you gotta know what you're doing.
 
There are not really pros and cons other than what you can/can't manage to run and what you become used to. This notion that some BSD operating systems "focus more on x than x" has little merit other than what Youtubers like to say.

Why do I say this? Because every *BSD wants to be an operating system with plenty of use cases. They just have their own standards, implementations, and methods but they all ultimately try to achieve the same goal of security, usability, and (for the most part) compatibility. For me, FreeBSDs way flows best, and since I'm used to the FreeBSD way of doing things I'd rather stick to it than use OpenBSD, NetBSD etc. and have to re-learn everything.
 
This notion that some BSD operating systems "focus more on x than x" has little merit other than what Youtubers like to say.
I'd quibble with that... OpenBSD is actually pretty loud about their own focus on security, and it is the project's official priority. NetBSD tries to run on everything under the sun - that project makes portability their official priority. Yeah, focus on those official priorities do come at the expense of other OS components.

The merits of those claims are backed by benchmarks run not just by Youtubers, but also by educational institutions and think tanks like Forrester Research, a favorite on ZDNet.
 
Does FreeBSD encourage building ports, or using custom kernels? It allows it, but is there a documented push towards it?
I think there's a tendency toward building a CUSTOM kernel, and also compiling the packages from the ports. At least, that's how I approach a FreeBSD machine in the past. However, I won't suggest that's a de facto, or even every FreeBSD normal user (like me) feels that way. It's just an anecdotal.
 
I feel that with modern hardware, there's little need for a custom kernel. In the days of FreeBSD-4.x and 5.x, I used to go through my kernel, removing unneeded drivers. These days, with say, a moderately modern laptop or desktop, I doubt you'd gain anything. Of course witha pi or ancient hardware, you might.

Greh Lehey, who wrote The Complete FreeBSD once wrote that you could tell each BSD's focus by their slogan. Back then, (before DragonFly), OpenBSD's motto was something like One security hole in 10 years, NetBSD's was Of course it runs NetBSD, and FreeBSD's was (and still is) The power to serve. Free emphasized running well on server hardware, Net on portable code, and Open, of course on security.
 
Does FreeBSD encourage building ports, or using custom kernels? It allows it, but is there a documented push towards it?
Encourage? My opinion would be no FreeBSD does not. But the flip side, FreeBSD does not discourage it either. I believe OpenBSD strongly discourages it, as in "if you report a bug on a kernel that is not GENERIC retry on GENERIC, and report if it still exists".

A documented push towards it? Again my opinion is FreeBSD does not have a documented push.

But the process to rebuild from source: make world && make kernel && make installkernel && make installworld && portmaster rebuild everything has been well documented and the standard method of doing upgrades for many people. Sometimes custom kernel, most times just GENERIC.

My opinion is people that need to have a custom kernel know what they need to do, people that have specific requirements for port configurations know what they need to do. Everyone else should be fine running GENERIC and prebuilt packages.

I think everyone should run through the "upgrade from source and rebuild all your ports" at least once in their life, even if it's just to gain appreciation for the ease of doing binary upgrades.
 
Encourage? My opinion would be no FreeBSD does not. But the flip side, FreeBSD does not discourage it either. I believe OpenBSD strongly discourages it, as in "if you report a bug on a kernel that is not GENERIC retry on GENERIC, and report if it still exists".

A documented push towards it? Again my opinion is FreeBSD does not have a documented push.

But the process to rebuild from source: make world && make kernel && make installkernel && make installworld && portmaster rebuild everything has been well documented and the standard method of doing upgrades for many people. Sometimes custom kernel, most times just GENERIC.

My opinion is people that need to have a custom kernel know what they need to do, people that have specific requirements for port configurations know what they need to do. Everyone else should be fine running GENERIC and prebuilt packages.

I think everyone should run through the "upgrade from source and rebuild all your ports" at least once in their life, even if it's just to gain appreciation for the ease of doing binary upgrades.
When I started with Linux back in 2002, I was reading stories of heroic efforts to recompile the kernel to squeeze more performance out of it. Back then, however, my priorities were simply on installing and running the programs, and experiencing powerful functionality for free. I was not that interested in putting in the effort to learn to recompile the kernel. But over time, as I got more experience in just using Linux (and later, FreeBSD), I learned quite a bit about how compiling even works. But even then, re-compiling the kernel and getting a handle on the steps involved - that was a time-consuming adventure that I was not ready for.

FreeBSD does have very nicely organized documentation. If you're not too lazy to study it, you can recompile the kernel just following that. BTW, I recently tried to take another look at Linux kernel re-compilation - and even the official documentation of the Linux kernel project doesn't have the same instructions as what a distro would provide. When you add in variations between distros - I got lost so completely, I gave up on Linux kernel recompilation. But with FreeBSD - if you follow the manual, you can do it.
 
  • Like
Reactions: mer
When I started with Linux back in 2002, I was reading stories of heroic efforts to recompile the kernel to squeeze more performance out of it. Back then, however, my priorities were simply on installing and running the programs, and experiencing powerful functionality for free. I was not that interested in putting in the effort to learn to recompile the kernel. But over time, as I got more experience in just using Linux (and later, FreeBSD), I learned quite a bit about how compiling even works. But even then, re-compiling the kernel and getting a handle on the steps involved - that was a time-consuming adventure that I was not ready for.

There is a potential win here, as demonstrated by Intel's own Clear Linux distribution. For some workloads it is indeed faster.

I haven't seen a bisection to narrow down which factors are the most relevant for that. Could be anything from compiler use to narrowing down on Intel's own CPUs or kernel options or...
 
  • Like
Reactions: mer
FreeBSD's was (and still is) The power to serve. Free emphasized running well on server hardware
I don't think that serve was ever meant in the particular meaning of a computer server. I understand it in the generic meaning of a servant serving someone or a soldier serving in the army. Computers of all kinds are there to serve us humans :)

One of FreeBSD's original goals (as opposed to NetBSD) was to focus on x86 hardware, which at the time was mostly a desktop PC architecture and not mainstream for servers.
Therefore an earlier FreeBSD slogan: Turning PCs into workstations.
freebsd_3.gif


Quoting the FreeBSD Foundation:
in all cases the Foundation acts to expand freedom and choice so that FreeBSD users have the power to serve their varied compute needs.
Those varied compute needs of course include running servers, but also much more.

I'd say in this slogan the world power is more important, because FreeBSD focusses on performance, more so than NetBSD or OpenBSD (if you ever used them, you know what I mean!).
 
Back
Top