The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: William Corcoran <wlc@jctaylor.com>
To: Henry Bent <henry.r.bent@gmail.com>
Cc: "tuhs@tuhs.org" <tuhs@tuhs.org>
Subject: Re: [TUHS] Awk for CSV files
Date: Sun, 13 Oct 2019 22:30:21 +0000	[thread overview]
Message-ID: <580AE12E-384E-4C13-9EA3-F9E53A2CC4C3@jctaylor.com> (raw)
In-Reply-To: <CAEdTPBfE+DTN_1XSUT8CZcjnhMszry0AQOou7AcPiXZrqBQciA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

Agreed.  Although it seems like a lot of these processor “bits” beyond 32 are now put to use into senseless saccharin AI endeavors like autocorrect.  I type “its” and it comes out as “it’s” when clearly it should have been “its” and it’s depressing, even more so when I miss it.

Truly,

Bill Corcoran
On Oct 13, 2019, at 3:36 PM, Henry Bent <henry.r.bent@gmail.com<mailto:henry.r.bent@gmail.com>> wrote:

On Sun, 13 Oct 2019 at 14:54, William Corcoran <wlc@jctaylor.com<mailto:wlc@jctaylor.com>> wrote:
Today, working with v7m, SVR1, and bsd2.11 all PDP11 ports, for example, will stay booted and operational for long periods under simulation.

This has certainly been my experience as well with mature, for the era, BSD ports.  Most of the problems I have encountered have been with TCP/IP issues in 2.11BSD and Ultrix 3.1 related to traffic they were never expecting.

With these older UNIX variants, working with awk and even the classic shell tools is often problematic.  Moreover resource constraints seem to be a persistent annoyance under simulation.

I think our expectations of a 16 bit Unix are going to be well out of proportion now.  When 16 and 32 bit Unix systems existed side by side it was easy to consider the resource limitations of both when programming.  Now that 16 bit systems have moved completely out of general end user space we only consider the constraints of the 32 and 64 bit systems that exist side by side.

Some of my interests lie in preserving early '90s hardware with original operating systems, and working within their constraints.  Porting modern tools to SunOS 4 or Ultrix 4 or IRIX 4 (huh, everyone really was stuck on the same version) is a challenge but it can be done, as long as those tools do not necessarily rely on shared libraries.  Backporting C99 to C89 is often not as difficult as it would seem, though it can sometimes be laborious.  On the other hand, porting modern tools to my PDP 11/23 running 2.9BSD is a total non-starter for reasons that I am sure I do not have to elaborate upon here.

-Henry

[-- Attachment #2: Type: text/html, Size: 3080 bytes --]

      reply	other threads:[~2019-10-13 22:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-13 13:53 Richard Tobin
2019-10-13 14:57 ` arnold
2019-10-13 18:46 ` William Corcoran
2019-10-13 19:36   ` Henry Bent
2019-10-13 22:30     ` William Corcoran [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=580AE12E-384E-4C13-9EA3-F9E53A2CC4C3@jctaylor.com \
    --to=wlc@jctaylor.com \
    --cc=henry.r.bent@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).