Subj : Re: NetBSD 10
To   : Arelor
From : Gamgee
Date : Tue Apr 02 2024 20:20:00

-=> Arelor wrote to Gamgee <=-

 > I've "wanted" to try/use the BSDs over the years, and have tried a few
 > times - found them aggravating and strange.  With the state of Linux
 > what it is today, I can find no valid reason to fuss with a BSD.

 Ar> They are only strange if you try to use them as you would use a
 Ar> Linux, which they aren't. I got into Linux before I got into BSD
 Ar> so I know some differences break your train of thought if you are
 Ar> not expecting them.

Fair enough - I admittedly did not spend enough time on my experiments to 
get past that.

 Ar> Realistically, the reason to deal with a BSD these days would be
 Ar> wanting to use a system that possesses the following
 Ar> characteristics:

 Ar> 1) Third party components can be built from source and installed
 Ar> automatically, patched and rebuilt if need be, and integrating
 Ar> your own components with the build system is trivial. ie. if you
 Ar> make a program for yourself you can add it to the build system
 Ar> and the build system will make and install a package for it as if
 Ar> it belonged to an official repository.

Okay, that sounds attractive.  Just for clarity, all of my comments here 
and below are mostly in regards to Slackware Linux, which I've used 
extensively and know the best.  For the above paragraph, I can do that 
with Slackware (think Slackbuilds.org).

 Ar> 2) Standard packages are still available from the repositories so
 Ar> you may install a big application without having to compile,
 Ar> without the need to give up on 1).

Same, again with Slackbuilds (which of course is compiling, but 
automated), and from places like AlienBob.

 Ar> 3) First-party components (aka. the core Operating System) are
 Ar> developped and deployed as a block, so you can assume an install
 Ar> of a given BSD fullfills a number of minimum requisites and
 Ar> contains certain components. Compare this to Linux, in which a
 Ar> Linux distribution is not even guaranteed to use a given libc
 Ar> flavor and the filesystem hierarchy is mutable. If a third-party
 Ar> application is described as Linux compatible it might mean it
 Ar> only works on certain distribution and fails to work on the rest.

I think Slack is pretty standardized and includes all "standard stuff" by 
default.

 Ar> 4) It has proper release engineering and predictable roadmaps and
 Ar> release schedules.

Admittedly, the Slackware release cycle is quite variable.  It's never 
released too early, though.  ;-)

 Ar> And, in the case of OpenBSD

 Ar> 5) Their sandboxing frameworks are much simpler to understand and
 Ar> blow Linux equivalents our of the water for applications in small
 Ar> deployments.

Okay, but not something I use/need.

 Ar> 6) BSD Auth makes more sense than PAM.

Don't know much about this, but not super important in my use cases.

 Ar> 7) Userspace utilities just rock. OpenSMTPD allows you to set an
 Ar> SMTP server in like 5 lines of configuration, OpenHTTPD gives you
 Ar> a lightweight HTTP server you can run serious applications on
 Ar> with minimal configuration. The reverse proxy developed in house
 Ar> follows suit. A firewall can be set with way less lines that
 Ar> you'd expect. And so on. This also leads to ease of maintenance
 Ar> since everything is so easy to understand.

That all does sound good.

 Ar> 8) The installation procedure is blazing fast.

 Ar> Quite frankly, for small server deployments, the real question is
 Ar> why should somebody use anything other than a BSD. This question
 Ar> has some valid answers, but in practical terms I suspect most
 Ar> people are running with Linux because if you want to run
 Ar> $some_random_blog there are plenty copypasteable tutorials for
 Ar> common Linux distributions to use.

Very good insights, and thanks for your post.


.... Forbidden fruit is responsible for many a bad jam.
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
 * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (21:2/138)

.