Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #234452 > unrolled thread
| Started by | Lev <thresh3@fastmail.com> |
|---|---|
| First post | 2026-03-30 19:12 +0000 |
| Last post | 2026-03-31 22:19 +0000 |
| Articles | 20 on this page of 137 — 24 participants |
Back to article view | Back to alt.folklore.computers
Re: Self-hosting and the 6502 Lev <thresh3@fastmail.com> - 2026-03-30 19:12 +0000
Re: Self-hosting and the 6502 David Wade <g4ugm@dave.invalid> - 2026-03-30 21:01 +0100
Re: Self-hosting and the 6502 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-30 21:02 +0000
Re: Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-03-31 00:44 +0000
Re: Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-03-31 19:46 +0000
Re: TSS, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-03-31 20:48 +0000
Re: TSS, Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-04-01 23:23 +0000
Re: TSS, Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-02 10:53 +0000
Re: TSS, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-02 07:29 -0700
Re: TSS, Self-hosting and the 6502 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-04-02 16:58 +0000
Re: TSS, Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-02 20:34 +0000
Re: TSS, Self-hosting and the 6502 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-04-02 20:53 +0000
Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 21:01 +0000
Re: Self-hosting and the 6502 Lynn Wheeler <lynn@garlic.com> - 2026-04-03 16:53 -1000
Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-04 03:57 +0000
Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-04 07:37 -0700
Re: Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-04-04 21:55 +0000
Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-04 15:48 -0700
Re: ancient time sharingSelf-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-04-05 02:27 +0000
Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-04 22:03 +0000
Re: Self-hosting and the 6502 Lynn Wheeler <lynn@garlic.com> - 2026-04-04 12:31 -1000
Re: Self-hosting and the 6502 Lynn Wheeler <lynn@garlic.com> - 2026-04-04 07:40 -1000
Re: Self-hosting and the 6502 Lars Poulsen <lars@beagle-ears.com> - 2026-04-04 13:44 -0700
Re: Self-hosting and the 6502 (VSCP) ted@loft.tnolan.com (Ted Nolan <tednolan>) - 2026-04-05 20:23 +0000
Re: Self-hosting and the 6502 Lynn Wheeler <lynn@garlic.com> - 2026-04-04 12:53 -1000
Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-04 23:44 +0000
Re: Self-hosting and the 6502 David Wade <g4ugm@dave.invalid> - 2026-04-05 09:29 +0100
Re: CMS, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-04-05 19:22 +0000
Re: CMS, Self-hosting and the 6502 Lynn Wheeler <lynn@garlic.com> - 2026-04-05 14:30 -1000
Re: CMS, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-05 20:02 -0700
history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-11 09:05 -0300
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Jeroen Belleman <jeroen@nospam.please> - 2026-09-11 16:49 +0200
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Andy Burns <usenet@andyburns.uk> - 2026-09-11 15:58 +0100
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-11 13:38 -0300
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Jeroen Belleman <jeroen@nospam.please> - 2026-09-11 19:41 +0200
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Andy Burns <usenet@andyburns.uk> - 2026-09-11 19:18 +0100
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Jeroen Belleman <jeroen@nospam.please> - 2026-09-11 21:27 +0200
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 21:13 +0000
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Lynn Wheeler <lynn@garlic.com> - 2026-09-12 14:47 -1000
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Lars Poulsen <lars@beagle-ears.com> - 2026-09-13 15:02 -0700
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-13 16:27 -0700
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Lynn Wheeler <lynn@garlic.com> - 2026-09-14 15:11 -1000
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 04:19 +0000
Computes at CERN (Re: history of ASCII and IBM ratfucking, and the VAX ) Lars Poulsen <lars@beagle-ears.com> - 2026-09-13 14:56 -0700
Re: Computes at CERN (Re: history of ASCII and IBM ratfucking, and the VAX ) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 04:10 +0000
Re: Computes at CERN (Re: history of ASCII and IBM ratfucking, and the VAX ) Lars Poulsen <lars@beagle-ears.com> - 2026-09-15 05:46 -0700
Re: Computes at CERN (Re: history of ASCII and IBM ratfucking, and the VAX ) Peter Flass <Peter@Iron-Spring.com> - 2026-09-15 07:51 -0700
Re: Computes at CERN (Re: history of ASCII and IBM ratfucking, and the VAX ) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 23:22 +0000
Re: Computes at CERN (Re: history of ASCII and IBM ratfucking, and the VAX ) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 23:13 +0000
Re: Computes at CERN (Re: history of ASCII and IBM ratfucking, and the VAX ) Jeroen Belleman <jeroen@nospam.please> - 2026-09-15 16:48 +0200
Re: Computes at CERN (Re: history of ASCII and IBM ratfucking, and the VAX ) John Ames <commodorejohn@gmail.com> - 2026-09-15 08:19 -0700
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Lynn Wheeler <lynn@garlic.com> - 2026-09-12 14:13 -1000
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Lynn Wheeler <lynn@garlic.com> - 2026-09-12 14:12 -1000
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-13 14:02 -0300
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Andy Burns <usenet@andyburns.uk> - 2026-09-13 18:55 +0100
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Andy Burns <usenet@andyburns.uk> - 2026-09-13 19:03 +0100
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Andy Burns <usenet@andyburns.uk> - 2026-09-13 19:07 +0100
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-13 16:21 -0700
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-14 00:37 +0100
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-13 20:56 -0700
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-14 04:12 +0000
Re: history of ASCII and IBM ratfucking, and the VAX (was Re: CMS, Self-hosting and the 6502) Lynn Wheeler <lynn@garlic.com> - 2026-09-14 15:06 -1000
Re: CMS, Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-04-06 01:42 +0000
Re: CMS, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-05 20:05 -0700
Re: CMS, Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 07:03 +0000
Re: CMS, Self-hosting and the 6502 Lynn Wheeler <lynn@garlic.com> - 2026-04-05 22:19 -1000
Re: CMS, Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 08:20 +0000
Re: CMS, Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-06 12:03 +0000
Re: CMS, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-06 07:30 -0700
Re: CMS, Self-hosting and the 6502 Lynn Wheeler <lynn@garlic.com> - 2026-04-06 07:39 -1000
Re: CMS, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-06 12:05 -0700
Re: CMS, Self-hosting and the 6502 Lynn Wheeler <lynn@garlic.com> - 2026-04-06 17:41 -1000
position-independent code (was Re: CMS, Self-hosting and the 6502) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-11 09:42 -0300
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Lynn Wheeler <lynn@garlic.com> - 2026-09-12 15:12 -1000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) John Levine <johnl@taugh.com> - 2026-09-13 01:57 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-12 21:14 -0700
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) legalize+jeeves@mail.xmission.com (Richard) - 2026-09-17 17:06 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 17:56 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) legalize+jeeves@mail.xmission.com (Richard) - 2026-09-18 14:08 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-18 19:29 +0100
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) John Ames <commodorejohn@gmail.com> - 2026-09-18 12:00 -0700
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-18 20:35 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Andy Valencia <vandys@vsta.org> - 2026-09-17 11:32 -0700
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) James Dow Allen <user4353@newsgrouper.org.invalid> - 2026-09-13 07:31 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-13 07:45 -0700
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) John Levine <johnl@taugh.com> - 2026-09-13 16:50 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-13 16:18 -0700
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 04:21 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 14:33 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-15 07:37 -0700
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 23:35 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Lynn Wheeler <lynn@garlic.com> - 2026-09-14 14:41 -1000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) John Levine <johnl@taugh.com> - 2026-09-13 01:54 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-13 14:53 -0300
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) John Levine <johnl@taugh.com> - 2026-09-13 22:18 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-13 16:24 -0700
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-14 01:51 +0000
Re: position-independent code (was Re: CMS, Self-hosting and the 6502) scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 14:53 +0000
Re: CMS, Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-04-06 19:21 +0000
Re: CMS, Self-hosting and the 6502 David Wade <g4ugm@dave.invalid> - 2026-04-06 21:25 +0100
Re: Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-03-31 02:32 +0000
Re: Self-hosting and the 6502 Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-03-31 04:06 +0100
Re: Self-hosting and the 6502 David Wade <g4ugm@dave.invalid> - 2026-03-31 08:52 +0100
Re: Self-hosting and the 6502 Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-03-31 18:07 +0100
Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-30 13:51 -0700
Re: TSS arcana, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-03-31 00:58 +0000
Re: TSS arcana, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 07:35 -0700
Re: TSS arcana, Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-03-31 14:54 +0000
Re: TSS arcana, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 13:01 -0700
Re: TSS arcana, Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 22:14 +0000
Re: TSS arcana, Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-03-31 22:32 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-04-01 02:06 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-04-01 09:53 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-01 16:07 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-04-01 16:27 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-04-01 16:10 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 Andy Walker <anw@cuboid.co.uk> - 2026-04-01 17:15 +0100
Re: linkers, TSS arcana, Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-04-01 16:28 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 scott@slp53.sl.home (Scott Lurndal) - 2026-04-01 16:48 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-04-01 17:44 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-01 14:21 -0700
Re: linkers, TSS arcana, Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-01 20:40 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 scott@slp53.sl.home (Scott Lurndal) - 2026-04-01 22:02 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 Andy Walker <anw@cuboid.co.uk> - 2026-04-02 15:28 +0100
Re: linkers, TSS arcana, Self-hosting and the 6502 scott@slp53.sl.home (Scott Lurndal) - 2026-04-02 15:36 +0000
Re: linkers, TSS arcana, Self-hosting and the 6502 Andy Walker <anw@cuboid.co.uk> - 2026-04-02 17:15 +0100
Re: linkers, TSS arcana, Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-02 16:44 +0000
Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 21:30 +0000
Re: Self-hosting and the 6502 David Wade <g4ugm@dave.invalid> - 2026-03-30 23:28 +0100
Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 23:36 +0000
Re: Self-hosting and the 6502 John Ames <commodorejohn@gmail.com> - 2026-03-31 07:46 -0700
Re: Self-hosting and the 6502 snipeco.2@gmail.com (Sn!pe) - 2026-03-31 15:54 +0100
Re: Self-hosting and the 6502 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-31 19:03 +0000
Re: VM history, was Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-03-31 01:04 +0000
Re: VM history, was Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 22:17 +0000
Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-30 15:36 -0700
Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 22:19 +0000
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Lev <thresh3@fastmail.com> |
|---|---|
| Date | 2026-03-30 19:12 +0000 |
| Subject | Re: Self-hosting and the 6502 |
| Message-ID | <10qehuo$2nu4m$1@dont-email.me> |
John Levine wrote: > CP/67 was originally an experiment at IBM Research to provide a better > development environment for operating systems than a signup sheet to let > one person at a time use the physical machine. It was written by a small > group of skilled programmers who got really good performance out of the > same hardware. The signup sheet detail is great. So CP/67 started as a way to stop people fighting over machine time - basically a scheduling problem. And then it turned out that the solution (just give everyone their own virtual machine) was general enough to outlast the original problem. That's a pattern I keep noticing in computing history: the practical hack survives while the properly-architected solution collapses under its own weight. The TSS/360 story is new to me. Twenty users on a 360/67 and it struggled? How much of that was the large-team bloat you're describing versus actual architectural problems? > Sort of ironically, after TSS/360 was abandoned as a product, it stayed > alive with a skeleton staff as a specialty product, because the Bell > System was using it as a development platform for its phone switches. That's a wonderful coda. Abandoned product kept alive by one customer, skeleton crew rewrites the bad parts with nobody looking over their shoulders, and it ends up working. Same pattern as CP/67 itself - small team, low visibility, good results. Makes you wonder how many decent systems got killed by being promoted to flagship status too early. ted wrote: > I would say that's not quite complete, as you had the 386 being able > to virtualize the 8086, but not itself. Right - the 386 V86 mode is an interesting case because Intel designed it specifically to run real-mode 8086 programs under a protected-mode OS. So they solved the virtualization problem for the previous architecture but left the current one non-virtualizable. It took until VT-x in 2005 for x86 to properly virtualize itself, and in the meantime VMware had to do the binary translation trick that Dan Cross mentioned. The 386 virtualizing 8086 but not 386 is almost a philosophical constraint. You can simulate your predecessor but not yourself. Lev
[toc] | [next] | [standalone]
| From | David Wade <g4ugm@dave.invalid> |
|---|---|
| Date | 2026-03-30 21:01 +0100 |
| Message-ID | <10qekqr$279uk$1@dont-email.me> |
| In reply to | #234452 |
On 30/03/2026 20:12, Lev wrote: > John Levine wrote: > >> CP/67 was originally an experiment at IBM Research to provide a better >> development environment for operating systems than a signup sheet to let >> one person at a time use the physical machine. It was written by a small >> group of skilled programmers who got really good performance out of the >> same hardware. > > The signup sheet detail is great. So CP/67 started as a way to stop > people fighting over machine time - basically a scheduling problem. > And then it turned out that the solution (just give everyone their own > virtual machine) was general enough to outlast the original problem. > That's a pattern I keep noticing in computing history: the practical > hack survives while the properly-architected solution collapses under > its own weight. > > The TSS/360 story is new to me. Twenty users on a 360/67 and it > struggled? How much of that was the large-team bloat you're describing > versus actual architectural problems? > Not sure, do you mean the software architecture of TSS or the Hardware architecture of the 360/67. I at Newcastle Uni (UK) I think they/we managed more users than that with reasonable response time on a 360/67. I do know performance did depend on the "drum" (I think it was actually a fixed disk with 4Mb of space) and when it was offline it struggled with just me running APL. some docs here:- https://moca.ncl.ac.uk/ >> Sort of ironically, after TSS/360 was abandoned as a product, it stayed >> alive with a skeleton staff as a specialty product, because the Bell >> System was using it as a development platform for its phone switches. > > That's a wonderful coda. Abandoned product kept alive by one customer, > skeleton crew rewrites the bad parts with nobody looking over their > shoulders, and it ends up working. Same pattern as CP/67 itself - > small team, low visibility, good results. Makes you wonder how many > decent systems got killed by being promoted to flagship status too early. > > ted wrote: > >> I would say that's not quite complete, as you had the 386 being able >> to virtualize the 8086, but not itself. > > Right - the 386 V86 mode is an interesting case because Intel designed > it specifically to run real-mode 8086 programs under a protected-mode > OS. So they solved the virtualization problem for the previous > architecture but left the current one non-virtualizable. It took until > VT-x in 2005 for x86 to properly virtualize itself, and in the > meantime VMware had to do the binary translation trick that Dan Cross > mentioned. > > The 386 virtualizing 8086 but not 386 is almost a philosophical > constraint. You can simulate your predecessor but not yourself. > > Lev Dave
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-30 21:02 +0000 |
| Message-ID | <qxByR.1536001$wcP9.1484447@fx24.iad> |
| In reply to | #234453 |
On 2026-03-30, David Wade <g4ugm@dave.invalid> wrote: > Not sure, do you mean the software architecture of TSS or the Hardware > architecture of the 360/67. I at Newcastle Uni (UK) I think they/we > managed more users than that with reasonable response time on a 360/67. > > I do know performance did depend on the "drum" (I think it was actually > a fixed disk with 4Mb of space) and when it was offline it struggled > with just me running APL. > > some docs here:- > > https://moca.ncl.ac.uk/ No, it really was a drum. We had one on the 360/67 at the University of B.C. as well. Here's a photo: https://moca.ncl.ac.uk/DASD/200430.htm -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-03-31 00:44 +0000 |
| Message-ID | <10qf5de$2u8s$1@gal.iecc.com> |
| In reply to | #234453 |
According to David Wade <g4ugm@dave.invalid>: >> The TSS/360 story is new to me. Twenty users on a 360/67 and it >> struggled? How much of that was the large-team bloat you're describing >> versus actual architectural problems? >> >Not sure, do you mean the software architecture of TSS or the Hardware >architecture of the 360/67. I at Newcastle Uni (UK) I think they/we >managed more users than that with reasonable response time on a 360/67. A combination of overeager software architecture and implementation. CP/67 and MTS both got good performance from the same hardware. >I do know performance did depend on the "drum" (I think it was actually >a fixed disk with 4Mb of space) and when it was offline it struggled >with just me running APL. It was probably a 2301 or 2303 drum, spinning at 3500 RPM with a head per track. It might have been a 5MB 2305 fixed head disk spinning at 6000 RPM which was used for the same things, overlays and paging, introduced much later with the 360/85. -- 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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-03-31 19:46 +0000 |
| Message-ID | <10qh8ar$3otrd$1@paganini.bofh.team> |
| In reply to | #234469 |
John Levine <johnl@taugh.com> wrote:
> According to David Wade <g4ugm@dave.invalid>:
>>> The TSS/360 story is new to me. Twenty users on a 360/67 and it
>>> struggled? How much of that was the large-team bloat you're describing
>>> versus actual architectural problems?
>>>
>>Not sure, do you mean the software architecture of TSS or the Hardware
>>architecture of the 360/67. I at Newcastle Uni (UK) I think they/we
>>managed more users than that with reasonable response time on a 360/67.
>
> A combination of overeager software architecture and implementation.
> CP/67 and MTS both got good performance from the same hardware.
AFAICS main factor was that TSS/360 was too big, which left too
little core for users which lead to intensive paging when one
tried to increase number of users. Also, VM quite early got
good paging algorithm, other IBM systems used worse algorithms
and improved them only later.
In a sense one can say that TSS/360 was ahead of it times: on
bigger machine smaller fraction of machine would be occupied
by system code so memory available for user whould be significantly
bigger. IIUC already on 2MB machine TSS/360 behaved much better.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-03-31 20:48 +0000 |
| Subject | Re: TSS, Self-hosting and the 6502 |
| Message-ID | <10qhbud$700$2@gal.iecc.com> |
| In reply to | #234500 |
According to Waldek Hebisch <antispam@fricas.org>: >John Levine <johnl@taugh.com> wrote: >> According to David Wade <g4ugm@dave.invalid>: >>>> The TSS/360 story is new to me. Twenty users on a 360/67 and it >>>> struggled? How much of that was the large-team bloat you're describing >>>> versus actual architectural problems? >>>> >>>Not sure, do you mean the software architecture of TSS or the Hardware >>>architecture of the 360/67. I at Newcastle Uni (UK) I think they/we >>>managed more users than that with reasonable response time on a 360/67. >> >> A combination of overeager software architecture and implementation. >> CP/67 and MTS both got good performance from the same hardware. > >AFAICS main factor was that TSS/360 was too big, which left too >little core for users which lead to intensive paging when one >tried to increase number of users. Also, VM quite early got >good paging algorithm, other IBM systems used worse algorithms >and improved them only later. That was certainly part of it. It was also quite buggy, with the bugginess inversely proportional to how heavily used a component was. The file system worked pretty well but I gather magtape support didn't. >In a sense one can say that TSS/360 was ahead of it times: on >bigger machine smaller fraction of machine would be occupied >by system code so memory available for user whould be significantly >bigger. IIUC already on 2MB machine TSS/360 behaved much better. Well, there's a rule of thumb that the way you get good performance from a paging system is to have enough RAM that you don't have to page. -- 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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-04-01 23:23 +0000 |
| Subject | Re: TSS, Self-hosting and the 6502 |
| Message-ID | <10qk9ea$6jl0$1@paganini.bofh.team> |
| In reply to | #234504 |
John Levine <johnl@taugh.com> wrote:
> According to Waldek Hebisch <antispam@fricas.org>:
>>John Levine <johnl@taugh.com> wrote:
>>> According to David Wade <g4ugm@dave.invalid>:
>>>>> The TSS/360 story is new to me. Twenty users on a 360/67 and it
>>>>> struggled? How much of that was the large-team bloat you're describing
>>>>> versus actual architectural problems?
>>>>>
>>>>Not sure, do you mean the software architecture of TSS or the Hardware
>>>>architecture of the 360/67. I at Newcastle Uni (UK) I think they/we
>>>>managed more users than that with reasonable response time on a 360/67.
>>>
>>> A combination of overeager software architecture and implementation.
>>> CP/67 and MTS both got good performance from the same hardware.
>>
>>AFAICS main factor was that TSS/360 was too big, which left too
>>little core for users which lead to intensive paging when one
>>tried to increase number of users. Also, VM quite early got
>>good paging algorithm, other IBM systems used worse algorithms
>>and improved them only later.
>
> That was certainly part of it. It was also quite buggy, with the bugginess
> inversely proportional to how heavily used a component was. The file system
> worked pretty well but I gather magtape support didn't.
>
>>In a sense one can say that TSS/360 was ahead of it times: on
>>bigger machine smaller fraction of machine would be occupied
>>by system code so memory available for user whould be significantly
>>bigger. IIUC already on 2MB machine TSS/360 behaved much better.
>
> Well, there's a rule of thumb that the way you get good performance from
> a paging system is to have enough RAM that you don't have to page.
To explain more what I mean: if one have 1MB machine and OS takes
800 kB for itself, then one has about 200 kB for user programs.
If OS takes 400 kB, then one has about 600 kB for user programs.
I this case smaller system effectively has 3 times more memory
available for user programs. On 2 MB machine (assuming the same
OS use) ratio is closer to 4/3, still giving advantage to smaller
system, but this advantage is much smaller.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-02 10:53 +0000 |
| Subject | Re: TSS, Self-hosting and the 6502 |
| Message-ID | <10qlhro$in4$2@reader2.panix.com> |
| In reply to | #234563 |
In article <10qk9ea$6jl0$1@paganini.bofh.team>, Waldek Hebisch <antispam@fricas.org> wrote: >John Levine <johnl@taugh.com> wrote: >> According to Waldek Hebisch <antispam@fricas.org>: >>>John Levine <johnl@taugh.com> wrote: >>>> According to David Wade <g4ugm@dave.invalid>: >>>>>> The TSS/360 story is new to me. Twenty users on a 360/67 and it >>>>>> struggled? How much of that was the large-team bloat you're describing >>>>>> versus actual architectural problems? >>>>>> >>>>>Not sure, do you mean the software architecture of TSS or the Hardware >>>>>architecture of the 360/67. I at Newcastle Uni (UK) I think they/we >>>>>managed more users than that with reasonable response time on a 360/67. >>>> >>>> A combination of overeager software architecture and implementation. >>>> CP/67 and MTS both got good performance from the same hardware. >>> >>>AFAICS main factor was that TSS/360 was too big, which left too >>>little core for users which lead to intensive paging when one >>>tried to increase number of users. Also, VM quite early got >>>good paging algorithm, other IBM systems used worse algorithms >>>and improved them only later. >> >> That was certainly part of it. It was also quite buggy, with the bugginess >> inversely proportional to how heavily used a component was. The file system >> worked pretty well but I gather magtape support didn't. >> >>>In a sense one can say that TSS/360 was ahead of it times: on >>>bigger machine smaller fraction of machine would be occupied >>>by system code so memory available for user whould be significantly >>>bigger. IIUC already on 2MB machine TSS/360 behaved much better. >> >> Well, there's a rule of thumb that the way you get good performance from >> a paging system is to have enough RAM that you don't have to page. > >To explain more what I mean: if one have 1MB machine and OS takes >800 kB for itself, then one has about 200 kB for user programs. >If OS takes 400 kB, then one has about 600 kB for user programs. >I this case smaller system effectively has 3 times more memory >available for user programs. On 2 MB machine (assuming the same >OS use) ratio is closer to 4/3, still giving advantage to smaller >system, but this advantage is much smaller. Relatedly, I saw a talk recently by an English gent where he talked about a similar phenomenon: if you're driving somewhere and you're going 20 MPH (or KPH, if you prefer; the important thing here is the ratio, not the unit) then incresing speed by 10 MPH to 30 is a significant different and makes a measurable difference in your arrival time at your destination. On the other hand, if you're doing 80, then increasing speed by 10 to 90 is almost immeasurable and just (in his words) "makes you a dickhead." Well, I thought it was funny. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-04-02 07:29 -0700 |
| Subject | Re: TSS, Self-hosting and the 6502 |
| Message-ID | <10qlugl$15ji5$1@dont-email.me> |
| In reply to | #234571 |
On 4/2/26 03:53, Dan Cross wrote: > In article <10qk9ea$6jl0$1@paganini.bofh.team>, > Waldek Hebisch <antispam@fricas.org> wrote: >> John Levine <johnl@taugh.com> wrote: >>> According to Waldek Hebisch <antispam@fricas.org>: >>>> John Levine <johnl@taugh.com> wrote: >>>>> According to David Wade <g4ugm@dave.invalid>: >>>>>>> The TSS/360 story is new to me. Twenty users on a 360/67 and it >>>>>>> struggled? How much of that was the large-team bloat you're describing >>>>>>> versus actual architectural problems? >>>>>>> >>>>>> Not sure, do you mean the software architecture of TSS or the Hardware >>>>>> architecture of the 360/67. I at Newcastle Uni (UK) I think they/we >>>>>> managed more users than that with reasonable response time on a 360/67. >>>>> >>>>> A combination of overeager software architecture and implementation. >>>>> CP/67 and MTS both got good performance from the same hardware. >>>> >>>> AFAICS main factor was that TSS/360 was too big, which left too >>>> little core for users which lead to intensive paging when one >>>> tried to increase number of users. Also, VM quite early got >>>> good paging algorithm, other IBM systems used worse algorithms >>>> and improved them only later. >>> >>> That was certainly part of it. It was also quite buggy, with the bugginess >>> inversely proportional to how heavily used a component was. The file system >>> worked pretty well but I gather magtape support didn't. >>> >>>> In a sense one can say that TSS/360 was ahead of it times: on >>>> bigger machine smaller fraction of machine would be occupied >>>> by system code so memory available for user whould be significantly >>>> bigger. IIUC already on 2MB machine TSS/360 behaved much better. >>> >>> Well, there's a rule of thumb that the way you get good performance from >>> a paging system is to have enough RAM that you don't have to page. >> >> To explain more what I mean: if one have 1MB machine and OS takes >> 800 kB for itself, then one has about 200 kB for user programs. >> If OS takes 400 kB, then one has about 600 kB for user programs. >> I this case smaller system effectively has 3 times more memory >> available for user programs. On 2 MB machine (assuming the same >> OS use) ratio is closer to 4/3, still giving advantage to smaller >> system, but this advantage is much smaller. > > Relatedly, I saw a talk recently by an English gent where he > talked about a similar phenomenon: if you're driving somewhere > and you're going 20 MPH (or KPH, if you prefer; the important > thing here is the ratio, not the unit) then incresing speed by > 10 MPH to 30 is a significant different and makes a measurable > difference in your arrival time at your destination. On the > other hand, if you're doing 80, then increasing speed by 10 to > 90 is almost immeasurable and just (in his words) "makes you a > dickhead." > > Well, I thought it was funny. > > - Dan C. > Back when I was doing cross-country trips I gave this some thought, and at one point came to the same conclusion. Is it worth it to save five minutes on a four-hour trip (or whatever, don't flame me), when other contingencies can easily cause you to gain or lose more than that making a rest stop?
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-04-02 16:58 +0000 |
| Subject | Re: TSS, Self-hosting and the 6502 |
| Message-ID | <efxzR.420328$qz1.297268@fx12.iad> |
| In reply to | #234575 |
On 2026-04-02, Peter Flass <Peter@Iron-Spring.com> wrote: > Back when I was doing cross-country trips I gave this some thought, and > at one point came to the same conclusion. Is it worth it to save five > minutes on a four-hour trip (or whatever, don't flame me), when other > contingencies can easily cause you to gain or lose more than that making > a rest stop? This leads to what I call my 5% rule. In many cases, a difference of less than 5% is either insignificant or gets washed out by other factors - so you might as well not worry about it. Yes, there are exceptions - but on the whole I've found it a good rule of thumb. -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-02 20:34 +0000 |
| Subject | Re: TSS, Self-hosting and the 6502 |
| Message-ID | <10qmjth$1dic3$1@dont-email.me> |
| In reply to | #234583 |
On Thu, 02 Apr 2026 16:58:50 GMT, Charlie Gibbs wrote: > This leads to what I call my 5% rule. In many cases, a difference of > less than 5% is either insignificant or gets washed out by other > factors - so you might as well not worry about it. Is Microsoft applying this principle to its QA on Windows releases now, do you think?
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-04-02 20:53 +0000 |
| Subject | Re: TSS, Self-hosting and the 6502 |
| Message-ID | <pHAzR.45$NK1.21@fx21.iad> |
| In reply to | #234589 |
On 2026-04-02, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Thu, 02 Apr 2026 16:58:50 GMT, Charlie Gibbs wrote: > >> This leads to what I call my 5% rule. In many cases, a difference of >> less than 5% is either insignificant or gets washed out by other >> factors - so you might as well not worry about it. > > Is Microsoft applying this principle to its QA on Windows releases > now, do you think? I doubt it. Remember the purpose of quality control: to keep quality under control so it doesn't rise too high and increase costs. -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-31 21:01 +0000 |
| Message-ID | <10qhco2$3m51a$3@dont-email.me> |
| In reply to | #234500 |
On Tue, 31 Mar 2026 19:46:37 -0000 (UTC), Waldek Hebisch wrote: > In a sense one can say that TSS/360 was ahead of it times ... Or just too inefficient -- typical bloated IBM software.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2026-04-03 16:53 -1000 |
| Message-ID | <875x67jv13.fsf@localhost> |
| In reply to | #234500 |
antispam@fricas.org (Waldek Hebisch) writes: > AFAICS main factor was that TSS/360 was too big, which left too > little core for users which lead to intensive paging when one > tried to increase number of users. Also, VM quite early got > good paging algorithm, other IBM systems used worse algorithms > and improved them only later. > > In a sense one can say that TSS/360 was ahead of it times: on > bigger machine smaller fraction of machine would be occupied > by system code so memory available for user whould be significantly > bigger. IIUC already on 2MB machine TSS/360 behaved much better. Largest 360/67 1-CPU had one mbyte memory ... mostly taken up by TSS/360 kernel ... but the tss/360 group would proudly point out that 360/67 2-CPU, two mbyte had 3.8 times the throughput of 1-CPU (trying to imply it was tss/360 multiprocessor capability ... as opposed larger memory for its horribly bloated fixed kernel requirement).). implying the tss/360 implementation was much better than the MVT 2-CPU 360/65MP (& later MVS 2-CPU) only had 1.2-1-5 times the throughput of 1-CPU. As undergraduate, univ hired me fulltime responsible for os/360 (360/67 running at 360/65). Then CSC came out to install (virtual machine) CP/67 (3rd after CSC itself and MIT Lincoln Labs) and I mostly get to play with it during my weekend 48hr window. I then spend a few months rewriting pathlengths for running OS/360 in virtual machine. Bare machine test ran 322secs ... initially 856secs (CP67 CPU 534secs). After a few months I had CP67 CPU down from 534secs to 113secs. I then start rewriting the dispatcher/scheduler , (dynamic adaptive resource manager/default fair share scheduling policy), paging, adding ordered seek queuing (from FIFO) and mutli-page transfer channel programs (from FIFO and optimized for transfers/revolution, getting 2301 paging drum from 70-80 4k transfers/sec to channel transfer peak of 270). Six months after univ initial CP/67 install, CSC was giving one week class in LA. I arrive on Sunday afternoon and asked to teach the class, it turns out that the people that were going to teach it had resigned the Friday before to join one of the 60s CSC CP67 commercial online spin-offs. Early last decade I was asked to track down decision to add virtual memory to all 370s. Basically MVT storage management was so bad that region sizes had to be specified four times larger than used, limit standard 1mbyte, 370/165 to four concurrent running regions, insufficient to keep system busy and justified. Running MVT in 16mbyte virtual address space (similar to running MVT in a 360/67, CP/67 16mbyte virtual machine) allowed number of concurrent regions to be increased by factor of four times (capped at 15 concurrent regions because of 4bit storage protect key) with little or no paging. When I graduated, I joined the IBM Cambridge Scientific Center (instead of staying w/CFO) and one of my hobbies was enhanced production operating systems for internal datacenters (one of the 1st & long time was the online termainl sales&marketing support HONE). Ludlow was doing the initial implementation of MVT->VS2/SVS on 360/67 (until engineering 370 with virtual memory) and I would drop by periodically. He had a little bit of code for the 16mbyte virtual address space and some simple paging. Biggest task was channel programs passed to EXCP/SVC0 now had virtual addresses and channels required real addresses and he borrows CP67's CCWTRANS for integrating into EXCP (creating channel program copies, replacing virtual with real addresses). Some of the MIT CTSS/7094 people go to the 5th flr to do MULTICS. Others when to the IBM Cambridge Science Center and did virtual machine (initially wanted 360/50 to add hardware virtual memory but all the extra 50s were going to FAA/ATC and they had to settle for 360/40 to modify with virtual memory and did CP40/CMS, when 360/67 standard with virtual memory are available, CP40/CMS morphs into CP67/CMS. With decision to add virtual memory to 370s and some of CSC spins off and goes to the 3rd flr, taking over the IBM Boston Programming Center for the VM370 Development Group. In the morph of CP67->VM370, lots of stuff was simplified and/or dropped (including paging, "wheeler scheduler", multiprocessor support). Then with VM370R2-base, I start adding lots of stuff back in for my internal CSC/VM release (paging, wheeler scheduler, etc). Then with VM370R3-base, I add more back in, including 2-CPU multiprocessor support (initially for internal HONE so they can upgrade 158s&168s systems to 2-CPU (getting twice the troughput). -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-04 03:57 +0000 |
| Message-ID | <10qq27k$depp$2@dont-email.me> |
| In reply to | #234603 |
On Fri, 03 Apr 2026 16:53:28 -1000, Lynn Wheeler wrote: > Largest 360/67 1-CPU had one mbyte memory ... mostly taken up by > TSS/360 kernel ... Wikipedia says TSS was not a great success. Did any timesharing OSes from IBM enjoy much success? Maybe TSO? Did that do multiuser, without the need for VMs?
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-04-04 07:37 -0700 |
| Message-ID | <10qr7mq$omgk$1@dont-email.me> |
| In reply to | #234605 |
On 4/3/26 20:57, Lawrence D’Oliveiro wrote: > On Fri, 03 Apr 2026 16:53:28 -1000, Lynn Wheeler wrote: > >> Largest 360/67 1-CPU had one mbyte memory ... mostly taken up by >> TSS/360 kernel ... > > Wikipedia says TSS was not a great success. > > Did any timesharing OSes from IBM enjoy much success? Maybe TSO? Did > that do multiuser, without the need for VMs? Obviously VM/CMS. Non-IBM MTS was fairly popular in the education community.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-04-04 21:55 +0000 |
| Message-ID | <10qs1cb$2lf0$2@gal.iecc.com> |
| In reply to | #234607 |
According to Peter Flass <Peter@Iron-Spring.com>: >On 4/3/26 20:57, Lawrence D’Oliveiro wrote: >> On Fri, 03 Apr 2026 16:53:28 -1000, Lynn Wheeler wrote: >> >>> Largest 360/67 1-CPU had one mbyte memory ... mostly taken up by >>> TSS/360 kernel ... >> >> Wikipedia says TSS was not a great success. >> >> Did any timesharing OSes from IBM enjoy much success? Maybe TSO? Did >> that do multiuser, without the need for VMs? > >Obviously VM/CMS. Non-IBM MTS was fairly popular in the education community. Single language APL\360 was also pretty popular, supporting a lot of interactive users on a 360/50. -- 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 | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-04-04 15:48 -0700 |
| Message-ID | <10qs4fu$11it2$1@dont-email.me> |
| In reply to | #234611 |
On 4/4/26 14:55, John Levine wrote: > According to Peter Flass <Peter@Iron-Spring.com>: >> On 4/3/26 20:57, Lawrence D’Oliveiro wrote: >>> On Fri, 03 Apr 2026 16:53:28 -1000, Lynn Wheeler wrote: >>> >>>> Largest 360/67 1-CPU had one mbyte memory ... mostly taken up by >>>> TSS/360 kernel ... >>> >>> Wikipedia says TSS was not a great success. >>> >>> Did any timesharing OSes from IBM enjoy much success? Maybe TSO? Did >>> that do multiuser, without the need for VMs? >> >> Obviously VM/CMS. Non-IBM MTS was fairly popular in the education community. > > Single language APL\360 was also pretty popular, supporting a lot of interactive > users on a 360/50. > > IBM also had Conversational Programming System (CPS) that supported BASIC and PL/I. Don't know about FORTRAN.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-04-05 02:27 +0000 |
| Subject | Re: ancient time sharingSelf-hosting and the 6502 |
| Message-ID | <10qsha9$2bm8$1@gal.iecc.com> |
| In reply to | #234614 |
According to Peter Flass <Peter@Iron-Spring.com>: >On 4/4/26 14:55, John Levine wrote: >>>> Did any timesharing OSes from IBM enjoy much success? Maybe TSO? Did >>>> that do multiuser, without the need for VMs? >>> >>> Obviously VM/CMS. Non-IBM MTS was fairly popular in the education community. >> >> Single language APL\360 was also pretty popular, supporting a lot of interactive >> users on a 360/50. >> >IBM also had Conversational Programming System (CPS) that supported >BASIC and PL/I. Don't know about FORTRAN. That was QUIKTRAN. -- 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 | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-04 22:03 +0000 |
| Message-ID | <10qs1rl$10uoq$1@dont-email.me> |
| In reply to | #234607 |
On Sat, 4 Apr 2026 07:37:14 -0700, Peter Flass wrote: > On 4/3/26 20:57, Lawrence D’Oliveiro wrote: >> >> On Fri, 03 Apr 2026 16:53:28 -1000, Lynn Wheeler wrote: >> >>> Largest 360/67 1-CPU had one mbyte memory ... mostly taken up by >>> TSS/360 kernel ... >> >> Wikipedia says TSS was not a great success. >> >> Did any timesharing OSes from IBM enjoy much success? Maybe TSO? >> Did that do multiuser, without the need for VMs? > > Obviously VM/CMS. CMS didn’t do multiuser. Hence the need for the “VM” part.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web