We started these discussions and exchanges a DECADE ago!!! A LOT has been
discussed and a lot has happened. Many improvements have been made in the
process.
BUT.
After thinking about the state of mind of many of us - tired, withdrawn,
frustrated and detached. As well as my own commitments to work and family,
I have come to the conclusion that we should all take a break from the
conference calls and focus on ourselves and when there is time work to get
some progress on the various Open Source projects we have been championing.
I myself have a new project at work with a TIGHT SCHEDULE with multiple
databases, multiple cluster, production, development, quality assurance,
backup, gateways, disaster recovery, inter-company data exchanges and a new
client. I also have about four or more small projects going on at any one
time for the rest of the my current client and even projects for myself.
Not to mention I would like to find time to visit family and friends in
several states West of the Mississippi and East of the Pacific Ocean, many
of whom I have not seen since 2017 (some of that may have to wait until
after this new project is completed in early 2023 or so).
As such I am not scheduling any more conference calls until at LEAST
September. I do want to keep communications open and I want comment and
feedback from ALL!!!
We had minimal discussion last conference call other than to some extent
this discussion and trying to rally more troops to help in the process.
John and I STILL BELIEVE that the GNUlib Assist Library makes the most sense
to help reduce the effort of porting to OpenVMS the myriad of Open Source
Packages that are out there and which are beneficial but which folks have
not undertaken due to the various efforts that have be more or less randomly
applied based upon the findings during the porting process. If we could get
a build with minimal effort and then worry about how to optimize and
integrate OpenVMS specific features the process could be sped up by at least
an order of magnitude or more.
Anyway, let me know your thoughts. Keep me informed of your efforts and
along the way we will distribute on a irregular basis news from the Open
Source On OpenVMS Community!
Thanks!
Best,
Bill.
Bill Pedersen
864 490 8863

On 2022-06-14, <pedersen@ccsscorp.com> <pedersen@ccsscorp.com> wrote:
> We started these discussions and exchanges a DECADE ago!!! A LOT has been
> discussed and a lot has happened. Many improvements have been made in the
> process.
>
> BUT.
>
> After thinking about the state of mind of many of us - tired, withdrawn,
> frustrated and detached. As well as my own commitments to work and family,
> I have come to the conclusion that we should all take a break from the
> conference calls and focus on ourselves and when there is time work to get
> some progress on the various Open Source projects we have been championing.
>

That makes perfect sense - it's been clear for quite some time that the
current meetings have been a case of "going through the motions".

Enjoy your well-earned break. I suspect that as September gets closer,
you will probably still feel the same way and that sometime next year
will be a more realistic goal for restarting the meetings (if you still
feel like you want to do so after having had the chance to reflect).

In any case, thanks to you and others for your open source efforts on VMS.

>
> John and I STILL BELIEVE that the GNUlib Assist Library makes the most sense
> to help reduce the effort of porting to OpenVMS the myriad of Open Source
> Packages that are out there and which are beneficial but which folks have
> not undertaken due to the various efforts that have be more or less randomly
> applied based upon the findings during the porting process. If we could get
> a build with minimal effort and then worry about how to optimize and
> integrate OpenVMS specific features the process could be sped up by at least
> an order of magnitude or more.
>

The Cygwin approach of providing core Unix compatibility functionality
in a library and then building Unix applications against that library
would indeed appear to be the best approach for VMS, given that it has
been a major success story on Windows and has provided us with a rich
Unix userland environment on Windows.

Simon.

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

On 2022-06-15, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2022-06-14, <pedersen@ccsscorp.com> <pedersen@ccsscorp.com> wrote:
>> We started these discussions and exchanges a DECADE ago!!! A LOT has been
>> discussed and a lot has happened. Many improvements have been made in the
>> process.
>>
>> BUT.
>>
>> After thinking about the state of mind of many of us - tired, withdrawn,
>> frustrated and detached. As well as my own commitments to work and family,
>> I have come to the conclusion that we should all take a break from the
>> conference calls and focus on ourselves and when there is time work to get
>> some progress on the various Open Source projects we have been championing.
>>
>
> That makes perfect sense - it's been clear for quite some time that the
> current meetings have been a case of "going through the motions".
>
> Enjoy your well-earned break. I suspect that as September gets closer,
> you will probably still feel the same way and that sometime next year
> will be a more realistic goal for restarting the meetings (if you still
> feel like you want to do so after having had the chance to reflect).
>
> In any case, thanks to you and others for your open source efforts on VMS.
>

I am surprised that no-one else has offered any comments about this or
about how they see, at a technical level, the best way forward for
porting open source software to VMS.

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 16, 2022 at 7:15:37 AM UTC-5, Simon Clubley wrote:
> I am surprised that no-one else has offered any comments about this or
> about how they see, at a technical level, the best way forward for
> porting open source software to VMS.
> Simon.
>
Well, as someone who had to write something to catch all OPCOM and some other messages creating modern syslog format (forget the number then) using C when the C compiler was about 10 years out of date so had to port the bulk of the GNU string library into the project before I could get anything to work . . .

There isn't one.

Operating systems and written on the x86-wanna-be-a-real-computer-one-day-when-I-grow-up platform never scale up.

You can scale a real OS and real software down because you are taking things out, but the x86 platform is inherently so insecure and non-robust you can't really port anything of significance to OpenVMS.

Despite what many others in here may wish to promote, layered logical name tables with user, group, and ACL access security is a robust and amazing security feature when properly used. Applications using these features in an appropriate manner can be self-protecting with the default super user tree pointing off to an "entertainment value" area of the system that can send a security alert and keep the user poking around for hours while teams/authorities backtrace the connection. You have to "know the magic codes" to get out of the "entertainment value" tree into the actual tree where all of the actual accounting, customer, cc, etc. information is.

Many didn't take it to that level, but you could.

The best, won't say where, won't say when, were the sites that re-purposed the "Test Cluster" as a glorified terminal.

All of the real software was loaded on this system. It was used for integration testing and new user training. It even had regularly scheduled nightly jobs. The operators sneaker netted actual inventory files over to the system each night. On the "Test Cluster" the critical files all had generic names like INVENTORY.DAT, INVOICES.DAT, etc. Completely different names on the production cluster.

The production cluster had no outside access. To get a terminal on it you had to go through the "Test Cluster" with your magic-magic access code to a magic-magic program that would open a basic terminal connection to a production cluster on a different network. It was a specific non-generic terminal package that would only connect with itself, I don't remember what. They might have rolled their own.

The only "outside access" the production cluster had was via MQSeries queues from a Websphere server. There was no way to initiate any kind of file transfer or terminal connection from the outside world. All of the free-flowing XML/JSON/etc. messages were converted to fix-width fixed-field-width proprietary message formats before being placed on the queue.

