* AMD CPUs compatibility
* Initial support for KVM SCSI VirtIO
* Built-in SSL3
* Numerous fixes and improvements to the debugger and dump analyzer
* Many native compilers, such as C, C++, Fortran, and Macro, are now
available for field test. A new set that includes Bliss, COBOL, and
BASIC is expected to become available soon
* Support for newer VMWare hypervisors versions
* Additional entropy collection mechanism

https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/

"SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
deprecated for years.

John

Den 2023-06-16 kl. 00:26, skrev John Dallman:
> * AMD CPUs compatibility
> * Initial support for KVM SCSI VirtIO
> * Built-in SSL3
> * Numerous fixes and improvements to the debugger and dump analyzer
> * Many native compilers, such as C, C++, Fortran, and Macro, are now
> available for field test. A new set that includes Bliss, COBOL, and
> BASIC is expected to become available soon
> * Support for newer VMWare hypervisors versions
> * Additional entropy collection mechanism
>
> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/
>
> "SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
> deprecated for years.
>
> John

Nice, good to hear.

Now, my last VMS work seem to have come to an end the 30th June.
So I'll probably never be able to work with this new VMS version.
I was 64 in may -23 so I will probably simple retire...

Ah well, 30+ years with VMS is not that bad anyway... :-)

Jan-Erik.

On 15/06/2023 23:26, John Dallman wrote:
> * AMD CPUs compatibility
> * Initial support for KVM SCSI VirtIO
> * Built-in SSL3
> * Numerous fixes and improvements to the debugger and dump analyzer
> * Many native compilers, such as C, C++, Fortran, and Macro, are now
> available for field test. A new set that includes Bliss, COBOL, and
> BASIC is expected to become available soon
> * Support for newer VMWare hypervisors versions
> * Additional entropy collection mechanism
>
> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/
>
> "SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
> deprecated for years.
>
> John

Any idea if we can upgrade from E9.2-1 or is a reinstall required?

--
Chris

On 15/06/2023 23:43, Jan-Erik Söderholm wrote:
> Den 2023-06-16 kl. 00:26, skrev John Dallman:
>> * AMD CPUs compatibility
>> * Initial support for KVM SCSI VirtIO
>> * Built-in SSL3
>> * Numerous fixes and improvements to the debugger and dump analyzer
>> * Many native compilers, such as C, C++, Fortran, and Macro, are now
>>    available for field test. A new set that includes Bliss, COBOL, and
>>    BASIC is expected to become available soon
>> * Support for newer VMWare hypervisors versions
>> * Additional entropy collection mechanism
>>
>> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/
>>
>> "SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
>> deprecated for years.
>>
>> John
>
> Nice, good to hear.
>
> Now, my last VMS work seem to have come to an end the 30th June.
> So I'll probably never be able to work with this new VMS version.
> I was 64 in may -23 so I will probably simple retire...
>
> Ah well, 30+ years with VMS is not that bad anyway... :-)
>
> Jan-Erik.

Well at least you can get the community license and play with it.
I lost VMS at work in 2013, and am now retired, but I still enjoy
messing around with VMS

--
Chris

On 6/15/2023 6:43 PM, Chris Townley wrote:
> On 15/06/2023 23:26, John Dallman wrote:
>> * AMD CPUs compatibility
>> * Initial support for KVM SCSI VirtIO
>> * Built-in SSL3
>> * Numerous fixes and improvements to the debugger and dump analyzer
>> * Many native compilers, such as C, C++, Fortran, and Macro, are now
>>    available for field test. A new set that includes Bliss, COBOL, and
>>    BASIC is expected to become available soon
>> * Support for newer VMWare hypervisors versions
>> * Additional entropy collection mechanism
>>
>> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/
>>
>> "SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
>> deprecated for years.
>>
>> John
>
> Any idea if we can upgrade from E9.2-1 or is a reinstall required?

Probably not supported.

Try it and see what happens; when I did that upgrade, it
worked, but I'm pretty sure that we state that upgrading
from a field test version is not supported.

--

--- Rob

