Post by email@example.com
ran it for years, great product.
Perfectdisk, perfectcache and perfect tune where great apps.
So let us look at this, from a somewhat more recent perspective...
We have some unsigned kernel code with full security access, optimizing
a very old and problematic and inherently slow I/O path (and one with
more than a little glue code), and which is certainly going to be
useful for some folks that are still on that I/O path. All good, for
folks that are still using that approach, but not exactly something I'd
expect folks to really want to choose going into 2021 or 2027.
What do I mean by this? Signed code and full disk encryption and some
replacement for RMS are usually going to be preferred by app developers
going forward, whether it's some combination of an integrated
relational database or a distributed object store or otherwise, and
with an I/O path that's a little less tedious to deal with and to code
and to access than RMS, and preferably a path that provides a mechanism
for online backups and whatever ongoing maintenance is required and
other such other features. Various of these are increasingly available
on other platforms, whether it's sandboxed and signed code — consider
that caching products share some similarities with anti-malware tools
in terms of the required level of system trust and the depth at which
they're integrated into the system and that they're all attack targets
and they have access to potentially very sensitive data. These are
all areas that VSI knows about and will be working on going forward,
though they've work on Kittson and the x86-64 port and more 64-bit
support ahead of that work.
Computing five or ten years out — where folks might choose to look at
and start basing their apps and partnerships on OpenVMS — is certainly
going to build on some of what OpenVMS has, but there's more than a
little work to make it interesting to wholly new folks and wholly new
What can be easily overlooked is that OpenVMS is not going to be
competing on mail servers, nor on RMS-based file I/O nor with tools to
overcome platform limitations with same. Not in the next five or ten
years. OpenVMS has to compete on what partners can do with it, and
that comes down to how much revenue can be accrued by the partners, how
much risk arises, pricing differentials, and that OpenVMS is presently
pretty close to an embedded platform in terms of how it's packaged and
deployed and updated and managed.
Products and features that are already available aren't going to be a
huge draw because, well, they haven't been. Look where OpenVMS is now
in the market. VSI is the only reason there's as much activity as
there is, and they're working diligently to establish and grow a
revenue stream, and to build up a partner network. They're not big
enough to keep up with what Microsoft and Linux and other platforms can
do, so the folks at VSI are focusing on what they can do to keep the
installed base happy, and then at what they need to start to do to grow
the base, and at what can draw in and keep the partners — at the next
couple of discussions and implementations and projects and partnerships
beyond the simplistic "revenues" mention, that is. That's also 2021
to 2027 before the VSI folks and third-parties start to have those
pieces in place, at the earliest.
The add-on Raxco tools and the add-on mail servers and the rest aren't
really aimed at attracting new folks, and there's more than a little
work around to get OpenVMS into a more competitive position in the
market outside the installed base, so the question becomes what areas
to focus on, and what areas to ignore, and what areas to market on.
VSI has chosen security for marketing — as have you and some other
folks here — though that comes with some discussions around getting
TLSv1.3 and later (and maybe frameworks to make that task and
networking easier) and integrated certificate stores and removing and
deprecating insecure transports and insecure or outdated
implementations, and a variety of discussions already posted. Work.
Lots of it.
Competing head-on with Windows Server and Exchange Server, or with
Postfix, Dovecot and the open source tools, isn't something I see as
being viable — if you do, certainly start offering that service to
folks, of course – but there are areas where an embedded platform can
compete. But it'll take more than a little time and effort, and
pointing to existing tools isn't (hasn't) going to do that, and hasn't
done that. Many folks reasonably don't want to manage the resulting
infrastructure, and don't have and don't want to acquire those too.
Those that do want more automation around those tasks, as we need to
install updates far more quickly and efficiently, and we need to reduce
the effort involved when applications are breached, or when
applications just stomp on each other — and system- and kernel-mode
extensions are really good at stomping on other things, from direct
You're seemingly very focused on what was, on the past, on how things
were once done, on history, and on what's familiar and perceived as
safe. At what competing products were, too. Fun times for some,
expensive and bespoke times for most, and an era of isolated servers
and partitioned networks and that often didn't need much in the way of
security or security knowledge, and we're just not and never will be
headed back to those days. Look around. Learn. Actually try some
of the competing products. Potential future customers of OpenVMS or
any platform certainly perform those comparisons now, and and will
continue to do that, too.
FWIW (1) and since there's been some "it's in draft" comments posted
about TLSv1.3, well, sure. The draft is has already been deployed in
some security-relevant products, and more are coming online. Stuff in
draft status is how a vendor has the features and capabilities
available when the release is available. The same holds for
announcing products and product marketing these days, but I digress.
Products that market on security usually want to select and track
appropriate security features, and TLS is one of the key security
features on any platform and in the many apps where IPSec doesn't and
can't fit. We're increasingly all dealing with mobile client devices
and far larger and far less trusted networks, and with all that
FWIW (2), we've come a long way from the environments that many of
OpenVMS users and developers started out in — massively different from
when I started, certainly — and requirements and expectations are
moving much more quickly, and products and vendors can either keep up
or the applications and environments transition into legacy status and
eventually set aside and maintained until replacement. Not that there
isn't a market for legacy products, but that path inevitably drifts
into irrelevance and oblivion. Something I'd prefer not to see happen
with OpenVMS. Competing products have gotten massively better, and
replacements and alternatives to tentpole OpenVMS features are now
commonplace — I just bumped into VMware's Herat, for instance.
https://github.com/vmware/haret/blob/master/docs/why.md That 65% of
data breaches are due to humans was a bit of a surprise, too, that per
the current Verizon DBIR.
Times and risks and expectations and businesses and the climate and the
competitive landscape all change, and each with significant effects on
existing products and new product development. Learn from the past,
but don't rest on the past. Always look forward.
Pure Personal Opinion | HoffmanLabs LLC