On Mon, Aug 2, 2021 at 5:19 PM Jon Steinhart <jon@fourwinds.com> wrote:

> John Cowan writes:
> > > fork() is a great model for a single-threaded text processing pipeline
> to
> > > do automated typesetting.  (More generally, anything that is a
> > > straightforward composition of filter/transform stages.)  Which is,
> y'know,
> > > what Unix is *for*.
> > >
> >
> > Indeed.  But it's also a very good model for "baking" web pages in the
> > background so that you can serve them up with a plain dumb web server,
> > maybe with a bit of JS to provide some auto-updating, especially if the
> > source data is stored not in a database but in the file system.  The
> result
> > is a page that displays (modulo network latency) as fast as you can hit
> the
> > Enter key in the address bar.
> >
> > (The weak point is the lack of dependency management when the system is
> too
> > big to rebake all the pages each time.  Perhaps make(1), which Alex Shinn
> > described as "a beautiful little Prolog for the file system", is the
> Right
> > Thing.)
>
> We have, of course, had similar discussions many times on this list.
> I think that the root issue is the false equivalence of "I don't
> understand this well enough to be able to use it effectively to solve
> my problem" with "it's broken/obsolete/dated".
>

That's a bit unfair. One can understand something and see value in it and
still appreciate its limitations.

Fork has served us well for more than five decades; I've got no argument
with that. However, should we never question whether it continues to be the
right, or best, abstraction as the environment around it continues to
evolve?

        - Dan C.