Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #66722 > unrolled thread
| Started by | Farley Flud <ff@linux.rocks> |
|---|---|
| First post | 2025-03-29 09:38 +0000 |
| Last post | 2025-05-31 23:29 +0100 |
| Articles | 20 on this page of 159 — 23 participants |
Back to article view | Back to comp.os.linux.misc
Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <ff@linux.rocks> - 2025-03-29 09:38 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-03-30 03:42 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-03-30 17:58 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? pothead <pothead@snakebite.com> - 2025-03-31 03:08 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-03-31 03:38 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? chrisv <chrisv@nospam.invalid> - 2025-03-31 07:11 -0500
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <fsquared@fsquared.linux> - 2025-03-31 13:59 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-03-31 17:38 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <ff@linux.rocks> - 2025-03-31 18:55 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? -hh <recscuba_google@huntzinger.com> - 2025-04-01 10:16 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Robert Heller <heller@deepsoft.com> - 2025-04-01 14:40 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? -hh <recscuba_google@huntzinger.com> - 2025-04-01 11:08 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-01 18:08 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <ff@linux.rocks> - 2025-04-01 21:22 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-01 22:20 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-01 23:32 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-02 11:40 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? -hh <recscuba_google@huntzinger.com> - 2025-04-02 16:04 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 22:46 +0200
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-02 22:36 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2025-04-03 02:00 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-03 07:28 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2025-04-03 10:53 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-03 06:11 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2025-04-03 11:12 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-03 12:20 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2025-04-03 13:05 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-03 10:53 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? "Carlos E.R." <robin_listas@es.invalid> - 2025-04-03 13:44 +0200
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-03 18:26 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-03 17:12 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-04 00:03 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-03 22:50 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-04 06:00 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-06 08:52 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Richard Kettlewell <invalid@invalid.invalid> - 2025-04-06 10:14 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-06 11:13 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-06 16:58 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-01 17:35 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Robert Heller <heller@deepsoft.com> - 2025-04-01 19:30 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-01 22:14 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-01 15:09 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? John Ames <commodorejohn@gmail.com> - 2025-04-01 12:16 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-01 22:07 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-03-31 04:46 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-03-31 11:53 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Richard Kettlewell <invalid@invalid.invalid> - 2025-03-31 17:36 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? pothead <pothead@snakebite.com> - 2025-04-03 02:38 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-03 10:59 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-03 06:52 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-03 12:10 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-03 18:12 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-03 16:38 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-04 00:16 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-03 23:03 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-04 05:54 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-04 09:38 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-04 08:30 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-04 18:53 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-05 04:31 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-05 11:41 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-05 19:20 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-05 20:23 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? pothead <pothead@snakebite.com> - 2025-04-05 22:58 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 22:10 +0200
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-05 20:27 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-05 20:14 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-05 19:11 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-04-05 16:24 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <ff@linux.rocks> - 2025-04-04 19:15 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-05 04:50 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <ff@linux.rocks> - 2025-04-05 10:21 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-06 08:59 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <ff@linux.rocks> - 2025-04-06 11:27 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-06 12:17 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Richard Kettlewell <invalid@invalid.invalid> - 2025-04-06 18:38 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-06 20:23 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Richard Kettlewell <invalid@invalid.invalid> - 2025-04-06 23:14 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-06 21:42 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Rich <rich@example.invalid> - 2025-04-07 03:33 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-07 01:04 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-06 22:49 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-07 11:56 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-07 07:08 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-07 12:20 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-04-06 16:51 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-05 12:13 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-05 15:22 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-05 20:40 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Richard Kettlewell <invalid@invalid.invalid> - 2025-04-05 22:57 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-06 01:57 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Richard Kettlewell <invalid@invalid.invalid> - 2025-04-06 10:05 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-06 13:02 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-05 18:27 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-06 02:07 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-06 00:26 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-06 12:55 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? -hh <recscuba_google@huntzinger.com> - 2025-04-07 16:39 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-07 17:59 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <fsquared@fsquared.linux> - 2025-04-08 11:59 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-08 13:17 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-08 10:28 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? -hh <recscuba_google@huntzinger.com> - 2025-04-08 16:26 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-04-08 23:18 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-08 22:29 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-04-09 16:49 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? -hh <recscuba_google@huntzinger.com> - 2025-04-09 14:18 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-09 16:51 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? -hh <recscuba_google@huntzinger.com> - 2025-04-09 22:33 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-09 23:11 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-08 20:04 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-04-09 16:49 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-09 13:09 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-08 10:24 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? -hh <recscuba_google@huntzinger.com> - 2025-04-08 16:17 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-08 19:03 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-04-08 11:51 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <fflud@gnu.rocks> - 2025-04-05 20:00 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Joel <joelcrump@gmail.com> - 2025-04-05 16:16 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-05 18:35 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Joel <joelcrump@gmail.com> - 2025-04-05 19:13 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-06 09:01 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Farley Flud <ff@linux.rocks> - 2025-04-06 15:48 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-05 18:34 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-06 02:13 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-04-06 00:48 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-04-06 12:58 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-06 08:58 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 07:22 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? John Ames <commodorejohn@gmail.com> - 2025-05-30 10:59 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-05-30 19:38 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Joel <joelcrump@gmail.com> - 2025-05-30 15:19 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? % <pursent100@gmail.com> - 2025-05-30 12:21 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-05-31 00:33 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Joel <joelcrump@gmail.com> - 2025-05-30 23:34 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? % <pursent100@gmail.com> - 2025-05-30 20:37 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-05-31 07:23 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Joel <joelcrump@gmail.com> - 2025-05-31 14:31 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-05-31 06:29 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-05-31 14:04 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-05-31 22:47 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-05-31 14:54 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-05-31 23:26 +0100
OT: Neo-liberal misconceptions? (was: Re: Rewriting SSA. Is This A Chance For GNU/Linux?) Nuno Silva <nunojsilva@invalid.invalid> - 2025-05-31 23:43 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? rbowman <bowman@montana.com> - 2025-05-31 23:08 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-05-31 13:51 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Joel <joelcrump@gmail.com> - 2025-05-31 17:11 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-05-30 23:18 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? % <pursent100@gmail.com> - 2025-05-30 20:38 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? c186282 <c186282@nnada.net> - 2025-06-01 01:20 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-05-31 23:03 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-06-01 15:13 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-05-31 07:21 +0100
Re: Software (Non)Bloat (was Re: Rewriting SSA. Is This A Chance For GNU/Linux?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-02 23:56 +0000
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-05-31 13:46 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-05-31 22:24 +0100
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-05-31 15:02 -0700
Re: Rewriting SSA. Is This A Chance For GNU/Linux? Joel <joelcrump@gmail.com> - 2025-05-31 18:13 -0400
Re: Rewriting SSA. Is This A Chance For GNU/Linux? The Natural Philosopher <tnp@invalid.invalid> - 2025-05-31 23:29 +0100
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | "David W. Hodgins" <dwhodgins@nomail.afraid.org> |
|---|---|
| Date | 2025-04-03 02:00 -0400 |
| Message-ID | <op.24eyy4ija3w0dxdave@hodgins.homeip.net> |
| In reply to | #66815 |
On Wed, 02 Apr 2025 18:36:02 -0400, rbowman <bowman@montana.com> wrote: > On Wed, 2 Apr 2025 22:46:00 +0200, Carlos E.R. wrote: > >> So, to the complexity of handling old code, you add the complexities of >> translating to another language. >> >> Keep it simple: use today's COBOL. Less translation effort. Fewer >> errors. > > The problem may be finding competent COBOL programmers. That leads me to > another question. Presumably the SSA and other government agencies > currently employ COBOL programmers. What have they been doing the last > fifty years? > > A more important question might be what have their managers been doing? > There is no question a re-write would be very painful and expensive. For a > government agency there isn't a market force to improve so what would > trigger them doing anything to rock the boat? There is a lot more to those systems than just the COBOL programs. The data is in EBCDIC, not ASCII. Sequential files can be fixed or variable length. For fixed, the length of each record is specified in the file declaration, while for variable, the length is in the first bytes of each record. There is no character or combination of characters used to represent the end of a record. There can be ISAM and VSAM (indexed direct access) files, IMS (heirarchical) databases and data comunnication with MFS for the 3270 style screen handling, as well as DB2 databases all used by those COBOL programs. The COBOL programs may have ASM subroutines for the parts that had to be highly optimized. The systems are constantly under maintenance due to changes imposed by governements regulations or due to interfaces with other systems such as pc or cloud usage. Regards, Dave Hodgins
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-04-03 07:28 +0000 |
| Message-ID | <m56rk6F83ouU1@mid.individual.net> |
| In reply to | #66821 |
On Thu, 03 Apr 2025 02:00:30 -0400, David W. Hodgins wrote: > The data is in EBCDIC, not ASCII. Sequential files can be fixed or > variable length. For fixed, the length of each record is specified in > the file declaration, while for variable, the length is in the first > bytes of each record. There is no character or combination of characters > used to represent the end of a record. I don't see any of that to be a problem. Until quite recently a mid- western US state's criminal justice system used EBCDIC and the IBM protocol where the record lengths are specified in a known size hearer. When I wrote the interface it converted from ASCII to EBCDIC and vice versa on the fly. Lookup tables were necessary. I would hope all the data uses the same code page. All this is business as usual when dealing with data. Again hopefully they have maintained uniformity over the decades and it is not the situation of the Obamacare roll-out that had to deal with many companies and agencies that march to their own drummer.
[toc] | [prev] | [next] | [standalone]
| From | "David W. Hodgins" <dwhodgins@nomail.afraid.org> |
|---|---|
| Date | 2025-04-03 10:53 -0400 |
| Message-ID | <op.24fnm4aea3w0dxdave@hodgins.homeip.net> |
| In reply to | #66823 |
On Thu, 03 Apr 2025 03:28:07 -0400, rbowman <bowman@montana.com> wrote: > On Thu, 03 Apr 2025 02:00:30 -0400, David W. Hodgins wrote: > >> The data is in EBCDIC, not ASCII. Sequential files can be fixed or >> variable length. For fixed, the length of each record is specified in >> the file declaration, while for variable, the length is in the first >> bytes of each record. There is no character or combination of characters >> used to represent the end of a record. > > I don't see any of that to be a problem. Until quite recently a mid- > western US state's criminal justice system used EBCDIC and the IBM > protocol where the record lengths are specified in a known size hearer. > When I wrote the interface it converted from ASCII to EBCDIC and vice > versa on the fly. Lookup tables were necessary. I would hope all the data > uses the same code page. > > All this is business as usual when dealing with data. Again hopefully they > have maintained uniformity over the decades and it is not the situation of > the Obamacare roll-out that had to deal with many companies and agencies > that march to their own drummer. The conversion is easy once you have the data and fully understand the relationship between the various files and databases. Converting the use forward and reverse chile pointers in an IMS hierarchical database to the equivalent in DB2 databases can be done, provided the person doing the conversion understands the purpose and use of the pointers. Some of the PL/1 programs I worked on used 15 dimensional tables (the max allowed in PL/1). Learning the data structures used, both in databases and within programs takes time. There are Panvalet (and other) file storage systems in addition to the databases and "regular files". There are a lot of parts developed over decades that all have to keep working in conjunction with each other. Regards, Dave Hodgins
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-04-03 06:11 -0400 |
| Message-ID | <lDWdnfaNTfBFw3P6nZ2dnZfqn_GdnZ2d@giganews.com> |
| In reply to | #66821 |
On 4/3/25 2:00 AM, David W. Hodgins wrote: > On Wed, 02 Apr 2025 18:36:02 -0400, rbowman <bowman@montana.com> wrote: > >> On Wed, 2 Apr 2025 22:46:00 +0200, Carlos E.R. wrote: >> >>> So, to the complexity of handling old code, you add the complexities of >>> translating to another language. >>> >>> Keep it simple: use today's COBOL. Less translation effort. Fewer >>> errors. >> >> The problem may be finding competent COBOL programmers. That leads me to >> another question. Presumably the SSA and other government agencies >> currently employ COBOL programmers. What have they been doing the last >> fifty years? >> >> A more important question might be what have their managers been doing? >> There is no question a re-write would be very painful and expensive. >> For a >> government agency there isn't a market force to improve so what would >> trigger them doing anything to rock the boat? > > There is a lot more to those systems than just the COBOL programs. > > The data is in EBCDIC, not ASCII. Sequential files can be fixed or > variable length. > For fixed, the length of each record is specified in the file > declaration, while for > variable, the length is in the first bytes of each record. There is no > character or > combination of characters used to represent the end of a record. > > There can be ISAM and VSAM (indexed direct access) files, IMS > (heirarchical) databases > and data comunnication with MFS for the 3270 style screen handling, as > well as DB2 > databases all used by those COBOL programs. > > The COBOL programs may have ASM subroutines for the parts that had to be > highly > optimized. > > The systems are constantly under maintenance due to changes imposed by > governements > regulations or due to interfaces with other systems such as pc or cloud > usage. > > Regards, Dave Hodgins You're seeing the True Picture - It's *not* "easy" to re-write at all. And if you get it wrong there's all hell to pay. Which is why bcrats are hyper-conservative in these regards. They have good jobs/pensions to protect. IMHO, any re-write will HAVE to involve a 'parallel system' for awhile ... give it the same data, the same tasks, and eval if it's always doing the same thing as the old stuff. THEN, in a few years, quietly switch.
[toc] | [prev] | [next] | [standalone]
| From | "David W. Hodgins" <dwhodgins@nomail.afraid.org> |
|---|---|
| Date | 2025-04-03 11:12 -0400 |
| Message-ID | <op.24fojgcka3w0dxdave@hodgins.homeip.net> |
| In reply to | #66830 |
On Thu, 03 Apr 2025 06:11:37 -0400, c186282 <c186282@nnada.net> wrote: <snip> > You're seeing the True Picture - It's *not* "easy" to > re-write at all. > > And if you get it wrong there's all hell to pay. > > Which is why bcrats are hyper-conservative in these > regards. They have good jobs/pensions to protect. > > IMHO, any re-write will HAVE to involve a 'parallel system' > for awhile ... give it the same data, the same tasks, and > eval if it's always doing the same thing as the old stuff. > THEN, in a few years, quietly switch. The problem is people come in who do not understand how many parts there are or are willing to spend the time to learn. They look at one small part such as the code for the main module, and think it's easy to convert. They rush the conversion, and only after they start using the new versions, learn that they missed or misunderstood many of the edge cases. They then get wrong results, but insist their results are correct! There are many languages used, not just COBOL Some of the ones I worked with include Fortran, PL/1, RPG III, Mark IV, ADF, ASM (360/370), Even simple looking things like MFS code for screen definitions has quirks that are not going to be obvious to anyone who has not encountered them. For example, in a 3270 style terminal where an input field is restricted to numeric, uppercase letters are still allowed. It's done that way to allow for signed numeric fields. In EBCDIC, the zoned decimal value for minus one and the capital letter D both use the same hexadecimal value. Plus one is "C". With edge cases, the problem is that the person doing the conversion doesn't understand that they exist, so they don't include them in test data, and don't encounter them during any parallel testing. Later, the system fails to handle the edge cases. Regards, Dave Hodgins
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-04-03 12:20 -0400 |
| Message-ID | <rbidnR1kQNbQKHP6nZ2dnZfqn_GdnZ2d@giganews.com> |
| In reply to | #66842 |
On 4/3/25 11:12 AM, David W. Hodgins wrote: > On Thu, 03 Apr 2025 06:11:37 -0400, c186282 <c186282@nnada.net> wrote: > <snip> >> You're seeing the True Picture - It's *not* "easy" to >> re-write at all. >> >> And if you get it wrong there's all hell to pay. >> >> Which is why bcrats are hyper-conservative in these >> regards. They have good jobs/pensions to protect. >> >> IMHO, any re-write will HAVE to involve a 'parallel system' >> for awhile ... give it the same data, the same tasks, and >> eval if it's always doing the same thing as the old stuff. >> THEN, in a few years, quietly switch. > > The problem is people come in who do not understand how many parts there > are or > are willing to spend the time to learn. They look at one small part such > as the code > for the main module, and think it's easy to convert. > > They rush the conversion, and only after they start using the new > versions, learn that > they missed or misunderstood many of the edge cases. > > They then get wrong results, but insist their results are correct! > > There are many languages used, not just COBOL Some of the ones I worked > with include > Fortran, PL/1, RPG III, Mark IV, ADF, ASM (360/370), > > Even simple looking things like MFS code for screen definitions has > quirks that are not > going to be obvious to anyone who has not encountered them. > > For example, in a 3270 style terminal where an input field is restricted > to numeric, uppercase > letters are still allowed. > > It's done that way to allow for signed numeric fields. In EBCDIC, the > zoned decimal value for > minus one and the capital letter D both use the same hexadecimal value. > Plus one is "C". > > With edge cases, the problem is that the person doing the conversion > doesn't understand that > they exist, so they don't include them in test data, and don't encounter > them during any parallel > testing. Later, the system fails to handle the edge cases. > > Regards, Dave Hodgins Aww ... just give 'em a copy of "COBOL For Total Idiots" and it'll all be just fine :-) Anyway, I do see where all those jagged little edges can totally confound anybody attempting conversions from the original sources. A sort of work-around is a functional understanding of the original - hardly ever look at the source - and then reproduce the function in a 'newer and better' lang/system. In short, GM didn't have to reproduce a Model-T, just have an idea of what cars were expected to do, what some of the parts should look kind-of look like. Then their own people could build a relative work-alike. Dealing with decades of the old RECORDS ... there's a pain regardless.
[toc] | [prev] | [next] | [standalone]
| From | "David W. Hodgins" <dwhodgins@nomail.afraid.org> |
|---|---|
| Date | 2025-04-03 13:05 -0400 |
| Message-ID | <op.24ftq3zla3w0dxdave@hodgins.homeip.net> |
| In reply to | #66845 |
On Thu, 03 Apr 2025 12:20:31 -0400, c186282 <c186282@nnada.net> wrote: <snip> > Dealing with decades of the old RECORDS ... there's > a pain regardless. I remember one of my first tasks in 1979 was converting a file from card storage to disk. 14 boxes of Hollerith punch cards. One of the boxes, I found a pen in the box laying length ways under the middle of the cards. The cards had been punched either in a machine that did not have a printer included, or where the ribbon had dried out so the top of the cards did not have the printed equivalent of what was punched. I had to duplicate the cards by manually reading the punch codes. Had two other people verifying each card I punched. That was one of the worst data storage conversion I ever had to deal with. Regards, Dave Hodgins
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-04-03 10:53 +0100 |
| Message-ID | <vsllqk$bemd$1@dont-email.me> |
| In reply to | #66815 |
On 02/04/2025 23:36, rbowman wrote: > On Wed, 2 Apr 2025 22:46:00 +0200, Carlos E.R. wrote: > >> So, to the complexity of handling old code, you add the complexities of >> translating to another language. >> >> Keep it simple: use today's COBOL. Less translation effort. Fewer >> errors. > > The problem may be finding competent COBOL programmers. That leads me to > another question. Presumably the SSA and other government agencies > currently employ COBOL programmers. What have they been doing the last > fifty years? > > A more important question might be what have their managers been doing? > There is no question a re-write would be very painful and expensive. For a > government agency there isn't a market force to improve so what would > trigger them doing anything to rock the boat? > The problem is that say 50 years ago someone brought in a COBOL house - might have been IBM - to analyse the business and write COBOL. Then they left. For a few years they paid a maintenance contract and those guys came back and fixed every bug and write all the extensions needed. The the accountants noticed that no one had called them in for two years, and cancelled the maintenance contract. And that was 40 years ago. And its worked ever since. Round wheels still work. Even wooden ones -- There’s a mighty big difference between good, sound reasons and reasons that sound good. Burton Hillis (William Vaughn, American columnist)
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-04-03 13:44 +0200 |
| Message-ID | <6t82clxnbu.ln2@Telcontar.valinor> |
| In reply to | #66815 |
On 2025-04-03 00:36, rbowman wrote: > On Wed, 2 Apr 2025 22:46:00 +0200, Carlos E.R. wrote: > >> So, to the complexity of handling old code, you add the complexities of >> translating to another language. >> >> Keep it simple: use today's COBOL. Less translation effort. Fewer >> errors. > > The problem may be finding competent COBOL programmers. That leads me to > another question. Presumably the SSA and other government agencies > currently employ COBOL programmers. What have they been doing the last > fifty years? So, train them. Think long term, train them, and offer them a long career, with a binding contract, so that it is worth their while. Something the current USA administration can not offer. And do this before the old gazers die and can not teach the recruits anymore. What have they been doing? Just coping. > A more important question might be what have their managers been doing? > There is no question a re-write would be very painful and expensive. For a > government agency there isn't a market force to improve so what would > trigger them doing anything to rock the boat? > -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-04-03 18:26 +0000 |
| Message-ID | <m5826aFe093U1@mid.individual.net> |
| In reply to | #66839 |
On Thu, 3 Apr 2025 13:44:06 +0200, Carlos E.R. wrote: > Think long term, train them, and offer them a long career, with a > binding contract, so that it is worth their while. Something the current > USA administration can not offer. Maybe. I doubt you would get the best and brightest but that isn't what you would want anyway.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-04-03 17:12 -0400 |
| Message-ID | <wdadnQ8ojftHZHP6nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #66852 |
On 4/3/25 2:26 PM, rbowman wrote: > On Thu, 3 Apr 2025 13:44:06 +0200, Carlos E.R. wrote: > >> Think long term, train them, and offer them a long career, with a >> binding contract, so that it is worth their while. Something the current >> USA administration can not offer. > > Maybe. I doubt you would get the best and brightest but that isn't what > you would want anyway. Note a significant SOCIAL shift in the USA as well. By the 80s people stopped being so interested in "careers" - they'd jump companies often, even jump job types. It's even worse now, seriously worse. Means nobody becomes "experts" in the usual sense of the word. Economic factors with corps also played a role - lots of mergers and breakups and outsourcing escalated in the 80s so even if you WANTED 50 years with XYZ Inc the company would disappear LONG before that. Only the federal govt still offered the needed 'stability'.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-04-04 00:03 +0000 |
| Message-ID | <m58lu2FguqjU1@mid.individual.net> |
| In reply to | #66864 |
On Thu, 3 Apr 2025 17:12:53 -0400, c186282 wrote: > Note a significant SOCIAL shift in the USA as well. > By the 80s people stopped being so interested in "careers" - they'd > jump companies often, even jump job types. I never went looking for a career. My eyes would glaze over when potential employers would start talking about pension plans and so forth. It was always about the next challenge. I slowed down in my 50s, found a place I wanted to stay, and was lucky enough to find a job that required frequent new interfaces and gave me the latitude for my skunk works projects. It's been interesting but I guess I'm not going to get a gold watch.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-04-03 22:50 -0400 |
| Message-ID | <JQOdnZUlVJa21HL6nZ2dnZfqn_adnZ2d@giganews.com> |
| In reply to | #66866 |
On 4/3/25 8:03 PM, rbowman wrote: > On Thu, 3 Apr 2025 17:12:53 -0400, c186282 wrote: > >> Note a significant SOCIAL shift in the USA as well. >> By the 80s people stopped being so interested in "careers" - they'd >> jump companies often, even jump job types. > > I never went looking for a career. My eyes would glaze over when potential > employers would start talking about pension plans and so forth. It was > always about the next challenge. > > I slowed down in my 50s, found a place I wanted to stay, and was lucky > enough to find a job that required frequent new interfaces and gave me the > latitude for my skunk works projects. > > It's been interesting but I guess I'm not going to get a gold watch. I got lucky and found a smallish but INTERESTING concern kinda early on. 40+ years later .... The latest boss wasn't interested in 'research' or DIY and hated the word "Linux" .... so it was time to retire. Just Office365 and Cloud ... like ALL the good ordinary places. Then you can't be "criticized" ........
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-04-04 06:00 +0000 |
| Message-ID | <m59ashFk3g2U2@mid.individual.net> |
| In reply to | #66870 |
On Thu, 3 Apr 2025 22:50:59 -0400, c186282 wrote: > The latest boss wasn't interested in 'research' or DIY and hated the > word "Linux" .... so it was time to retire. Just Office365 and Cloud > ... like ALL the good ordinary places. Then you can't be "criticized" > ........ The division I worked for retired. A few of the sites are on extended support so I pick up a few hours if I have to step in to help the remaining support people so I'm not 100% officially retired. I had no desire to move to the other division -- completely different culture.
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2025-04-06 08:52 +0000 |
| Message-ID | <67f240d5$0$29723$426a74cc@news.free.fr> |
| In reply to | #66864 |
Le 03-04-2025, c186282 <c186282@nnada.net> a écrit : > > It's even worse now, seriously worse. Means nobody > becomes "experts" in the usual sense of the word. I don't know why it's like that in the entire world, but in France, the reason is obvious. The company refuse to take into account technical skills. If you want to increase your salary, you have to switch to management. So, as nobody wants to become the most important guy in the company with the lowest salary, there is no more experts. And most importantly, things evolved very fast, so if you become an expert on something which disappear, you switch very fast from very required guy to useless guy. So, before becoming an expert, you need to be sure your skills will stay useful until you retire. Which is difficult if you are young. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2025-04-06 10:14 +0100 |
| Message-ID | <wwv1pu5ircs.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #66952 |
Stéphane CARPENTIER <sc@fiat-linux.fr> writes: > Le 03-04-2025, c186282 <c186282@nnada.net> a écrit : > >> It's even worse now, seriously worse. Means nobody >> becomes "experts" in the usual sense of the word. > > I don't know why it's like that in the entire world, but in France, the > reason is obvious. The company refuse to take into account technical > skills. If you want to increase your salary, you have to switch to > management. So, as nobody wants to become the most important guy in the > company with the lowest salary, there is no more experts. I think the issue is general, and so are the exceptions to it. On the one hand I’ve heard similar complaints about UK and US employers. On the other hand when we were owned by a French company they were very clear about their grade structure branching into management and technical tracks past a certain point, and they did actually implement this; at no point did they make the mistake of asking me to do any line management. > And most importantly, things evolved very fast, so if you become an > expert on something which disappear, you switch very fast from very > required guy to useless guy. So, before becoming an expert, you need to > be sure your skills will stay useful until you retire. Which is > difficult if you are young. Specializing in the wrong thing is certainly a risk. For any given technology it’s useful to be able to look past what its boosters (and detractors) say about it to whether it does anything useful in reality. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2025-04-06 11:13 +0000 |
| Message-ID | <67f261ed$0$5197$426a74cc@news.free.fr> |
| In reply to | #66957 |
Le 06-04-2025, Richard Kettlewell <invalid@invalid.invalid> a écrit : > Stéphane CARPENTIER <sc@fiat-linux.fr> writes: >> Le 03-04-2025, c186282 <c186282@nnada.net> a écrit : >> >>> It's even worse now, seriously worse. Means nobody >>> becomes "experts" in the usual sense of the word. >> >> I don't know why it's like that in the entire world, but in France, the >> reason is obvious. The company refuse to take into account technical >> skills. If you want to increase your salary, you have to switch to >> management. So, as nobody wants to become the most important guy in the >> company with the lowest salary, there is no more experts. > > I think the issue is general, and so are the exceptions to it. On the > one hand I’ve heard similar complaints about UK and US employers. I'm not well informed on the US employers. I heard one can be a programmer in US with a very good salary which is impossible in France. I mean compared with a manager, not compared with a low job salary. Now, I know that in US the salary are higher than in France. Which is very good for a young guy without kid. For someone with kids, the difference in salary isn't as good. And for an older guy with health issues, the difference in salary isn't as good, neither. So, I don't really know and it's very difficult to compare the salaries between France and US because the taxes are very different. >> And most importantly, things evolved very fast, so if you become an >> expert on something which disappear, you switch very fast from very >> required guy to useless guy. So, before becoming an expert, you need to >> be sure your skills will stay useful until you retire. Which is >> difficult if you are young. > > Specializing in the wrong thing is certainly a risk. For any given > technology it’s useful to be able to look past what its boosters (and > detractors) say about it to whether it does anything useful in reality. It's very difficult to know how to specialize. And today more than ever because of the AI. One can know what AI can do today and what it can't do. But one can't know what it will be able to do tomorrow. And one can't know how it will be used tomorrow. One can have guesses, but one can't know. One thing is sure: some jobs will be impacted. For some jobs the impact can be easy to guess, but it remains a guess. Which can be proven wrong with AI evolution. I'm not saying AI are good or bad. I'm just saying AI will impact jobs. And I'm saying the impact is impossible to know for sure. Some can have strong opinion about it, it still remain some guess impossible to prove. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-04-06 16:58 +0000 |
| Message-ID | <m5fq5dFl467U2@mid.individual.net> |
| In reply to | #66952 |
On 06 Apr 2025 08:52:37 GMT, Stéphane CARPENTIER wrote: > And most importantly, things evolved very fast, so if you become an > expert on something which disappear, you switch very fast from very > required guy to useless guy. So, before becoming an expert, you need to > be sure your skills will stay useful until you retire. Which is > difficult if you are young. You need to become an expert at keeping up.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-04-01 17:35 +0000 |
| Message-ID | <m52mefFi3nfU4@mid.individual.net> |
| In reply to | #66771 |
On Tue, 1 Apr 2025 14:40:27 -0000 (UTC), Robert Heller wrote: > It should be noted that GnuCOBOL actually translates COBOL to C, and > then compiles the C code with GnuC. In *theory* one could just run the > whole code base through GnuCOBOL and create a C code base, but good luck > making much sense of the generated C code... I never did it with COBOL but I did use 'f2c' to generate C code from Fortran. When I saw the results I wrote the C code manually. It probably would have compiled and ran but it was not maintainable. I've seen more readable output from disassemblers.
[toc] | [prev] | [next] | [standalone]
| From | Robert Heller <heller@deepsoft.com> |
|---|---|
| Date | 2025-04-01 19:30 +0000 |
| Message-ID | <vshetb$3shon$1@dont-email.me> |
| In reply to | #66773 |
Yes, one of the things I did when I was working at UMass was to convert some FORTRAN code to C and yes, automated tool commonly did either a poor job or created code that was not maintainable or readable. (And some of the code needed to be made multi-threaded for parallelization.) At 1 Apr 2025 17:35:11 GMT rbowman <bowman@montana.com> wrote: > > On Tue, 1 Apr 2025 14:40:27 -0000 (UTC), Robert Heller wrote: > > > It should be noted that GnuCOBOL actually translates COBOL to C, and > > then compiles the C code with GnuC. In *theory* one could just run the > > whole code base through GnuCOBOL and create a C code base, but good luck > > making much sense of the generated C code... > > I never did it with COBOL but I did use 'f2c' to generate C code from > Fortran. When I saw the results I wrote the C code manually. It probably > would have compiled and ran but it was not maintainable. I've seen more > readable output from disassemblers. > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller@deepsoft.com -- Webhosting Services
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web