[FreeBSD-Announce] FreeBSD 12.0 end-of-life
freebsd at edvax.de
Sat May 16 19:54:54 UTC 2020
On Sat, 16 May 2020 12:56:25 -0600, @lbutlr wrote:
> On 16 May 2020, at 12:19, Polytropon <freebsd at 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
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.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions