Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #115698 > unrolled thread

Arm to run within IBM z

Back to article view | Back to comp.arch

Contents

  Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-04 21:34 +0300
    Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-04 20:39 +0000
      Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-04 22:08 +0000
        Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-04 23:32 +0000
          Re: Arm to run within IBM z David Schultz <david.schultz@earthlink.net> - 2026-04-04 20:12 -0500
            Re: Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-05 00:14 -0400
              Re: Arm to run within IBM z David Schultz <david.schultz@earthlink.net> - 2026-04-05 06:12 -0500
                Re: Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-06 13:09 -0400
            Re: Arm to run within IBM z anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-05 09:56 +0000
              Re: Arm to run within IBM z David Schultz <david.schultz@earthlink.net> - 2026-04-05 06:17 -0500
            Re: Arm to run within IBM z antispam@fricas.org (Waldek Hebisch) - 2026-04-05 16:09 +0000
    Re: Arm to run within IBM z antispam@fricas.org (Waldek Hebisch) - 2026-04-05 02:35 +0000
      Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-05 02:56 +0000
        Re: Arm to run within IBM z Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-04-04 21:11 -0700
          Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-05 04:34 +0000
            Re: Arm to run within IBM z Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-04-04 22:04 -0700
              Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 00:30 +0000
            Re: Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-05 12:51 +0300
            Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-05 15:04 +0000
        Re: Arm to run within IBM z antispam@fricas.org (Waldek Hebisch) - 2026-04-05 16:16 +0000
          Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 00:31 +0000
          Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-06 03:57 +0000
            Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 07:04 +0000
              Re: Arm to run within IBM z MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-06 16:35 +0000
                Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-06 16:48 +0000
                  Re: Arm to run within IBM z MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-06 22:32 +0000
                Re: Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-06 18:41 +0000
                  Re: Arm to run within IBM z MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-06 22:33 +0000
                    Re: Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-07 02:31 +0300
                    Re: Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-07 14:41 +0000
                Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-07 02:16 +0000
                  Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-07 04:55 +0000
                  Re: Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-07 05:44 +0000
                    Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-07 07:53 +0000
                  Re: Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-07 14:44 +0000
                    Re: Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-07 19:39 +0000
                      Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-08 11:39 +0000
                        Re: Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-08 19:25 +0000
                          Re: Windows, was Arm to run within IBM z David Schultz <david.schultz@earthlink.net> - 2026-04-08 15:48 -0500
                          Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-08 20:54 +0000
                            Re: Windows, was Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-09 00:07 +0300
                            Re: Windows, was Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-09 17:51 -0400
                              Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-10 11:47 +0000
                                Re: Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-11 15:09 +0000
                                  Re: Windows, was Arm to run within IBM z MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-11 17:53 +0000
                                    Re: Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-11 19:20 +0000
                                    Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-11 21:37 +0000
                                      Re: Windows, was Arm to run within IBM z "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-11 14:49 -0700
                                        Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-11 23:37 +0000
                                          Re: Windows, was Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-12 23:03 -0400
                                          Re: Windows, was Arm to run within IBM z "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 12:55 -0700
                                    Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-12 20:22 +0000
                                  Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-12 20:17 +0000
                                    Re: library confusion, Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-13 03:36 +0000
                                      Re: library confusion, Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-13 11:27 +0000
                                Re: Windows, was Arm to run within IBM z jgd@cix.co.uk (John Dallman) - 2026-04-15 12:22 +0100
                                  Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-15 13:51 +0000
                                    Re: Windows, was Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-15 14:43 +0000
                                      Re: libraries, Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-16 01:24 +0000
                                  Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-16 00:49 +0000
                          Re: Windows, was Arm to run within IBM z Paul Clayton <paaronclayton@gmail.com> - 2026-04-18 22:35 -0400
                            Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-19 03:04 +0000
                            Re: Windows, was Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-19 00:34 -0400
                            Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-19 06:03 +0000
                        Re: Windows, was Arm to run within IBM z Andy Valencia <vandys@vsta.org> - 2026-04-13 09:21 -0700
                          Re: Windows, was Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-13 17:21 +0000
                            Re: Windows, was Arm to run within IBM z legalize+jeeves@mail.xmission.com (Richard) - 2026-04-13 18:55 +0000
                              Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-13 20:15 +0000
                              Re: Windows, was Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-13 20:20 +0000
                                Re: Windows, was Arm to run within IBM z legalize+jeeves@mail.xmission.com (Richard) - 2026-04-14 04:51 +0000
                                  Re: Windows, was Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-14 05:54 +0000
                                    Re: Windows, was Arm to run within IBM z legalize+jeeves@mail.xmission.com (Richard) - 2026-04-14 16:23 +0000
                          Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-13 19:56 +0000
                        Re: Windows, was Arm to run within IBM z jgd@cix.co.uk (John Dallman) - 2026-04-15 12:22 +0100
                          Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-15 13:53 +0000
                          Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-15 22:28 +0000
                      Re: Windows, was Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-08 19:48 +0000
                        Re: Windows, was Arm to run within IBM z Stefan Monnier <monnier@iro.umontreal.ca> - 2026-04-09 09:49 -0400
                Re: Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-07 19:35 +0000
      Re: Arm to run within IBM z Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-04-04 20:56 -0700
        Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-05 04:36 +0000
          Re: Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-05 13:41 +0300
        Re: Arm to run within IBM z antispam@fricas.org (Waldek Hebisch) - 2026-04-05 17:04 +0000
          Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-06 04:04 +0000
            Re: Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-06 12:29 +0300
      Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-05 05:24 +0000
        Re: Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-05 19:14 +0000
    Re: Arm to run within IBM z jgd@cix.co.uk (John Dallman) - 2026-04-05 12:43 +0100
      Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-05 15:12 +0000
        Re: Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-06 12:21 +0000
          Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-06 16:46 +0000
          Re: Arm to run within IBM z "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-09 02:27 -0700
            Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-09 14:49 +0000
      Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 00:35 +0000
    Re: Arm to run within IBM z "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-08 18:41 -0700

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#116036 — Re: Windows, was Arm to run within IBM z

On 4/8/26 3:25 PM, John Levine wrote:
> According to Dan Cross <cross@spitfire.i.gajendra.net>:
>>> Maybe he's thinking of what's known as DLL Hell, which resulted
>> >from Microsoft's neglecting to put a version number in DLL filenames. ...
>>
>> Quite possibly!  It's interesting to note that Linux has also
>> suffered from similar issues, exacerbated by libraries that
>> don't handle versioning well.  Containers were the solution.
> 
> That's kind of sad.
> 
> ELF library names include multi-part version numbers, with the plan being that
> if the API changes you bump the major number, while if it's a bug fix or
> otherwise compatible you just bump the minor number.  

One issue with this kind of version numbering is that adding a
feature is an API change but does not necessarily prevent
compatibility. This expression of versioning allows users
dependent on newer features to request the newer major version,
but it does not allow a newer major version to be used when it
is compatible (which might be desirable to reduce library bloat
or just not force installation of a different version).

While one could include a backward compatibility range (e.g.,
14-12 or 14b to indicate implementation of version 14 features
with compatibility back to version (b) to version 12), this
would still not maximize the compatibility support (which may
well not be a desirable goal).

Bug compatibility is also an issue as are leaky abstractions.
For ISAs, if early implementations use a stronger memory model
(or appear to do so), software could be written to exploit that
and be incompatible with future hardware.

One can also have performance (or non-time resource consumption)
incompatibilities, where the abstract architecture is the same
but some uses may be significantly impacted. E.g., an ISA might
initially not define a preferred register zeroing idiom and
software might choose any single cycle instruction that zeros a
register, but later implementations might only optimize one of
those options.

(A library function that moved from a O(nlogn) implementation to
a O(logn) implementation with larger constant factor might
"break" software that calls the function N times rather than
once with an N-times larger list/array but be broadly considered
an improvement.)

> Then you symlink the name
> with the minor version number back to the name with just the major number so the
> lists of imported library names just have the major number. This seems to work
> OK on FreeBSD. What happens on linux?

I guess using minor version is tricky as it depends on the
specific implementation. The fourth bug fix version of Burzatt's
implementation of the 14th version of the libgood API would be
different than the fourth of Blinfoo's implementation. (There
could, in theory, be cooperation in minor versioning when a
common bug is discovered, but that seems unlikely.)

I guess the major version represents the abstract interface and
the minor version represents a "release number". With ISAs,
multiple resource-use targets (power-performance-area tradeoffs,
e.g.) might be pursued with the same abstract interface (the
original goal of Architecture), so specifying the interface
version number is not sufficient.

There may also be desirable for different implementations to
deprecate features (possibly where a feature technically works
but has poor resource use traits) or extend the lifetime of a
feature. E.g., an ISA version might specify that an opcode no
longer needs to be supported and can either generate an illegal
opcode exception or provide the legacy behavior while the
implementation could still claim to be of that version of the
ISA.

[I feel my mind is getting fuzzy, sleep is calling.]

[toc] | [prev] | [next] | [standalone]

#116037 — Re: Windows, was Arm to run within IBM z

On Sat, 18 Apr 2026 22:35:31 -0400, Paul Clayton wrote:

> One issue with this kind of version numbering is that adding a
> feature is an API change but does not necessarily prevent
> compatibility.

This is why we distinguish between “API” changes and “ABI” changes.

API changes which do not impact compatibility with existing binaries
built against that shared library do not require a library version
bump. ABI changes, which affect the generated code in some way (e.g.
increasing the size of fixed structures), require some kind of
versioning, either at the entire library level, or possibly just at
the individual symbol level.

[toc] | [prev] | [next] | [standalone]

#116039 — Re: Windows, was Arm to run within IBM z

On Sat, 18 Apr 2026 22:35:31 -0400, Paul Clayton
<paaronclayton@gmail.com> wrote:

>On 4/8/26 3:25 PM, John Levine wrote:
>> According to Dan Cross <cross@spitfire.i.gajendra.net>:
>>>> Maybe he's thinking of what's known as DLL Hell, which resulted
>>> >from Microsoft's neglecting to put a version number in DLL filenames. ...
>>>
>>> Quite possibly!  It's interesting to note that Linux has also
>>> suffered from similar issues, exacerbated by libraries that
>>> don't handle versioning well.  Containers were the solution.
>> 
>> That's kind of sad.
>> 
>> ELF library names include multi-part version numbers, with the plan being that
>> if the API changes you bump the major number, while if it's a bug fix or
>> otherwise compatible you just bump the minor number.  
>
>One issue with this kind of version numbering is that adding a
>feature is an API change but does not necessarily prevent
>compatibility. This expression of versioning allows users
>dependent on newer features to request the newer major version,
>but it does not allow a newer major version to be used when it
>is compatible (which might be desirable to reduce library bloat
>or just not force installation of a different version).
>
>While one could include a backward compatibility range (e.g.,
>14-12 or 14b to indicate implementation of version 14 features
>with compatibility back to version (b) to version 12), this
>would still not maximize the compatibility support (which may
>well not be a desirable goal).

And does not address the possibility of gaps in the range of
compatible versions.

I have encountered this problem just a few times, but it has been a
nightmare each time:  a new version changes some behavior in a way
that is incompatible with your application.  Some versions later after
many complaints, the original behavior is restored [with new behavior
kept but moved to a new API].  Now there is a gap in the list of
compatible versions ... e.g., you can use versions  C D E ... H  but F
and G  won't work.


>Bug compatibility is also an issue as are leaky abstractions.

Yup!


>For ISAs, if early implementations use a stronger memory model
>(or appear to do so), software could be written to exploit that
>and be incompatible with future hardware.
>
>One can also have performance (or non-time resource consumption)
>incompatibilities, where the abstract architecture is the same
>but some uses may be significantly impacted. E.g., an ISA might
>initially not define a preferred register zeroing idiom and
>software might choose any single cycle instruction that zeros a
>register, but later implementations might only optimize one of
>those options.

Seen this too working with DSPs.



>(A library function that moved from a O(nlogn) implementation to
>a O(logn) implementation with larger constant factor might
>"break" software that calls the function N times rather than
>once with an N-times larger list/array but be broadly considered
>an improvement.)
>
>> Then you symlink the name
>> with the minor version number back to the name with just the major number so the
>> lists of imported library names just have the major number. This seems to work
>> OK on FreeBSD. What happens on linux?
>
>I guess using minor version is tricky as it depends on the
>specific implementation. The fourth bug fix version of Burzatt's
>implementation of the 14th version of the libgood API would be
>different than the fourth of Blinfoo's implementation. (There
>could, in theory, be cooperation in minor versioning when a
>common bug is discovered, but that seems unlikely.)
>
>I guess the major version represents the abstract interface and
>the minor version represents a "release number". With ISAs,
>multiple resource-use targets (power-performance-area tradeoffs,
>e.g.) might be pursued with the same abstract interface (the
>original goal of Architecture), so specifying the interface
>version number is not sufficient.
>
>There may also be desirable for different implementations to
>deprecate features (possibly where a feature technically works
>but has poor resource use traits) or extend the lifetime of a
>feature. E.g., an ISA version might specify that an opcode no
>longer needs to be supported and can either generate an illegal
>opcode exception or provide the legacy behavior while the
>implementation could still claim to be of that version of the
>ISA.
>
>[I feel my mind is getting fuzzy, sleep is calling.]

[toc] | [prev] | [next] | [standalone]

#116040 — Re: Windows, was Arm to run within IBM z

In article <10s1f1m$3mi35$1@dont-email.me>,
Paul Clayton  <paaronclayton@gmail.com> wrote:
>On 4/8/26 3:25 PM, John Levine wrote:
>> According to Dan Cross <cross@spitfire.i.gajendra.net>:
>>>> Maybe he's thinking of what's known as DLL Hell, which resulted
>>> >from Microsoft's neglecting to put a version number in DLL filenames. ...
>>>
>>> Quite possibly!  It's interesting to note that Linux has also
>>> suffered from similar issues, exacerbated by libraries that
>>> don't handle versioning well.  Containers were the solution.
>> 
>> That's kind of sad.
>> 
>> ELF library names include multi-part version numbers, with the plan being that
>> if the API changes you bump the major number, while if it's a bug fix or
>> otherwise compatible you just bump the minor number.  
>
>One issue with this kind of version numbering is that adding a
>feature is an API change but does not necessarily prevent
>compatibility. This expression of versioning allows users
>dependent on newer features to request the newer major version,
>but it does not allow a newer major version to be used when it
>is compatible (which might be desirable to reduce library bloat
>or just not force installation of a different version).

This is precisely the type of problem that so-called "semantic
versioning" (semver) is meant to solve: https://semver.org

It works decently well, as long as projects actually follow the
convention.

        - Dan C.

[toc] | [prev] | [next] | [standalone]

#115865 — Re: Windows, was Arm to run within IBM z

John Levine <johnl@taugh.com> writes:
> According to Dan Cross <cross@spitfire.i.gajendra.net>:
> >It's interesting to note that Linux has also
> >suffered from similar issues, exacerbated by libraries that
> >don't handle versioning well.  Containers were the solution.
> That's kind of sad.

It has become a vicious cycle.  Devs have lost interest in compatibility,
especially WRT API's.  Users of the API thus have to make each app a snpashot
of the one blend of libraries which work with each other.  This frees the
devs to change their API willy-nilly, since it's just a candidate for
whatever montage snapshot happens to make it work this month/year.

And then a security flaw is found, and it's actually becoming more cost
efficient to just ignore it rather than find and fix it in each one-off
snapshot in all the myriad types of library combinatoric snapshotting
out there.

I came up the SW ranks with an expectation of rigor and attention to detail.
Since these show no sign of ever returning, perhaps it's this AI thing which
will eventually be used to jump out of this pit.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html
No AI was used in the composition of this message

[toc] | [prev] | [next] | [standalone]

#115866 — Re: Windows, was Arm to run within IBM z

Andy Valencia <vandys@vsta.org> schrieb:

> I came up the SW ranks with an expectation of rigor and attention to detail.
> Since these show no sign of ever returning, perhaps it's this AI thing which
> will eventually be used to jump out of this pit.

Right now, it seems people are managing to dig themselves deeper into
the pit, much faster, with the help of AI. 

To quote something that just got forwarded to me today:

"It's more like asking the agent to build a building from floorplans
and spec, and it produces everything in the right measurements and
passes all tests. Except then you find out that the walls and
beams are made of foam and the art is load-bearing".

> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html
> No AI was used in the composition of this message

See my own .sig :-)

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#115867 — Re: Windows, was Arm to run within IBM z

Thomas Koenig <tkoenig@netcologne.de> spake the secret code
<10rj8mj$3fme6$1@dont-email.me> thusly:

>Andy Valencia <vandys@vsta.org> schrieb:
>
>> I came up the SW ranks with an expectation of rigor and attention to detail.
>> Since these show no sign of ever returning, perhaps it's this AI thing which
>> will eventually be used to jump out of this pit.
>
>Right now, it seems people are managing to dig themselves deeper into
>the pit, much faster, with the help of AI. 

My take on the situation (and I've been using the AI tools more and
more over time) is that the tools are great in the hands of someone
with enough experience to "call the AI out on it's shit".  I'm not
sure how well a n00b or junior engineer is able to spot the obvious
bad decisions the AI sometimes makes.  The AI definitely acts like a
"confident incompetent".  It will always admit failure when you point
it out, but what happens if you don't?