On 6/15/2023 6:26 PM, John Dallman wrote:
> * AMD CPUs compatibility
> * Initial support for KVM SCSI VirtIO
> * Built-in SSL3
> * Numerous fixes and improvements to the debugger and dump analyzer
> * Many native compilers, such as C, C++, Fortran, and Macro, are now
> available for field test. A new set that includes Bliss, COBOL, and
> BASIC is expected to become available soon
> * Support for newer VMWare hypervisors versions
> * Additional entropy collection mechanism
>
> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/

Lots of useful stuff (I don't get the entropy thing - sure it is
important, but there are many other things more important IMHO).

I got a notification email with what I think is an important paragraph:

<quote>
OpenVMS on x86 will be available for commercial orders on September 1, 2023.
<quote>

commercial order => revenue !!

> "SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
> deprecated for years.

Yes. That is VMS terminology.

Arne

On 15/06/2023 23:51, Robert A. Brooks wrote:
> On 6/15/2023 6:43 PM, Chris Townley wrote:
>> On 15/06/2023 23:26, John Dallman wrote:
>>> * AMD CPUs compatibility
>>> * Initial support for KVM SCSI VirtIO
>>> * Built-in SSL3
>>> * Numerous fixes and improvements to the debugger and dump analyzer
>>> * Many native compilers, such as C, C++, Fortran, and Macro, are now
>>>    available for field test. A new set that includes Bliss, COBOL, and
>>>    BASIC is expected to become available soon
>>> * Support for newer VMWare hypervisors versions
>>> * Additional entropy collection mechanism
>>>
>>> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/
>>>
>>> "SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
>>> deprecated for years.
>>>
>>> John
>>
>> Any idea if we can upgrade from E9.2-1 or is a reinstall required?
>
> Probably not supported.
>
> Try it and see what happens; when I did that upgrade, it
> worked, but I'm pretty sure that we state that upgrading
> from a field test version is not supported.
>

Thanks. I will probably do a fresh install, but also try an upgrade on
my current setup. Aren't VMs great!

--
Chris

On 2023-06-15, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> Now, my last VMS work seem to have come to an end the 30th June.

Sorry to hear that. Are you allowed to say what VMS was replaced with ?

> So I'll probably never be able to work with this new VMS version.
> I was 64 in may -23 so I will probably simple retire...
>

I hope you enjoy your retirement, Jan-Erik.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Den 2023-06-16 kl. 14:09, skrev Simon Clubley:
> On 2023-06-15, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>
>> Now, my last VMS work seem to have come to an end the 30th June.
>
> Sorry to hear that. Are you allowed to say what VMS was replaced with ?

Why do you think that VMS was replaced? :-)
It is just my agreement that will not be prolonged.

> I hope you enjoy your retirement, Jan-Erik.

Sure. I might spend more time on my other technical hobbies.
Like the 8-bit MCUs from Microchip (PIC processors)...

Thanks för asking anyway... :-)

Jan-Erik.

On 2023-06-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 6/15/2023 6:26 PM, John Dallman wrote:
>> * AMD CPUs compatibility
>> * Initial support for KVM SCSI VirtIO
>> * Built-in SSL3
>> * Numerous fixes and improvements to the debugger and dump analyzer
>> * Many native compilers, such as C, C++, Fortran, and Macro, are now
>> available for field test. A new set that includes Bliss, COBOL, and
>> BASIC is expected to become available soon
>> * Support for newer VMWare hypervisors versions
>> * Additional entropy collection mechanism
>>
>> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/
>
> Lots of useful stuff (I don't get the entropy thing - sure it is
> important, but there are many other things more important IMHO).
>

The entropy stuff is a critical part of getting "the world's most
secure operating system" actually back up the standards of modern
operating systems. Before this, random number generation on VMS
was hopeless from a security point of view.

It's also vital that it's in x86-64 VMS _before_ the first commercial
releases so that software that should be using it can rely on it actually
being present so it does get used in code.

The amount of effort that VSI are spending on this, at this point in time,
is well justified.

> I got a notification email with what I think is an important paragraph:
>

[snip]

The bit that caught my attention was the following:

|Note: With this release, VMS Software announces an end to standard support
|for V9.2. We encourage everyone who runs V9.2 or earlier x86 builds on
|their systems to migrate to V9.2-1 immediately. Only customers with an
|extended engineering support contract with VMS Software Inc. will receive
|support on OpenVMS V9.2. Patches will no longer be developed for V9.2. Bug
|reports will not be investigated until reporters can reproduce the issue on
|V9.2-1.

