• Re: VMS previous DEC/CPQ/HP[E] decisions and paths

    From Craig A. Berry@craigberry@nospam.mac.com to comp.os.vms on Wed Oct 15 15:33:20 2025
    From Newsgroup: comp.os.vms


    On 10/15/25 7:16 AM, Dan Cross wrote:
    In article <10cmovf$3a740$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/13/2025 10:03 PM, Lawrence DrCOOliveiro wrote:
    On Mon, 13 Oct 2025 21:20:43 -0400, Arne Vajh|+j wrote:
    On 10/13/2025 8:20 PM, Lawrence DrCOOliveiro wrote:
    On Mon, 13 Oct 2025 19:26:56 -0400, Arne Vajh|+j wrote:
    Enterprises with a need to document support can not just hire a
    random consultant when the need arrive.

    If something is mission-critical and core to their entire business,
    they want a staff they can rely on, completely, to manage that
    properly.

    Few/no CIO's want to support the hundreds of millions of lines
    of open source code their business rely on themselves.

    The whole point of having all that code is that they didnrCOt need to write >>> it themselves.

    Yes. But they want free beer more than free speech.

    You have to take responsibility for your own business, donrCOt you?

    They don't want to write or maintain their own OS.

    They don't want to write or maintain their own platform
    software (web/app servers, database servers, message queue
    servers, cache servers etc.).

    They don't want to write or maintain their own tools
    (compilers, build tools, IDE's, source control, unit
    test frameworks etc.).

    None of that stuff is their business.

    They want to focus on their business the applications
    that help them produce and sell whatever products
    or services.

    Every single one of the FAANG companies do all of those things.

    In other words, hardly anyone.

    At Google, we used to joke that, "not only does Google reinvent
    the wheel, we vulcanize the rubber for the tires." Spanner, Piper/Fig/Jujutsu, Prodkernel/ChromeOS/Android, CitC, gunit, Go
    (not to mention the work on LLVM/Clang), Blaze/Bazel/Skylark,
    etc, are all examples of the things you mentioned above. And
    that's not even to mention all the custom hardware.

    For organizations working at hyperscale, there comes a point
    where the off-the-shelf solutions simply cannot scale to meet
    the load you're putting on them.

    At that point, you have no choice but to do it yourself.
    You're kinda going in circles here by arguing that very big companies
    whose business is to make their own technology need to make their own technology. I believe Arne's point was the fairly obvious one that a
    retail chain or a hospital chain does not need to and cannot afford to maintain, for example, their own operating system.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Wed Oct 15 23:01:44 2025
    From Newsgroup: comp.os.vms

    On Wed, 15 Oct 2025 15:33:20 -0500, Craig A. Berry wrote:

    I believe Arne's point was the fairly obvious one that a retail
    chain or a hospital chain does not need to and cannot afford to
    maintain, for example, their own operating system.

    Do you think that is hard to do?
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Wed Oct 15 19:40:51 2025
    From Newsgroup: comp.os.vms

    On 10/15/2025 7:01 PM, Lawrence DrCOOliveiro wrote:
    On Wed, 15 Oct 2025 15:33:20 -0500, Craig A. Berry wrote:
    I believe Arne's point was the fairly obvious one that a retail
    chain or a hospital chain does not need to and cannot afford to
    maintain, for example, their own operating system.

    Do you think that is hard to do?

    Clone an existing distro and change name and logo: easy.

    Hire a couple of "experts" that in case of a problem
    can post on the internet and hope somebody else can
    come up with a fix and then apply the fix: easy.

    Hire a couple of "experts" that know C and
    in case of a problem plan to start read code
    and hope they will be able to find a solution: easy.

    Hire enough experts to have people that know
    the code base of every critical part: Linux
    kernel, glibc etc. probably 50-100 million
    lines of code: bloody expensive. We are talking
    hundreds engineers - and not just any engineers
    but top engineers.

    Redhat, Canonical, SUSE etc. have them.

    Amazon, Microsoft, Google etc. have them.

    The vast majority of companies don't have them.

    Arne



    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Wed Oct 15 19:55:28 2025
    From Newsgroup: comp.os.vms

    On 10/15/2025 8:16 AM, Dan Cross wrote:
    In article <10cmovf$3a740$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/13/2025 10:03 PM, Lawrence DrCOOliveiro wrote:
    On Mon, 13 Oct 2025 21:20:43 -0400, Arne Vajh|+j wrote:
    Few/no CIO's want to support the hundreds of millions of lines
    of open source code their business rely on themselves.

    The whole point of having all that code is that they didnrCOt need to write >>> it themselves.

    Yes. But they want free beer more than free speech.

    You have to take responsibility for your own business, donrCOt you?

    They don't want to write or maintain their own OS.

    They don't want to write or maintain their own platform
    software (web/app servers, database servers, message queue
    servers, cache servers etc.).

    They don't want to write or maintain their own tools
    (compilers, build tools, IDE's, source control, unit
    test frameworks etc.).

    None of that stuff is their business.

    They want to focus on their business the applications
    that help them produce and sell whatever products
    or services.

    Every single one of the FAANG companies do all of those things.
    At Google, we used to joke that, "not only does Google reinvent
    the wheel, we vulcanize the rubber for the tires." Spanner, Piper/Fig/Jujutsu, Prodkernel/ChromeOS/Android, CitC, gunit, Go
    (not to mention the work on LLVM/Clang), Blaze/Bazel/Skylark,
    etc, are all examples of the things you mentioned above. And
    that's not even to mention all the custom hardware.

    For organizations working at hyperscale, there comes a point
    where the off-the-shelf solutions simply cannot scale to meet
    the load you're putting on them.

    At that point, you have no choice but to do it yourself.
    Few companies are like Google.

    For a few reasons:

    1) As you mention they may have special customization needs
    due to their scale.

    2) But even if they did not need that, then their numbers
    are special. If cost of creating a competent Linux team
    that can deliver support at Redhat level is less than
    number of Linux instances multiplied with what Redhat
    would charge per instance (and I am sure that Google would
    get a gigantic discount if they asked), then it makes
    financial sense to DIY. But it requires a huge number
    of Linux instances.

    My napkin calculation / RNG says you will need more
    than a million Linux instances for the math to work.
    Google has that. Most companies does not.

    3) Google is not just a company using IT to produce
    products/services - Google is also a company doing
    IT for other.

    Google Search is an IT user where it is not a given
    that they want their own distro.

    But Android and ChromeOS is Google delivering an
    OS to other. The OS is their business in that case.

    And one facet of GCP is that Google is taking
    over OS support from Redhat/Canonical/SUSE when
    companies moves their workload from on-prem to
    GCP managed services. Linux support is their
    business.

    Arne




    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Wed Oct 15 19:59:39 2025
    From Newsgroup: comp.os.vms

    On 10/15/2025 7:58 AM, Dan Cross wrote:
    In article <memo.20251014170713.10624x@jgd.cix.co.uk>,
    John Dallman <jgd@cix.co.uk> wrote:
    In article <10ckadi$7dr$1@reader2.panix.com>,
    cross@spitfire.i.gajendra.net (Dan Cross) wrote:
    In article <memo.20251011151314.10624m@jgd.cix.co.uk>,
    John Dallman <jgd@cix.co.uk> wrote:
    Our stuff does gain significantly from 64-bit addressing; I could
    believe fields that didn't need 64-bit gave up on Sun earlier.

    I can see that. Personally, I really liked Tru64 nee DEC Unix

    Compaq Tru64, Digital Unix, DEC OSF/1.

    nee OSF/1 AXP on Alpha. OSF/1 felt like it was a much better
    system overall if one had to go if swimming in Unix waters,
    while Solaris felt underbaked.

    I was happy with it, but a very experienced Unix chap of my acquaintance
    reckoned "It doesn't run - it just lurches!" regarding it as a
    Frankenstein job of parts stitched together.

    Ha! I can sort of see why they'd say that. It definitely had
    odd bits of Mach and System V seemingly bolted onto it. Overall
    though I thought it was a good system.

    To bring it back to VMS (and sheepishly admit a good bunch of
    the recent drift is my own) We had an Alpha running OpenVMS AXP
    1.2, or whatever one of the earlier versions was;

    Probably 1.5.

    VMS Alpha went 1.0 -> 1.5 -> 6.1.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Thu Oct 16 00:26:10 2025
    From Newsgroup: comp.os.vms

    In article <10cpc9g$191j$2@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 8:16 AM, Dan Cross wrote:
    In article <10cmovf$3a740$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/13/2025 10:03 PM, Lawrence DrCOOliveiro wrote:
    On Mon, 13 Oct 2025 21:20:43 -0400, Arne Vajh|+j wrote:
    Few/no CIO's want to support the hundreds of millions of lines
    of open source code their business rely on themselves.

    The whole point of having all that code is that they didnrCOt need to write
    it themselves.

    Yes. But they want free beer more than free speech.

    You have to take responsibility for your own business, donrCOt you?

    They don't want to write or maintain their own OS.

    They don't want to write or maintain their own platform
    software (web/app servers, database servers, message queue
    servers, cache servers etc.).

    They don't want to write or maintain their own tools
    (compilers, build tools, IDE's, source control, unit
    test frameworks etc.).

    None of that stuff is their business.

    They want to focus on their business the applications
    that help them produce and sell whatever products
    or services.

    Every single one of the FAANG companies do all of those things.
    At Google, we used to joke that, "not only does Google reinvent
    the wheel, we vulcanize the rubber for the tires." Spanner,
    Piper/Fig/Jujutsu, Prodkernel/ChromeOS/Android, CitC, gunit, Go
    (not to mention the work on LLVM/Clang), Blaze/Bazel/Skylark,
    etc, are all examples of the things you mentioned above. And
    that's not even to mention all the custom hardware.

    For organizations working at hyperscale, there comes a point
    where the off-the-shelf solutions simply cannot scale to meet
    the load you're putting on them.

    At that point, you have no choice but to do it yourself.

    Few companies are like Google.

    Yup.

    For a few reasons:
    [snip]

    3) Google is not just a company using IT to produce
    products/services - Google is also a company doing
    IT for other.

    Google Search is an IT user where it is not a given
    that they want their own distro.

    Actually, a disproportionate amount of kernel effort was put
    into place specifically for search, but there is a dedicated
    team that does kernel work for production specifically.

    Internal Google IT, i.e. the people who staff the helpdesk and
    manage desktop workstations, provision laptops, and so on, had
    their own Linux distro that was based on Debian, and (mostly)
    unrelated to the production OS. They did almost no kernel work,
    however.

    But Android and ChromeOS is Google delivering an
    OS to other. The OS is their business in that case.

    And one facet of GCP is that Google is taking
    over OS support from Redhat/Canonical/SUSE when
    companies moves their workload from on-prem to
    GCP managed services. Linux support is their
    business.

    Do you mean ContainerOS? That's just a distro.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Thu Oct 16 00:28:09 2025
    From Newsgroup: comp.os.vms

    On Wed, 15 Oct 2025 19:55:28 -0400, Arne Vajh|+j wrote:

    My napkin calculation / RNG says you will need more than a million
    Linux instances for the math to work. Google has that. Most
    companies does not.

    <https://linuxfromscratch.org/>
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Wed Oct 15 20:30:48 2025
    From Newsgroup: comp.os.vms

    On 10/15/2025 7:58 AM, Dan Cross wrote:
    In article <memo.20251014170713.10624x@jgd.cix.co.uk>,
    John Dallman <jgd@cix.co.uk> wrote:
    In article <10ckadi$7dr$1@reader2.panix.com>,
    cross@spitfire.i.gajendra.net (Dan Cross) wrote:
    I never quite got the business play behind Java from Sun's
    perspective. It seemed to explode in popularity overnight, but
    they never quite figured out how to monetize it; I remember
    hearing from some Sun folks that they wanted to set standards
    and be at the center of the ecosystem, but were content to let
    other players actually build the production infrastructure.

    The trick with monetising something like that is to price it so that
    customers find it far cheaper to pay than to write their own. However,
    you still need to be able to make money on it. I've seen this done with a
    sliding royalty scale.

    However, this kind of scheme definitely would have clashed with the
    desire Sun had to make Java a standard piece of client software. It may
    have been doomed to unprofitability by the enthusiasm of its creators.

    I think that's a really insightful way to put it.

    My sense was that they overplayed their hand, and did so
    prematurely relative to the actual value they were holding onto.

    I mentioned Microsoft and Java on the client side: I believe
    that they were largely responsible for failure of Java desktop
    applications (and the supporting ecosystem) to take root. As I
    recall, at the time, MSFT tried to license Java from Sun: Sun
    said no, and I'm quite sure that McNealy was positively giddy
    about it as well. However, I think in doing so, Sun gravely
    underestimated Gates-era MSFT, because then Microsoft very
    publicly said, "we're going to wait and see whether the industry
    adopts Java on the desktop." But, since Microsoft was the
    biggest player in that space, the rest of the industy waited to
    see what Microsoft would do and whether they would support it on
    Windows: the result was that Java no one adopted it, and so it
    never saw widespread client-side adoption.

    Not quite what happened.

    Sun did license Java to MS.

    But MS violated license condition and their J++ had a couple
    of incompatibilities (they replaced JNI with something better
    and they replaced RMI with COM that fitted better with Windows).

    Sun sued and MS had to pay 20 M$ (peanuts for MS) and ditch the product.

    So MS ditched their Java and Sun delivered Java to Windows
    users that wanted it. And in the early 00's that was most Windows
    users, because everybody needed applet support in their browsers.

    Until applets died out and Java stopped being needed/wanted
    by most ordinary users.

    And the world changed and in recent years MS created their
    own Java again based on OpenJDK.

    Oh sure, it had some
    adoption in mobile phone type applications, but util Android
    (which tried to skirt the licensing issues with Dalvik) that
    was pretty limited.

    Almost all the 3 millions apps available for the 3 billion
    Android phones are written in Java or Kotlin. Not particular limited.

    Anyway, while Microsoft stalled, they did
    C# in the background, and when it was ready, they no longer had
    any real need for Java on the client side.

    MS started .NET and C# after they were forced to drop their
    Java.

    Anders Hejlsberg was actually headhunted from Borland to
    do MS Java. And when that was no longer a thing he moved
    on to creating .NET and C#.

    The framing that the web rendered Java on desktops obsolete is
    incomplete. Certainly, that was true for _many_ applications,
    as the web rendered much of the client-side ecosystem obsolete,
    but consider things in Microsoft's portfolio like Word, Except,
    PowerPoint, and so on. Those remained solidly desktop focused
    until 360;

    What moved to web in the early 00's were all the internal
    business app frontends. The stuff that used to be done on
    VB6, Delphi, Jyacc etc..

    Mostly trivial stuff but millions of applications requiring
    millions of developers.

    MS Office and other MSVC++ MFC apps may have been difficult to
    port to web at the time, but it would also have been difficult
    to come up with a business case for it - that first showed up
    when MS had a cloud and could charge customer per user per month
    for it.

    one never saw credible competitors to that in Java,
    which was something Sun very much wanted (recall McNealy's
    writing at this time about a "new" style of development based
    around open source and Java).

    OpenOffice owned by Sun at the time actually did implement
    some stuff in Java.

    But neither as OpenOffice as office package nor Java as language
    for desktop apps ever took off.

    Similarly, investment in C# shows
    that they weren't quite ready to move everything to the web;

    ????

    One of the main areas for C# is web applications ASP.NET and
    was so from day 1.

    (not everybody may like ASP.NET web forms, but that is
    another discussion)

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Thu Oct 16 00:31:33 2025
    From Newsgroup: comp.os.vms

    On Wed, 15 Oct 2025 19:40:51 -0400, Arne Vajh|+j wrote:

    On 10/15/2025 7:01 PM, Lawrence DrCOOliveiro wrote:

    On Wed, 15 Oct 2025 15:33:20 -0500, Craig A. Berry wrote:

    I believe Arne's point was the fairly obvious one that a retail chain
    or a hospital chain does not need to and cannot afford to maintain,
    for example, their own operating system.

    Do you think that is hard to do?

    Hire enough experts to have people that know the code base of every
    critical part: Linux kernel, glibc etc. probably 50-100 million lines of code: bloody expensive. We are talking hundreds engineers - and not just
    any engineers but top engineers.

    When the Raspberry Pi was first released, there was a Debian version
    available for it, but it was not optimized for the PirCOs unusual
    combination of hardware floating point + an older version of the ARM instruction set.

    Two guys decided to take it upon themselves to rebuild the whole of
    Debian, from source, optimized for the Pi hardware. It took them six
    weeks.

    They called their distro rCLRaspbianrCY. These days I think the Raspberry Pi foundation has taken on official support for it, and are calling it rCLRaspberry Pi OSrCY.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Wed Oct 15 20:40:42 2025
    From Newsgroup: comp.os.vms

    On 10/15/2025 8:26 PM, Dan Cross wrote:
    In article <10cpc9g$191j$2@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    And one facet of GCP is that Google is taking
    over OS support from Redhat/Canonical/SUSE when
    companies moves their workload from on-prem to
    GCP managed services. Linux support is their
    business.

    Do you mean ContainerOS? That's just a distro.

    I am talking about that like 10 years ago a company
    would run like:

    their application + their database server
    RHEL [paying Redhat for Linux support]
    ESXi
    on-prem HW

    but now they may run as (assuming Google customer):

    their application in GKE + database as GCP managed service
    whatever Linux Google want to use [paying Google for Linux support as
    part of what they pay for the cloud services]
    Linux with KVM
    Google HW

    Amazon, Microsoft and Google are taking revenue away
    from Redhat (IBM). They have de facto gotten into
    the Linux support business.

    Arne



    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Thu Oct 16 00:43:51 2025
    From Newsgroup: comp.os.vms

    In article <10cp0eg$3tqik$1@dont-email.me>,
    Craig A. Berry <craigberry@nospam.mac.com> wrote:
    On 10/15/25 7:16 AM, Dan Cross wrote:
    In article <10cmovf$3a740$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/13/2025 10:03 PM, Lawrence DrCOOliveiro wrote:
    On Mon, 13 Oct 2025 21:20:43 -0400, Arne Vajh|+j wrote:
    On 10/13/2025 8:20 PM, Lawrence DrCOOliveiro wrote:
    On Mon, 13 Oct 2025 19:26:56 -0400, Arne Vajh|+j wrote:
    Enterprises with a need to document support can not just hire a
    random consultant when the need arrive.

    If something is mission-critical and core to their entire business, >>>>>> they want a staff they can rely on, completely, to manage that
    properly.

    Few/no CIO's want to support the hundreds of millions of lines
    of open source code their business rely on themselves.

    The whole point of having all that code is that they didnrCOt need to write
    it themselves.

    Yes. But they want free beer more than free speech.

    You have to take responsibility for your own business, donrCOt you?

    They don't want to write or maintain their own OS.

    They don't want to write or maintain their own platform
    software (web/app servers, database servers, message queue
    servers, cache servers etc.).

    They don't want to write or maintain their own tools
    (compilers, build tools, IDE's, source control, unit
    test frameworks etc.).

    None of that stuff is their business.

    They want to focus on their business the applications
    that help them produce and sell whatever products
    or services.

    Every single one of the FAANG companies do all of those things.

    In other words, hardly anyone.

    I wonder what percentage of professional software engineers work
    or have worked at one of those companies at this point.

    But Arne's statements were categorical and near absolute. "They
    don't..." "Few/no..." "None of that is their business...", and
    so on. It wasn't Meta's business to do any of that stuf,
    either, until they reached a point where they had to.

    At Google, we used to joke that, "not only does Google reinvent
    the wheel, we vulcanize the rubber for the tires." Spanner,
    Piper/Fig/Jujutsu, Prodkernel/ChromeOS/Android, CitC, gunit, Go
    (not to mention the work on LLVM/Clang), Blaze/Bazel/Skylark,
    etc, are all examples of the things you mentioned above. And
    that's not even to mention all the custom hardware.

    For organizations working at hyperscale, there comes a point
    where the off-the-shelf solutions simply cannot scale to meet
    the load you're putting on them.

    At that point, you have no choice but to do it yourself.

    You're kinda going in circles here by arguing that very big companies
    whose business is to make their own technology need to make their own >technology.

    Really? I thought I was providing a counter-example to Arne's
    assertions.

    And none of those companies started out big; with the exception
    of Apple and Microsoft, which both started at the dawn of the
    personal computer era, it was not part of the mission for
    Google, Meta, Amazon, Netflix, etc, to do any of the things that
    Arne mentioned most organizations don't want to do. The FAANGs
    didn't want to do them, either, honestly, but they do so out of
    business necessity, which is the point: most companies don't
    have to do those things because they never reach the point where
    it's required. That's not necessarily a feature.

    It's an oversimplifictation to assert that people and businesses
    won't do the things that are essential to their core business;
    history shows that they can and will---once it actually becomes
    a necessity.

    I believe Arne's point was the fairly obvious one that a
    retail chain or a hospital chain does not need to and cannot afford to >maintain, for example, their own operating system.

    Of course, but those aren't technology companies. Most farmers
    don't need to maintain their own OS either, though I know at
    least two who do just for fun. But just saying that most child
    daycare centers don't need their own in-house IT stack is a non
    sequitur, because they're not reliant on their technical
    infrastructure the way that organizations for which it is
    essential are.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Thu Oct 16 00:51:43 2025
    From Newsgroup: comp.os.vms

    In article <10cpeu9$26ht$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 8:26 PM, Dan Cross wrote:
    In article <10cpc9g$191j$2@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    And one facet of GCP is that Google is taking
    over OS support from Redhat/Canonical/SUSE when
    companies moves their workload from on-prem to
    GCP managed services. Linux support is their
    business.

    Do you mean ContainerOS? That's just a distro.

    I am talking about that like 10 years ago a company
    would run like:

    their application + their database server
    RHEL [paying Redhat for Linux support]
    ESXi
    on-prem HW

    but now they may run as (assuming Google customer):

    their application in GKE + database as GCP managed service
    whatever Linux Google want to use [paying Google for Linux support as
    part of what they pay for the cloud services]
    Linux with KVM
    Google HW

    Not quite how the stack is structured.

    Amazon, Microsoft and Google are taking revenue away
    from Redhat (IBM). They have de facto gotten into
    the Linux support business.

    Not really. They're taking revenue away from Broadcom/VMWare,
    perhaps, and probably from Dell, HPE, and Lenovo. But if you
    want to run RHEL on a VM on Google's cloud, they won't stop you. https://cloud.google.com/compute/docs/images/os-details

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Thu Oct 16 01:01:52 2025
    From Newsgroup: comp.os.vms

    In article <10cpebq$26b5$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 7:58 AM, Dan Cross wrote:
    [snip]
    Oh sure, it had some
    adoption in mobile phone type applications, but util Android
    (which tried to skirt the licensing issues with Dalvik) that
    was pretty limited.

    Almost all the 3 millions apps available for the 3 billion
    Android phones are written in Java or Kotlin. Not particular limited.

    ...but not running on the JVM or using the JRE.

    Anyway, while Microsoft stalled, they did
    C# in the background, and when it was ready, they no longer had
    any real need for Java on the client side.

    MS started .NET and C# after they were forced to drop their
    Java.

    Be careful: it is precisely this forcing event that I am
    referring to. Could MSFT have come into compliance with the
    Java licensing terms instead of doing C#? I'm quite sure they
    could have, but this was the era of MSFT "Embrace and Extend",
    where they'd de facto take over a standard ("embrace") and make
    their extended version the de facto standard ("extend"). Sun
    very much did not want to let them do that to Java, and did not.

    Anders Hejlsberg was actually headhunted from Borland to
    do MS Java. And when that was no longer a thing he moved
    on to creating .NET and C#.

    See above.

    The framing that the web rendered Java on desktops obsolete is
    incomplete. Certainly, that was true for _many_ applications,
    as the web rendered much of the client-side ecosystem obsolete,
    but consider things in Microsoft's portfolio like Word, Except,
    PowerPoint, and so on. Those remained solidly desktop focused
    until 360;

    What moved to web in the early 00's were all the internal
    business app frontends. The stuff that used to be done on
    VB6, Delphi, Jyacc etc..

    Mostly trivial stuff but millions of applications requiring
    millions of developers.

    MS Office and other MSVC++ MFC apps may have been difficult to
    port to web at the time, but it would also have been difficult
    to come up with a business case for it - that first showed up
    when MS had a cloud and could charge customer per user per month
    for it.

    They didn't need a "cloud": they needed a large, Internet-scale
    server architecture and data center presence, and they had such
    things pretty quickly: remember when they bought Hotmail?

    They could have easily charged subscription fees.

    one never saw credible competitors to that in Java,
    which was something Sun very much wanted (recall McNealy's
    writing at this time about a "new" style of development based
    around open source and Java).

    OpenOffice owned by Sun at the time actually did implement
    some stuff in Java.

    Right. So no credible competitors.

    But neither as OpenOffice as office package nor Java as language
    for desktop apps ever took off.

    Similarly, investment in C# shows
    that they weren't quite ready to move everything to the web;

    ????

    The whole point of CLR languages on Windows desktops is that
    they run locally.

    One of the main areas for C# is web applications ASP.NET and
    was so from day 1.

    (not everybody may like ASP.NET web forms, but that is
    another discussion)

    I'm not saying it wasn't a use-case; I'm saying that investing
    in the client-side infrastructure to be able to write rich
    applications that run locally shows that they weren't ready,
    organizationally, business-wise, or technologically, to move
    everything to the web.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Thu Oct 16 08:18:26 2025
    From Newsgroup: comp.os.vms

    On 10/15/2025 8:51 PM, Dan Cross wrote:
    In article <10cpeu9$26ht$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 8:26 PM, Dan Cross wrote:
    In article <10cpc9g$191j$2@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    And one facet of GCP is that Google is taking
    over OS support from Redhat/Canonical/SUSE when
    companies moves their workload from on-prem to
    GCP managed services. Linux support is their
    business.

    Do you mean ContainerOS? That's just a distro.

    I am talking about that like 10 years ago a company
    would run like:

    their application + their database server
    RHEL [paying Redhat for Linux support]
    ESXi
    on-prem HW

    but now they may run as (assuming Google customer):

    their application in GKE + database as GCP managed service
    ^^^ ^^^^^^^^^^^^^^^>>
    whatever Linux Google want to use [paying Google for Linux support as
    part of what they pay for the cloud services]
    Linux with KVM
    Google HW

    Not quite how the stack is structured.

    Amazon, Microsoft and Google are taking revenue away
    from Redhat (IBM). They have de facto gotten into
    the Linux support business.

    Not really. They're taking revenue away from Broadcom/VMWare,
    perhaps, and probably from Dell, HPE, and Lenovo. But if you
    want to run RHEL on a VM on Google's cloud, they won't stop you. https://cloud.google.com/compute/docs/images/os-details

    If someone has a strong desire to do cloud like they did 10
    years ago, then buying GCE instances, installing RHEL,
    installing OpenShift, installing database, installing
    application and manage everything is certainly still an option.

    But I was very explicit above talking about managed services.
    Managed Kubernetes and managed database. GKE not GCE.

    Again I wonder if you read what you are replying to.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Thu Oct 16 09:24:26 2025
    From Newsgroup: comp.os.vms

    On 10/15/2025 9:01 PM, Dan Cross wrote:
    In article <10cpebq$26b5$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 7:58 AM, Dan Cross wrote:
    [snip]
    Oh sure, it had some
    adoption in mobile phone type applications, but util Android
    (which tried to skirt the licensing issues with Dalvik) that
    was pretty limited.

    Almost all the 3 millions apps available for the 3 billion
    Android phones are written in Java or Kotlin. Not particular limited.

    ...but not running on the JVM or using the JRE.

    True.

    But the difference is not that big.

    A) library

    Mostly:

    Android SDK =
    standard Java library
    - desktop GUI (Swing)
    + Android GUI
    + phone stuff

    So the Java developer need to learn a new GUI (but few will
    miss Swing) and learn some phone specific API's (which
    is sort of unavoidable).

    But mostly the usual API. Which was the core of Oracle's
    lawsuit against Google.

    They can use most of the third party Java libraries that they
    know from elsewhere. If they make sense on a phone and are
    not too heavy.

    B) VM

    It is different:

    Java source
    --(javac)-->
    Java byte code (stack based)

    JVM

    (Hotspot JVM is JIT only, GraalVM is JIT or AOT, J9 is JIT with
    cache between runs which result in some sort of AOT)

    vs

    Java source
    --(javac)-->
    Java byte code (stack based)
    --(Android tool)-->
    Android byte code (register based)

    Android VM

    (Dalvik in Android 2-4 is JIT, ART in Android 5-6 i AOT,
    ART in Android 7- is a hybrid between AOT and JIT)

    And while I am sure the different byte code formats and
    AOT vs JIT can create very heated arguments among VM writers,
    then the average Java developer does not care. They write their
    Java code, they compile it with javac and then it gets deployed
    and it somehow runs.

    Arne




    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Thu Oct 16 17:06:54 2025
    From Newsgroup: comp.os.vms

    In article <10cqrma$c7a9$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 9:01 PM, Dan Cross wrote:
    In article <10cpebq$26b5$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 7:58 AM, Dan Cross wrote:
    [snip]
    Oh sure, it had some
    adoption in mobile phone type applications, but util Android
    (which tried to skirt the licensing issues with Dalvik) that
    was pretty limited.

    Almost all the 3 millions apps available for the 3 billion
    Android phones are written in Java or Kotlin. Not particular limited.

    ...but not running on the JVM or using the JRE.

    True.

    But the difference is not that big.
    [snip]

    ...anyway, the point I was making earlier was that Java never
    achieved widespread adoption on the desktop.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Thu Oct 16 17:18:45 2025
    From Newsgroup: comp.os.vms

    In article <10cqnqi$c7a8$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 8:51 PM, Dan Cross wrote:
    In article <10cpeu9$26ht$1@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    On 10/15/2025 8:26 PM, Dan Cross wrote:
    In article <10cpc9g$191j$2@dont-email.me>,
    Arne Vajh|+j <arne@vajhoej.dk> wrote:
    And one facet of GCP is that Google is taking
    over OS support from Redhat/Canonical/SUSE when
    companies moves their workload from on-prem to
    GCP managed services. Linux support is their
    business.

    Do you mean ContainerOS? That's just a distro.

    I am talking about that like 10 years ago a company
    would run like:

    their application + their database server
    RHEL [paying Redhat for Linux support]
    ESXi
    on-prem HW

    but now they may run as (assuming Google customer):

    their application in GKE + database as GCP managed service
    ^^^ ^^^^^^^^^^^^^^^>>
    whatever Linux Google want to use [paying Google for Linux support as
    part of what they pay for the cloud services]
    Linux with KVM
    Google HW

    Not quite how the stack is structured.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Amazon, Microsoft and Google are taking revenue away
    from Redhat (IBM). They have de facto gotten into
    the Linux support business.

    Not really. They're taking revenue away from Broadcom/VMWare,
    perhaps, and probably from Dell, HPE, and Lenovo. But if you
    want to run RHEL on a VM on Google's cloud, they won't stop you.
    https://cloud.google.com/compute/docs/images/os-details

    If someone has a strong desire to do cloud like they did 10
    years ago, then buying GCE instances, installing RHEL,
    installing OpenShift, installing database, installing
    application and manage everything is certainly still an option.

    But I was very explicit above talking about managed services.
    Managed Kubernetes and managed database. GKE not GCE.

    Have you ever used any GCP services?

    Again I wonder if you read what you are replying to.

    Did you?

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From jgd@jgd@cix.co.uk (John Dallman) to comp.os.vms on Sat Oct 18 14:19:40 2025
    From Newsgroup: comp.os.vms

    In article <10co28b$isl$1@reader2.panix.com>,
    cross@spitfire.i.gajendra.net (Dan Cross) wrote:

    I've said this before in this group, but the homogeneity of
    modern computing does not strike me as a universally good thing.
    There are economies of scale one can leverage, to be sure, but
    just as monocultures aren't robust against external threats in
    biological systems, I can't help but think that the same is true
    of computing systems.

    Yup. I much enjoyed freaking out my old boss the day the ILOVEYOU e-mail
    virus hit. Lots of people at work were reading their mail on Windows and
    got hit. I was reading mine using Netscape on an HP-UX PA-RISC box and
    read the Visual Basic virus code with some interest. Some explaining that neither HP-UX nor Netscape could run this code, so I was safe, was
    necessary.

    Some years later, when I had a new boss, the old one spotted me reading a
    book about how buffer overflows and other security holes actually work.
    He was concerned, and felt that staff should not know these things. My
    new boss gave me a meta-instruction: if doing something reasonable
    worries the old boss, keep on doing it.

    It felt like there was a time when we had built hetergeneous
    systems that were at least reasonable to manage; these days, I
    think we'd know how to do much better. But the diversity of
    systems and platforms common 30 years ago are mostly gone, and
    we're left with essentially three buckets: Windows, Linux, and
    a small sliver of "everything else". Not great.

    The heterogeneity shows up at different levels these days. VMware tried
    to enforce a monopoly, and now lots of different virtualisation systems
    are getting more popular. Tintri is taking market share from NetApp, and
    so on.

    John
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Mon Oct 20 16:13:41 2025
    From Newsgroup: comp.os.vms

    In article <memo.20251018141828.2688B@jgd.cix.co.uk>,
    John Dallman <jgd@cix.co.uk> wrote:
    In article <10co28b$isl$1@reader2.panix.com>,
    cross@spitfire.i.gajendra.net (Dan Cross) wrote:

    I've said this before in this group, but the homogeneity of
    modern computing does not strike me as a universally good thing.
    There are economies of scale one can leverage, to be sure, but
    just as monocultures aren't robust against external threats in
    biological systems, I can't help but think that the same is true
    of computing systems.

    Yup. I much enjoyed freaking out my old boss the day the ILOVEYOU e-mail >virus hit. Lots of people at work were reading their mail on Windows and
    got hit. I was reading mine using Netscape on an HP-UX PA-RISC box and
    read the Visual Basic virus code with some interest. Some explaining that >neither HP-UX nor Netscape could run this code, so I was safe, was
    necessary.

    Some years later, when I had a new boss, the old one spotted me reading a >book about how buffer overflows and other security holes actually work.
    He was concerned, and felt that staff should not know these things. My
    new boss gave me a meta-instruction: if doing something reasonable
    worries the old boss, keep on doing it.

    This idea that people would be discouraged from understanding
    how attack vectors work seems incredibly regressive to me. How
    misguided. New boss's advice seems sound!

    It felt like there was a time when we had built hetergeneous
    systems that were at least reasonable to manage; these days, I
    think we'd know how to do much better. But the diversity of
    systems and platforms common 30 years ago are mostly gone, and
    we're left with essentially three buckets: Windows, Linux, and
    a small sliver of "everything else". Not great.

    The heterogeneity shows up at different levels these days. VMware tried
    to enforce a monopoly, and now lots of different virtualisation systems
    are getting more popular. Tintri is taking market share from NetApp, and
    so on.

    Perhaps, but where the juicy bits are (the applications and
    access to their data, etc) is pretty much Linux all the way
    down.

    - Dan C.

    --- Synchronet 3.21a-Linux NewsLink 1.2