Also, crafting prompts and properly seeding the context is essential
to getting the most out of the AI and this is a new skill that, while
not difficult to obtain, you have to invest in.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#115870 — Re: Windows, was Arm to run within IBM z

In article <10rje78$1d4f3$1@news.xmission.com>, Richard <> wrote:
>Thomas Koenig <tkoenig@netcologne.de> spake the secret code
><10rj8mj$3fme6$1@dont-email.me> thusly:
>
>>Andy Valencia <vandys@vsta.org> schrieb:
>>
>>> I came up the SW ranks with an expectation of rigor and attention to detail.
>>> Since these show no sign of ever returning, perhaps it's this AI thing which
>>> will eventually be used to jump out of this pit.
>>
>>Right now, it seems people are managing to dig themselves deeper into
>>the pit, much faster, with the help of AI. 
>
>My take on the situation (and I've been using the AI tools more and
>more over time) is that the tools are great in the hands of someone
>with enough experience to "call the AI out on it's shit".  I'm not
>sure how well a n00b or junior engineer is able to spot the obvious
>bad decisions the AI sometimes makes.  The AI definitely acts like a
>"confident incompetent".  It will always admit failure when you point
>it out, but what happens if you don't?
>
>Also, crafting prompts and properly seeding the context is essential
>to getting the most out of the AI and this is a new skill that, while
>not difficult to obtain, you have to invest in.

I've been working with these things to get a sense of their
capabilities, and so far it seems like they work best when you
can constrain their behavior by pinning them to some set of
external criteria that they cannot fudge.  For example, I've
if you have a formal specification of a thing, and have checked
it with some automated system (e.g., expressed in a modeling
language like Promela, TLA+ or Alloy and checked using a tool
like SPIN or tlc or something) and you tell the LLM that the
model is both immutable and the basis for what they must do,
then you can get it to do a decent job.

On the other hand, prompts alone don't seem to be sufficient to
keep it honest, but maybe I am just not good at generating them.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#115871 — Re: Windows, was Arm to run within IBM z

Richard <legalize+jeeves@mail.xmission.com> schrieb:
> The AI definitely acts like a
> "confident incompetent".  It will always admit failure when you point
> it out, but what happens if you don't?

The amusing thing is that it will also admit failure when it is
actually right.

Or pretend to have corrected something when it hasn't, especially in
pictures.

For a long time, I've wanted it to draw a path which splits into
two and then comes together again.  The result has been unmitigated
disaster.

But at least, after years of trying, I have made one of
my favorite misquotes into a picture: "Before the gates of
scale-up the high gods have placed scale-down."  It is a wistom
that too few lab chemists heed.  (Warning: shameless plug)
https://www.linkedin.com/feed/update/urn:li:activity:7448403583332413440/

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#115879 — Re: Windows, was Arm to run within IBM z

Thomas Koenig <tkoenig@netcologne.de> spake the secret code
<10rjj6u$3j33t$1@dont-email.me> thusly:

>For a long time, I've wanted it to draw a path which splits into
>two and then comes together again.  The result has been unmitigated
>disaster.

I've had good results using it as a coding assistant.

I tried using google gemini for writing terminals wiki articles and it
was pretty horrible.  When pinned down to explain it's horrible
ability to do what I asked, it simply confessed that it's primary job
was trying to make me happy, everything else be damned. So it would
hallucinate URLs to "primary sources" and make up a bunch of other
stuff in the generated prose that I could spot as obvious B.S.  Worse,
it wouldn't consistently follow my rules, even though that's how it's
supposed to work.

Working with chatgpt was much less frustrating, was more reliable at
providing me links to primary sources and followed my rules pretty
well.

Then I tried to get them to generate a picture and I found the process
entirely frustrating.  Most of my experiments have been with
researching vintage computing stuff and writing code, both areas where
I have enough personal knowledge to spot hallucinations.

Again, I think it comes back to having the bot do the grunt work while
being overseen by someone with enough knowledge to spot the b.s.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#115882 — Re: Windows, was Arm to run within IBM z