I took that tiny detour to point out the level of thinking that want into many/much/a-not-insignificant-part of the VMS world. People actually thought about things like bifurcated terminal applications and other secured communications. We have $SEVERITY with many different values that qualify as $SUCCESS because the values were deemed INFORMATIONAL.

The x86 world doesn't have this. More importantly can't be made to deal with it. To make OpenSource software of any significance run correctly you end up with one-off forks because what you need can't be passed back upstream.

Yes, many small useful things like JED https://www.jedsoft.org/jed/ can be ported. I use JED a lot in my embedded systems work.

Instead of having huge range of exit codes that can convey $SEVERITY one can only safely use 0-125 and 0 **is the only success value**

https://unix.stackexchange.com/questions/418784/what-is-the-min-and-max-values-of-exit-codes-in-linux

The one package that shoulda-woulda-coulda made a lot of sense was PostgreSQL because it actually started out on VMS decades ago. According to the port page
https://wiki.postgresql.org/wiki/OpenVMS_port
last updated 2012 . . .

I say it would have made a lot of sense only because OpenVMS could then become a robust host OS for a robust relational database that all of the x86 languages that matter could hit. Would have granted much purpose to the x86 port, especially if the COBOL/BASIC/FORTRAN/C compilers got a PostgreSQLMod utility so shops could begin migrating applications from RDB to a free-as-in-beer database the new maintainers of VMS could sell support contracts for.

I suspect that was a giant hill to push a boulder up though.

Lack of any real desktop for VMS torpedoed adding support to a large C++ framework like CopperSpice or Qt that would have hidden most of the ugly OS details

On 2022-06-16 13:50:16 +0000, seasoned_geek said:

> On Thursday, June 16, 2022 at 7:15:37 AM UTC-5, Simon Clubley wrote:
>> I am surprised that no-one else has offered any comments about this or
>> about how they see, at a technical level, the best way forward for
>> porting open source software to VMS.

There's a whole lot known about what's required. Fundamentally, it's
people getting paid to work on open source for OpenVMS, and investments
from VSI in fixes and updates. In short, money.

> Well, as someone who had to write something to catch all OPCOM and some
> other messages creating modern syslog format (forget the number then)
> using C when the C compiler was about 10 years out of date so had to
> port the bulk of the GNU string library into the project before I could
> get anything to work . . .

Good news: while the OpenVMS C compiler reached C99 support back around
2020 and is thus still a decade or so out of date, part of that will be
changing with the OpenVMS x86-64 port, LLVM, and Clang.

As for syslog, there's an old port at VSI:
https://vmssoftware.com/products/syslogd/

And a whole lot of GNU and Clang and POSIX extensions are missing,
though base C support is vastly better than it once was given C99.
getopt_long is probably the one API I've bumped into most, and having
to avoid the missing calls is less than fun for new work.

> There isn't one.

There's way more here to the dependency chains involved, yes. That was
all starting to pile up around Y2K, and the dependencies have only
increased. The scale and scope of app development has increased, along
with developer and customer expectations.

> Operating systems and written on the
> x86-wanna-be-a-real-computer-one-day-when-I-grow-up platform never
> scale up.

x86-64 servers are substantially more capable than the Alpha and
Itanium boxes that many of us are dealing with.

How fast OpenVMS and its memory management model will perform on x86-64
remains to be determined, though.

> You can scale a real OS and real software down because you are taking
> things out, but the x86 platform is inherently so insecure and
> non-robust you can't really port anything of significance to OpenVMS.

Alas, scaling down is surprisingly difficult, particularly around
memory and power requirements.

Might want to encourage housekeeping interrupts to all hit at the same
time to improve power efficiency.

There's a whole lot of OpenVMS that just doesn't make sense in
low-range configurations, too.

But if you're thinking of x86-64 servers as small or slow or limited,
that's not the case.

But as for OpenVMS itself, that never got around to adding support for
the larger HP/HPE Itanium servers in years past, and is decidedly now
positioned in the low-to-mid-range server computing market in recent
years.

> Despite what many others in here may wish to promote, layered logical
> name tables with user, group, and ACL access security is a robust and
> amazing security feature when properly used. Applications using these
> features in an appropriate manner can be self-protecting with the
> default super user tree pointing off to an "entertainment value" area
> of the system that can send a security alert and keep the user poking
> around for hours while teams/authorities backtrace the connection. You
> have to "know the magic codes" to get out of the "entertainment value"
> tree into the actual tree where all of the actual accounting, customer,
> cc, etc. information is.

You've also just described LDAP.

Pragmatically, all of the logical name stuff could be re-hosted over
onto LDAP and with minimal or no disruption, and with support for
multiple hosts and replication added.

> Many didn't take it to that level, but you could.

Most will use parallel LDAP, if they want or need full separation.

> The best, won't say where, won't say when, were the sites that
> re-purposed the "Test Cluster" as a glorified terminal.

These same messes can arise with OpenVMS, and this mess is unrelated to
the underlying processor architecture.

> All of the real software was loaded on this system. It was used for
> integration testing and new user training. It even had regularly
> scheduled nightly jobs. The operators sneaker netted actual inventory
> files over to the system each night. On the "Test Cluster" the critical
> files all had generic names like INVENTORY.DAT, INVOICES.DAT, etc.
> Completely different names on the production cluster.

Outside of its own non-production data, there's no reason for the test
environment to diverge from productions, and often various good reasons
why it should not. The more test diverges, the more time spent testing
divergences.

> The production cluster had no outside access. To get a terminal on it
> you had to go through the "Test Cluster" with your magic-magic access
> code to a magic-magic program that would open a basic terminal
> connection to a production cluster on a different network. It was a
> specific non-generic terminal package that would only connect with
> itself, I don't remember what. They might have rolled their own.

A combination of access controls and DNS are commonly used to direct
clients to the appropriate servers.

> The only "outside access" the production cluster had was via MQSeries
> queues from a Websphere server. There was no way to initiate any kind
> of file transfer or terminal connection from the outside world. All of
> the free-flowing XML/JSON/etc. messages were converted to fix-width
> fixed-field-width proprietary message formats before being placed on
> the queue.

That's server isolation is a fairly common preference, and independent
of the processor architecture.

> I took that tiny detour to point out the level of thinking that want
> into many/much/a-not-insignificant-part of the VMS world. People
> actually thought about things like bifurcated terminal applications and
> other secured communications. We have $SEVERITY with many different
> values that qualify as $SUCCESS because the values were deemed
> INFORMATIONAL.

None of what you've described so far is unique to OpenVMS. As for the
OpenVMS condition handling, yes, that can be useful. Though more often
than not lately, I'm selecting by error, and not on the OpenVMS SIWEF,
and logging and exiting on unrecognized errors. Unix shell error
handling is different, subtle, and quick to anger. Other environments
and other platforms differ.
>
> The x86 world doesn't have this. More importantly can't be made to deal
> with it. To make OpenSource software of any significance run correctly
> you end up with one-off forks because what you need can't be passed
> back upstream.
> Yes, many small useful things like JED https://www.jedsoft.org/jed/ can
> be ported. I use JED a lot in my embedded systems work.
>
> Instead of having huge range of exit codes that can convey $SEVERITY
> one can only safely use 0-125 and 0 **is the only success value**

Oh, you really need to keep up with that particular mess. 0 can
sometimes be the only success value, or negative can be failure and
positive success, or other schemes. That's when the APIs and tools are
still using the old OpenVMS-style APIs.

Some other error reporting via error classes are far more flexible, for
newer environments.

Here's the older NSError, as an alternative to what OpenVMS does:
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/ErrorHandling/ErrorHandling.html

As for OpenVMS, one of my favorite" error messes is the stupidity
around errors and parameters for system errors, for RMS errors, and for
user errors. Why that isn't consistent is a discussion for another era,
and changes there are ~impossible due to compatibility. But I usually
end up wrapping the built-in error handling and message output support
to make it somewhat less stupid.

And again, this design (or this mess) has nothing to do with the
underlying processor architecture.

> https://unix.stackexchange.com/questions/418784/what-is-the-min-and-max-values-of-exit-codes-in-linux
>

Being quite portable, Linux specifically avoids tying into x86-64
architecture, outside of that necessary to boot and build for that
architecture. Put differently, what Linux does for error codes is what
Linux does, independent of x86-64 architecture.

> The one package that shoulda-woulda-coulda made a lot of sense was
> PostgreSQL because it actually started out on VMS decades ago.
> According to the port page
> https://wiki.postgresql.org/wiki/OpenVMS_port
> last updated 2012 . . .

PostgreSQL hasn't ever supported OpenVMS. (You're probably confusing
PostgreSQL with Ingres or some other database package which did have
support for VAX/VMS or OpenVMS.)

The PostgreSQL port stalled due to shared stream I/O corruptions (SSIO)
latent in OpenVMS, among other issues.
VSI is reportedly addressing those corruption issues for single-host,
non-clustered apps.

On 6/15/2022 8:23 AM, Simon Clubley wrote:
> On 2022-06-14, <pedersen@ccsscorp.com> <pedersen@ccsscorp.com> wrote:
>> John and I STILL BELIEVE that the GNUlib Assist Library makes the most sense
>> to help reduce the effort of porting to OpenVMS the myriad of Open Source
>> Packages that are out there and which are beneficial but which folks have
>> not undertaken due to the various efforts that have be more or less randomly
>> applied based upon the findings during the porting process. If we could get
>> a build with minimal effort and then worry about how to optimize and
>> integrate OpenVMS specific features the process could be sped up by at least
>> an order of magnitude or more.
>
> The Cygwin approach of providing core Unix compatibility functionality
> in a library and then building Unix applications against that library
> would indeed appear to be the best approach for VMS, given that it has
> been a major success story on Windows and has provided us with a rich
> Unix userland environment on Windows.

*nix compatibility is definitely a good thing.

But a few comments.

1) Cygwin is not a success on Windows. It is a great thing, but
it has not gotten mainstream for Windows development and
its use is pretty rare.

2) *nix compatible libraries are great but please do not make it
a separate *nix "subsystem" with *nix shell.

That is not what most VMS users want.

3) The open source world in 2022 is not the same as the open
source world in 1992.

If one looks at:
https://madnight.github.io/githut/#/pull_requests/2022/1

It shows:

Script
------
Python 16.7%
JavaScript 14.3%
TypeScript 9.1%
Ruby 6.2%
PHP 5.3%
Dart 0.8%
Perl 0.2%
Lua 0.1%

JVM
---
Java 13.1%
Scala 1.7%
Kotlin 1.1%
Groovy 0.3%

Traditional
native
------
C++ 7.0%
C 3.0%

New
native
------
Go 7.9%
Rust 1.1%
Swift 0.7%

CLR
---
C# 3.1%

Arne

On 6/16/2022 3:11 PM, Stephen Hoffman wrote:
> On 2022-06-16 13:50:16 +0000, seasoned_geek said:
>> The one package that shoulda-woulda-coulda made a lot of sense was
>> PostgreSQL because it actually started out on VMS decades ago.
>> According to the port page
>> https://wiki.postgresql.org/wiki/OpenVMS_port
>> last updated 2012 . . .
>
> PostgreSQL hasn't ever supported OpenVMS. (You're probably confusing
> PostgreSQL with Ingres or some other database package which did have
> support for VAX/VMS or OpenVMS.)

PostgreSQL has some heritage from Ingres, but PostgreSQL started
on *nix (not quite sure which).

>> I say it would have made a lot of sense only because OpenVMS could
>> then become a robust host OS for a robust relational database that all
>> of the x86 languages that matter could hit. Would have granted much
>> purpose to the x86 port, especially if the COBOL/BASIC/FORTRAN/C
>> compilers got a PostgreSQLMod utility so shops could begin migrating
>> applications from RDB to a free-as-in-beer database the new
>> maintainers of VMS could sell support contracts for.
>
> VSI does seem intent on a port of PostgreSQL. Probably as an option or
> fallback, should Oracle Rdb be delayed or unavailable or otherwise
> under- or uninteresting to VSI customers.

PostgreSQL on VMS is interesting even with Rdb in fine shape on
VMS x86-64. PostgreSQL is a major database today - Rdb is a nice
database but totally niche in the market.

>> I suspect that was a giant hill to push a boulder up though.
>
> Definitely. OpenVMS app ports from Rdb to not-Rdb will involve a fair
> amount of work, and the pre-compilers are just part of that "fun". (I'll
> have to ponder what's involved in pre-compiler support, given LLVM-based
> languages. LLVM integrates far better than did DEC-era compilers.)

Pre-compilers should not be a big problem.

PostgreSQL comes with an embedded SQL for C compiler.

There is an open source embedded SQL for Cobol compiler.

VSI got embedded SQL working for all languages for SQL Relay - and
changing that from SQL Relay API to libpq API should not be a big
task.

But question is how relevant it is. PostgreSQL will probably
appeal most to new application. And new applications will
probably not use embedded SQL. Embedded SQL is a technology
of the past.

I expect to see libpq in C/C++, JDBC driver for JVM languages,
psycopg2 module for Python, pgsql extension in PHP etc..

Arne

Bill, perhaps you saw my recent post about giving away my DS10, the only
hardware I have that can run VMS. It was this system I was hoping to use to
help out the porting group’s efforts, back when I contacted you maybe 2(?)
years ago about doing so. At the time I was working mostly or entirely from
home, but by late Summer 2020 I was already back to spending most of my
time at the office, and so had rather less flexibility to be of help.

Some day I’ll be running VMS as a hobbyist once again, but using X86-64
hardware. It would certainly be much more reliable over the long haul than
my aged Alpha hardware would have been.)

If this comes about I hope I can at that time be of some real use to the
porting project.

Galen

On 06/16/22 21:55, Arne Vajhøj wrote:
> On 6/15/2022 8:23 AM, Simon Clubley wrote:
>> On 2022-06-14, <pedersen@ccsscorp.com> <pedersen@ccsscorp.com> wrote:
>>> John and I STILL BELIEVE that the GNUlib Assist Library makes the
>>> most sense
>>> to help reduce the effort of porting to OpenVMS the myriad of Open
>>> Source
>>> Packages that are out there and which are beneficial but which folks
>>> have
>>> not undertaken due to the various efforts that have be more or less
>>> randomly
>>> applied based upon the findings during the porting process. If we
>>> could get
>>> a build with minimal effort and then worry about how to optimize and
>>> integrate OpenVMS specific features the process could be sped up by
>>> at least
>>> an order of magnitude or more.
>>
>> The Cygwin approach of providing core Unix compatibility functionality
>> in a library and then building Unix applications against that library
>> would indeed appear to be the best approach for VMS, given that it has
>> been a major success story on Windows and has provided us with a rich
>> Unix userland environment on Windows.
>
> *nix compatibility is definitely a good thing.
>
> But a few comments.
>
> 1) Cygwin is not a success on Windows. It is a great thing, but
> it has not gotten mainstream for Windows development and
> its use is pretty rare.

It's definately a success for those who need its functionality. As
a developer, it allows me to run X under cygwin on windows and
to access a whole myriad of useful apps and as much of a unix like
environment as needed. For those who must use windows, cygwin
adds so much functionality, and unlike some offerings, it's quite
lightweight in resource usage as well.

I know uSoft have a linux environment package for windows, but
they really are a bit late to the game. Cygwin don't make a big
noise in publicity terms, but it just gets the job done...

Chris

>
> 2) *nix compatible libraries are great but please do not make it
> a separate *nix "subsystem" with *nix shell.
>
> That is not what most VMS users want.
>
> 3) The open source world in 2022 is not the same as the open
> source world in 1992.
>
> If one looks at:
> https://madnight.github.io/githut/#/pull_requests/2022/1
>
> It shows:
>
> Script
> ------
> Python 16.7%
> JavaScript 14.3%
> TypeScript 9.1%
> Ruby 6.2%
> PHP 5.3%
> Dart 0.8%
> Perl 0.2%
> Lua 0.1%
>
> JVM
> ---
> Java 13.1%
> Scala 1.7%
> Kotlin 1.1%
> Groovy 0.3%
>
> Traditional
> native
> ------
> C++ 7.0%
> C 3.0%
>
> New
> native
> ------
> Go 7.9%
> Rust 1.1%
> Swift 0.7%
>
> CLR
> ---
> C# 3.1%
>
> Arne
>
>
>

On 6/17/2022 9:18 AM, chris wrote:
> On 06/16/22 21:55, Arne Vajhøj wrote:
>> On 6/15/2022 8:23 AM, Simon Clubley wrote:
>>> The Cygwin approach of providing core Unix compatibility functionality
>>> in a library and then building Unix applications against that library
>>> would indeed appear to be the best approach for VMS, given that it has
>>> been a major success story on Windows and has provided us with a rich
>>> Unix userland environment on Windows.
>>
>> *nix compatibility is definitely a good thing.
>>
>> But a few comments.
>>
>> 1) Cygwin is not a success on Windows. It is a great thing, but
>> it has not gotten mainstream for Windows development and
>> its use is pretty rare.
>
> It's definately a success for those  who need its functionality. As
> a developer, it allows me to run X under cygwin on windows and
> to access a whole myriad of useful apps and as much of a unix like
> environment as needed. For those who must use windows, cygwin
> adds so much functionality, and unlike some offerings, it's quite
> lightweight in resource usage as well.
>
> I know uSoft have a linux environment package for windows, but
> they really are a bit late to the game. Cygwin don't make a big
> noise in publicity terms, but it just gets the job done...

I like Cygwin. I have always had it on my Windows PC's for more
than 2 decades. I don't use that much of it and I never use
bash, but I like many of the utilities.

But if you look at what software for Windows is being build
with then MSVC++ is by far the majority and number two is
GCC mingw*. GCC cygwin is a niche.

For whatever reason the average Windows + *nix developer
seem to prefer #ifdef'ing and building with either MSVC++
or GCC mingw* instead of GCC cygwin.

As a data point with significant impact look at
Boost.

Arne

On 06/17/22 14:33, Arne Vajhøj wrote:
> On 6/17/2022 9:18 AM, chris wrote:
>> On 06/16/22 21:55, Arne Vajhøj wrote:
>>> On 6/15/2022 8:23 AM, Simon Clubley wrote:
>>>> The Cygwin approach of providing core Unix compatibility functionality
>>>> in a library and then building Unix applications against that library
>>>> would indeed appear to be the best approach for VMS, given that it has
>>>> been a major success story on Windows and has provided us with a rich
>>>> Unix userland environment on Windows.
>>>
>>> *nix compatibility is definitely a good thing.
>>>
>>> But a few comments.
>>>
>>> 1) Cygwin is not a success on Windows. It is a great thing, but
>>> it has not gotten mainstream for Windows development and
>>> its use is pretty rare.
>>
>> It's definately a success for those who need its functionality. As
>> a developer, it allows me to run X under cygwin on windows and
>> to access a whole myriad of useful apps and as much of a unix like
>> environment as needed. For those who must use windows, cygwin
>> adds so much functionality, and unlike some offerings, it's quite
>> lightweight in resource usage as well.
>>
>> I know uSoft have a linux environment package for windows, but
>> they really are a bit late to the game. Cygwin don't make a big
>> noise in publicity terms, but it just gets the job done...
>
> I like Cygwin. I have always had it on my Windows PC's for more
> than 2 decades. I don't use that much of it and I never use
> bash, but I like many of the utilities.
>
> But if you look at what software for Windows is being build
> with then MSVC++ is by far the majority and number two is
> GCC mingw*. GCC cygwin is a niche.
>
> For whatever reason the average Windows + *nix developer
> seem to prefer #ifdef'ing and building with either MSVC++
> or GCC mingw* instead of GCC cygwin.
>
> As a data point with significant impact look at
> Boost.
>
> Arne
>

Two to 3 decades here as well. Originally from a DEC systems
environment, but with familiarity, always preferred a unix like
environment for development work. Can understand why some
prefer a windows environment for windows app work, but more
real time embedded here, where unix scores because of the
overall flexibility. In general, windows is here on sufferance,
because off some legacy apps, but that's about it.

Like like so much else, depends on the area you are working
in. Computing is a very broad church these days...

Chris

On 17/06/2022 14:33, Arne Vajhøj wrote:
> On 6/17/2022 9:18 AM, chris wrote:
>> On 06/16/22 21:55, Arne Vajhøj wrote:
>>> On 6/15/2022 8:23 AM, Simon Clubley wrote:
>>>> The Cygwin approach of providing core Unix compatibility functionality
>>>> in a library and then building Unix applications against that library
>>>> would indeed appear to be the best approach for VMS, given that it has
>>>> been a major success story on Windows and has provided us with a rich
>>>> Unix userland environment on Windows.
>>>
>>> *nix compatibility is definitely a good thing.
>>>
>>> But a few comments.
>>>
>>> 1) Cygwin is not a success on Windows. It is a great thing, but
>>> it has not gotten mainstream for Windows development and
>>> its use is pretty rare.
>>
>> It's definately a success for those  who need its functionality. As
>> a developer, it allows me to run X under cygwin on windows and
>> to access a whole myriad of useful apps and as much of a unix like
>> environment as needed. For those who must use windows, cygwin
>> adds so much functionality, and unlike some offerings, it's quite
>> lightweight in resource usage as well.
>>
>> I know uSoft have a linux environment package for windows, but
>> they really are a bit late to the game. Cygwin don't make a big
>> noise in publicity terms, but it just gets the job done...
>
> I like Cygwin. I have always had it on my Windows PC's for more
> than 2 decades. I don't use that much of it and I never use
> bash, but I like many of the utilities.
>
> But if you look at what software for Windows is being build
> with then MSVC++ is by far the majority and number two is
> GCC mingw*. GCC cygwin is a niche.
>
> For whatever reason the average Windows + *nix developer
> seem to prefer #ifdef'ing and building with either MSVC++
> or GCC mingw* instead of GCC cygwin.
>
> As a data point with significant impact look at
> Boost.
>

Have you looked at Windows Subsystem for Linux as an option?

--
Chris

On 6/17/2022 11:00 AM, Chris Townley wrote:
> On 17/06/2022 14:33, Arne Vajhøj wrote:
>> I like Cygwin. I have always had it on my Windows PC's for more
>> than 2 decades. I don't use that much of it and I never use
>> bash, but I like many of the utilities.

> Have you looked at Windows Subsystem for Linux as an option?

My impression is that WSL is more for people developing
for Linux on Windows than for for Windows users
wanting to use some *nix utilities.

Arne

On 06/17/22 16:32, Arne Vajhøj wrote:
> On 6/17/2022 11:00 AM, Chris Townley wrote:
>> On 17/06/2022 14:33, Arne Vajhøj wrote:
>>> I like Cygwin. I have always had it on my Windows PC's for more
>>> than 2 decades. I don't use that much of it and I never use
>>> bash, but I like many of the utilities.
>
>> Have you looked at Windows Subsystem for Linux as an option?
>
> My impression is that WSL is more for people developing
> for Linux on Windows than for for Windows users
> wanting to use some *nix utilities.
>
> Arne
>
>

Not forgetting the fact that previous uSoft efforts in that
direction ended up putting over Gbyte on to the hard drive :-(...

Chris

On Thursday, June 16, 2022 at 2:11:32 PM UTC-5, Stephen Hoffman wrote:
> On 2022-06-16 13:50:16 +0000, seasoned_geek said:
>
>
> As for syslog, there's an old port at VSI:
> https://vmssoftware.com/products/syslogd/
>
That's a train wreck that got hit by a plane crash and is rolling downhill towards a daycare center at noon play. I think there was almost 20 "working examples" my client found for me. They tested only under SYSTEM. Every one of them was worthless junk. Un-initialized pointers, wrote to buffers they never allocated. Uninitialized numeric values. List went on and on. When you ran them as a mere mortal with just a couple of added privs for the function calls they all self-destructed.

I also needed the "modern" layout in use by RSyslog at the time.

> > Operating systems and written on the
> > x86-wanna-be-a-real-computer-one-day-when-I-grow-up platform never
> > scale up.
> x86-64 servers are substantially more capable than the Alpha and
> Itanium boxes that many of us are dealing with.
>
Sorry, but you completely missed the point here.

https://www.logikalsolutions.com/wordpress/information-technology/business-class-computing/
https://www.logikalsolutions.com/wordpress/information-technology/soversion/

Speed is not the problem. Lack of skill and architectural design is the problem. The completely worthless and criminally fraudulent AGILE stuff isn't helping the x86 world get any better. You cannot architect a valid solution for thousands of users jumping straight into coding looking no further ahead than six inches in front of your shoes which is what AGILE TDD CI/CD does.

The focus of the operating systems originally written on x86 platforms has been single user. Eventually access for a few other users was hacked on. Even Linux has processes too light to be considered threads on VMS which is why there are hundreds, possibly thousands, of articles written on how to kill dangling threads.

It's not a hardware issue, it's the itty-bitty brain behind the software and the OS.

> > Despite what many others in here may wish to promote, layered logical
> > name tables with user, group, and ACL access security is a robust and
> > amazing security feature when properly used. Applications using these
> > features in an appropriate manner can be self-protecting with the
> > default super user tree pointing off to an "entertainment value" area
> > of the system that can send a security alert and keep the user poking
> > around for hours while teams/authorities backtrace the connection. You
> > have to "know the magic codes" to get out of the "entertainment value"
> > tree into the actual tree where all of the actual accounting, customer,
> > cc, etc. information is.
> You've also just described LDAP.
>
No, I didn't.

> Pragmatically, all of the logical name stuff could be re-hosted over
> onto LDAP and with minimal or no disruption, and with support for
> multiple hosts and replication added.
No, it can't.

I know you have hated logicals since you went over to the dark side, but they are the one crown jewel and none of the cheap PC implementations come close to them.

> > Many didn't take it to that level, but you could.
> Most will use parallel LDAP, if they want or need full separation.

No. We will continue to use logicals.

> These same messes can arise with OpenVMS, and this mess is unrelated to
> the underlying processor architecture.

I didn't say it was. Tiny x86 minds are the problem.

> Outside of its own non-production data, there's no reason for the test
> environment to diverge from productions, and often various good reasons
> why it should not. The more test diverges, the more time spent testing
> divergences.

Oh, there are numerous good reasons for Test != production. How else are you going to test a new OS release or patch for one.

> A combination of access controls and DNS are commonly used to direct
> clients to the appropriate servers.

Nowhere near as secure.

> That's server isolation is a fairly common preference, and independent
> of the processor architecture.

Will let this one go because earlier in this message you assumed I was talking about the processor. I was talking about the engineering mindset of VMS and all applications written for it. Simply does not exist in the x86 world.

> > I took that tiny detour to point out the level of thinking that want
> > into many/much/a-not-insignificant-part of the VMS world. People
> > actually thought about things like bifurcated terminal applications and
> > other secured communications. We have $SEVERITY with many different
> > values that qualify as $SUCCESS because the values were deemed
> > INFORMATIONAL.
> None of what you've described so far is unique to OpenVMS.

It was unique to VMS __and__ nothing on the x86 comes close. When you look around on the x86 platform for comparable things it's like looking around at the women left in a bar at closing time.

>
> Some other error reporting via error classes are far more flexible, for
> newer environments.
>
> Here's the older NSError, as an alternative to what OpenVMS does:
> https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/ErrorHandling/ErrorHandling.html
>
Real developers don't use Apple. The language of business is COBOL and those classes won't work with COBOL.

> > The one package that shoulda-woulda-coulda made a lot of sense was
> > PostgreSQL because it actually started out on VMS decades ago.
> > According to the port page
> > https://wiki.postgresql.org/wiki/OpenVMS_port
> > last updated 2012 . . .
> PostgreSQL hasn't ever supported OpenVMS. (You're probably confusing
> PostgreSQL with Ingres or some other database package which did have
> support for VAX/VMS or OpenVMS.)
>

