Re: [TUHS] Systematic approach to command-line interfaces

["Greg A. Woods" <woods@robohack.ca>]

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

At Tue, 28 Sep 2021 11:10:16 -0700, Larry McVoy <lm@mcvoy.com> wrote:
Subject: Re: [TUHS] Systematic approach to command-line interfaces
>
> On Tue, Sep 28, 2021 at 10:46:25AM -0700, Greg A. Woods wrote:
> > The "unix" nod to
> > single level storage by way of mmap() suffers from horribly bad design
> > and neglect.
>
> So what is it about mmap you don't like?

Mmap() as we have it today almost completely ignores the bigger picture
and the lessons that came before it.

It was an add-on hack that basically said only "Oh, Yeah, we can do that
too!  Look at this." -- and nobody bothered to look for decades.

For one it has no easy direct language support (though it is possible in
C to pretend to use it directly, though the syntax often gets cumbersome).

Single-level-storage was obviously designed into Multics from the
beginning and from the ground up, and it was easily used in the main
languages supported on Multics -- but it was just an add-on hack in Unix
(that, if memory serves me correctly, was initially only poorly used in
another extremely badly designed add-on hack that didn't pay any
attention whatsoever to past lessons, i.e. dynamic linking. which to
this day is a horror show of inefficiencies and bad hacks).

I think perhaps the problem was that mmap() came too soon in a narrow
sub-set of the Unix implementations that were around at the time, when
many couldn't support it well (especially on 32-bit systems -- it really
only becomes universally useful with either segments or 64-bit and
larger address spaces).  The fracturing of "unix" standards at the time
didn't help either.

Perhaps these "add-on hack" problems are the reason so many people think
fondly of the good old Unix versions where everything was still coming
from a few good minds that could work together to build a cohesive
design.  The add-ons were poorly done, not widely implemented, and
usually incompatible with each other when they were adopted by
additional implementations.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]