Richard <legalize+jeeves@mail.xmission.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> spake the secret code
><10rjj6u$3j33t$1@dont-email.me> thusly:
>
>>For a long time, I've wanted it to draw a path which splits into
>>two and then comes together again.  The result has been unmitigated
>>disaster.
>
> I've had good results using it as a coding assistant.
>
> I tried using google gemini for writing terminals wiki articles and it
> was pretty horrible.  When pinned down to explain it's horrible
> ability to do what I asked, it simply confessed that it's primary job
> was trying to make me happy, everything else be damned. So it would
> hallucinate URLs to "primary sources" and make up a bunch of other
> stuff in the generated prose that I could spot as obvious B.S.  Worse,
> it wouldn't consistently follow my rules, even though that's how it's
> supposed to work.

You know Wikipedia has a policy on AI-generated content,
https://en.wikipedia.org/wiki/Wikipedia:LLM_use_disclosure ,
and an "AI style guide" to spot it,
https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing ?

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#115894 — Re: Windows, was Arm to run within IBM z

Thomas Koenig <tkoenig@netcologne.de> spake the secret code
<10rkkqc$3t7iu$1@dont-email.me> thusly:

>Richard <legalize+jeeves@mail.xmission.com> schrieb:
>> I tried using google gemini for writing terminals wiki articles [...]
>
>You know Wikipedia has a policy on AI-generated content,

Terminals wiki is mine and I decide the policies; IDGAF what
wikipenis(tm) decides to do :).
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#115869 — Re: Windows, was Arm to run within IBM z

On Mon, 13 Apr 2026 09:21:09 -0700, Andy Valencia wrote:

> It has become a vicious cycle. Devs have lost interest in
> compatibility, especially WRT API's. Users of the API thus have to
> make each app a snpashot of the one blend of libraries which work
> with each other. This frees the devs to change their API
> willy-nilly, since it's just a candidate for whatever montage
> snapshot happens to make it work this month/year.
>
> And then a security flaw is found, and it's actually becoming more
> cost efficient to just ignore it rather than find and fix it in each
> one-off snapshot in all the myriad types of library combinatoric
> snapshotting out there.

This may be an accurate description of the proprietary world, but I’m
not aware of this sort of thing happening in the open-source world.
Can you give an example or two?

[toc] | [prev] | [next] | [standalone]

#115921 — Re: Windows, was Arm to run within IBM z

In article <10r5eor$b6q$1@reader1.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

> Quite possibly!  It's interesting to note that Linux has also
> suffered from similar issues, exacerbated by libraries that
> don't handle versioning well. Containers were the solution.

Containers were designed to make it easy to run lots of different
applications on the same cloud servers. The companies that offer cloud
services don't want to solve such problems in the applications - it's
hard to blame them - and the SaaS companies have learned that their
customers want cheap, not good, software. 

John 

[toc] | [prev] | [next] | [standalone]

#115925 — Re: Windows, was Arm to run within IBM z

In article <memo.20260415122259.25212B@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <10r5eor$b6q$1@reader1.panix.com>,
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> Quite possibly!  It's interesting to note that Linux has also
>> suffered from similar issues, exacerbated by libraries that
>> don't handle versioning well. Containers were the solution.
>
>Containers were designed to make it easy to run lots of different
>applications on the same cloud servers. The companies that offer cloud
>services don't want to solve such problems in the applications - it's
>hard to blame them - and the SaaS companies have learned that their
>customers want cheap, not good, software. 

The companies that are offering such things on "cloud servers"
are not allowing their customers to run those applications on
the bare metal.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#115958 — Re: Windows, was Arm to run within IBM z

On Wed, 15 Apr 2026 12:22 +0100 (BST), John Dallman wrote:

> Containers were designed to make it easy to run lots of different
> applications on the same cloud servers.

Linux systems have been serving multirole operations for years. Time
was that the built-in multiuser capabilities were sufficient to keep
apps isolated from each other.

The problem seems to be with increasing use of proprietary apps. The
developers of those seem to be accustomed to thinking that they have
full control over the machine their software is running on.

So virtualization became popular as a way of dealing with this, by
isolating each problem app into what it thinks is its own machine.

Full virtualization has a certain cost in terms of resources used. For
example, each VM needs its own OS installation. Containerization is a
much lighter-weight solution, that shares the OS kernel among multiple
userlands, while still keeping the latter isolated from each other.

This requires special features of the OS kernel that are only
available in Linux. It also means that the apps must be developed for
Linux. This seems to have happened anyway; Windows Server has very
little presence in the cloud, even in Microsoft’s cloud.