Not confused. Some number of years ago, early in the PostgreSQL world I was exchanging emails with one of the main developers. PostgreSQL started with the Ingres code base which built on VAX. None of the x86 minds working on the port wanted to keep working on VMS. Possibly none had access to a system.

> The PostgreSQL port stalled due to shared stream I/O corruptions (SSIO)
> latent in OpenVMS, among other issues.
> VSI is reportedly addressing those corruption issues for single-host,
> non-clustered apps.
>

Long way from first time the port failed.

https://wiki.postgresql.org/images/d/d3/PGConf_2015_VAX_Lightning.pdf

Actually rather hilarious read.

> VSI does seem intent on a port of PostgreSQL. Probably as an option or
> fallback, should Oracle Rdb be delayed or unavailable or otherwise
> under- or uninteresting to VSI customers.
>
DEC screwed the pooch here back when I worked at LIOCS. They briefly were including RDB run-time but shafting the VARs royally for a Development license. As such, all of the VARs stuck with RMS indexed files for their applications. The landscape is littered with ERP, CRM, and other canned packages which could have made the jump and kept the platform relative. Now there are huge corporations trapped on systems from vendors that no longer exist. God-awful hacks got done to export "historical" data that had to be kept in the system but RMS indexed file size limits were routinely being hit. The job you would have to run once every 5-7 years became a monthly scheduled job and yes, you had to use a logical name table to keep the history file search path dynamically updated.

Oracle will squeeze the orange with RDB. If enough juice doesn't come out they will kill it. Having PostgreSQL as the standard cluster-aware ACMS-transaction-aware database installed for free and by default will go a looong way towards giving VMS a tiny remaining purpose.

> > Lack of any real desktop for VMS torpedoed adding support to a large
> > C++ framework like CopperSpice or Qt that would have hidden most of the
> > ugly OS details
> Absent massive and likely futile investments, OpenVMS on the desktop is
> and will remain uninteresting outside of the installed base, and
> outside of those few hobbyists with unusually low app expectations, and
> outside those not requiring interoperation with other common desktop
> apps and formats. Insufficient Phillips for meaningful profits.

The point is, all of the well tested USB, serial port, SQL, et-al high level application routines are in large frameworks like Qt, CopperSpice, wxWidgets, etc.

On Thursday, June 16, 2022 at 4:33:02 PM UTC-5, Arne Vajhøj wrote:
> On 6/16/2022 3:11 PM, Stephen Hoffman wrote:
> > On 2022-06-16 13:50:16 +0000, seasoned_geek said:
> >> The one package that shoulda-woulda-coulda made a lot of sense was
> > Definitely. OpenVMS app ports from Rdb to not-Rdb will involve a fair
> > amount of work, and the pre-compilers are just part of that "fun". (I'll
> > have to ponder what's involved in pre-compiler support, given LLVM-based
> > languages. LLVM integrates far better than did DEC-era compilers.)
> Pre-compilers should not be a big problem.
>
> PostgreSQL comes with an embedded SQL for C compiler.
>
> There is an open source embedded SQL for Cobol compiler.
>
> VSI got embedded SQL working for all languages for SQL Relay - and
> changing that from SQL Relay API to libpq API should not be a big
> task.
>
> But question is how relevant it is. PostgreSQL will probably
> appeal most to new application. And new applications will
> probably not use embedded SQL. Embedded SQL is a technology
> of the past.
>
> I expect to see libpq in C/C++, JDBC driver for JVM languages,
> psycopg2 module for Python, pgsql extension in PHP etc..
>

The PostgreSQLMOD needs to support, in order of priority just from my memory of what customers have:
VAX BASIC
COBOL
FORTRAN
DIBOL - which Synergy has a bunch of their own stuff now. This is running most of the currency exchanges in America and CVS.
PASCAL - as much as I hate typing that
C/C++

I probably left a couple of languages off. C/C++ has the smallest footprint.. Companies trapped on TOLAS, LIOCS Perspective, older MCBA, MAXCIM Accounting, etc. need the first two. MCBA was always COBOL if memory serves. I vaguely remember someone telling me about an early first gen that was BASIC (possibly Business BASIC) before it moved to COBOL. Those companies are already dealing with RMS indexed file limits and a litany of hacks to work around them.

In addition some large use packages will need to be updated

Datatrieve
CDD - Gee Oracle, do you want to support a database you don't make a nickel from?

On Friday, June 17, 2022 at 10:32:21 AM UTC-5, Arne Vajhøj wrote:
> On 6/17/2022 11:00 AM, Chris Townley wrote:
> > On 17/06/2022 14:33, Arne Vajhøj wrote:
> >> I like Cygwin. I have always had it on my Windows PC's for more
> >> than 2 decades. I don't use that much of it and I never use
> >> bash, but I like many of the utilities.
> > Have you looked at Windows Subsystem for Linux as an option?
> My impression is that WSL is more for people developing
> for Linux on Windows than for for Windows users
> wanting to use some *nix utilities.

It's the first cut of Microsoft Windows becoming "just a desktop" on top of Ubuntu ala Gnome, KDE, etc. Canonical and Google are moving to Fuchsia. A whole lot of YABUs will soon go away.