I hope that isn't going to be the policy when production releases are
produced. There needs to be a support overlap between the prior releases
and the current release for all customers, even when the current release
is a point release.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Friday, June 16, 2023 at 8:21:27 AM UTC-4, Simon Clubley wrote:

>
> The bit that caught my attention was the following:
>
> |Note: With this release, VMS Software announces an end to standard support
> |for V9.2. We encourage everyone who runs V9.2 or earlier x86 builds on
> |their systems to migrate to V9.2-1 immediately. Only customers with an
> |extended engineering support contract with VMS Software Inc. will receive
> |support on OpenVMS V9.2. Patches will no longer be developed for V9.2. Bug
> |reports will not be investigated until reporters can reproduce the issue on
> |V9.2-1.
>
> I hope that isn't going to be the policy when production releases are
> produced. There needs to be a support overlap between the prior releases
> and the current release for all customers, even when the current release
> is a point release.
> Simon.
>

My view is this is a one time thing. V9.2 and V9.2update2 have enough sharp edges
that we really REALLY REALLY! want sites to upgrade.

For example, I'm about to refresh the native compiler FT kits on the portal.. Those were built/linked
on V9.2update2. Going forward, I'll switch to build/link against V9.2-1. I'll probably stick
with using V9.2-1 headers/libraries even for future kits to ensure backwards compatibility. I won't
bump forward for the rest of the year at least (unless something forces me)..

On Fri, 2023-06-16 at 00:15 +0100, Chris Townley wrote:
> > Try it and see what happens; when I did that upgrade, it
> > worked, but I'm pretty sure that we state that upgrading
> > from a field test version is not supported.
> >
>
> Thanks. I will probably do a fresh install, but also try an upgrade
> on my current setup. Aren't VMs great!

Same here, just took a VM snapshot ready to revert should the upgrade
fail. In the event of failure, I plan to do a fresh install and cluster
it to the older VM and copy my files across.
--
Tactical Nuclear Kittens

On Thursday, June 15, 2023 at 6:51:32 PM UTC-4, Robert A. Brooks wrote:
> On 6/15/2023 6:43 PM, Chris Townley wrote:
> > Any idea if we can upgrade from E9.2-1 or is a reinstall required?
> Probably not supported.
>
> Try it and see what happens; when I did that upgrade, it
> worked, but I'm pretty sure that we state that upgrading
> from a field test version is not supported.
>
> --- Rob

I upgraded from the field test and the only glitch seems to be that SYSINIT
complained about not finding <SYS$LDR>NET$MESSAGE.EXE. The field
test originally had DECNET_PLUS, but I uninstalled it and replaced it with
DECNET_PHASE_IV. The upgrade said it would replace the Phase IV install
with a new Phase IV, so I don't know why it was looking for a Phase V file.

I manually extracted net$message.exe from the decnet_plus kit on the ISO,
built a new memory disk image with sys$md.com, and the error messages
ceased.

I re-built SQLite and ran its speedtest program. The CPU time was pretty much
exactly half the previous run on 28-MAY-2023. The benchmark is I/O bound, so
the I/O processing overhead appears to be much improved.

Running a re-built Bytemark program under the new release is a wash, speedwise.

On 6/16/2023 7:05 PM, David Jones wrote:
> I re-built SQLite and ran its speedtest program. The CPU time was pretty much
> exactly half the previous run on 28-MAY-2023. The benchmark is I/O bound, so
> the I/O processing overhead appears to be much improved.

Nice.

> Running a re-built Bytemark program under the new release is a wash, speedwise.

That is CPU bound right?

So it is sort of expected that it depends more on compiler
than on OS.

Arne

On 6/16/2023 8:21 AM, Simon Clubley wrote:
> On 2023-06-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Lots of useful stuff (I don't get the entropy thing - sure it is
>> important, but there are many other things more important IMHO).
>
> The entropy stuff is a critical part of getting "the world's most
> secure operating system" actually back up the standards of modern
> operating systems. Before this, random number generation on VMS
> was hopeless from a security point of view.
>
> It's also vital that it's in x86-64 VMS _before_ the first commercial
> releases so that software that should be using it can rely on it actually
> being present so it does get used in code.
>
> The amount of effort that VSI are spending on this, at this point in time,
> is well justified.