[toc] | [prev] | [next] | [standalone]

#115807 — Re: Windows, was Arm to run within IBM z

John Levine <johnl@taugh.com> schrieb:
> According to Dan Cross <cross@spitfire.i.gajendra.net>:
>>Maybe, maybe not.  Setting aside the matter of binary-only
>>programs (that are not uncommon on Linux, FWIW) there is _also_
>>the matter of software that has a long list of requirements, and
>>may or many not work particularly well on any given distribution
>>of Linux (of which there are far, far too many).
>
> Maybe he's thinking of what's known as DLL Hell, which resulted
> from Microsoft's neglecting to put a version number in DLL filenames.
> Programs typically ship with the library DLLs they use, and each
> time a program was installed, its DLLs would replace any previous
> ones with the same name, even though it might be a different
> incompatible version.

Seems that shared libraries don't work too well on Linux,
either, or there would be no need for snap:

$ find ~/snap -name '*.so' | wc -l
162
$ find /snap -name '*.so' 2>/dev/null | wc -l
21567

If they are shipping shared libraries for single applications, why not
just do away with the shared library overhead and link these in
statically?

> They've mostly fixed that, I think by having each program in
> some sort of environment so it's tied to the libraries it was
> using when it was installed.

See above...

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#115820 — Re: Windows, was Arm to run within IBM z

> Seems that shared libraries don't work too well on Linux,
> either, or there would be no need for snap:
>
> $ find ~/snap -name '*.so' | wc -l
> 162
> $ find /snap -name '*.so' 2>/dev/null | wc -l
> 21567

I've never seen "DLL hell" (or thereabouts) mentioned as the motivation
for snaps.

> If they are shipping shared libraries for single applications, why not
> just do away with the shared library overhead and link these in
> statically?

There are so many things that make no sense about snaps.
I think for this particular question the answer is "because it's
expedient" (AFAIK this same answer explains most of the other problems
with snaps).


=== Stefan

[toc] | [prev] | [next] | [standalone]

#115801

According to MitchAlsup  <user5857@newsgrouper.org.invalid>:
>I find it interesting that MS made it virtually impossible to transport an
>application from one machine to another while Linux made it absolutely
>simple.

I don't understand what this means, either.  Most Windows applications are licensed
so it's deliberate that you can't install it on a bunch of machines without getting
more license keys.

If you mean something like x86 to ARM or 32 to 64 bit x86, who knows? We don't
have the source code. Windows 11 runs on both AMD64 and ARM64, and they provide
applications like Office for both. It's all written in high level languages so
I'd think that it would be little more than recompiling.



-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#115712

On 4/4/2026 7:35 PM, Waldek Hebisch wrote:
> Michael S <already5chosen@yahoo.com> wrote:
>> https://newsroom.ibm.com/2026-04-02-ibm-announces-strategic-collaboration-with-arm-to-shape-the-future-of-enterprise-computing
> 
> That anonoucement has little content. 

Agreed.

> In particular I do not see
> "Arm within Z" statement.  Since Z people are involved this is
> likely, but equally likely IBM may wish to deliver servers with
> Arm cores, but peripherial system taken from Z.  Or something
> entirely different.

Of course, I may be way off base here.  But I thought it could be 
something like - Z series currently has specialized cores or some 
mechanism for running crypto stuff, and at least some AI stuff.  So I 
thought it may be a mechanism to have ARM cores as specialized cores to 
run some Android like stuff.  Perhaps the advantage of running this 
stuff in the Z series itself instead of remotely is better communication 
between the Android app and whatever is running on the Z series.

Once again, I emphasize that I have no inside knowledge or do I know if 
such a scheme makes any sense.


> Now, interesting question is what will happen to Power? 

Probably nothing.  Power and Z are pretty much independent.


> Using
> Arm may mean that IBM no longer considers Power a viable platform.

They make a lot of money from it.


> Also, if IBM delivers machines capable of running both Arm and
> Z code, then likely consequence will be demise of Z as a hardware
> architecture. 

I don't think so.  IBM is unlikely to port things like CICS, or TPF to 
ARM and without those, ARM couldn't replace Z series CPUs.

> That is, once performance crritical things run on
> Arm they would no longer need real hardware for Z, software emulation
> will be good enough.

Again, I may be totally off base here, but I saw nothing to indicate 
that they were going to move any substantial amount of software to ARM.


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.arch

csiph-web