On 6/18/2022 11:53 AM, seasoned_geek wrote:
> On Friday, June 17, 2022 at 10:32:21 AM UTC-5, Arne Vajhøj wrote:
>> On 6/17/2022 11:00 AM, Chris Townley wrote:
>>> On 17/06/2022 14:33, Arne Vajhøj wrote:
>>>> I like Cygwin. I have always had it on my Windows PC's for more
>>>> than 2 decades. I don't use that much of it and I never use
>>>> bash, but I like many of the utilities.
>>> Have you looked at Windows Subsystem for Linux as an option?
>> My impression is that WSL is more for people developing
>> for Linux on Windows than for for Windows users
>> wanting to use some *nix utilities.
>
> It's the first cut of Microsoft Windows becoming "just a desktop" on top of Ubuntu ala Gnome, KDE, etc.

Nonsense.

WSL 1 is the exact opposite - Linux userland on top of Windows kernel.
And WSL 2 is just a VM with Linux.

> Canonical and Google are moving to Fuchsia.

Google has not said that Android will replace
Linux with Fuchsia.

There are just a lot of rumors going around.
Time will tell.

They could probably do it. If Android SDK,
Android NDK and Play Services are available, then
practically everything should work identical whether
it is Linux or Fuchsia below.

Arne

On Saturday, June 18, 2022 at 5:49:30 PM UTC-5, Arne Vajhøj wrote:
> On 6/18/2022 11:53 AM, seasoned_geek wrote:
> > On Friday, June 17, 2022 at 10:32:21 AM UTC-5, Arne Vajhøj wrote:
> >> On 6/17/2022 11:00 AM, Chris Townley wrote:
> >>> On 17/06/2022 14:33, Arne Vajhøj wrote:
> >>>> I like Cygwin. I have always had it on my Windows PC's for more
> >>>> than 2 decades. I don't use that much of it and I never use
> >>>> bash, but I like many of the utilities.
> >>> Have you looked at Windows Subsystem for Linux as an option?
> >> My impression is that WSL is more for people developing
> >> for Linux on Windows than for for Windows users
> >> wanting to use some *nix utilities.
> >
> > It's the first cut of Microsoft Windows becoming "just a desktop" on top of Ubuntu ala Gnome, KDE, etc.
> Nonsense.
>
> WSL 1 is the exact opposite - Linux userland on top of Windows kernel.
> And WSL 2 is just a VM with Linux.

Not nonsense, where they are headed. It just takes the tiny x86 minds at Microsoft a while to get there.

There are huge legal reasons for Microsoft to move in that direction especially now with all of the privacy and liability laws being enacted globally. When there is a security breach in the Linux TCP/IP stack or some other Linux kernel/component there is nobody to hold liable. When the same thing happens with Windows, Microsoft can now be held liable.

If Windows becomes "just another desktop" on top of the Linux kernel, Microsoft can only be held accountable for its portion.

Ford found this out with the Firestone incident. After blaming everyone and everything under the sun, the courts ruled "When the blue oval is on the grill, Ford is responsible for all of it."
That same level of litigation has now come to the software world.

> > Canonical and Google are moving to Fuchsia.
> Google has not said that Android will replace
> Linux with Fuchsia.
>
> There are just a lot of rumors going around.
> Time will tell.
>
> They could probably do it. If Android SDK,
> Android NDK and Play Services are available, then
> practically everything should work identical whether
> it is Linux or Fuchsia below.

No. Android is being EOL in its entirety. Android cannot be fixed. The Fuchsia phone Samsung is actively developing is pure Fuchsia using DART for the primary app language. No Android anything. No Java support what-so-ever.

https://screenrant.com/future-samsung-smartphones-might-ship-with-fuchsia-os-instead-of-android/

There are a lot more companies than Samsung adopting Fuchsia now. It's had a pretty successful pilot run on the smart speakers.

On 6/19/2022 10:37 AM, seasoned_geek wrote:
> On Saturday, June 18, 2022 at 5:49:30 PM UTC-5, Arne Vajhøj wrote:
>> On 6/18/2022 11:53 AM, seasoned_geek wrote:
>>> On Friday, June 17, 2022 at 10:32:21 AM UTC-5, Arne Vajhøj wrote:
>>>> On 6/17/2022 11:00 AM, Chris Townley wrote:
>>>>> On 17/06/2022 14:33, Arne Vajhøj wrote:
>>>>>> I like Cygwin. I have always had it on my Windows PC's for more
>>>>>> than 2 decades. I don't use that much of it and I never use
>>>>>> bash, but I like many of the utilities.
>>>>> Have you looked at Windows Subsystem for Linux as an option?
>>>> My impression is that WSL is more for people developing
>>>> for Linux on Windows than for for Windows users
>>>> wanting to use some *nix utilities.
>>>
>>> It's the first cut of Microsoft Windows becoming "just a desktop" on top of Ubuntu ala Gnome, KDE, etc.
>> Nonsense.
>>
>> WSL 1 is the exact opposite - Linux userland on top of Windows kernel.
>> And WSL 2 is just a VM with Linux.
>
> Not nonsense, where they are headed. It just takes the tiny x86 minds at Microsoft a while to get there.
>
> There are huge legal reasons for Microsoft to move in that direction
> especially now with all of the privacy and liability laws being enacted
> globally. When there is a security breach in the Linux TCP/IP stack or
> some other Linux kernel/component there is nobody to hold liable. When
> the same thing happens with Windows, Microsoft can now be held liable.
>
> If Windows becomes "just another desktop" on top of the Linux kernel, Microsoft can only be held accountable for its portion.

No MS is accountable for what they sell to customers.

> Ford found this out with the Firestone incident. After blaming
> everyone and everything under the sun, the courts ruled "When the
> blue oval is on the grill, Ford is responsible for all of it." That
> same level of litigation has now come to the software world.
Which is exactly why it would not help MS a to claim that the piece
with the bug was not written by MS.

>>> Canonical and Google are moving to Fuchsia.
>> Google has not said that Android will replace
>> Linux with Fuchsia.
>>
>> There are just a lot of rumors going around.
>> Time will tell.
>>
>> They could probably do it. If Android SDK,
>> Android NDK and Play Services are available, then
>> practically everything should work identical whether
>> it is Linux or Fuchsia below.
>
> No. Android is being EOL in its entirety. Android cannot be fixed.
> The Fuchsia phone Samsung is actively developing is pure Fuchsia using DART
> for the primary app language. No Android anything. No Java support
> what-so-ever.
>
> https://screenrant.com/future-samsung-smartphones-might-ship-with-fuchsia-os-instead-of-android/
>
> There are a lot more companies than Samsung adopting Fuchsia now.
> It's had a pretty successful pilot run on the smart speakers.
If you actually read the article then you can see that it is just
speculation.

There are always someone on the internet willing to make some
weird predictions.

A total switch from Android is very unlikely to happen.

The smartphone platform market is extremely difficult to enter.
People will not buy a smartphone without the apps they
use. And the app creators will not supply their apps for a
platform without users.

