From owner-freebsd-questions@freebsd.org Sat May 16 19:54:54 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 A28242FBD33 for ; Sat, 16 May 2020 19:54:54 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PbbK1f2mz3xQs for ; Sat, 16 May 2020 19:54:52 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([94.222.31.138]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPA (Nemesis) id 1MrhLw-1jFKg02GMm-00nhuS; Sat, 16 May 2020 21:54:40 +0200 Date: Sat, 16 May 2020 21:54:37 +0200 From: Polytropon To: "@lbutlr" Cc: FreeBSD Subject: Re: [FreeBSD-Announce] FreeBSD 12.0 end-of-life Message-Id: <20200516215437.4802660c.freebsd@edvax.de> In-Reply-To: <257EF587-92B5-4671-B6F4-89E86CC2ACA0@kreme.com> 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> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:yGI82qzvmLBm4cJXXllf1PIsPbgNxhm2IuWQqsGRNDit4afErvn wMWlPdG6ZT5xXr5yuknAJhHPsKzx0i5QTFFjDKi/S4zr88tLouVeWLMuA5JpTB3FX6t9lY6 ZDqbArHe9hApdoh/EXbgfwq/W6KAPh968fqedsV86jVz6hfkYIkgfGoZ2AKYO7VNri8DVXQ U/mC6BrXH2QawowO1d/hg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Hqacsh2dJo0=:7geztwhU/DhaKhyHRop3i4 vsmLFt47dTa7T4Hp54AqebHRm+c8R4nTKa+mUmunp5NRCxU3KSmkdcF9Vs2NOsA4p71jQVTNa ZX49T72L/rGx9K6zSjE3QzjRuPb37qZZfg5dJEaBNjZbhQ16ONbzmZWGBKYSmAIogv5mIOS2y ecNIE3ylhPiaQrlWZRYuOnrezb0dA3BILm9K/iaUyYEcQxnDbPhTrD+lSr/4QIO5kjYKTa8bi h4C+vhLtViNUZj8X2+KseEJEDhx+ul39tx5P8eYoJEH6MXpl6ecyke6H+thTPeOV0CYh03Ay5 A1aBkg+7zLrMeLrePDPqygGOSxCmmLdfIiT7ryacz3IAJ4nvtooFL7Dr4BNDV6DWnpbptwCbt 6POP0j2SuS4plWKjE06GEgEY+rvG4BObuDawH7HJrICYmd++jnuyK29kD4t5sLpn4ghYp7VJS mbTEt7dn1v/bfdEwJt1ZVY9oTL5TaqknjQIu/fotqUumO88NeUOwPDq4MxehsEm/AVbKDFz0/ oVeFlDi0quiR980txIa/tWPngnEtsBpuMbTMWMpx7jZCk5q0QZ4/tJFocZqp7jHOB9dct4qmu Dim408oKa82bulZQfsg3CbhNinqYX4WR40zPv/+U5+0NXqiZApVAURCqQY8gbuUCuccCnvNYE t67a6vChadcrT/H+zVN0e9651vNIi/CHtKsdzDhdVfvJSeLTYXqd8G+HrBLx9rzQD4IqxDufY OfUtCGO5r24KBiiEKx/6yvx2FC7STOkpYrPMGYmozAZjPCVmvXfhovEYK/HlgEmXeMFACeIJR BbgtNlshtfpPNqKRZkE7c161+u4Q3fzBqfIcjLpIxIOFqm6d7fcvazYcQ0q7KLdN0j++8Lm X-Rspamd-Queue-Id: 49PbbK1f2mz3xQs X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.126.187) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.55 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[138.31.222.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.90)[0.905,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[187.126.227.212.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[187.126.227.212.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.24)[ip: (0.44), ipnet: 212.227.0.0/16(-1.20), asn: 8560(1.99), country: DE(-0.02)] 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: Sat, 16 May 2020 19:54:54 -0000 On Sat, 16 May 2020 12:56:25 -0600, @lbutlr wrote: > On 16 May 2020, at 12:19, Polytropon wrote: > > And it runs and runs and runs and runs. Older hardware could > > do this. And older software, in combination with that hardware, > > could do this. As long as the requirements don't change, it's > > not a problem, especially not when _not_ connected to the > > Internet - yes, I'm quite aware that _this_ is a significant > > problem in considering system security. > > If the computer is not connected to any other computers and no > person ever has access to it, that’s fine. I know of a few particular systems that are networked to other computers, and operated by skilled and responsible (!) persons, but of course I can't go into detail; those settings involve FreeBSD 6 and Solaris, they have been set up many years ago, and they are still in use because they work as expected, and trying to replicate their functionality with modern hardware and software is a siginificant cost factor - much higher than keeping the current infrastructures alive, with spare parts at hand if needed. The requirements didn't change for years, and they won't change; the machinery involved doesn't change, and what people do with it doesn't change. So nobody saw a need to update anything just to have updated something. > Otherwise, old OSes are porous insecure botnets-in-wait with > dozens or hundreds or thousands of exploits. That is true, but is significant only as far as those systems interact with other things, especially over Internet. > But that’s an even smaller tiny tiny percentage than desktop > FreeBSD users and should have no bearing on the EOL schedule > of the current versions of the OS. The declarations of EOL do not take into mind how people use the software (and probably never have) - instead, they try to adapt to how software changes. Software dictates how people work, it's not the other way round (as it probably _should_ be). And business processes as well as executive mindsets have adapted to the way software changes, how it requires updates. That is surely not the ultimately desired state, but it is the current state. There are active discussions about how software design has disimproved over decades, and that things have become complicated for no real benefit. Of course this is not entirely true, because for every situation, you can ask: Who profits from the situation as it is now? You won't always know an answer, that's intended, but you will find many examples of "re-buying" (you pay for what already have paid for) in many sectors of economy: computer hardware, software, cars, mobile devices, media. All those have certain paths of "forced upgrade", often combined with some kind of vendor lock-in or "you will lose everything". Software is no special case, but it has come to a point where certain questions can be asked: for simplicity, for correctness, for reliability, for compatibility, for standardizedness, for predictability. In software, we _know_ how to do this. But we don't do it. So the primary question is: Why? And we're back at "cui bono". I just want to provide an example that "younger people" (TM) might find strange: In mainframe world, you can still compile and run programs written in a way to read data from a punched card reader and write data to a chain printer or a tape drive. There is no need to modify the source in order to run such a program on a current mainframe with a current OS. To a certain extent, you even have native binary compatibility. Yes, this is simplified, but basically true. ;-) More or less, we know this in UNIX world as standards like POSIX: Any POSIX-compliant program can be compiled, without any change, on any POSIX-compliant system, and will work as expected. But modern software is so much more than just POSIX, or anything that could be mapped to long-term standards. That's why operating systems have to adapt to innovations and changes not just in hardware, but also in software, especially for things related to security. Oh, and it has to mitigate the errors that hardware manufacturers put into their CPUs. :-) > The issue has been (but hopefully is not any lonher?) is that > upgrading from one version to another can be … well, sometimes > impossible is the best result. More than once I’ve had to > completely setup anew because the upgrade path either did not > work or had been shut-off (like version x.4 can be upgraded to > only from x.3, but x.3 cannot be installed now because it is > EOL so you have no path forward from x.0 x.1 and x.2 but to > start afresh and you installed x.2 6 months ago). It's not always bad to start from scratch. Situations differ, use cases differ, preferences differ, so no matter what paths you plan, there will always be users and admins who will not be able to take that path, for whatever reason. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...