Date: Fri, 14 Feb 2020 19:02:20 +0100 From: Polytropon <freebsd@edvax.de> To: Dale Scott <dalescott@shaw.ca> Cc: Alejandro Imass <aimass@yabarana.com>, freebsd-questions <freebsd-questions@freebsd.org>, Victor Sudakov <vas@sibptus.ru> Subject: Re: Technological advantages over Linux Message-ID: <20200214190220.1560784d.freebsd@edvax.de> In-Reply-To: <2011372779.118117269.1581701700318.JavaMail.zimbra@shaw.ca> References: <20200214121620.GA80657@admin.sibptus.ru> <CAHieY7Ss0SftTD6S%2Bk2OkX-PinTwzEXGQwz1twmwZ5ZMndpc%2Bg@mail.gmail.com> <2011372779.118117269.1581701700318.JavaMail.zimbra@shaw.ca>
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. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200214190220.1560784d.freebsd>