How many more VMS licenses will VSI sell because of that feature?

My guess: zero.

The OpenSSL maintainers may be happy that they get better entropy
with less code.

The security interested people may think it is nice to get
better entropy.

But when it comes to sales I see zero extra sale.

Sale will be driven by other things:
* getting the last traditional compilers available (Cobol and Basic)
* getting Java and Python available
* making sure Oracle get Rdb available
* convince Synergex to get DBL available
* getting all other platform-software currently available
on Alpha and/or Itanium available
* get some new stuff not currently available
on Alpha and/or Itanium (like RabbitMQ, RocksDB etc.)
available
* getting the OS build with native optimizing
compilers
* enhance RTL to support some of all the "newer" stuff
(like HTTP, JSON etc.)
* get a modern Fortran compiler available
* etc.

Arne

Hi.
How and from which source are you installed SQLite?
Thank you.

Dana subota, 17. lipnja 2023. u 01:05:41 UTC+2 korisnik David Jones napisao je:
> On Thursday, June 15, 2023 at 6:51:32 PM UTC-4, Robert A. Brooks wrote:
> > On 6/15/2023 6:43 PM, Chris Townley wrote:
> > > Any idea if we can upgrade from E9.2-1 or is a reinstall required?
> > Probably not supported.
> >
> > Try it and see what happens; when I did that upgrade, it
> > worked, but I'm pretty sure that we state that upgrading
> > from a field test version is not supported.
> >
> > --- Rob
>
> I upgraded from the field test and the only glitch seems to be that SYSINIT
> complained about not finding <SYS$LDR>NET$MESSAGE.EXE. The field
> test originally had DECNET_PLUS, but I uninstalled it and replaced it with
> DECNET_PHASE_IV. The upgrade said it would replace the Phase IV install
> with a new Phase IV, so I don't know why it was looking for a Phase V file.
>
> I manually extracted net$message.exe from the decnet_plus kit on the ISO,
> built a new memory disk image with sys$md.com, and the error messages
> ceased.
>
> I re-built SQLite and ran its speedtest program. The CPU time was pretty much
> exactly half the previous run on 28-MAY-2023. The benchmark is I/O bound, so
> the I/O processing overhead appears to be much improved.
>
> Running a re-built Bytemark program under the new release is a wash, speedwise.

On 6/17/23 2:55 PM, Crni Mrki wrote:
> Hi.
> How and from which source are you installed SQLite?
> Thank you.

He maintains his own port. I think it's this one:

https://sourceforge.net/projects/vms-ports/files/SQLITE3/

>
> Dana subota, 17. lipnja 2023. u 01:05:41 UTC+2 korisnik David Jones napisao je:
>> On Thursday, June 15, 2023 at 6:51:32 PM UTC-4, Robert A. Brooks wrote:
>>> On 6/15/2023 6:43 PM, Chris Townley wrote:
>>>> Any idea if we can upgrade from E9.2-1 or is a reinstall required?
>>> Probably not supported.
>>>
>>> Try it and see what happens; when I did that upgrade, it
>>> worked, but I'm pretty sure that we state that upgrading
>>> from a field test version is not supported.
>>>
>>> --- Rob
>>
>> I upgraded from the field test and the only glitch seems to be that SYSINIT
>> complained about not finding <SYS$LDR>NET$MESSAGE.EXE. The field
>> test originally had DECNET_PLUS, but I uninstalled it and replaced it with
>> DECNET_PHASE_IV. The upgrade said it would replace the Phase IV install
>> with a new Phase IV, so I don't know why it was looking for a Phase V file.
>>
>> I manually extracted net$message.exe from the decnet_plus kit on the ISO,
>> built a new memory disk image with sys$md.com, and the error messages
>> ceased.
>>
>> I re-built SQLite and ran its speedtest program. The CPU time was pretty much
>> exactly half the previous run on 28-MAY-2023. The benchmark is I/O bound, so
>> the I/O processing overhead appears to be much improved.
>>
>> Running a re-built Bytemark program under the new release is a wash, speedwise.

On Saturday, June 17, 2023 at 4:18:26 PM UTC-4, Craig A. Berry wrote:
> On 6/17/23 2:55 PM, Crni Mrki wrote:
> > Hi.
> > How and from which source are you installed SQLite?
> > Thank you.
> He maintains his own port. I think it's this one:
>
> https://sourceforge.net/projects/vms-ports/files/SQLITE3/

