From owner-freebsd-questions@freebsd.org Sun May 17 18:46:32 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BB5232F10E6 for ; Sun, 17 May 2020 18:46:32 +0000 (UTC) (envelope-from kremels@kreme.com) Received: from mail.covisp.net (mail.covisp.net [65.121.55.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49QB1z3Vwzz4lcM for ; Sun, 17 May 2020 18:46:30 +0000 (UTC) (envelope-from kremels@kreme.com) From: "@lbutlr" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [FreeBSD-Announce] FreeBSD 12.0 end-of-life Date: Sun, 17 May 2020 12:46:28 -0600 References: <20200217231452.717FA1E820@freefall.freebsd.org> <85E7C97E-EF8B-4FC7-8EF1-758B7BCBAE90@kreme.com> <05112EEC-7FA3-4E18-974B-263A58058E01@kicp.uchicago.edu> <332714B8-2798-42CF-A082-9EDA180CC65B@kreme.com> <20200516201923.8676289a.freebsd@edvax.de> <257EF587-92B5-4671-B6F4-89E86CC2ACA0@kreme.com> <12062767-7DF1-45FE-A464-C864F03CBDCF@thehowies.com> <7BB197EB-5A5C-47D7-903A-BAE7E7F4D66F@thehowies.com> To: FreeBSD In-Reply-To: <7BB197EB-5A5C-47D7-903A-BAE7E7F4D66F@thehowies.com> Message-Id: <2EB8C1A9-A889-47C3-BB8A-3BBA63CB3D90@kreme.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49QB1z3Vwzz4lcM X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kremels@kreme.com designates 65.121.55.42 as permitted sender) smtp.mailfrom=kremels@kreme.com X-Spamd-Result: default: False [1.10 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_MIME_VERSION(2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; DMARC_NA(0.00)[kreme.com]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.50)[-0.499]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:65.112.0.0/12, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[65.121.55.42:from] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2020 18:46:32 -0000 On 17 May 2020, at 02:48, John Howie wrote: > Respectfully, you missed my points, and your counterpoints are the = regular industry talking points for why we cannot solve the problem.=20 They are more than just talking points. > As for =E2=80=9Cperfection is the enemy of good=E2=80=9D, please tell = me you will willingly step into a 737-MAX with its original s/w because = it is =E2=80=9Cgood enough=E2=80=9D. It is obviously NOT good enough, which is why the entire fleet was = grounded. And there is such a thing as good enough. Uf you are cutting a piece of = wood for a shelf there is a vast difference between 30cm and = 30.0000000001 cm. Exactly (perfect) 30cm is the enemy of good (30cm=C2=B10.05). Now, in some cases, (not cutting a shelf, but other cases) you might = need something that is 30.00001=C2=B1.000005, but that is a much harder = goal to achieve, takes many more attempts, a lot more failure, and a = exponentially higher cost. And, is a total waste in cases where it is = not necessary. Are you designing parts for a NASA mission? Well, then = you know why these missions are so expensive. Perfect is absolute an unobtainable, good is relative and the goal. = Things that do not work, are dangerous, are insecure, or cause damage = are not "good" (though in some isolated cases, they may be "good = enough". For example, I have a script that I run on my mobile devices that sends = the URL of the page I am on to one of my machines. That machine parses = the URL and produces a markdown file and a PDF file of the page and puts = them into a folder that is synced to my machines. Basically a = roll-your-own Instapaper. It is secure (using key exchange to login to the server) but it is quite = exploitable and could cause damage if I sent a malformed URL that = exploited a failure in one of the libraries on the system. However, I am = exceedingly unlikely to do that, so despite the technical risk inherent = in my system, it is definitely "good enough" even if it is not "good" = (and certainly not perfect). > There are plenty of real world examples where perfection should be = mandatory, and good is not enough. Name one thing that is perfect. Just one. > I may be wrong, but I get the feeling I have been in the software = industry longer than you, and maybe it is just my age talking, but we = are arrogant in thinking that we can get away with Minimum Viable = Product, and (shudder) =E2=80=9Cfail forward=E2=80=9D Agile methodology. No one is suggesting that. > Maybe, just maybe, we should take a step back and reconsider what we = are trying to achieve. I prefer living in 2020 with 2020 computers, despite their flaws and = missteps, than going back to a "simple" age of 1970s machines that did = amazing things, but very limited by today's standards. The cost of = modern benefits is vigilance and updating very complex systems. It is something we are getting better at, and our systems are far more = robust AND far more capable. System V (back in the 80s) was relatively = trivial to get root rpiveldges on and do anything you wanted to the = system, something that happened quite often on the user machines I was = logging into at the time. While I have fond memories of those days = (mostly involving hunt, forums, rchat, and mTrek), I would never go back = to mid 80s computers; nor mid 90s computers, nor pre 2010 computers. YMMV. --=20 'Everything will be all right. =46rom History's point of view, that is. There really isn't any other.'