Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #233681 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-01-27 20:15 +0000 |
| Last post | 2026-04-15 22:10 +0000 |
| Articles | 20 on this page of 268 — 29 participants |
Back to article view | Back to alt.folklore.computers
Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-27 20:15 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-27 15:58 -0500
Re: Don Norman: The Truth About Unix jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-01-27 21:00 -0500
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-01-28 03:24 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-27 21:41 -0700
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 04:45 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-28 05:26 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-28 08:00 -0700
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 23:47 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 00:47 +0000
Re: Don Norman: The Truth About Unix ram@zedat.fu-berlin.de (Stefan Ram) - 2026-01-28 12:07 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-28 13:37 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-01-28 15:21 +0000
Re: Don Norman: The Truth About Unix Adam Sampson <ats@offog.org> - 2026-01-28 19:54 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 23:45 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 00:56 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-28 20:29 -0700
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-29 16:09 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 19:32 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-29 20:40 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-28 15:55 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-01-28 18:31 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 14:10 -0500
Re: Don Norman: The Truth About Unix Rich Alderson <news@alderson.users.panix.com> - 2026-01-28 16:26 -0500
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 00:59 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 22:26 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-29 06:54 -0500
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-29 14:50 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-30 13:04 -0800
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-31 15:10 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-01-31 11:59 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-31 16:39 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-31 20:56 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-02-02 10:36 -0800
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-29 14:39 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-29 16:01 +0000
Re: Don Norman: The Truth About Unix "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-01-30 17:19 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-28 08:11 -0700
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 14:15 -0500
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 22:25 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 00:52 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 04:19 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 06:55 -0500
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-01-28 12:01 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-28 15:51 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-28 16:14 -0800
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 06:30 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-29 15:34 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 19:32 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-29 12:49 -0700
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 20:01 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 22:56 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-30 00:58 +0000
Re: Don Norman: The Truth About Unix John Levine <johnl@taugh.com> - 2026-01-30 23:49 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-31 04:55 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-29 23:48 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-30 07:35 -0700
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-30 11:29 -0500
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-30 19:18 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-30 12:22 -0800
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-30 22:26 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-31 05:04 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-31 04:58 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-31 06:59 -0500
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-31 18:10 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-31 19:39 +0000
Re: Don Norman: The Truth About Unix jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-01-30 13:57 -0500
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-30 21:11 +0000
Re: Don Norman: The Truth About Unix Rich Alderson <news@alderson.users.panix.com> - 2026-01-30 18:59 -0500
Re: Don Norman: The Truth About Unix Beej Jorgensen <beej@beej.us> - 2026-02-02 02:22 +0000
Re: Don Norman: The Truth About Unix Daniel <me@sc1f1dan.com> - 2026-01-27 21:32 -0800
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 06:11 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 07:07 -0500
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 06:30 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 15:28 +0000
Re: Don Norman: The Truth About Unix Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-29 17:14 +0000
Re: Don Norman: The Truth About Unix "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-01-30 17:32 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-30 13:03 -0700
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-30 21:18 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-01-31 11:30 +0000
Re: Don Norman: The Truth About Unix drb@ihatespam.msu.edu (Dennis Boone) - 2026-01-31 19:22 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-31 21:08 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-31 22:52 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 01:37 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-02-01 05:44 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 06:15 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-02-01 06:23 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 06:50 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-02-01 06:58 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-02-01 17:56 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-02-01 07:38 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-02-01 07:24 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-01 08:28 -0500
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-02-01 19:48 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-02 11:44 -0500
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-02-02 19:49 +0000
Re: Don Norman: The Truth About Unix Beej Jorgensen <beej@beej.us> - 2026-02-03 19:40 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-02-04 00:58 +0000
Re: Don Norman: The Truth About Unix Beej Jorgensen <beej@beej.us> - 2026-02-05 05:52 +0000
Re: Don Norman: The Truth About Unix Andreas Eder <a_eder_muc@web.de> - 2026-02-04 11:08 +0100
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-01 08:18 -0500
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-01 08:16 -0500
ed (was: Don Norman: The Truth About Unix) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-02-02 15:31 +0000
Re: ed (was: Don Norman: The Truth About Unix) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-02-02 17:36 +0000
Re: ed (was: Don Norman: The Truth About Unix) rbowman <bowman@montana.com> - 2026-02-02 20:19 +0000
Re: ed (was: Don Norman: The Truth About Unix) scott@slp53.sl.home (Scott Lurndal) - 2026-02-02 20:46 +0000
Re: ed (was: Don Norman: The Truth About Unix) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-02 21:01 +0000
Re: Don Norman: The Truth About Unix jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-01-28 14:07 -0500
Re: Don Norman: The Truth About Unix Adam Sampson <ats@offog.org> - 2026-01-28 19:40 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 17:30 -0500
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-28 20:19 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-28 13:50 -0700
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-28 22:13 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 06:30 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 15:24 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 06:30 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-29 07:59 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 19:32 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-29 20:48 +0000
less is *not* really more or less like more? (was: Re: Don Norman: The Truth About Unix) Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-30 09:51 +0000
Re: less is *not* really more or less like more? (was: Re: Don Norman: The Truth About Unix) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-30 19:18 +0000
Re: Don Norman: The Truth About Unix antispam@fricas.org (Waldek Hebisch) - 2026-01-30 15:14 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-30 15:50 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-30 18:46 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-30 20:56 +0000
Re: Don Norman: The Truth About Unix antispam@fricas.org (Waldek Hebisch) - 2026-01-31 13:10 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-30 21:15 +0000
Re: Don Norman: The Truth About Unix antispam@fricas.org (Waldek Hebisch) - 2026-01-31 13:14 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-31 20:57 +0000
Re: Don Norman: The Truth About Unix drb@ihatespam.msu.edu (Dennis Boone) - 2026-01-28 21:50 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 22:24 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 01:19 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 17:32 -0500
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 01:42 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-29 14:34 +0000
pg (was: Don Norman: The Truth About Unix) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-02-02 15:39 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 17:27 -0500
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 01:17 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-29 14:06 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-29 12:42 -0700
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-30 11:01 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-30 07:44 -0700
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-30 15:48 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-30 12:55 -0800
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-31 16:47 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-02-05 10:35 -0800
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-09 13:10 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-02-16 15:49 -0800
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-30 21:18 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-31 07:40 -0700
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-31 17:58 +0000
Re: Don Norman: The Truth About Unix drb@ihatespam.msu.edu (Dennis Boone) - 2026-01-31 19:44 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-01 15:09 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-01 08:12 -0500
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-31 21:05 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-31 22:52 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 01:35 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-02-01 06:32 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 06:49 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-02-02 09:47 -0800
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-02-01 00:40 -0700
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 08:59 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-01 15:06 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-02-01 12:54 -0700
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 19:57 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-02-01 14:21 -0700
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 21:31 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-02-02 17:33 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-02 18:10 +0000
Re: Don Norman: The Truth About Unix Anthk <anthk@disroot.org> - 2026-04-15 06:48 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-04-15 15:52 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-15 22:12 +0000
Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-04-17 14:20 +0100
Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) Bob Eager <throwaway0008@eager.cx> - 2026-04-17 13:48 +0000
Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-17 22:44 +0000
Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-04-20 13:26 +0100
Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-20 13:19 +0000
Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-20 21:32 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-02 18:08 +0000
Re: PC/IX, was Don Norman: The Truth About Unix John Levine <johnl@taugh.com> - 2026-02-03 02:29 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-03 03:24 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-02-03 10:56 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-03 21:19 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-02-03 21:55 +0000
"POSIX" ACLs (was: Don Norman: The Truth About Unix) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-02-04 13:47 +0000
Re: "POSIX" ACLs (was: Don Norman: The Truth About Unix) scott@slp53.sl.home (Scott Lurndal) - 2026-02-04 15:41 +0000
Re: "POSIX" ACLs (was: Don Norman: The Truth About Unix) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-02-05 13:33 +0000
Re: "POSIX" ACLs (was: Don Norman: The Truth About Unix) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-05 16:13 +0000
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-02-04 18:16 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-04 20:39 +0000
Re: Don Norman: The Truth About Unix Anthk <anthk@disroot.org> - 2026-04-15 06:48 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-02-03 15:02 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-02-03 15:22 -0700
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-03 22:32 +0000
fucking lies [was Re: Don Norman: The Truth About Unix] Rich Alderson <news@alderson.users.panix.com> - 2026-02-04 15:29 -0500
Re: fucking lies [was Re: Don Norman: The Truth About Unix] cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-04 21:47 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-02-04 15:41 +0000
Re: Don Norman: The Truth About Unix Lars Poulsen <lars@beagle-ears.com> - 2026-02-04 23:43 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-02-05 02:07 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:05 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-02-05 14:55 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-02-05 10:42 -0700
Re: Don Norman: The Truth About Unix Anthk <anthk@disroot.org> - 2026-04-15 06:48 +0000
Re: Don Norman: The Truth About Unix Bob Eager <throwaway0008@eager.cx> - 2026-04-15 09:27 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-04-15 07:40 -0700
torn ACLs [was Re: Don Norman: The Truth About Unix] Rich Alderson <news@alderson.users.panix.com> - 2026-04-15 14:58 -0400
Re: torn ACLs [was Re: Don Norman: The Truth About Unix] scott@slp53.sl.home (Scott Lurndal) - 2026-04-15 20:27 +0000
Re: torn ACLs [was Re: Don Norman: The Truth About Unix] Rich Alderson <news@alderson.users.panix.com> - 2026-04-16 20:32 -0400
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-02-01 19:55 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-02 18:05 +0000
Re: Don Norman: The Truth About Unix Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-02-04 15:07 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-02-04 09:01 -0700
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-04 19:34 +0000
Re: Don Norman: The Truth About Unix Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-02-04 19:37 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-04 20:41 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-04 19:20 +0000
Re: Don Norman: The Truth About Unix Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-02-04 19:36 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-02-04 21:46 +0000
Re: Don Norman: The Truth About Unix Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-02-05 15:12 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-01 08:12 -0500
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-31 18:19 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-29 20:57 +0000
Re: Don Norman: The Truth About Unix Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-30 10:03 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-28 08:06 -0700
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 14:38 -0500
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-28 20:34 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-28 17:36 -0500
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 00:36 +0000
Re: Don Norman: The Truth About Unix David Wade <g4ugm@dave.invalid> - 2026-01-29 08:43 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-01-29 15:36 +0000
Re: Don Norman: The Truth About Unix Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-01-29 11:46 -0500
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 19:32 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 19:58 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 06:30 +0000
Re: Don Norman: The Truth About Unix Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-29 12:15 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-29 19:32 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 19:55 +0000
Re: Don Norman: The Truth About Unix Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-30 09:56 +0000
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-30 19:02 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-30 11:32 -0800
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-31 05:10 +0000
Re: Don Norman: The Truth About Unix Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-02-05 03:04 -0400
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-01-31 11:40 +0000
Re: Don Norman: The Truth About Unix "Kurt Weiske" <kurt.weiske@realitycheckbbs.org.remove-m6d-this> - 2026-01-31 08:35 -0800
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-30 11:59 -0800
Re: Don Norman: The Truth About Unix Niklas Karlsson <nikke.karlsson@gmail.com> - 2026-01-31 11:36 +0000
Re: Don Norman: The Truth About Unix John Levine <johnl@taugh.com> - 2026-01-28 22:26 +0000
Re: Don Norman: The Truth About Unix Peter Flass <Peter@Iron-Spring.com> - 2026-01-28 20:26 -0700
Re: Don Norman: The Truth About Unix Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-30 09:46 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-30 19:18 +0000
Re: Don Norman: The Truth About Unix antispam@fricas.org (Waldek Hebisch) - 2026-01-31 16:25 +0000
Re: Don Norman: The Truth About Unix Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-29 11:22 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-27 16:02 -0800
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-28 01:52 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-28 16:12 -0800
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-29 00:28 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-30 13:07 -0800
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-30 21:21 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-01-29 14:36 +0000
Re: Don Norman: The Truth About Unix Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-28 00:29 +0000
Re: Don Norman: The Truth About Unix John Ames <commodorejohn@gmail.com> - 2026-01-28 16:11 -0800
Re: Don Norman: The Truth About Unix rbowman <bowman@montana.com> - 2026-01-29 00:54 +0000
Re: Don Norman: The Truth About Unix Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-29 11:20 +0000
Re: Don Norman: The Truth About Unix Anthk <anthk@disroot.org> - 2026-04-15 06:48 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-15 11:24 +0000
Re: Don Norman: The Truth About Unix scott@slp53.sl.home (Scott Lurndal) - 2026-04-15 15:47 +0000
Re: Don Norman: The Truth About Unix cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-15 16:11 +0000
Re: Don Norman: The Truth About Unix Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-15 22:10 +0000
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-02-01 00:40 -0700 |
| Message-ID | <10ln01t$3hqko$1@dont-email.me> |
| In reply to | #233843 |
On 1/31/26 14:05, Lawrence D’Oliveiro wrote: > Worth also pointing out that, at the time of MS-DOS 2.0 with its > introduction of some bizarro-Unix features, the commonly-available PC > hardware was already more powerful than the original PDP-11 systems > that Unix was created on. So why couldn’t Microsoft (or IBM) provide a > full Unix-equivalent OS for PC hardware back then? No memory protection or memory mapping until the 386. There were unix-like OSs for 8086, but they were terrible fragile without memory protection. I don't know how it was managed on the PDP-11.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-02-01 08:59 +0000 |
| Message-ID | <10ln4l9$3j3gu$1@dont-email.me> |
| In reply to | #233858 |
On Sun, 1 Feb 2026 00:40:44 -0700, Peter Flass wrote: > On 1/31/26 14:05, Lawrence D’Oliveiro wrote: > >> Worth also pointing out that, at the time of MS-DOS 2.0 with its >> introduction of some bizarro-Unix features, the commonly-available >> PC hardware was already more powerful than the original PDP-11 >> systems that Unix was created on. So why couldn’t Microsoft (or >> IBM) provide a full Unix-equivalent OS for PC hardware back then? > > No memory protection or memory mapping until the 386. There were > unix-like OSs for 8086, but they were terrible fragile without > memory protection. I don't know how it was managed on the PDP-11. The 386, and even the 286, had advanced memory protection beyond anything available on the PDP-11. That had a 64kiB address space, divided into just 8 pages of 8kiB each, each covering a fixed portion of that address space. No paging. That was enough for Unix.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-02-01 15:06 +0000 |
| Message-ID | <10lnq6e$643$1@reader2.panix.com> |
| In reply to | #233858 |
In article <10ln01t$3hqko$1@dont-email.me>, Peter Flass <Peter@Iron-Spring.com> wrote: >On 1/31/26 14:05, Lawrence D’Oliveiro wrote: > >> Worth also pointing out that, at the time of MS-DOS 2.0 with its >> introduction of some bizarro-Unix features, the commonly-available PC >> hardware was already more powerful than the original PDP-11 systems >> that Unix was created on. So why couldn’t Microsoft (or IBM) provide a >> full Unix-equivalent OS for PC hardware back then? > >No memory protection or memory mapping until the 386. There were >unix-like OSs for 8086, but they were terrible fragile without memory >protection. I don't know how it was managed on the PDP-11. [Meta note: I wonder why people continue to engage with Lawrence as he is an obvious troll. Please don't feed him] Most PDP-11 models that ran Unix had an MMU. It wasn't a very capable MMU, mind you, but it at least allowed the system to protect processes from one another and protect the kernel from processes. John Levine has posted before about a port of Unix to the 8086, that made use of the segmentation system to more or less protect the OS from errant user programs; the C compiler simply did not emit instructions to change the segmentation registers, so it worked pretty well as I understand it. The 80286 featured a bizarre, overly wrought "task" model in hardware that saw little use in practice; I believe that OS/2 might have used it. Vestiges of it persist into the modern day, where the "TSS" (Task State Segment) has been overloaded in 64-bit "long" mode to hold a table of stack pointers that can be used with various traps so that, say, the double-fault, NMI or debug/breakpoint handlers can run on dedicated stacks. There's also some business about allowing non-privileged access to IO ports for programmed IO from user-mode code. Anyway. The 80386 was designed as a 32-bit CPU for the Unix workstation market, and supported paging natively. I must say, all things considered they did a pretty good job overall with the design of the MMU and page table format. To maintain backwards compabibility they extended the segmentation mechanism; the intent was that you would define segments covering the entire 32-bit address space and then more or less ignore them. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-02-01 12:54 -0700 |
| Message-ID | <10lob1i$264s$1@dont-email.me> |
| In reply to | #233865 |
On 2/1/26 08:06, Dan Cross wrote: > > John Levine has posted before about a port of Unix to the 8086, > that made use of the segmentation system to more or less protect > the OS from errant user programs; the C compiler simply did not > emit instructions to change the segmentation registers, so it > worked pretty well as I understand it. As long is everything is limited to 64K data and 64K program. > The "TSS" (Task State Segment) has been overloaded in > 64-bit "long" mode to hold a table of stack pointers that can be > used with various traps so that, say, the double-fault, NMI or > debug/breakpoint handlers can run on dedicated stacks. I can see where this would be useful. There's > also some business about allowing non-privileged access to IO > ports for programmed IO from user-mode code. Anyway. > > The 80386 was designed as a 32-bit CPU for the Unix workstation > market, and supported paging natively. I must say, all things > considered they did a pretty good job overall with the design of > the MMU and page table format. To maintain backwards > compabibility they extended the segmentation mechanism; the > intent was that you would define segments covering the entire > 32-bit address space and then more or less ignore them. I'm still disappointed that they didn't adopt the Multics model for segments.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-02-01 19:57 +0000 |
| Message-ID | <10lob7m$28gf$2@dont-email.me> |
| In reply to | #233869 |
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote: > I'm still disappointed that they didn't adopt the Multics model for > segments. I think the Multics model imposed a limit on file sizes based on the size of the directly-accessible virtual address space. That meant that 32-bit machines could not have coped with multi-gigabyte files.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-02-01 14:21 -0700 |
| Message-ID | <10log5k$48j6$1@dont-email.me> |
| In reply to | #233871 |
On 2/1/26 12:57, Lawrence D’Oliveiro wrote: > On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote: > >> I'm still disappointed that they didn't adopt the Multics model for >> segments. > > I think the Multics model imposed a limit on file sizes based on the > size of the directly-accessible virtual address space. That meant that > 32-bit machines could not have coped with multi-gigabyte files. They came up with multi-segment files to solve this problem.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-02-01 21:31 +0000 |
| Message-ID | <10logo3$4c75$2@dont-email.me> |
| In reply to | #233872 |
On Sun, 1 Feb 2026 14:21:55 -0700, Peter Flass wrote: > On 2/1/26 12:57, Lawrence D’Oliveiro wrote: >> >> I think the Multics model imposed a limit on file sizes based on >> the size of the directly-accessible virtual address space. That >> meant that 32-bit machines could not have coped with multi-gigabyte >> files. > > They came up with multi-segment files to solve this problem. See, that kind of workaround was unnecessary with the Unix bytestream model. I suppose with 64-bit architectures, we have now reached a point where the Multics model could be practical again. But that would not get around the drawback of having to deal differently with files that are mapped from backing store, versus stream-style I/O (pipes, sockets etc).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-02-02 17:33 +0000 |
| Message-ID | <Jd5gR.2$l1w.1@fx16.iad> |
| In reply to | #233872 |
Peter Flass <Peter@Iron-Spring.com> writes: >On 2/1/26 12:57, Lawrence D’Oliveiro wrote: >> On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote: >> >>> I'm still disappointed that they didn't adopt the Multics model for >>> segments. >> >> I think the Multics model imposed a limit on file sizes based on the >> size of the directly-accessible virtual address space. That meant that >> 32-bit machines could not have coped with multi-gigabyte files. > >They came up with multi-segment files to solve this problem. That's a band-aid, not a solution. Segments (also used by Burroughs systems and the HP-3000) are relegated to the scrap-heap of history. Thankfully.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-02-02 18:10 +0000 |
| Message-ID | <10lqpa4$et1$3@reader2.panix.com> |
| In reply to | #233872 |
In article <10log5k$48j6$1@dont-email.me>, Peter Flass <Peter@Iron-Spring.com> wrote: >On 2/1/26 12:57, Lawrence D’Oliveiro wrote: >> On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote: >> >>> I'm still disappointed that they didn't adopt the Multics model for >>> segments. >> >> I think the Multics model imposed a limit on file sizes based on the >> size of the directly-accessible virtual address space. That meant that >> 32-bit machines could not have coped with multi-gigabyte files. > >They came up with multi-segment files to solve this problem. 32-bit machines running Unix suffered constraints on total file sizes for years, because the size (in bytes) of a disk file was a signed quantity. It was very painful to move to 64-bit file offsets and sizes, and took many, many years. The Multics multi-segment files were certainly a bit of a bandaid solution, but to act as if Unix didn't have similar challenges is silly. Again, I wonder why anyone seriously engages with this known troll. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Anthk <anthk@disroot.org> |
|---|---|
| Date | 2026-04-15 06:48 +0000 |
| Message-ID | <slrn10tq23v.467.anthk@openbsd.home> |
| In reply to | #233871 |
On 2026-02-01, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote: > >> I'm still disappointed that they didn't adopt the Multics model for >> segments. > > I think the Multics model imposed a limit on file sizes based on the > size of the directly-accessible virtual address space. That meant that > 32-bit machines could not have coped with multi-gigabyte files. By default under GNU/Linux you need to pass a preprocessor flag to enforce large file support on 32 bit programs. For instance, VLC, dd and so on.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-15 15:52 +0000 |
| Message-ID | <RuODR.276696$4wI6.69495@fx24.iad> |
| In reply to | #234662 |
Anthk <anthk@disroot.org> writes: >On 2026-02-01, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote: >> >>> I'm still disappointed that they didn't adopt the Multics model for >>> segments. >> >> I think the Multics model imposed a limit on file sizes based on the >> size of the directly-accessible virtual address space. That meant that >> 32-bit machines could not have coped with multi-gigabyte files. > >By default under GNU/Linux you need to pass a preprocessor flag >to enforce large file support on 32 bit programs. For instance, VLC, >dd and so on. In the mid-90's, I represented my employer at the Large File Summit, which specified a set of standard updates to support accessing files greater than 2GB on 32-bit unix systems. https://en.wikipedia.org/wiki/Large-file_support
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-15 22:12 +0000 |
| Message-ID | <10rp2g4$192to$5@dont-email.me> |
| In reply to | #234662 |
On Wed, 15 Apr 2026 06:48:42 -0000 (UTC), Anthk wrote: > By default under GNU/Linux you need to pass a preprocessor flag to > enforce large file support on 32 bit programs. All that does is choose which kernel calls your source code will make.
[toc] | [prev] | [next] | [standalone]
| From | Geoff Clare <geoff@clare.See-My-Signature.invalid> |
|---|---|
| Date | 2026-04-17 14:20 +0100 |
| Subject | Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) |
| Message-ID | <rmo9bm-qan.ln1@ID-313840.user.individual.net> |
| In reply to | #234696 |
Lawrence D’Oliveiro wrote:
> On Wed, 15 Apr 2026 06:48:42 -0000 (UTC), Anthk wrote:
>
>> By default under GNU/Linux you need to pass a preprocessor flag to
>> enforce large file support on 32 bit programs.
>
> All that does is choose which kernel calls your source code will make.
It does rather more than that. The primary thing it does is change
the definition of off_t so that it is a 64-bit integer instead of 32.
E.g. with glibc:
$ echo '#include <sys/types.h>' | gcc -m32 -E - | grep '[^l]off_t'
__extension__ typedef long int __off_t;
typedef __off_t off_t;
$ echo '#include <sys/types.h>' | gcc -m32 -D_FILE_OFFSET_BITS=64 -E - | grep '[^l]off_t'
__extension__ typedef long int __off_t;
typedef __off64_t off_t;
As a consequence of this, every C library function that involves off_t
or structures containing off_t has to end up calling a different function.
Some of them just make kernel calls, but others don't. For example, the
fseeko() function:
$ echo '#include <stdio.h>' | gcc -m32 -E - | grep fseeko
extern int fseeko (FILE *__stream, __off_t __off, int __whence);
$ echo '#include <stdio.h>' | gcc -m32 -D_FILE_OFFSET_BITS=64 -E - | grep fseeko
extern int fseeko (FILE *__stream, __off64_t __off, int __whence) __asm__ ("" "fseeko64")
--
Geoff Clare <netnews@gclare.org.uk>
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <throwaway0008@eager.cx> |
|---|---|
| Date | 2026-04-17 13:48 +0000 |
| Subject | Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) |
| Message-ID | <n4es19FopcoU3@mid.individual.net> |
| In reply to | #234715 |
On Fri, 17 Apr 2026 14:20:59 +0100, Geoff Clare wrote: > Lawrence D’Oliveiro wrote: > >> On Wed, 15 Apr 2026 06:48:42 -0000 (UTC), Anthk wrote: >> >>> By default under GNU/Linux you need to pass a preprocessor flag to >>> enforce large file support on 32 bit programs. >> >> All that does is choose which kernel calls your source code will make. > > It does rather more than that. The primary thing it does is change the > definition of off_t so that it is a 64-bit integer instead of 32. I remember when the offset was a 16 bit integer! And one of the reasons UNIX disks were partitioned, because the device driver only handled 16 bits on the API side. (and why the seek call is called lseek)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-17 22:44 +0000 |
| Subject | Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) |
| Message-ID | <10rud5b$2r14r$3@dont-email.me> |
| In reply to | #234715 |
On Fri, 17 Apr 2026 14:20:59 +0100, Geoff Clare wrote: > Lawrence D’Oliveiro wrote: > >> On Wed, 15 Apr 2026 06:48:42 -0000 (UTC), Anthk wrote: >> >>> By default under GNU/Linux you need to pass a preprocessor flag to >>> enforce large file support on 32 bit programs. >> >> All that does is choose which kernel calls your source code will >> make. > > It does rather more than that. The primary thing it does is change > the definition of off_t so that it is a 64-bit integer instead of > 32. Again, that’s just to suit different kernel calls. The kernel doesn’t know, doesn’t care, what “off_t” means in your source code, or indeed any other name you might use.
[toc] | [prev] | [next] | [standalone]
| From | Geoff Clare <geoff@clare.See-My-Signature.invalid> |
|---|---|
| Date | 2026-04-20 13:26 +0100 |
| Subject | Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) |
| Message-ID | <4kihbm-blg.ln1@ID-313840.user.individual.net> |
| In reply to | #234722 |
Lawrence D’Oliveiro wrote: > On Fri, 17 Apr 2026 14:20:59 +0100, Geoff Clare wrote: > >> Lawrence D’Oliveiro wrote: >> >>> On Wed, 15 Apr 2026 06:48:42 -0000 (UTC), Anthk wrote: >>> >>>> By default under GNU/Linux you need to pass a preprocessor flag to >>>> enforce large file support on 32 bit programs. >>> >>> All that does is choose which kernel calls your source code will >>> make. >> >> It does rather more than that. The primary thing it does is change >> the definition of off_t so that it is a 64-bit integer instead of >> 32. > > Again, that’s just to suit different kernel calls. The kernel doesn’t > know, doesn’t care, what “off_t” means in your source code, or indeed > any other name you might use. The kernel doesn't care about the change of off_t size, but programmers very much need to care. If you try to mix object files compiled with different off_t sizes, and they interact in any way that involves off_t, it is not going to end well. The way glibc handles this for its own functions (that I mentioned but you didn't quote) is a special case of this, but for third-party libraries you're probably on your own. -- Geoff Clare <netnews@gclare.org.uk>
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-20 13:19 +0000 |
| Subject | Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) |
| Message-ID | <10s595e$aoc$1@reader1.panix.com> |
| In reply to | #234723 |
In article <4kihbm-blg.ln1@ID-313840.user.individual.net>, Geoff Clare <netnews@gclare.org.uk> wrote: >Lawrence D’Oliveiro wrote: >> On Fri, 17 Apr 2026 14:20:59 +0100, Geoff Clare wrote: >>> Lawrence D’Oliveiro wrote: >>>> On Wed, 15 Apr 2026 06:48:42 -0000 (UTC), Anthk wrote: >>>>> By default under GNU/Linux you need to pass a preprocessor flag to >>>>> enforce large file support on 32 bit programs. >>>> >>>> All that does is choose which kernel calls your source code will >>>> make. >>> >>> It does rather more than that. The primary thing it does is change >>> the definition of off_t so that it is a 64-bit integer instead of >>> 32. >> >> Again, that’s just to suit different kernel calls. The kernel doesn’t >> know, doesn’t care, what “off_t” means in your source code, or indeed >> any other name you might use. > >The kernel doesn't care about the change of off_t size, but programmers >very much need to care. If you try to mix object files compiled with >different off_t sizes, and they interact in any way that involves >off_t, it is not going to end well. The way glibc handles this for its >own functions (that I mentioned but you didn't quote) is a special case >of this, but for third-party libraries you're probably on your own. It's unclear to me what point Lawrence is trying to make; as usual, I suspect he doesn't have one. The kernel, of course, cares very much what a user program is using for `off_t`, since it will need to adjust to the different definitions accordingly (copy-in's and -outs need the size, of course, and it may exercise different error paths, and so on). If he simply means that the kernel is not concerned with the actual `typedef` or equivalent in a user program, since user programs are compiled separtely and outside of the domain of the program, then that may be true, but it's a pretty meaningless statement. But it would be typical of him, to fixate on some trivial detail and ignore the larger context. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-20 21:32 +0000 |
| Subject | Re: Glibc LFS on 32 bit (was: Don Norman: The Truth About Unix) |
| Message-ID | <10s661k$128dq$1@dont-email.me> |
| In reply to | #234723 |
On Mon, 20 Apr 2026 13:26:12 +0100, Geoff Clare wrote: > Lawrence D’Oliveiro wrote: > >> On Fri, 17 Apr 2026 14:20:59 +0100, Geoff Clare wrote: >> >>> Lawrence D’Oliveiro wrote: >>> >>>> On Wed, 15 Apr 2026 06:48:42 -0000 (UTC), Anthk wrote: >>>> >>>>> By default under GNU/Linux you need to pass a preprocessor flag >>>>> to enforce large file support on 32 bit programs. >>>> >>>> All that does is choose which kernel calls your source code will >>>> make. >>> >>> It does rather more than that. The primary thing it does is change >>> the definition of off_t so that it is a 64-bit integer instead of >>> 32. >> >> Again, that’s just to suit different kernel calls. The kernel >> doesn’t know, doesn’t care, what “off_t” means in your source code, >> or indeed any other name you might use. > > The kernel doesn't care about the change of off_t size, but > programmers very much need to care. Like I said, all it does is change which kernel calls your source code will make.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-02-02 18:08 +0000 |
| Message-ID | <10lqp6e$et1$2@reader2.panix.com> |
| In reply to | #233869 |
In article <10lob1i$264s$1@dont-email.me>, Peter Flass <Peter@Iron-Spring.com> wrote: >On 2/1/26 08:06, Dan Cross wrote: >> >> John Levine has posted before about a port of Unix to the 8086, >> that made use of the segmentation system to more or less protect >> the OS from errant user programs; the C compiler simply did not >> emit instructions to change the segmentation registers, so it >> worked pretty well as I understand it. > >As long is everything is limited to 64K data and 64K program. Yeah, that would be the downside. >> The "TSS" (Task State Segment) has been overloaded in >> 64-bit "long" mode to hold a table of stack pointers that can be >> used with various traps so that, say, the double-fault, NMI or >> debug/breakpoint handlers can run on dedicated stacks. > >I can see where this would be useful. It is. However, it would be better if there were banked stack pointers one could initialize via MSRs, as one does for e.g. LSTAR and KERNEL_GS_BASE. The need to continue to use the TSS feels weird; you _do_ need to touch it on every context switch, if your kernel threading model has separate stacks for each schedulable user thing (thread/process/task/whatever you want to call them). >There's >> also some business about allowing non-privileged access to IO >> ports for programmed IO from user-mode code. Anyway. >> >> The 80386 was designed as a 32-bit CPU for the Unix workstation >> market, and supported paging natively. I must say, all things >> considered they did a pretty good job overall with the design of >> the MMU and page table format. To maintain backwards >> compabibility they extended the segmentation mechanism; the >> intent was that you would define segments covering the entire >> 32-bit address space and then more or less ignore them. > >I'm still disappointed that they didn't adopt the Multics model for >segments. Which part of the model, specifically? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-02-03 02:29 +0000 |
| Subject | Re: PC/IX, was Don Norman: The Truth About Unix |
| Message-ID | <10lrmhr$18g4$1@gal.iecc.com> |
| In reply to | #233882 |
>>> John Levine has posted before about a port of Unix to the 8086, >>> that made use of the segmentation system to more or less protect >>> the OS from errant user programs; the C compiler simply did not >>> emit instructions to change the segmentation registers, so it >>> worked pretty well as I understand it. >> >>As long is everything is limited to 64K data and 64K program. We ported System III Unix from the PDP-11. The 8086 code was slightly smaller than PDP-11 code, and the data formats were basically the same, so all the programs that worked on the PDP-11 worked on PC/IX. But we found rather quickly that people wanted bigger programs and that would have meant a major system redesign. Despite the lack of hardware protection PC/IX was very reliable and often stayed up for months at a time. -- 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]
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web