Yes, that's the one. I started 8 years ago with 3.8.11 and now they are
at 3.42.0. They used to have a lot more 3.n.x+1 releases before going
to the 3.n+1.0 update. The additional features have ballooned the core
library source file by ~50% while the command line tool (shell.c) is over
5 times bigger.

Since the VMS-specific stuff is mostly isolated in a separate VFS
implementation, the only changes usually needed for a new SQLite
release are updates to the symbol vectors and image IDs.

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via
> Info-vax
> Sent: Friday, June 16, 2023 8:17 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] VSI has released 9.2-1
>
> On 6/16/2023 7:05 PM, David Jones wrote:
> > I re-built SQLite and ran its speedtest program. The CPU time was
> > pretty much exactly half the previous run on 28-MAY-2023. The
> > benchmark is I/O bound, so the I/O processing overhead appears to be
> much improved.
>
> Nice.
>
> > Running a re-built Bytemark program under the new release is a wash,
> speedwise.
>
> That is CPU bound right?
>
> So it is sort of expected that it depends more on compiler than on OS.
>
> Arne
>

Might not apply here, but in other vendors FT versions of code, it was (is?)
common to leave debug code in for better support in resolving functionality
issues until the release became official. This would typically make FT
versions slower than the final release.

Walk down memory lane - Microsoft left the debug code in PROD versions of
Alpha Windows NT Office and the Alpha Windows benchmarks were still
significantly better than the x86 versions of the time.

We (Digital NT Wizards program at DEC) never could convince MS to release
Prod Alpha NT versions without the debug code.

Ah well .. and the rest is history.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 2023-06-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 6/16/2023 8:21 AM, Simon Clubley wrote:
>> On 2023-06-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Lots of useful stuff (I don't get the entropy thing - sure it is
>>> important, but there are many other things more important IMHO).
>>
>> The entropy stuff is a critical part of getting "the world's most
>> secure operating system" actually back up the standards of modern
>> operating systems. Before this, random number generation on VMS
>> was hopeless from a security point of view.
>>
>> It's also vital that it's in x86-64 VMS _before_ the first commercial
>> releases so that software that should be using it can rely on it actually
>> being present so it does get used in code.
>>
>> The amount of effort that VSI are spending on this, at this point in time,
>> is well justified.
>
> How many more VMS licenses will VSI sell because of that feature?
>
> My guess: zero.
>

This is not about selling new systems. This is about being a part of
work to make sure that existing sites don't get forced to move away
from VMS because VMS no longer meets the industry standard security standards.

You can have a nice piece of software running on VMS, but that's no
good unless those VMS systems are secure by modern standards. VMS systems
_WILL_ be dropped in many areas if they are regarded as no longer being
secure by today's standards.

> The OpenSSL maintainers may be happy that they get better entropy
> with less code.
>

Replace "better entropy" with "now-acceptable entropy". The new entropy
engine running within the kernel offers a brand-new capability for VMS
that is considered to be standard elsewhere.

To put this another way, the previous solutions for generating entropy
within user mode that I am aware of were not suitable by today's standards.

Look at previous discussions here about trying to find sources to get
a bit more entropy while running in user mode.

> The security interested people may think it is nice to get
> better entropy.
>
> But when it comes to sales I see zero extra sale.
>

I am not exactly a fan of some things that VSI are doing :-), but this
is one thing I _strongly_ agree with and it was a pleasant surprise to
see VSI spending the time to implement this. Well done to VSI.

Maybe I am seeing something here you are missing ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Thursday, June 15, 2023 at 6:43:08 PM UTC-4, Jan-Erik Söderholm wrote:
>
> Now, my last VMS work seem to have come to an end the 30th June.
> So I'll probably never be able to work with this new VMS version.
> I was 64 in may -23 so I will probably simple retire...
>
> Ah well, 30+ years with VMS is not that bad anyway... :-)
>
> Jan-Erik.

come to the U.S. with Biden in charge no one will ever be able to retire :)

