Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Feb 2020 19:02:20 +0100
From:      Polytropon <>
To:        Dale Scott <>
Cc:        Alejandro Imass <>, freebsd-questions <>, Victor Sudakov <>
Subject:   Re: Technological advantages over Linux
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Fri, 14 Feb 2020 10:35:00 -0700 (MST), Dale Scott wrote:
> +1. Linux is abstraction on top of abstraction, it is like SAP! 

No, SAP is inner platform. ;-)

But basically, you are correct. According to my (limited and
individual) experiences, people are used to put abstractions
on top of abstractions, several layers, and they expect (!)
things to always be like that. So for example, if you'd say
for a specific task you'd build a FreeBSD system with the
function of a mailserver, they'd tell you that you cannot
do this, because you need this running on that controlled
by something else scripted by something else controlled by
again something different virtualized on blah blah blah.
I find it hard to even remember this week's set of tools
you "need" to use...

> The pendulum has started to swing, abstraction that could be done without
> only increases project duration and effort, and reduces future maintainability.

With those piles of abstraction, you lose control, and
you don't recognize it immediately, but when it _stops_
working and you are held liable for a problem. In such
a case, costs will be significant (except you are in the
lucky position where you can just have your customers pay
for your failure).

As always, you can shift costs around, but at a certain
point, when your business depends too much on the good will
of several (!) 3rd parties, and one of them closes shop,
you are immediately affected and have "non-controllable"
costs to modify your "stack" to get it working again.

> A story I heard recently concerned a consultant, who wanted to use a 
> particular piece of technology because the consultant knew he could produce
> a superior solution. However, the consultant realized that once he was gone, the
> technology would be as if magic to the company, and the solution would over time
> become less understood and maintainable, and so the consultant used more familiar
> "old-school" technology because long-term it would be better for the client.
> Food for thought....   ;-)

Here is an important piece of information:

Short term vs. long term.

In my opinion, if costs don't matter, and you want a certain
combination of things right away, a Linux solution will do.
It will work short term, within a certain time window, and
will probably do without significant problems. But if you
need to provide something for a long term, reliably, and
understandable (!) for those who have to maintain it, FreeBSD
probably is the better solution.

Again, "worse" and "better" significantly depends on what
your actual use case is. I wouldn't generalize, even though
my personal "list of superiority" contains, among others:

 - UFS
 - ZFS and BEs
 - clean and predictable (!) OS
 - OS separated from 3rd party software
 - documentation locally available
 - release approach - no "moving target"
 - good development tools
 - friendly, helpful and intelligent community
 - compliant to existing standards
 - well intended security barriers
 - general "UNIX mentality"
 - distribution as RELEASE / STABLE / HEAD, whatever you need
 - ports collection & pkg

Sure, there is lots of potential for improvement. As it has
been mentioned, OpenBSD shines at documentation, but FreeBSD
isn't all that bad - compared to some Linusi (plural of Linux)
where documentation is scattered across user web pages, wikis,
discussion forums and "WhatsApp" groups, partially outdated
or simply just wrong. For developers, this is a nightmare, but
sysadmins also suffer from it.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

Want to link to this message? Use this URL: <>