Arne

On 6/16/2022 8:15 AM, Simon Clubley wrote:
> On 2022-06-15, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2022-06-14, <pedersen@ccsscorp.com> <pedersen@ccsscorp.com> wrote:
>>> We started these discussions and exchanges a DECADE ago!!! A LOT has been
>>> discussed and a lot has happened. Many improvements have been made in the
>>> process.
>>>
>>> BUT.
>>>
>>> After thinking about the state of mind of many of us - tired, withdrawn,
>>> frustrated and detached. As well as my own commitments to work and family,
>>> I have come to the conclusion that we should all take a break from the
>>> conference calls and focus on ourselves and when there is time work to get
>>> some progress on the various Open Source projects we have been championing.
>>>
>>
>> That makes perfect sense - it's been clear for quite some time that the
>> current meetings have been a case of "going through the motions".
>>
>> Enjoy your well-earned break. I suspect that as September gets closer,
>> you will probably still feel the same way and that sometime next year
>> will be a more realistic goal for restarting the meetings (if you still
>> feel like you want to do so after having had the chance to reflect).
>>
>> In any case, thanks to you and others for your open source efforts on VMS.
>>
>
> I am surprised that no-one else has offered any comments about this or
> about how they see, at a technical level, the best way forward for
> porting open source software to VMS.
>
> Simon.
>

That supposes that one would want some Unixy software.

For me, it would all mostly be written in C, or worse (if that is possible) and
I don't do C.

My attitude is, if I want something, I'll design and write it. Or I'd use an
existing design, and write it.

Yes, if one is using VMS, then one is already using some of "that stuff".

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-06-19, Dave Froble <davef@tsoft-inc.com> wrote:
>
> That supposes that one would want some Unixy software.
>

That Unixy software can be a lot more functional than the VMS version
(that is, if the VMS version even exists).

Simon.

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

On Sunday, June 19, 2022 at 1:50:47 PM UTC-5, Arne Vajhøj wrote:
> On 6/19/2022 10:37 AM, seasoned_geek wrote:
> > On Saturday, June 18, 2022 at 5:49:30 PM UTC-5, Arne Vajhøj wrote:
> >> On 6/18/2022 11:53 AM, seasoned_geek wrote:
> >>> On Friday, June 17, 2022 at 10:32:21 AM UTC-5, Arne Vajhøj wrote:
> >>>> On 6/17/2022 11:00 AM, Chris Townley wrote:
> >>>>> On 17/06/2022 14:33, Arne Vajhøj wrote:
> > Not nonsense, where they are headed. It just takes the tiny x86 minds at Microsoft a while to get there.
> >
> > There are huge legal reasons for Microsoft to move in that direction
> > especially now with all of the privacy and liability laws being enacted
> > globally. When there is a security breach in the Linux TCP/IP stack or
> > some other Linux kernel/component there is nobody to hold liable. When
> > the same thing happens with Windows, Microsoft can now be held liable.
> >
> > If Windows becomes "just another desktop" on top of the Linux kernel, Microsoft can only be held accountable for its portion.
> No MS is accountable for what they sell to customers.

This shows just how little you know.

The __purchased__ item is the Windows desktop and it runs on the free Linux distro of your choice. Microsoft and Windows are no longer liable for any network breaches because 100% of the network code is OpenSource Linux which they have no control over per the license agreement.

> > Ford found this out with the Firestone incident. After blaming
> > everyone and everything under the sun, the courts ruled "When the
> > blue oval is on the grill, Ford is responsible for all of it." That
> > same level of litigation has now come to the software world.
> Which is exactly why it would not help MS a to claim that the piece
> with the bug was not written by MS.

Again, showing how little you know.

Ford sold a complete vehicle with a blue oval on the grill.

Microsoft is going to sell a Windows Desktop that installs on the Linux of your choice, just like KDE, Gnome, etc.

> >> They could probably do it. If Android SDK,
> >> Android NDK and Play Services are available, then
> >> practically everything should work identical whether
> >> it is Linux or Fuchsia below.
> >
> > No. Android is being EOL in its entirety. Android cannot be fixed.
> > The Fuchsia phone Samsung is actively developing is pure Fuchsia using DART
> > for the primary app language. No Android anything. No Java support
> > what-so-ever.
> >
> > https://screenrant.com/future-samsung-smartphones-might-ship-with-fuchsia-os-instead-of-android/
> >
> > There are a lot more companies than Samsung adopting Fuchsia now.
> > It's had a pretty successful pilot run on the smart speakers.
> If you actually read the article then you can see that it is just
> speculation.
>
> There are always someone on the internet willing to make some
> weird predictions.
>
> A total switch from Android is very unlikely to happen.
>
> The smartphone platform market is extremely difficult to enter.
> People will not buy a smartphone without the apps they
> use. And the app creators will not supply their apps for a
> platform without users.

That's exactly what people who know nothing said about Apple each and every time it completely abandoned a platform.
So far, everyone I know that does phone apps and used to use QT has jumped to Dart. They are writing their apps using Dart on Fuchsia. The legacy Android platform has some Dart support so the apps kind of run there. To counter your point, there already is a large supply of Fuchsia apps, they are simply waiting on the Samsung phone and a Fuchsia specific "store"
> Arne

In article <4ae4de33-ba0d-403a-83a0-3959ce51076fn@googlegroups.com>,
roland@logikalsolutions.com (seasoned_geek) wrote:

> So far, everyone I know that does phone apps and used to use QT
> has jumped to Dart. They are writing their apps using Dart on
> Fuchsia.

How many organisations and apps is that? Qt hasn't exactly dominated UI
in smartphone apps AFAIK.

> Microsoft is going to sell a Windows Desktop that installs on the
> Linux of your choice, just like KDE, Gnome, etc.

Will it run existing Windows programs? Doing that requires having a large
fraction of the Windows OS, over and above the desktop.

John

On 7/3/22 10:55, John Dallman wrote:
> In article <4ae4de33-ba0d-403a-83a0-3959ce51076fn@googlegroups.com>,
> roland@logikalsolutions.com (seasoned_geek) wrote:
>
>> So far, everyone I know that does phone apps and used to use QT
>> has jumped to Dart. They are writing their apps using Dart on
>> Fuchsia.
>
> How many organisations and apps is that? Qt hasn't exactly dominated UI
> in smartphone apps AFAIK.
>
>> Microsoft is going to sell a Windows Desktop that installs on the
>> Linux of your choice, just like KDE, Gnome, etc.

We had a window manager that imitated Windows back in the good
old days, FVWM95. It was never popular and while FVWM appears
to still be around the Windos95 flavor does not.
>
> Will it run existing Windows programs? Doing that requires having a large
> fraction of the Windows OS, over and above the desktop.

Windows managers don't run anything.

bill