On 2023-06-19 16:41, Pizza RAC wrote:
> On Thursday, June 15, 2023 at 6:43:08 PM UTC-4, Jan-Erik Söderholm wrote:
>>
>> Now, my last VMS work seem to have come to an end the 30th June.
>> So I'll probably never be able to work with this new VMS version.
>> I was 64 in may -23 so I will probably simple retire...
>>
>> Ah well, 30+ years with VMS is not that bad anyway... :-)
>>
>> Jan-Erik.
>
> come to the U.S. with Biden in charge no one will ever be able to retire :)

Yeah. I guess that concept only exist in socialist countries, like Sweden.

Johnny

On 6/19/2023 10:41 AM, Pizza RAC wrote:
> On Thursday, June 15, 2023 at 6:43:08 PM UTC-4, Jan-Erik Söderholm wrote:
>>
>> Now, my last VMS work seem to have come to an end the 30th June.
>> So I'll probably never be able to work with this new VMS version.
>> I was 64 in may -23 so I will probably simple retire...
>>
>> Ah well, 30+ years with VMS is not that bad anyway... :-)
>>
>> Jan-Erik.
>
> come to the U.S. with Biden in charge no one will ever be able to retire :)

If only the data backed up that baseless statement that the economy suffers
under a Democrat in the White House.

https://www.nytimes.com/2021/02/02/opinion/sunday/democrats-economy.html

https://en.wikipedia.org/wiki/U.S._economic_performance_under_Democratic_and_Republican_presidents

https://www.thebalancemoney.com/democrats-vs-republicans-which-is-better-for-the-economy-4771839

https://newrepublic.com/article/166274/economy-record-republicans-vs-democrats

https://www.newsweek.com/us-jobs-income-gdp-growth-startlingly-higher-under-democratic-presidents-analysis-1566313

--

--- Rob

On 2023-06-19, Pizza RAC <pizzaracorders@gmail.com> wrote:
>
> come to the U.S. with Biden in charge no one will ever be able to retire :)

You are delusional if you think only one party is responsible.

Looking at your country from Europe, I am filled with a mixture of
horror and sadness at what you are doing to yourselves.

The Democrats are destroying your social fabric (look at your major
cities in general and San Francisco in particular).

The Republicans are destroying your business and intellectual fabric
in the name of short term profit and the Democrats have no interest
in reversing that.

Both parties have no interest in getting your debt under control and
only offer short-term solutions that put off the day of reckoning and
will make the collapse when it comes just more massive than it would
be if it happened today.

You are now so weak and cripplied by your short-term thinking, you can
only threaten China (and bully your traditional allies) with sanctions
to try and stop China becoming a bigger competitor, instead of competing
with them as a business rival.

The US is currently in the early stages of the modern day version of
the fall of the Roman Empire.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-06-19, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 6/19/2023 10:41 AM, Pizza RAC wrote:
>>
>> come to the U.S. with Biden in charge no one will ever be able to retire :)
>
> If only the data backed up that baseless statement that the economy suffers
> under a Democrat in the White House.
>
> https://www.nytimes.com/2021/02/02/opinion/sunday/democrats-economy.html
>
> https://en.wikipedia.org/wiki/U.S._economic_performance_under_Democratic_and_Republican_presidents
>
> https://www.thebalancemoney.com/democrats-vs-republicans-which-is-better-for-the-economy-4771839
>
> https://newrepublic.com/article/166274/economy-record-republicans-vs-democrats
>
> https://www.newsweek.com/us-jobs-income-gdp-growth-startlingly-higher-under-democratic-presidents-analysis-1566313
>

That's all well and good Rob, but what happens when China grows a bit
stronger and then decides to show you who the boss is by cutting off
your imports ?

Outside of that, what happens when changing world relationships result
in a decline of the dollar as a reserve currency ? That's where the US
currently gets most of its bullying power from.

In the old days, your military had to worry about protecting your
industrial base from an enemy. These days, all your enemy needs to
do is to threaten to stop sending you the goods they now produce
for you.

Unlike you, China has a strong industrial base, and so is far better
placed to handle that situation than you are. They don't need to
produce the best product on the market to survive the destruction of
the US economy (if they decide to do that), they just need to produce
a product that is good enough.

Think about that if they decide to destroy the Taiwan fabs. They will
survive that (even though they will be badly damaged initially), but
your economy will not.

Both your parties are equally to blame for the situation you are in
and it is a very sad and worrying sight to see.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.