Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #109362 > unrolled thread
| Started by | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| First post | 2024-10-01 19:02 +0000 |
| Last post | 2024-10-03 00:30 +0000 |
| Articles | 20 on this page of 456 — 31 participants |
Back to article view | Back to comp.arch
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-01 19:02 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-01 20:00 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-01 21:04 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-01 23:38 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 00:31 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-03 01:26 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 06:28 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Brown <david.brown@hesbynett.no> - 2024-10-03 09:21 +0200
Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 09:39 +0000
Re: Byte ordering (was: Whether something is RISC or not) David Brown <david.brown@hesbynett.no> - 2024-10-03 14:34 +0200
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 22:17 +0000
Re: Byte ordering Lynn Wheeler <lynn@garlic.com> - 2024-10-03 15:33 -1000
Re: Byte ordering (was: Whether something is RISC or not) David Brown <david.brown@hesbynett.no> - 2024-10-04 11:23 +0200
Re: Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-04 17:30 +0000
Re: Byte ordering BGB <cr88192@gmail.com> - 2024-10-04 14:05 -0500
Re: Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2024-10-04 23:06 +0000
Re: Byte ordering BGB <cr88192@gmail.com> - 2024-10-04 19:44 -0500
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:35 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:34 +0000
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:31 +0000
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-05 17:52 +0000
Re: Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-05 18:11 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-05 22:53 +0300
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-06 22:07 +0200
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-06 21:53 +0000
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:29 +0000
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-07 16:16 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-07 19:57 +0300
Re: Byte ordering Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-07 16:00 -0400
Re: Byte ordering Michael S <already5chosen@yahoo.com> - 2024-10-08 00:11 +0300
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:46 +0000
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-08 10:40 +0200
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-06 11:58 +0200
Re: Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-06 13:04 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-06 16:34 +0100
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:32 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-08 22:28 +0100
Re: Byte ordering EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-09 13:37 -0400
VMS/NT memory management (was: Byte ordering) Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-09 16:01 -0400
Re: VMS/NT memory management (was: Byte ordering) scott@slp53.sl.home (Scott Lurndal) - 2024-10-09 23:16 +0000
Re: VMS/NT memory management EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-11 15:21 -0400
Re: VMS/NT memory management scott@slp53.sl.home (Scott Lurndal) - 2024-10-12 15:20 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:55 +0000
Re: Byte ordering Michael S <already5chosen@yahoo.com> - 2024-10-15 11:16 +0300
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-15 18:40 +0100
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:56 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-15 18:40 +0100
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2024-10-15 18:57 +0000
Re: Byte ordering George Neuner <gneuner2@comcast.net> - 2024-10-15 19:51 -0400
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-16 07:36 +0200
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-16 09:17 +0200
Re: Byte ordering George Neuner <gneuner2@comcast.net> - 2024-10-16 21:19 -0400
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-17 14:39 +0200
Re: clouds, not Byte ordering John Levine <johnl@taugh.com> - 2024-10-17 02:35 +0000
Re: clouds, not Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-17 14:41 +0200
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:57 +0000
Re: Byte ordering "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-16 11:34 -0400
Re: Microkernels & Capabilities (was Re: Byte ordering) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:54 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:51 +0000
Re: Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:17 +0000
80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-07 07:33 +0000
Re: 80286 protected mode Lars Poulsen <lars@cleo.beagle-ears.com> - 2024-10-07 12:42 +0000
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-07 15:17 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-07 17:45 +0300
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:55 +0000
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-08 10:44 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-07 16:32 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-07 20:03 +0300
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-07 17:40 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:52 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-07 23:13 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-08 06:16 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-08 20:53 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 08:48 +0200
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:46 +0000
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-08 07:28 +0000
Re: 80286 protected mode Robert Finch <robfi680@gmail.com> - 2024-10-08 07:28 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 10:24 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-09 16:28 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-09 16:42 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 22:20 +0200
Re: 80286 protected mode Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-10-09 14:52 -0700
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 00:33 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:30 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:24 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-11 08:15 -0700
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-15 17:26 -0400
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 21:55 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-15 22:05 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 00:24 +0000
Re: C and turtles, 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-16 01:08 +0000
Re: C and turtles, 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 02:48 +0000
Re: C and turtles, 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-16 03:09 +0000
Re: C and turtles, 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-17 19:49 +0000
Re: C and turtles, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 21:03 +0000
Re: C and turtles, 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-20 07:08 +0000
Re: C and turtles, 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-20 15:49 -0400
Re: C and turtles, 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-21 18:19 -0700
Re: C and turtles, 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-22 17:28 -0400
Re: C and turtles, 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 10:04 +0200
Re: C and turtles, 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-16 15:07 -0400
Re: C and turtles, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-16 19:41 +0000
Re: C and turtles, 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:13 +0200
Re: C and turtles, 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-20 07:07 +0000
Re: C and turtles, 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-20 12:14 -0400
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-16 15:38 +0000
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-16 23:06 -0400
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 03:16 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:16 +0200
Re: 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-16 20:00 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 22:18 +0000
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 01:18 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 00:40 -0700
Re: fine points of dynamic memory allocation, not 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-17 18:31 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 19:01 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-17 19:32 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 21:01 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 07:12 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 02:48 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 09:38 +0200
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-16 23:32 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:25 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 03:17 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 09:21 +0200
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-16 11:18 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 19:57 +0200
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-21 14:04 -0400
Re: 80286 protected mode Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-18 17:38 +0100
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-18 21:45 +0200
Re: 80286 protected mode Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-20 21:51 +0100
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-21 08:58 +0200
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-21 09:21 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-21 18:32 -0700
Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-22 08:27 +0200
Re: Retirement hobby (was Re: 80286 protected mode) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-23 07:25 -0700
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-23 18:11 +0000
Re: Retirement hobby (was Re: 80286 protected mode) scott@slp53.sl.home (Scott Lurndal) - 2024-10-23 18:27 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:12 +0200
Re: Retirement hobby (was Re: 80286 protected mode) Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-27 20:45 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:11 +0200
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-23 21:01 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-24 07:39 +0200
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-24 18:32 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-28 11:39 +0100
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-28 16:30 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-10-28 10:12 -0700
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-28 18:14 +0000
Re: Retirement hobby (was Re: 80286 protected mode) EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-28 15:24 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 06:33 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-29 08:07 +0100
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 19:57 +0000
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-29 20:21 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 21:27 +0000
Re: Retirement hobby (was Re: 80286 protected mode) scott@slp53.sl.home (Scott Lurndal) - 2024-10-29 20:30 +0000
Re: Retirement hobby (was Re: 80286 protected mode) EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-29 14:29 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-29 14:19 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:09 +0200
Re: Retirement hobby (was Re: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-24 06:55 +0000
Re: Retirement hobby (was Re: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-24 10:00 +0200
Re: Retirement hobby (was Re: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-24 16:34 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-21 23:17 +0000
Re: portable malloc mitchalsup@aol.com (MitchAlsup1) - 2024-10-21 23:52 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-22 01:09 +0000
Re: portable malloc George Neuner <gneuner2@comcast.net> - 2024-10-22 17:26 -0400
Re: portable malloc Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-27 20:42 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-27 21:04 +0000
Re: portable malloc David Schultz <david.schultz@earthlink.net> - 2024-10-27 17:55 -0500
Re: tiny portable malloc John Levine <johnl@taugh.com> - 2024-10-27 23:58 +0000
Re: 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-09 18:10 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 22:22 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-09 21:37 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:31 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 18:38 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 21:21 +0200
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-10 20:00 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-10 23:54 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-10 21:03 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-10 16:19 -0500
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 13:37 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-11 15:13 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 16:54 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 12:00 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 14:10 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 21:30 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 14:10 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-11 18:55 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-12 00:02 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-11 23:32 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-12 17:16 +0200
Re: 80286 protected mode Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> - 2024-10-12 19:26 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 12:57 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-13 19:36 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-13 19:43 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 23:01 +0300
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 18:33 +0000
Re: 80286 protected mode Niklas Holsti <niklas.holsti@tidorum.invalid> - 2024-10-13 10:31 +0300
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 12:26 +0300
Re: 80286 protected mode Niklas Holsti <niklas.holsti@tidorum.invalid> - 2024-10-13 13:33 +0300
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-13 15:32 -0500
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 13:58 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 05:06 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-12 12:36 -0500
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 18:17 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-12 18:37 +0000
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-13 01:25 +0000
Re: 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-12 23:09 -0400
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-12 18:32 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 10:56 +0300
Re: 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-13 13:32 -0400
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-13 21:21 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 15:19 +0200
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-14 16:40 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 17:19 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-14 19:08 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 10:53 +0200
memcpy and friend (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2024-10-15 13:12 +0300
Re: memcpy and friend (was: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-15 13:20 +0200
Re: memcpy and friend (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2024-10-15 14:55 +0300
Re: memcpy and friend (was: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-15 14:03 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 06:00 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 05:39 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-12 05:11 -0700
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-13 15:45 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 17:04 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-14 19:02 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-14 22:20 +0300
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:14 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 10:41 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-14 19:39 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:15 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-18 12:47 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-18 14:06 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-18 17:34 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-18 16:19 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-19 19:46 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 12:38 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 14:22 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 14:09 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-15 19:46 +0000
Re: 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-08 16:00 +0000
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-08 16:23 +0000
Re: 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-08 21:03 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-15 05:20 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 11:59 +0300
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 07:01 +0000
Re: Byte ordering antispam@fricas.org (Waldek Hebisch) - 2025-01-03 03:37 +0000
Re: Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-03 08:38 +0000
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-03 18:11 +0000
Re: Byte ordering antispam@fricas.org (Waldek Hebisch) - 2025-01-04 22:40 +0000
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-05 08:54 +0100
80286 protected mode (was: Byte ordering) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-05 11:10 +0000
Re: 80286 protected mode (was: Byte ordering) Robert Swindells <rjs@fdy2.co.uk> - 2025-01-05 18:30 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2025-01-05 16:38 -0500
Re: 80286 protected mode antispam@fricas.org (Waldek Hebisch) - 2025-01-05 21:49 +0000
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2025-01-05 23:01 -0500
Segments (was: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-06 08:24 +0000
Re: Segments (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2025-01-06 14:41 +0200
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-06 16:05 +0100
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-06 16:36 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 19:49 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 19:41 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-07 11:45 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-06 22:02 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 22:57 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 11:05 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 14:43 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-07 17:04 +0200
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 15:28 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 16:41 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-07 20:16 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 21:26 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 22:01 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-07 23:16 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-08 11:53 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-11 22:31 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 17:46 -0800
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 07:09 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-15 14:00 +0200
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 18:00 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-15 22:28 +0200
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 20:59 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 12:36 +0100
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-16 14:35 +0200
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 13:59 +0100
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-16 16:46 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-16 18:12 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 18:30 +0000
Re: Stacks, was Segments John Levine <johnl@taugh.com> - 2025-01-18 03:08 +0000
Re: Stacks, was Segments Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-01-18 10:59 +0200
Re: Stacks, was Segments John Levine <johnl@taugh.com> - 2025-01-18 19:41 +0000
Re: Stacks, was Segments David Brown <david.brown@hesbynett.no> - 2025-01-19 17:33 +0100
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-19 18:28 +0000
Re: Stacks, was Segments Michael S <already5chosen@yahoo.com> - 2025-01-20 12:55 +0200
Re: Stacks, was Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-20 11:12 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-20 22:05 +0000
Re: Stacks, was Segments Michael S <already5chosen@yahoo.com> - 2025-01-21 01:25 +0200
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-21 00:17 +0000
Re: Stacks, was Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-21 06:21 +0000
Re: Stacks, was Segments Bill Findlay <findlaybill@blueyonder.co.uk> - 2025-01-21 10:36 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-21 17:49 +0000
Re: Stacks, was Segments Stefan Monnier <monnier@iro.umontreal.ca> - 2025-02-03 14:09 -0500
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 21:13 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-03 21:23 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 22:47 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-03 23:11 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-05 12:11 -0500
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-05 14:55 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-05 23:36 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 11:41 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-06 17:13 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 13:51 -0500
Re: Stacks, was Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-02-06 12:06 -0800
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 16:53 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 02:53 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-09 15:45 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-09 21:03 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 02:39 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-07 13:57 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 18:25 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-07 20:32 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-08 22:19 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-10 20:18 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-10 23:40 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 14:04 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-11 20:19 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 20:49 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-11 23:29 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-12 00:34 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-13 16:42 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-13 18:12 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-13 21:48 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-13 22:23 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-14 19:13 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-14 19:51 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-14 21:50 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-15 15:31 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-15 23:28 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-16 19:56 +0000
Re: Stacks, was Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-02-11 09:30 -0800
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 18:19 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-06 20:49 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-05 21:31 +0000
Re: Stacks, was Segments Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-01-19 23:37 +0200
Re: Stacks, was Segments David Brown <david.brown@hesbynett.no> - 2025-01-20 09:00 +0100
Re: Stacks, was Segments Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:26 -0800
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-18 16:30 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-18 17:40 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-16 20:46 +0200
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-16 20:34 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-16 21:02 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 22:16 +0100
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-16 21:40 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 10:20 +0100
Re: Segments "Brian G. Lucas" <bagel99@gmail.com> - 2025-01-17 10:08 -0500
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-17 15:17 +0000
Re: Segments jgd@cix.co.uk (John Dallman) - 2025-01-19 18:49 +0000
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-17 02:22 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 19:52 -0800
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 15:52 +0100
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 15:30 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-17 16:42 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 18:21 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-17 20:08 +0000
Re: Segments George Neuner <gneuner2@comcast.net> - 2025-01-21 20:30 -0500
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 02:19 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 14:58 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 17:45 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 20:00 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 22:25 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 22:44 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 01:39 +0200
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 01:00 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 11:52 +0200
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 17:41 +0200
Re: Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-01-23 14:22 -0500
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 08:14 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 12:23 +0200
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 12:39 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:04 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:31 +0000
Re: Segments Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:18 -0800
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-23 14:02 -0800
Re: Segments George Neuner <gneuner2@comcast.net> - 2025-01-23 11:50 -0500
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 17:18 +0000
Re: stack sizes, Segments John Levine <johnl@taugh.com> - 2025-01-22 02:54 +0000
Re: stack sizes, Segments Michael S <already5chosen@yahoo.com> - 2025-01-22 15:25 +0200
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 15:01 +0000
Re: stack sizes, Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 01:45 +0200
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 01:07 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 02:47 +0000
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:00 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 17:49 +0000
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 19:45 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 20:04 +0000
Re: stack sizes, Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-24 08:11 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-24 14:50 +0000
Re: stack sizes, Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 07:24 +0000
Re: stack sizes, Segments George Neuner <gneuner2@comcast.net> - 2025-01-22 20:28 -0500
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 11:43 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-15 13:42 -0800
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 22:39 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 10:11 +0100
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 13:11 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 13:10 -0800
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 22:23 +0100
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-16 09:15 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 17:24 +0000
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-16 09:55 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 18:23 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 20:22 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-16 19:14 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 20:12 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 15:18 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 23:39 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 17:04 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-17 02:10 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 16:15 +0100
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-17 18:02 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-17 10:55 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-17 19:27 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-17 21:05 -0800
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-20 12:29 -0800
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-22 14:15 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-22 18:44 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 23:41 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 10:53 +0000
Re: Segments Andy Valencia <vandys@vsta.org> - 2025-01-11 13:59 -0800
Re: what's a segment, 80286 protected mode John Levine <johnl@taugh.com> - 2025-01-06 18:58 +0000
Re: what's a segment, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 19:45 +0000
Re: what's a segment, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 19:48 +0000
Re: what's a segment, 80286 protected mode Lynn Wheeler <lynn@garlic.com> - 2025-01-06 17:28 -1000
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-05 15:20 +0000
Re: the 286, Byte ordering John Levine <johnl@taugh.com> - 2025-01-05 02:56 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 03:55 +0000
Re: the 286, Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-05 15:15 +0000
Re: the 286, Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-05 15:23 +0000
Re: the 286, Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-05 17:51 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 19:40 +0000
Re: the 286, Byte ordering John Levine <johnl@taugh.com> - 2025-01-05 20:01 +0000
Re: the 286, Byte ordering Brett <ggtgp@yahoo.com> - 2025-01-05 20:46 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 20:55 +0000
Re: the 286, Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-05 22:01 +0100
Re: the 286, Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-06 00:35 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 03:02 +0000
Re: the 286, Byte ordering Michael S <already5chosen@yahoo.com> - 2025-01-06 15:19 +0200
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-05 14:48 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-06 18:50 +0300
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:33 +0000
Re: Byte ordering (was: Whether something is RISC or not) jgd@cix.co.uk (John Dallman) - 2024-10-03 23:49 +0100
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-02 20:23 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 10:07 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-02 16:08 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 13:51 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-02 21:34 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 18:55 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 00:30 +0000
Page 3 of 23 — ← Prev page 1 2 [3] 4 5 … 23 Next page →
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2024-10-11 15:21 -0400 |
| Subject | Re: VMS/NT memory management |
| Message-ID | <AVeOO.11286$Vuz4.1302@fx08.iad> |
| In reply to | #109610 |
Scott Lurndal wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> In the VMS/WinNT way, each memory section is defined as either shared >>> or private when created and cannot be changed. This allows optimizations >>> in page table and page file handling. >> Interesting. Do you happen to have a pointer for further reading >> about it? >> >>> *nix needs to maintain various data structures to support forking >>> memory just in case it happens. >> I can't imagine what those datastructures would be (which might be just >> another way to say that I was brought up on POSIX and can't imagine the >> world differently). >> > > http://bitsavers.org/pdf/dec/vax/vms/training/EY-8264E-DP_VMS_Internals_and_Data_Structures_4.4_1988.pdf Yeah, that's a great book on how VMS works in detail. My copy is v1.0 from 1981. It describes the various data structures, some down to the bit level. Then chapter 15 Paging Dynamics walks through the details of how paging works. A book of comparable detail on Linux (but dated) would be: Understanding the Linux Virtual Memory Manager, Gorman, 2007 https://www.kernel.org/doc/gorman/pdf/understand.pdf Of a similar nature on Windows but without the detail of the above two is: (this appears to be two volumes jammed together) Windows Internals 6th ed vol 1&2, 2012 https://empyreal96.github.io/nt-info-depot/Windows-Internals-PDFs/Windows%20Internals%206e%20Part1%2B2.pdf
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-12 15:20 +0000 |
| Subject | Re: VMS/NT memory management |
| Message-ID | <NswOO.82298$S9Vb.80997@fx45.iad> |
| In reply to | #109640 |
EricP <ThatWouldBeTelling@thevillage.com> writes: >Scott Lurndal wrote: >> Stefan Monnier <monnier@iro.umontreal.ca> writes: >>>> In the VMS/WinNT way, each memory section is defined as either shared >>>> or private when created and cannot be changed. This allows optimizations >>>> in page table and page file handling. >>> Interesting. Do you happen to have a pointer for further reading >>> about it? >>> >>>> *nix needs to maintain various data structures to support forking >>>> memory just in case it happens. >>> I can't imagine what those datastructures would be (which might be just >>> another way to say that I was brought up on POSIX and can't imagine the >>> world differently). >>> >> >> http://bitsavers.org/pdf/dec/vax/vms/training/EY-8264E-DP_VMS_Internals_and_Data_Structures_4.4_1988.pdf > >Yeah, that's a great book on how VMS works in detail. >My copy is v1.0 from 1981. I also have a printed copy from 1981, along with the internals class notes and the microfiche.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-14 23:55 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <vekb2f$1co97$6@dont-email.me> |
| In reply to | #109592 |
On Wed, 09 Oct 2024 13:37:41 -0400, EricP wrote: > The Posix interface support was there so *MS* could bid on US government > and military contracts which, at that time frame, were making noise > about it being standard for all their contracts. > The Posix DLLs didn't come with WinNT, you had to ask MS for them > specially. And that whole POSIX subsystem was so sadistically, unusably awful, it just had to be intended for show as a box-ticking exercise, nothing more. <https://www.youtube.com/watch?v=BOeku3hDzrM> > Back then "object oriented" and "micro-kernel" buzzwords were all the > rage. OO still lives on in higher-level languages. Microsoft’s one attempt to incorporate its OO architecture--Dotnet--into the lower layers of the OS, in Windows Vista, was an abject, embarrassing failure which hopefully nobody will try to repeat. On the other hand, some stubborn holdouts are still fond of microkernels -- you just have to say the whole idea is pointless, and they come out of the woodwork in a futile attempt to disagree ...
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-15 11:16 +0300 |
| Subject | Re: Byte ordering |
| Message-ID | <20241015111655.000064b3@yahoo.com> |
| In reply to | #109709 |
On Mon, 14 Oct 2024 23:55:59 -0000 (UTC) Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Wed, 09 Oct 2024 13:37:41 -0400, EricP wrote: > > > The Posix interface support was there so *MS* could bid on US > > government and military contracts which, at that time frame, were > > making noise about it being standard for all their contracts. > > The Posix DLLs didn't come with WinNT, you had to ask MS for them > > specially. > > And that whole POSIX subsystem was so sadistically, unusably awful, > it just had to be intended for show as a box-ticking exercise, > nothing more. > > <https://www.youtube.com/watch?v=BOeku3hDzrM> > > > Back then "object oriented" and "micro-kernel" buzzwords were all > > the rage. > > OO still lives on in higher-level languages. Microsoft’s one attempt > to incorporate its OO architecture--Dotnet--into the lower layers of > the OS, in Windows Vista, was an abject, embarrassing failure which > hopefully nobody will try to repeat. > It sounds like you confusing .net with something unrelated. Probably with Microsoft's failed WinFS filesystem. WinFS was *not* object-oriented. AFAIK, .net is hugely successful application development technology that was never incorporated into lower layers of the OS. If you are interested in failed attempts to incorporate .net into something it does not fit then please consider Silverlight. But then, the story of Silverlight is not dissimilar to the story of in-browser Java, with main difference that the latter was more harmful to the industry. > On the other hand, some stubborn holdouts are still fond of > microkernels -- you just have to say the whole idea is pointless, and > they come out of the woodwork in a futile attempt to disagree ... Seems, you are not ashamed to admit your trolling tactics.
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2024-10-15 18:40 +0100 |
| Subject | Re: Byte ordering |
| Message-ID | <memo.20241015184005.19028n@jgd.cix.co.uk> |
| In reply to | #109716 |
In article <20241015111655.000064b3@yahoo.com>, already5chosen@yahoo.com (Michael S) wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > > OO still lives on in higher-level languages. Microsoft_s one > > attempt to incorporate its OO architecture--Dotnet--into the > > lower layers of the OS, in Windows Vista, was an abject, > > embarrassing failure which hopefully nobody will try to repeat. > AFAIK, .net is hugely successful application development technology > that was never incorporated into lower layers of the OS. You're correct. There was an experimental Microsoft OS that was almost entirely written in .NET but it was never commercialised. <https://en.wikipedia.org/wiki/Singularity_(operating_system)> John
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-18 05:56 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <vest9j$35pc2$4@dont-email.me> |
| In reply to | #109716 |
On Tue, 15 Oct 2024 11:16:55 +0300, Michael S wrote: > AFAIK, .net is hugely successful application development technology that > was never incorporated into lower layers of the OS. Look up the infamous “Longhorn reset”. Microsoft had to chuck away a bunch of low-performance, high-overhead code and try again, and Dotnet was the reason. This delayed Windows Vista by about a year and a half, and it was still a rush to get it out.
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2024-10-15 18:40 +0100 |
| Subject | Re: Byte ordering |
| Message-ID | <memo.20241015184006.19028o@jgd.cix.co.uk> |
| In reply to | #109709 |
In article <vekb2f$1co97$6@dont-email.me>, ldo@nz.invalid (Lawrence D'Oliveiro) wrote: > On the other hand, some stubborn holdouts are still fond of > microkernels -- you just have to say the whole idea is pointless, > and they come out of the woodwork in a futile attempt to disagree The idea is impractical, not pointless. A hybrid kernel gives most of the advantages of a microkernel to its developers, and avoids the need for lots of context switches. It doesn't let you easily replace low-level OS components, but not many people actually want that. <https://en.wikipedia.org/wiki/Hybrid_kernel> Windows NT and Apple's XNU, used in all their operating systems, are both hybrid kernels, so the idea is somewhat practical. John
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-15 18:57 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <7WyPO.262352$v8v2.145716@fx18.iad> |
| In reply to | #109730 |
jgd@cix.co.uk (John Dallman) writes: >In article <vekb2f$1co97$6@dont-email.me>, ldo@nz.invalid (Lawrence >D'Oliveiro) wrote: > >> On the other hand, some stubborn holdouts are still fond of >> microkernels -- you just have to say the whole idea is pointless, >> and they come out of the woodwork in a futile attempt to disagree > >The idea is impractical, not pointless. A hybrid kernel gives most of the >advantages of a microkernel to its developers, and avoids the need for >lots of context switches. It doesn't let you easily replace low-level OS >components, but not many people actually want that. It's useful to note that the primary shortcoming of a microkernel (domain crossing latency) is mostly not a problem on RISC processors (like ARM64) where the ring change takes about the same amount of time as a function call. One might also argue that in many aspects, a hypervisor is a 'microkernel' with some hardware support on most modern CPUs. Disclaimer: I spent most of the 90's working with the Chorus microkernel.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2024-10-15 19:51 -0400 |
| Subject | Re: Byte ordering |
| Message-ID | <ogvtgjhh4eujri9p7biok6c14qd9mv40v3@4ax.com> |
| In reply to | #109730 |
On Tue, 15 Oct 2024 18:40 +0100 (BST), jgd@cix.co.uk (John Dallman) wrote: >In article <vekb2f$1co97$6@dont-email.me>, ldo@nz.invalid (Lawrence >D'Oliveiro) wrote: > >> On the other hand, some stubborn holdouts are still fond of >> microkernels -- you just have to say the whole idea is pointless, >> and they come out of the woodwork in a futile attempt to disagree > >The idea is impractical, not pointless. A hybrid kernel gives most of the >advantages of a microkernel to its developers, and avoids the need for >lots of context switches. It doesn't let you easily replace low-level OS >components, but not many people actually want that. Actually, I think there are a whole lot of people who can't afford non-stop server hardware but would greatly appreciate not having to waste time with a shutdown/reboot every time some OS component gets updated. YMMV. > ><https://en.wikipedia.org/wiki/Hybrid_kernel> > >Windows NT and Apple's XNU, used in all their operating systems, are both >hybrid kernels, so the idea is somewhat practical. > >John
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-16 07:36 +0200 |
| Subject | Re: Byte ordering |
| Message-ID | <venjcu$23p27$1@dont-email.me> |
| In reply to | #109738 |
George Neuner wrote: > On Tue, 15 Oct 2024 18:40 +0100 (BST), jgd@cix.co.uk (John Dallman) > wrote: > >> In article <vekb2f$1co97$6@dont-email.me>, ldo@nz.invalid (Lawrence >> D'Oliveiro) wrote: >> >>> On the other hand, some stubborn holdouts are still fond of >>> microkernels -- you just have to say the whole idea is pointless, >>> and they come out of the woodwork in a futile attempt to disagree >> >> The idea is impractical, not pointless. A hybrid kernel gives most of the >> advantages of a microkernel to its developers, and avoids the need for >> lots of context switches. It doesn't let you easily replace low-level OS >> components, but not many people actually want that. > > Actually, I think there are a whole lot of people who can't afford > non-stop server hardware but would greatly appreciate not having to > waste time with a shutdown/reboot every time some OS component gets > updated. > > YMMV. This is _exactly_ (one of) the problem(s) cloud infrastructure solves: As soon as you have more than a single instance of a particular server/service, then you replace them in groups so that the service sees zero downtime even though all the servers have been updated/replaced. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-16 09:17 +0200 |
| Subject | Re: Byte ordering |
| Message-ID | <venp9g$241bk$1@dont-email.me> |
| In reply to | #109743 |
On 16/10/2024 07:36, Terje Mathisen wrote: > George Neuner wrote: >> On Tue, 15 Oct 2024 18:40 +0100 (BST), jgd@cix.co.uk (John Dallman) >> wrote: >> >>> In article <vekb2f$1co97$6@dont-email.me>, ldo@nz.invalid (Lawrence >>> D'Oliveiro) wrote: >>> >>>> On the other hand, some stubborn holdouts are still fond of >>>> microkernels -- you just have to say the whole idea is pointless, >>>> and they come out of the woodwork in a futile attempt to disagree >>> >>> The idea is impractical, not pointless. A hybrid kernel gives most of >>> the >>> advantages of a microkernel to its developers, and avoids the need for >>> lots of context switches. It doesn't let you easily replace low-level OS >>> components, but not many people actually want that. >> >> Actually, I think there are a whole lot of people who can't afford >> non-stop server hardware but would greatly appreciate not having to >> waste time with a shutdown/reboot every time some OS component gets >> updated. >> >> YMMV. > > This is _exactly_ (one of) the problem(s) cloud infrastructure solves: > As soon as you have more than a single instance of a particular > server/service, then you replace them in groups so that the service sees > zero downtime even though all the servers have been updated/replaced. > That's fine - /if/ you have a service that can easily be spread across multiple systems, and you can justify the cost of that. Setting up a database server is simple enough. Setting up a database server along with a couple of read-only replications is harder. Adding a writeable failover secondary is harder still. Making sure that everything works /perfectly/ when the primary goes down for maintenance, and that everything is consistent afterwards, is even harder. Being sure it still all works even while the different parts have different versions during updates typically means you have to duplicate the whole thing so you can do test runs. And if the database server is not open source, your license costs will be absurd, compared to what you actually need to provide the service - usually just one server instance. Clouds do nothing to help any of that. But clouds /do/ mean that your virtual machine can be migrated (with zero, or almost zero, downtime) to another physical server if there are hardware problems or during hardware maintenance. And if you can do easy snapshots with your cloud / VM infrastructure, then you can roll back if things go badly wrong. So you have a single server instance, you plan a short period of downtime, take a snapshot, stop the service, upgrade, restart. That's what almost everyone does, other than the /really/ big or /really/ critical service providers.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2024-10-16 21:19 -0400 |
| Subject | Re: Byte ordering |
| Message-ID | <0po0hj548t7tula7kda8jnelrs4qess881@4ax.com> |
| In reply to | #109745 |
On Wed, 16 Oct 2024 09:17:03 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 16/10/2024 07:36, Terje Mathisen wrote: >> George Neuner wrote: >>> On Tue, 15 Oct 2024 18:40 +0100 (BST), jgd@cix.co.uk (John Dallman) >>> wrote: >>> >>>> In article <vekb2f$1co97$6@dont-email.me>, ldo@nz.invalid (Lawrence >>>> D'Oliveiro) wrote: >>>> >>>>> On the other hand, some stubborn holdouts are still fond of >>>>> microkernels -- you just have to say the whole idea is pointless, >>>>> and they come out of the woodwork in a futile attempt to disagree >>>> >>>> The idea is impractical, not pointless. A hybrid kernel gives most of >>>> the >>>> advantages of a microkernel to its developers, and avoids the need for >>>> lots of context switches. It doesn't let you easily replace low-level OS >>>> components, but not many people actually want that. >>> >>> Actually, I think there are a whole lot of people who can't afford >>> non-stop server hardware but would greatly appreciate not having to >>> waste time with a shutdown/reboot every time some OS component gets >>> updated. >>> >>> YMMV. >> >> This is _exactly_ (one of) the problem(s) cloud infrastructure solves: >> As soon as you have more than a single instance of a particular >> server/service, then you replace them in groups so that the service sees >> zero downtime even though all the servers have been updated/replaced. >> > >That's fine - /if/ you have a service that can easily be spread across >multiple systems, and you can justify the cost of that. Setting up a >database server is simple enough. > >Setting up a database server along with a couple of read-only >replications is harder. Adding a writeable failover secondary is harder >still. Making sure that everything works /perfectly/ when the primary >goes down for maintenance, and that everything is consistent afterwards, >is even harder. Being sure it still all works even while the different >parts have different versions during updates typically means you have to >duplicate the whole thing so you can do test runs. And if the database >server is not open source, your license costs will be absurd, compared >to what you actually need to provide the service - usually just one >server instance. > >Clouds do nothing to help any of that. > >But clouds /do/ mean that your virtual machine can be migrated (with >zero, or almost zero, downtime) to another physical server if there are >hardware problems or during hardware maintenance. And if you can do >easy snapshots with your cloud / VM infrastructure, then you can roll >back if things go badly wrong. So you have a single server instance, >you plan a short period of downtime, take a snapshot, stop the service, >upgrade, restart. That's what almost everyone does, other than the >/really/ big or /really/ critical service providers. For various definitions of "short period of downtime". 8-) Fortunately, Linux installs updates - or stages updates for restart - much faster than Windoze. But rebooting to the point that all the services are running still can take several minutes. That can feel like an eternity when it's the only <whatever> server in a small business.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-17 14:39 +0200 |
| Subject | Re: Byte ordering |
| Message-ID | <ver0ih$2obfr$1@dont-email.me> |
| In reply to | #109769 |
On 17/10/2024 03:19, George Neuner wrote: > On Wed, 16 Oct 2024 09:17:03 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 16/10/2024 07:36, Terje Mathisen wrote: >>> George Neuner wrote: >>>> On Tue, 15 Oct 2024 18:40 +0100 (BST), jgd@cix.co.uk (John Dallman) >>>> wrote: >>>> >>>>> In article <vekb2f$1co97$6@dont-email.me>, ldo@nz.invalid (Lawrence >>>>> D'Oliveiro) wrote: >>>>> >>>>>> On the other hand, some stubborn holdouts are still fond of >>>>>> microkernels -- you just have to say the whole idea is pointless, >>>>>> and they come out of the woodwork in a futile attempt to disagree >>>>> >>>>> The idea is impractical, not pointless. A hybrid kernel gives most of >>>>> the >>>>> advantages of a microkernel to its developers, and avoids the need for >>>>> lots of context switches. It doesn't let you easily replace low-level OS >>>>> components, but not many people actually want that. >>>> >>>> Actually, I think there are a whole lot of people who can't afford >>>> non-stop server hardware but would greatly appreciate not having to >>>> waste time with a shutdown/reboot every time some OS component gets >>>> updated. >>>> >>>> YMMV. >>> >>> This is _exactly_ (one of) the problem(s) cloud infrastructure solves: >>> As soon as you have more than a single instance of a particular >>> server/service, then you replace them in groups so that the service sees >>> zero downtime even though all the servers have been updated/replaced. >>> >> >> That's fine - /if/ you have a service that can easily be spread across >> multiple systems, and you can justify the cost of that. Setting up a >> database server is simple enough. >> >> Setting up a database server along with a couple of read-only >> replications is harder. Adding a writeable failover secondary is harder >> still. Making sure that everything works /perfectly/ when the primary >> goes down for maintenance, and that everything is consistent afterwards, >> is even harder. Being sure it still all works even while the different >> parts have different versions during updates typically means you have to >> duplicate the whole thing so you can do test runs. And if the database >> server is not open source, your license costs will be absurd, compared >> to what you actually need to provide the service - usually just one >> server instance. >> >> Clouds do nothing to help any of that. >> >> But clouds /do/ mean that your virtual machine can be migrated (with >> zero, or almost zero, downtime) to another physical server if there are >> hardware problems or during hardware maintenance. And if you can do >> easy snapshots with your cloud / VM infrastructure, then you can roll >> back if things go badly wrong. So you have a single server instance, >> you plan a short period of downtime, take a snapshot, stop the service, >> upgrade, restart. That's what almost everyone does, other than the >> /really/ big or /really/ critical service providers. > > For various definitions of "short period of downtime". 8-) Yes, indeed. > > Fortunately, Linux installs updates - or stages updates for restart - > much faster than Windoze. But rebooting to the point that all the > services are running still can take several minutes. > My experience is that the updates on Linux servers are usually fast (for desktops they can be slow, but that is usually because you have far more and bigger programs). Updates for virtual machines are particularly fast because you generally have a minimum of programs in the VM. Restarts are also fast for virtual machines - physical servers are often slow to restart, sometimes taking many minutes before they get to the point of starting the OS boot. > That can feel like an eternity when it's the only <whatever> server in > a small business. Sure. But for most small businesses, it's not hard to find off-peak times when you can have hours of downtime without causing a problem.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2024-10-17 02:35 +0000 |
| Subject | Re: clouds, not Byte ordering |
| Message-ID | <vept4r$e1l$1@gal.iecc.com> |
| In reply to | #109745 |
According to David Brown <david.brown@hesbynett.no>: >Setting up a database server along with a couple of read-only >replications is harder. Adding a writeable failover secondary is harder >still. Making sure that everything works /perfectly/ when the primary >goes down for maintenance, and that everything is consistent afterwards, >is even harder. Being sure it still all works even while the different >parts have different versions during updates typically means you have to >duplicate the whole thing so you can do test runs. And if the database >server is not open source, your license costs will be absurd, compared >to what you actually need to provide the service - usually just one >server instance. > >Clouds do nothing to help any of that. AWS provides a database service that does most of that. You can spin up databases, read-only mirrors, failover from one region to another, staging environments to test upgrades. They offer MySQL and PostgreSQL, as well as Oracle and DB2. It's still a fair amount of work, but way less than doing it all yourself. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-17 14:41 +0200 |
| Subject | Re: clouds, not Byte ordering |
| Message-ID | <ver0l2$2obfr$2@dont-email.me> |
| In reply to | #109770 |
On 17/10/2024 04:35, John Levine wrote: > According to David Brown <david.brown@hesbynett.no>: >> Setting up a database server along with a couple of read-only >> replications is harder. Adding a writeable failover secondary is harder >> still. Making sure that everything works /perfectly/ when the primary >> goes down for maintenance, and that everything is consistent afterwards, >> is even harder. Being sure it still all works even while the different >> parts have different versions during updates typically means you have to >> duplicate the whole thing so you can do test runs. And if the database >> server is not open source, your license costs will be absurd, compared >> to what you actually need to provide the service - usually just one >> server instance. >> >> Clouds do nothing to help any of that. > > AWS provides a database service that does most of that. You can spin > up databases, read-only mirrors, failover from one region to another, > staging environments to test upgrades. They offer MySQL and > PostgreSQL, as well as Oracle and DB2. > > It's still a fair amount of work, but way less than doing it all yourself. > That's an additional service they provide - it's not an inherent part of a cloud infrastructure. Still, it sounds like a useful service, and one that I might find useful in the future.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-18 05:57 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <vestbq$35pc2$5@dont-email.me> |
| In reply to | #109730 |
On Tue, 15 Oct 2024 18:40 +0100 (BST), John Dallman wrote: > Windows NT and Apple's XNU, used in all their operating systems, are > both hybrid kernels, so the idea is somewhat practical. The fact that both are regularly outperformed (and outfeatured) by Linux, on hardware that is supposedly optimized for those specific proprietary OSes, just reinforces my point.
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2024-10-16 11:34 -0400 |
| Subject | Re: Byte ordering |
| Message-ID | <veomeb$2a76j$1@dont-email.me> |
| In reply to | #109709 |
On 10/14/24 7:55 PM, Lawrence D'Oliveiro wrote: [snip] > On the other hand, some stubborn holdouts are still fond of microkernels > -- you just have to say the whole idea is pointless, and they come out of > the woodwork in a futile attempt to disagree ... While the argument that only microkernels can provide modularity with respect to software development seems highly flawed, modularity with respect to privilege seems more challenging (impossible?) for a monolithic kernel and modularity with respect to fault isolation seems to require substantially more discipline/ constraint than typical for a monolithic design. Data isolation seems possible in a monolithic kernel such that a failure could be isolated to a specific subsystem and that subsystem could be restarted into a known good state. Microrebooting seems uncommon. I am guessing this comes from extremely high availability not being that important and/or other mechanism are used for availability, especially at warehouse scale. Physical distribution of functionality may also be more foreign to a monolithic kernel design. E.g., pinning functionality to a particular core or kind of core may urge message passing. In theory, something like MWAIT could be used for a fast and targeted inter-processor interrupt, but the limit of one wait condition per active thread is a significant constraint. The primary argument against microkernels seem to be the poor performance due to changing permission and more abstracted communication. Most of the overhead for permission change is not physically fundamental; the overhead can be nearly equal to that of a function call. Since the overhead of indirect function calls seems to be considered acceptable in a monolithic kernel, the performance overhead argument seems limited to existing hardware rather than implementable hardware. (This also depends on permission metadata being present in a nearby cache. If the code/data and permission caches have similar persistence, this would mean the fast case would be nearly equal. With hierarchical page tables — especially if nested — the slow case for permission change can be much worse for a permission change.) Software like FUSE (Filesystem in Userspace) hints that some microkernel aspects are desirable even in a monolithic kernel system. PA-RISC and Itanium had page groups, which could allow fast permission removal (invalidating or removing some permissions from a page group key could be fast). Fast de-privileging might be useful. Scanning a binary for (not) re-enabling might be practical if the operation is not simply a store, and this would allow re-enabling permissions to be fast. However, actually removing the permission to grant permissions seems better. Itanium's Enter Privileged Code (EPC) instruction was intended to provide fast system calls, but it had some complications in interacting with other Itanium features (I vaguely recall). I know relatively little about OSes, but the arguments I have read on both sides seem to have been very biased.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-18 05:54 +0000 |
| Subject | Re: Microkernels & Capabilities (was Re: Byte ordering) |
| Message-ID | <vest6o$35pc2$3@dont-email.me> |
| In reply to | #109750 |
On Wed, 16 Oct 2024 11:34:31 -0400, Paul A. Clayton wrote: > While the argument that only microkernels can provide modularity with > respect to software development seems highly flawed, modularity with > respect to privilege seems more challenging (impossible?) for a > monolithic kernel and modularity with respect to fault isolation seems > to require substantially more discipline/ constraint than typical for a > monolithic design. The CHERI project has been trying to revive the capability concept. They chose BSD over Linux (neither being microkernel-based) for their research purely on the basis that BSD was a slower-moving target. (Maybe they didn’t know about LTS Linux kernels.) Seems like the idea of using a microkernel never occurred to them. Not seriously, anyway. > Software like FUSE (Filesystem in Userspace) hints that some microkernel > aspects are desirable even in a monolithic kernel system. It is useful for less performance-intensive code. For example, NTFS support has primarily been primarily provided over the past couple of decades via FUSE; the equivalent kernel-based filesystem module has been lagging somewhat in features, even though that is still seen as the better approach for high performance. Obviously this is not true of Linux filesystems in general, it just happens to be the case with NTFS. > I know relatively little about OSes, but the arguments I have read on > both sides seem to have been very biased. Can’t argue with reality, though.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-14 23:51 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <vekapv$1co97$5@dont-email.me> |
| In reply to | #109580 |
On Tue, 8 Oct 2024 22:28 +0100 (BST), John Dallman wrote: > The same problem seems to have messed up all the attempts to provide > good Unix emulation on VMS. Was it the Perl build scripts that, at some point their compatibility tests on a *nix system, would announce “Congratulations! You’re not running EUNICE!”. > In article <vdvvae$1k931$2@dont-email.me>, ldo@nz.invalid (Lawrence > D'Oliveiro) wrote: > >> I think the whole _personality_ concept, along with the supposed >> portability to non-x86 architectures, had just bit-rotted away by that >> point. > > Some combination of that, Microsoft confidence that "of course we can do > something better now!" - they are very prone to overconfidence - and the > terrible tendency of programmers to ignore the details of the old code. It was the Microsoft management that did it -- the culmination of a whole sequence of short-term, profit-oriented decisions over many years ... decades. What may have started out as an “elegant design” finally became unrecognizable as such. Compare what was happening to Linux over the same time interval, where the programmers were (largely) not beholden to managers and bean counters.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-15 00:17 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <4409d7d76314f27f6a14f3523d3e9365@www.novabbs.org> |
| In reply to | #109708 |
On Mon, 14 Oct 2024 23:51:27 +0000, Lawrence D'Oliveiro wrote: > On Tue, 8 Oct 2024 22:28 +0100 (BST), John Dallman wrote: > >> The same problem seems to have messed up all the attempts to provide >> good Unix emulation on VMS. > > Was it the Perl build scripts that, at some point their compatibility > tests on a *nix system, would announce “Congratulations! You’re not > running EUNICE!”. > >> In article <vdvvae$1k931$2@dont-email.me>, ldo@nz.invalid (Lawrence >> D'Oliveiro) wrote: >> >>> I think the whole _personality_ concept, along with the supposed >>> portability to non-x86 architectures, had just bit-rotted away by that >>> point. >> >> Some combination of that, Microsoft confidence that "of course we can do >> something better now!" - they are very prone to overconfidence - and the >> terrible tendency of programmers to ignore the details of the old code. > > It was the Microsoft management that did it -- the culmination of a > whole > sequence of short-term, profit-oriented decisions over many years ... > decades. What may have started out as an “elegant design” finally became > unrecognizable as such. > > Compare what was happening to Linux over the same time interval, where > the > programmers were (largely) not beholden to managers and bean counters. Last 5 words are unnecessary.
[toc] | [prev] | [next] | [standalone]
Page 3 of 23 — ← Prev page 1 2 [3] 4 5 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web