FreeBSD has a culture of keeping -CURRENT as stable as possible.
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.Was that the spritefs paper? I think I still have that around somewhere.
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.Well, mayhaps I'd be living under a bridge now...
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.Security is a side effect that happens automatically if you care about code correctness.
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.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.
— OpenBSD.org | FAQ15The 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 | FAQ1Some 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 | FAQ5There 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
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.Does FreeBSD encourage building ports, or using custom kernels? It allows it, but is there a documented push towards it?
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.This notion that some BSD operating systems "focus more on x than x" has little merit other than what Youtubers like to say.
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.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".Does FreeBSD encourage building ports, or using custom kernels? It allows it, but is there a documented push towards it?
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.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.
Does FreeBSD encourage building ports, or using custom kernels? It allows it, but is there a documented push towards it?
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.
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 humansFreeBSD's was (and still is) The power to serve. Free emphasized running well on server hardware
Those varied compute needs of course include running servers, but also much more.in all cases the Foundation acts to expand freedom and choice so that FreeBSD users have the power to serve their varied compute needs.