Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #115698 > unrolled thread
| Started by | Michael S <already5chosen@yahoo.com> |
|---|---|
| First post | 2026-04-04 21:34 +0300 |
| Last post | 2026-04-08 18:41 -0700 |
| Articles | 20 on this page of 95 — 19 participants |
Back to article view | Back to comp.arch
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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-06 00:31 +0000 |
| Message-ID | <10quutm$1pi2v$2@dont-email.me> |
| In reply to | #115741 |
On Sun, 5 Apr 2026 16:16:11 -0000 (UTC), Waldek Hebisch wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> >> Mainframes were never about “performance critical” stuff -- unless >> your meaning of “performance” was purely about I/O throughput, not >> CPU power. Because I/O throughput is what mainframes are/were >> optimized for. > > Business have some job to do and some performance expectation. If > performance did not matter they would only use lower end Z machines > and IBM would not bother to make bigger Z boxes. As long as there are dyed-in-the-wool long-time IBM diehards who believe that, no doubt there will be some market for new Z-series boxes. Even if they do mostly seem to be running Linux these days ...
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-04-06 03:57 +0000 |
| Message-ID | <10qvauj$1s43i$1@dont-email.me> |
| In reply to | #115741 |
On Sun, 05 Apr 2026 16:16:11 +0000, Waldek Hebisch wrote: > Business have some job to do and some performance expectation. > If performance did not matter they would only use lower end Z machines > and IBM would not bother to make bigger Z boxes. > > In fact, if performance did not matter IBM could go with emulation > (possibly using similar approach to AS/400 and later i series). Or they > could use standard FPGA: that probably would be slower than emulation > but IBM could still clain that Z runs on real hardware, which has some > marketing advantage. Yes, the people who buy System z hardware would prefer more bang for the buck rather than less. But they settle for less bang for the buck than they would get with PowerPC hardware or commodity x86 or ARM because of two things: 1) Old System/360 or 370 software they want to still use instead of converting, and 2) The superior reliability features of IBM's mainframes. So there's no contradiction; what there is, instead, is a constraint. An additional criterion that must be satisfied, which limits the available performance. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-06 07:04 +0000 |
| Message-ID | <10qvltu$1uf62$3@dont-email.me> |
| In reply to | #115754 |
On Mon, 6 Apr 2026 03:57:07 -0000 (UTC), quadi wrote: > 2) The superior reliability features of IBM's mainframes. Batch systems were never designed for high uptime. There is a paper on Bitsavers dated 1986 that says that, to turn daylight saving on or off on an IBM mainframe, you have to reboot.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-04-06 16:35 +0000 |
| Message-ID | <1775493332-5857@newsgrouper.org> |
| In reply to | #115758 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > On Mon, 6 Apr 2026 03:57:07 -0000 (UTC), quadi wrote: > > > 2) The superior reliability features of IBM's mainframes. > > Batch systems were never designed for high uptime. There is a paper on > Bitsavers dated 1986 that says that, to turn daylight saving on or off > on an IBM mainframe, you have to reboot. 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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-06 16:48 +0000 |
| Message-ID | <6tRAR.279262$_E1.73040@fx45.iad> |
| In reply to | #115766 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > >> On Mon, 6 Apr 2026 03:57:07 -0000 (UTC), quadi wrote: >> >> > 2) The superior reliability features of IBM's mainframes. >> >> Batch systems were never designed for high uptime. There is a paper on >> Bitsavers dated 1986 that says that, to turn daylight saving on or off >> on an IBM mainframe, you have to reboot. > >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 find it interesting that you actually accept L'do's bullshit about IBM history. The idea that "batch systems were never designed for high uptime" is just another in a long string of incorrect statements about computing history from L'do.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-04-06 22:32 +0000 |
| Message-ID | <1775514737-5857@newsgrouper.org> |
| In reply to | #115769 |
scott@slp53.sl.home (Scott Lurndal) posted: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > > > >Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > > > >> On Mon, 6 Apr 2026 03:57:07 -0000 (UTC), quadi wrote: > >> > >> > 2) The superior reliability features of IBM's mainframes. > >> > >> Batch systems were never designed for high uptime. There is a paper on > >> Bitsavers dated 1986 that says that, to turn daylight saving on or off > >> on an IBM mainframe, you have to reboot. > > > >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 find it interesting that you actually accept L'do's bullshit about > IBM history. The idea that "batch systems were never designed for > high uptime" is just another in a long string of incorrect statements > about computing history from L'do. My comment had and has nothing to do with IBM or batch systems.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-06 18:41 +0000 |
| Message-ID | <10r0uos$dcb$1@reader1.panix.com> |
| In reply to | #115766 |
In article <1775493332-5857@newsgrouper.org>, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > >> On Mon, 6 Apr 2026 03:57:07 -0000 (UTC), quadi wrote: >> >> > 2) The superior reliability features of IBM's mainframes. >> >> Batch systems were never designed for high uptime. There is a paper on >> Bitsavers dated 1986 that says that, to turn daylight saving on or off >> on an IBM mainframe, you have to reboot. > >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'm not sure that's at all true, but I suppose it depends on the definition of an "application". What precisely do you mean? Also, to echo what Scott said, Lawrence is a troll. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-04-06 22:33 +0000 |
| Message-ID | <1775514812-5857@newsgrouper.org> |
| In reply to | #115771 |
cross@spitfire.i.gajendra.net (Dan Cross) posted: > In article <1775493332-5857@newsgrouper.org>, > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > >Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > > > >> On Mon, 6 Apr 2026 03:57:07 -0000 (UTC), quadi wrote: > >> > >> > 2) The superior reliability features of IBM's mainframes. > >> > >> Batch systems were never designed for high uptime. There is a paper on > >> Bitsavers dated 1986 that says that, to turn daylight saving on or off > >> on an IBM mainframe, you have to reboot. > > > >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'm not sure that's at all true, but I suppose it depends on the > definition of an "application". What precisely do you mean? Say, MS-Office or CorelDraw. > Also, to echo what Scott said, Lawrence is a troll. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-04-07 02:31 +0300 |
| Message-ID | <20260407023152.00000592@yahoo.com> |
| In reply to | #115775 |
On Mon, 06 Apr 2026 22:33:32 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > cross@spitfire.i.gajendra.net (Dan Cross) posted: > > > In article <1775493332-5857@newsgrouper.org>, > > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > > > >Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > > > > > >> On Mon, 6 Apr 2026 03:57:07 -0000 (UTC), quadi wrote: > > >> > > >> > 2) The superior reliability features of IBM's mainframes. > > >> > > >> Batch systems were never designed for high uptime. There is a > > >> paper on Bitsavers dated 1986 that says that, to turn daylight > > >> saving on or off on an IBM mainframe, you have to reboot. > > > > > >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'm not sure that's at all true, but I suppose it depends on the > > definition of an "application". What precisely do you mean? > > Say, MS-Office or CorelDraw. > Technically or legally? > > Also, to echo what Scott said, Lawrence is a troll. > > > > - Dan C. > >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-07 14:41 +0000 |
| Message-ID | <10r3536$1eg$1@reader1.panix.com> |
| In reply to | #115775 |
In article <1775514812-5857@newsgrouper.org>, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >cross@spitfire.i.gajendra.net (Dan Cross) posted: > >> In article <1775493332-5857@newsgrouper.org>, >> MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >> > >> >Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: >> > >> >> On Mon, 6 Apr 2026 03:57:07 -0000 (UTC), quadi wrote: >> >> >> >> > 2) The superior reliability features of IBM's mainframes. >> >> >> >> Batch systems were never designed for high uptime. There is a paper on >> >> Bitsavers dated 1986 that says that, to turn daylight saving on or off >> >> on an IBM mainframe, you have to reboot. >> > >> >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'm not sure that's at all true, but I suppose it depends on the >> definition of an "application". What precisely do you mean? > >Say, MS-Office or CorelDraw. I'm sorry; I'm still confused by these statements. I suppose I'm not clear on what you mean by moving from one machine to another: it seems almost trivial to install MS Office on two computers; moving documents is also easy. Taking a binary build of a random program installed on a Linux computer, perhaps from source, and copying it to another machine? Well, often these things drop fles all over the filesystem; better make sure you get them all into a tarball or something. Fortunately, most distributions have some sort of package manager that does that for you. Unfortunately, all of those managers are different, and each is incompatible with all others. Hence, Flatpak, snap etc, and heavy-weight solutions like containers to sort out the shared library mess. Bottom line: it's not, actually, all that simple in the Linux ecosystem. MS has a package manager kind of thing too, and I'd say their single offering is better than the plethora of mutually-incompatible options in the Linux world. On the other hand, if you mean the base level of portability between different types of hardware (say, across different ISAs) then perhaps Linux has some small advantage here; I'd chalk that up more to compilers than the applications themselves. I don't know how many x86'isms are in MS Office, but I suspect it runs on ARM pretty well, so probably not that many. It likely has many msvc dependencies, though. >> Also, to echo what Scott said, Lawrence is a troll. (FWIW, this is stll true.) - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-04-07 02:16 +0000 |
| Message-ID | <10r1pd0$2he75$1@dont-email.me> |
| In reply to | #115766 |
On Mon, 06 Apr 2026 16:35:32 +0000, MitchAlsup wrote: > 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 didn't think this has anything to do with anything that Microsoft (specifically) did. Applications written for Windows are distributed as binaries. Applications written for Linux are available as source code, which anyone can recompile. The reasons for this are well known, but I don't think any of them include anything nefarious on the part of Microsoft. Naturally, like other operating systems developers, they knew that the way to sell many copies of their operating system and make money was to encourage people to write software for it, by letting them make money too. Which meant not having stuff like the GPL, or even the LGPL, which doesn't require disclosure of source, but which does require making hooks into one's code possible. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-07 04:55 +0000 |
| Message-ID | <10r22oa$2jeup$2@dont-email.me> |
| In reply to | #115779 |
On Tue, 7 Apr 2026 02:16:00 -0000 (UTC), quadi wrote: > The reasons for this are well known, but I don't think any of them > include anything nefarious on the part of Microsoft. Nothing nefarious. Just the consequence of a decades-long chain of management decisions prioritizing short-term profit over the long-term integrity of the platform. Until now they have evolved themselves into a corner, with no clear way out.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-04-07 05:44 +0000 |
| Message-ID | <10r25kh$2k2dn$1@dont-email.me> |
| In reply to | #115779 |
quadi <quadibloc@ca.invalid> schrieb: > On Mon, 06 Apr 2026 16:35:32 +0000, MitchAlsup wrote: > >> 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 didn't think this has anything to do with anything that Microsoft > (specifically) did. > > Applications written for Windows are distributed as binaries. Applications > written for Linux are available as source code, which anyone can recompile. That turns out not to be the case. There is a lot of commercial software for Linux distributed in binary-only form. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-07 07:53 +0000 |
| Message-ID | <10r2d5u$2m3bf$1@dont-email.me> |
| In reply to | #115784 |
On Tue, 7 Apr 2026 05:44:49 -0000 (UTC), Thomas Koenig wrote: > There is a lot of commercial software for Linux distributed in > binary-only form. s/commercial/proprietary/
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-07 14:44 +0000 |
| Message-ID | <10r357m$1eg$2@reader1.panix.com> |
| In reply to | #115779 |
In article <10r1pd0$2he75$1@dont-email.me>, quadi <quadibloc@ca.invalid> wrote: >On Mon, 06 Apr 2026 16:35:32 +0000, MitchAlsup wrote: > >> 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 didn't think this has anything to do with anything that Microsoft >(specifically) did. > >Applications written for Windows are distributed as binaries. Applications >written for Linux are available as source code, which anyone can recompile. 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). >The reasons for this are well known, but I don't think any of them include >anything nefarious on the part of Microsoft. Naturally, like other >operating systems developers, they knew that the way to sell many copies >of their operating system and make money was to encourage people to write >software for it, by letting them make money too. Which meant not having >stuff like the GPL, or even the LGPL, which doesn't require disclosure of >source, but which does require making hooks into one's code possible. I doubt this is true. I'm quite certain that lots of GPL'd code gets run on Windows. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-04-07 19:39 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10r3mh2$1ifl$2@gal.iecc.com> |
| In reply to | #115794 |
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. 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. -- 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]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-08 11:39 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10r5eor$b6q$1@reader1.panix.com> |
| In reply to | #115802 |
In article <10r3mh2$1ifl$2@gal.iecc.com>, John Levine <johnl@taugh.com> wrote: >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. > >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. 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. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-04-08 19:25 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10r6a2l$57g$1@gal.iecc.com> |
| In reply to | #115805 |
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. 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? -- 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]
| From | David Schultz <david.schultz@earthlink.net> |
|---|---|
| Date | 2026-04-08 15:48 -0500 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <qazBR.4$rGx6.1@fx24.iad> |
| In reply to | #115806 |
On 4/8/26 2:25 PM, John Levine wrote: > 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. 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? A random example: /usr/lib64$ ls -l libpng* lrwxrwxrwx. 1 root root 19 Feb 12 18:00 libpng16.so -> libpng16.so.16.55.0 lrwxrwxrwx. 1 root root 19 Feb 12 18:00 libpng16.so.16 -> libpng16.so.16.55.0 -rwxr-xr-x. 1 root root 241112 Feb 12 18:00 libpng16.so.16.55.0 lrwxrwxrwx. 1 root root 11 Feb 12 18:00 libpng.so -> libpng16.so -- http://davesrocketworks.com David Schultz "It's just this little chromium switch here..."
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-08 20:54 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10r6faj$91t$1@reader1.panix.com> |
| In reply to | #115806 |
In article <10r6a2l$57g$1@gal.iecc.com>, John Levine <johnl@taugh.com> 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. 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? That works fine, as long as it's actually done. It's when the plethora of dependencies a given program uses don't play by the rules that one runs into problems. I suppose the issue is that on Windows it cannot be avoided due to a technical limitation, while on Linux, it can be, but often is not. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.arch
csiph-web