Date: Sat, 16 May 2020 21:54:37 +0200 From: Polytropon <freebsd@edvax.de> To: "@lbutlr" <kremels@kreme.com> Cc: FreeBSD <freebsd-questions@freebsd.org> 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> <CAFYkXjmZi1-MB6W0HsMx9gHek7Xg5heoSKKWkNTnw74dxRTwAw@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 May 2020 12:56:25 -0600, @lbutlr wrote: > On 16 May 2020, at 12:19, Polytropon <freebsd@edvax.de> 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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200516215437.4802660c.freebsd>